B. Vocabulary

5. Give Russian equivalents of the following words and expressions:

suite; routine; clipboard; ingenuity; middleware; ordered se- quence; retailer; debugger; template;

arbitrary; stand-alone; iteratively;

bundle; encompass; extract; insulate; paste; precede; endeavour; tailor.

6. Find the word belonging to the given synonymic group among the words and word combinations from the previous exercise:

1. cleverness, inventiveness, skill, creativity;

2. try; attempt, make an effort;

3. random, chance, subjective;

4. insert, attach, fix, stick;

5. set, group, collection;

1. supplied complete/as complete (with), furnish (with), deliver factory-assembled;

6. vendor, seller, trader, dealer;

2. separate, unconnected, unrelated, autonomous, individual, detached;

7. convert, develop, adapt, modify, fit;

10. pattern, model, sample, shape;

11. cover, include, take in;

12. fetch, retrieve, unload, get;

13. go before, come first, pave the way, head;

14. separate, detach, part, isolate, cut off;

7. Translate the words/expressions into English:

предшествовать; произвольный, случайный; розничный тор- говец; многократно; связующее ПО; отделять; подпрограмма; автономный; охватывать; (программный) комплект; вставить; упорядоченная последовательность; извлекать; шаблон, трафа-

100 —

101 ——

рет; разрабатывать, адаптировать; буфер обмена; пытаться, ста- раться; отладчик; поставлять комплектно; изобретательность.

С. Reading and Discussion

8. Study the words and explain their meanings. Read the text. Deter- mine the expression 'software quality'. Enumerate software quality factors and characterize them.

measure source code consequences

conventions update consistency

notation maintainability evaluation

robustness vague withstand

authentication encryption relevant

Software Quality

In the context of software engineering, software quality measures how well software is designed (quality of design), and how well the software conforms to that design (quality of conformance), although there are several different definitions.

One of the problems with Software Quality is mat «everyone feels tiiey understand it.» In addition to the definition above by Dr. Roger S. Pressman, other software engineering experts have given several definitions.

A definition, in Steve McConnell's Code Complete similarly divides software into two pieces: internal and external quality charac- teristics. External quality characteristics are those parts of a product that face its users, where internal quality characteristics are mose that do not.

Anomer definition by Dr. Tom DeMarco says: «A product's qual- ity is a function of how much it changes the world for the better.» This can be interpreted as meaning that user satisfaction is more important than anything in determining software quality.

Anomer definition, coined by Gerald Weinberg in Quality Soft- ware Management: Systems Thinking, is «Quality is value to some person.» This definition stresses that quality is inherently subjective — different people will experience the quality of the same software very differently. One strength of mis definition is the questions it invites software teams to consider, such as «Who are the people we want to value our software?» and «What will be valuable to them?»

102

Source code quality ?' TO -a computer, there is no real concept of «well-written» source .•66dl. However,'to a human, the way a program is written can have s«ine important txmsequences for me hAimanmaintainers. Many source eode progranmmg style guides, which stress readability and some language-specific conventions are aimed at the maintenance of me Software source code, which involves debugging and updating. Other itfsues also come into considering whether code is well written, such as me logical structuring of die code into more manageable sections.

Readability , Ease of maintenance, testing, debugging, fixing, modification apd portability

Low complexity

Low resource consumption: memory, CPU

Number of compilation or lint warnings

Software Quality Factors

A software quality factor is a non-functional requirement for a software program which is not called up by ию customer's contract, but is nevertheless desirable and enhances the quality of the software program.

Some software quality factors are:

• Understandability

The purpose of the software product is clear. This goes further man just a statement of purpose — all of the design and user docu- mentation must be clearly written so mat it is easily understandable. Obviously, the user context must be taken into account, e.g. if the software product is to be used by software engineers it is not required to be understandable to lay users.

• Completeness

All parts of the software product are present and each of its parts are fully developed. For example, if the code calls a sub-routine from an external library, the software package must provide reference to mat library and all required parameters must be passed. All required input data must be available.

• Conciseness

No excessive information is present. This is important where memory capacity is limited, and it is important to reduce lines of code to a minimum. It can be improved by replacing repeated functionality by one sub-routine or function which achieves mat functionality. This quality factor also applies to documentation.

103

• Portability

The software product can be easily operated or made to operate on multiple computer configurations. This can be between multiple hardware configurations (such as server hardware and personal com- puters), multiple operating systems (e.g. Microsoft Windows and Linux-based operating systems), or both.

• Consistency

The software contains uniform notation, symbology and terminol- ogy within itself.

• Maintainability

The product facilitates updating to satisfy new requirements. The software product that is maintainable is simple, well-documented, and should have spare capacity for processor memory usage.

• Testability

The software product facilitates the establishment of acceptance criteria and supports evaluation of its performance. Such a character- istic must be built-in during the design phase if the product is to be easily testable, since a complex design leads to poor testability.

• Usability

The product is convenient and practicable to use. The component of the software which has most impact on this is the user interface (UI), which for best usability is usually graphical.

• Reliability

The software can be expected to perform its intended functions satisfactorily over a period of time. Reliability also encompasses en- vironmental considerations in that the product is required to perform correctly in whatever conditions it is operated in; this is sometimes termed robustness.

• Structure

The software possesses a definite pattern of organization in its constituent parts.

• Efficiency

The software product fulfills its purpose without wasting re- sources, e.g. memory or CPU cycles.

• Security

The product is able to protect data against unauthorized access and to withstand malicious interference with its operations. Besides the presence of appropriate security mechanisms such as authentication,

— 104 —

access control and encryption, security also implies reliability in the face of malicious, intelligent and adaptive attackers.

9. Read the text. Divide it into parts and give the title to each of them. Make a summary of the text.

Software Reliability and Testing

An important facet of software quality is software reliability. It is defined as «the probability of failure-free operation of a computer program in a specified environment for a specified time».

One of reliability's distinguishing characteristics is that it is objec- tive, measurable, and can be estimated, whereas much of software quality consists of subjective criteria. This distinction is especially important in the discipline of Software Quality Assurance. These measured criteria are typically called software metrics.

With software embedded into many devices today, software failure has caused more than inconvenience. Software errors have even caused human fatalities. The causes have ranged from poorly designed user interfaces to direct programming errors. An example of a programming error that lead to multiple deaths is discussed in Dr. Leveson's paper. This has resulted in requirements for development of some software types. In the United States, both the Food and Drug Administration (FDA) and Federal Aviation Administration (FAA) have requirements for software development.

The need for a means to objectively determine software quality comes from die desire to apply the techniques of contemporary engi- neering fields to the development of software. That desire is a result of the common observation, by both lay-persons and specialists, that computer software does not work the way it ought to. In other words, Software is seen to exhibit undesirable behavior, up to and including outright failure, with consequences for the data which is processed, the machinery on which die software runs, and by extension the people and materials which those machines might negatively affect. The more critical the application of the software to economic and production processes, or to life-sustaining systems is, the more important is the need to assess the software's reliability.

Regardless of the criticality of any single software application, it is also more and more frequently observed that software has penetrated

105-^

deeply into most every aspect of modern life through the technology we use. It is only expected that this infiltration will continue, along with an accompanying dependency on the software by the systems which maintain our society. As software becomes more and more crucial to the operation of the systems on which we depend, the argument goes, it only follows that the software should offer a concomitant level of dependability. In other words, the software should behave in the way it is intended, or even better, in the way it should.

The circular logic of the preceding sentence is not accidental — it is meant to illustrate a fundamental problem in the issue of measuring software reliability, which is the difficulty of determining, in advance, exactly how the software is intended to operate. The problem seems to stem from a common conceptual error in the consideration of software, which is that software in some sense takes on a role which would otherwise be filled by a human being. This is a problem on two levels. Firstly, most modern software performs work which a human could never perform, especially at the high level of reliability that is often expected from software in comparison to humans. Secondly, software is fundamentally incapable of most of the mental capabilities of humans which separate them from mere mechanisms: qualities such as adaptability, general-purpose knowledge, a sense of conceptual and functional context, and common sense.

Nevertheless, most software programs could safely be considered to have a particular, even singular purpose. If the possibility can be allowed that said purpose can be well or even completely defined, it should present a means for at least considering objectively whether the software is, in fact, reliable, by comparing the expected outcome to the actual outcome of running the software in a given environment, with given data. Unfortunately, it is still not known whether it is possible to exhaustively determine either the expected outcome or the actual outcome of the entire set of possible environment and input data to a given program, without which it is probably impossible to determine the program's reliability with any certainty.

However, various attempts are in the works to attempt to rein in the vastness of the space of software's environmental and input variables, both for actual programs and theoretical descriptions of programs. Such attempts to improve software reliability can be ap- plied at different stages of a program's development, in the case of real software. These stages principally include: requirements, design,

— 106

programming, testing, and run time evaluation. The study of theoreti- cal software reliability is predominantly concerned with the concept of correctness, a mathematical field of computer science which is an outgrowth of language and automata, theory.

A program cannot be expected to work as desired if the developers of the program do not, in fact, know the program's desired behavior in advance, or if they cannot at least determine its desired behavior in parallel with development, in sufficient detail. What level of detail is considered sufficient is hotly debated. The idea of perfect detail is attractive, but may be impractical, if not actually impossible, in practice. This is because the desired behavior tends to change as the possible range of the behavior is determined through actual attempts, or more accurately, failed attempts, to achieve it.

Whether a program's desired behavior can be successfully speci- fied in advance is a moot point if the behavior cannot be specified at all, and this is the focus of attempts to formalize the process of creating requirements for new software projects. In situ with the formalization effort is an attempt to help inform non-specialists, particularly non- programmers, who commission software projects without sufficient knowledge of what computer software is in fact capable. Communicat- ing this knowledge is made more difficult by the fact that, as hinted above, even programmers cannot always know in advance what is actually possible for software in advance of trying.

While requirements are meant to specify what a program should do, design is meant, at least at a high level, to specify how the program should do it. The usefulness of design is also questioned by some, but those who look to formalize the process of ensuring reliability often offer good software design processes as the most significant means to accomplish it. Software design usually involves the use of more abstract and general means of specifying the parts of the software and what they do. As such, it can be seen as a way to break a large program down into many smaller programs, such that those smaller pieces together do me work of the whole program.

The purposes of high-level design are as follows. It separates what are considered to be problems of architecture, or overall program concept and structure, from problems of actual coding, which solve problems of actual data processing. It applies additional constraints to the development process by narrowing the scope of the smaller soft- ware components, and diereby — it is hoped — removing variables

107 —-

which could increase the likelihood of programming errors. It provides a program template, including the specification of interfaces, which can be shared by different teams of developers working on disparate parts, such that they can know in advance how each of their contribu- tions will interface with those of the other teams. Finally, and perhaps most controversially, it specifies the program independently of the implementation language or languages, thereby removing language- specific biases and limitations which would otherwise creep into the design, perhaps unwittingly on the part of programmer-designers.

Software testing, when done correctly, can increase overall soft- ware quality of conformance by testing that the product conforms to its requirements. Testing includes, but is not limited to:

Unit Testing

Functional Testing

Performance Testing

Fail over Testing

Usability Testing

A number of agile methodologies use testing early in the develop- ment cycle to ensure quality in their products. For example, die test- driven development practice, where tests are written before the code tiiey will test, is used in Extreme Programming to ensure quality.

Run time reliability determinations are similar to tests, but go beyond simple confirmation of behavior to the evaluation of qualities such as performance and interoperability with odier code or particular hardware configurations.

facet, estimate, assurance, lay(-)person, outright, sustain, penetrate, concomitant, sufficient, moot point, in situ, disparate, confirmation

10. Read the text and answer the questions: 1) What are the rights that software license gives the user? 2) Why is the issue of software patents controversial? State your opinion concerning hacker ethic.

Ethics and Rights for Software Users

License. Software license gives the user me right to use the software in the licensed environment, some software comes with me license when purchased off the shelf, or an OEM license when bundled

with hardware. Other software comes with a free software license, granting the recipient the rights to modify and redistribute the software. Software can also be in the form of freeware or shareware.

Patents. The issue of software patents is controversial. Some believe that they hinder software development, while others argue mat software patents provide an important incentive to spur software innovation.

Being a new part of society, the idea of what rights users of software should have is not very developed. Some, such as the free software community, believe that software users should be free to modify and redistribute the software they use. They argue that mese rights are necessary so that each individual can control tiieir computer, and so that everyone can cooperate, if they choose, to work together as a community and control me direction that software progresses in. Others believe that software authors should have me power to say what rights the user will get.

The former philosophy is somewhat derived from the «hacker ethic».

Hacker ethic refers to the values and philosophy that are stand- ard in me hacker community. The early hacker culture and resulting philosophy originated at the Massachusetts Institute of Technology (MIT) in the 1950s and 1960's. The term 'hacker ethic' is attributed to journalist Steven Levy as described in his book titled 'Hackers: Heroes of the Computer Revolution', written in 1984.

While some tenets of hacker ethic were described in other texts like 'Computer Lib/Dream Machines' (1974) by Theodor Nelson, Levy appears to have been the first to document and historicize both the philosophy and me founders of the philosophy.

As Levy stated in the preface the general tenets or principles of hacker ethic include:

Sharing

Openness

Decentralization

Free access to computers

World Improvement

According to Levy's account, sharing was the norm and expected within the non-corporate hacker culture. The principle of sharing stemmed from the atmosphere and resources at MIT. During the early days of computers and programming (when computers were the

-—108 —

-—109 —

size of whole rooms), the hackers at MIT would develop a program and share it.

If the hack was particularly good, then the program might be posted on a board somewhere near one of the computers. Other pro- grams that could be built upon and improved were saved to tapes and added to a drawer of programs — readily accessible to all the other hackers. At any time, a fellow hacker might reach into the drawer, pick out the program, and begin adding to it or «bumming» it to make it better (bumming refers to the process of making the code more concise so that more can be done in fewer instructions).

In the second generation of hackers, sharing was about sharing with the general public in addition to sharing with other hackers. A particular organization of hackers that was concerned with sharing computers with the general public was a group called Community Memory. This group of hackers and idealists put computers in public places for anyone to use. The first community computer was placed outside of Leopold's Records in Berkeley, California.

Another sharing of resources occurred when Bob Albrecht provided considerable resources for a non-profit organization called People's Computer Company (PCC). PCC opened a computer center where anyone could use the computers there for fifty cents an hour.

It was also the sharing of this second generation that resulted in some of the battles over free and open software. In fact, when Bill Gates' version of BASIC for the Altair was 'shared' among the hacker community, Gates lost a considerable sum of money because no one was paying for the software. As a result, Gates wrote an Open Letter to Hobbyists. This letter was published by several computer magazines and newsletters — most notably that of the Homebrew Computer Club where much of the sharing occurred.

Hands-On Imperative

Many of the principles and tenets of Hacker. Ethic contribute to a common goal — the Hands-On Imperative.

Employing the Hands-On Imperative requires free access, open information, and the sharing of knowledge. To a true hacker, if the Hands-On Imperative is restricted, then the ends justify the means to make it unrestricted so that improvements can be made. When these principles are not present, hackers tend to work around them. For example, when the computers at MIT were protected either by physi-

cal locks or login programs, the hackers there systematically worked around them in order to have access to the machines.

It is important to note that this behavior was not malicious in nature — the MIT hackers did not seek to harm the systems or then- users (although, every now and then, some practical jokes were played using the computer systems). This deeply contrasts with me modern, media-encouraged image of hackers who crack secure systems in order to steal information or complete an act of cybervandalism.

Community and Collaboration

Throughout writings about hackers and their work processes, a common value of community and collaboration is present. For exam- ple, in Levy's Hackers, each generation of hackers had geographically- based communities where collaboration and sharing occurred. For the hackers at MIT, it was the labs where the computers were running. For the hardware hackers (second generation) and the game hackers (third generation) the geographic area was centered in Silicon Valley where the Homebrew Computer Club and the People's Computer Company helped hackers network, collaborate, and share their work.

The concept of community and collaboration is still relevant today, although hackers are no longer limited to collaboration in geographic regions. Now collaboration takes place via the Internet. Eric S. Raymond identifies and explains this concept shift in «The Cathedral and the Bazaar».

New Hacker Ethic

While it might.be convenient to label the current shared values of hackers as the «New Hacker Ethic», this type of identification implies a radical shift in hacker ethic. While the nature of hacker activity has evolved due to the availability of new technologies (for example, the mainstreaming of the personal computer or the social connectivity of die internet), the hacker ethics — particularly those of access, shar- ing, and community — remain the same.

Other Descriptions of Hacker Ethic

Later in 2001, Finnish philosopher Pekka Himanen promoted the hacker ethic in opposition to the Protestant work ethic. In Himanen's

110

111 —

opinion the hacker ethic is more closely related to the virtue ethics found in the writings of Plato and of Aristotle.

Free Software, Open Source Software, and Hacker Ethic

Free open source software is the modern day descendant of the hacker ethics that Levy described. The hackers who hold true to me hacker ethics listed above — especially the Hands-On Impera- tive — are usually supporters of the either free software and open source software. This is because free and open source software allows hackers to access the code used to create the software to improve or reuse it. In effect the free and open source software movements embody all of the hacker ethics.

shareware, controversial, incentive, spur, hands-on, imperative, restrict, justify, collaboration

11. Reproduce the text in English, emphasizing the information not mentioned in the English texts. Use the words at the bottom.

Программное обеспечение (ПО) — наряду с аппаратными средствами, важнейшая составляющая информационных тех- нологий, включающая компьютерные программы и данные, предназначенные для решения определенного круга задач и хранящиеся на машинных носителях. Программное обеспечение представляет собой либо данные для использования в других программах, либо алгоритм, реализованный в виде последова- тельности инструкций для процессора.

В компьютерном жаргоне часто используется слово «софт» от английского software, которое в этом смысле впервые при- менил в статье American Mathematical Monthly математик из Принстонского университета Джон Тьюки (John W. Tukey) в 1958 г. В области вычислительной техники и программи- рования программное обеспечение — это совокупность всей информации, данных и программ, которые обрабатываются компьютерными системами.

Классификация ПО

• По способу распространения (доставки, оплаты, ограни- чения в использовании):

Commercial Software, Freeware, Shareware, Abandonware, Adware, Free Software, Careware...

• По назначению ПО разделяется на системное, прикладное и инструментальное.

Системное программное обеспечение — это комплекс программ, которые обеспечивают эффективное управление компонентами вычислительной системы, такими как процессор, оперативная память, каналы ввода-вывода, сетевое и коммуни- кационное оборудование и т.п. Системное программное обеспе- чение реализует связь аппаратного и программного обеспечения, выступая как «межслойный интерфейс», с одной стороны кото- рого аппаратура, а с другой приложения пользователя. В состав системного программного обеспечения входят: операционные системы, среды программирования (компиляторы, трансляторы, компоновщики, загрузчики, отладчики, текстовый редактор, библиотеки подпрограмм), утилиты, системы управления фай- лами и системы управления базами данных.

Кроме системного программного обеспечения принято вы- делять прикладное программное обеспечение, которое призвано решать прикладные задачи пользователя.

Классификация прикладного программного обеспечения

• Прикладное программное обеспечение предприятий и организаций. Например, финансовое управление, систе- ма отношений с потребителями, сеть поставок. К этому типу относится также ведомственное ПО предприятий малого бизнеса, а также ПО отдельных подразделений внутри большого предприятия. (Примеры, Управление транспортными расходами, Служба IT поддержки)

• Программное обеспечение инфраструктуры предприятия. Обеспечивает общие возможности для поддержки ПО предприятий. Это базы данных, серверы электронной почты, управление сетью и безопасностью.

• Программное обеспечение информационного работника. Обслуживает потребности индивидуальных пользова-

-112 —

—■— 113 —■—

тел ей в создании и управлении информацией. Это, как правило, управление временем, ресурсами, докумен- тацией, например, текстовые редакторы, электронные таблицы, программы-клиенты для электронной почты и блогов, персональные информационные системы и медиа-редакторы.

• Программное обеспечение для доступа к контенту. Ис- пользуется для доступа к тем или иным программам или ресурсам без их редактирования (однако может и включать функцию редактирования). Предназначено для групп или индивидуальных пользователей цифрового контента. Это, например, медиа-плееры, веб-браузеры, вспомогательные браузеры и др.

• Образовательное программное обеспечение по содер- жанию близко к ПО для медиа и развлечений, однако в отличие от него имеет четкие требования по тестиро- ванию знаний пользователя и отслеживанию прогресса в изучении того или иного материала. Многие образо- вательные программы включают функции совместного пользования и многостороннего сотрудничества.

• Имитационное программное обеспечение. Используется для симуляции физических или абстрактных систем в це- лях научных исследований, обучения или развлечения.

• Инструментальные программнью средства в области медиа. Обеспечивают потребности пользователей, которые произ- водят печатные или электронные медиа-ресурсы для других потребителей, на коммерческой или образовательной осно- ве. Это программы полиграфической обработки, верстки, обработки мультимедиа, редакторы HTML, редакторы цифровой анимации, цифрового звука и т.п.

• Прикладные программы для проектирования и констру- ирования. Используются при разработке аппаратного («Железо») и программного обеспечения. Охватывают автоматизированный дизайн (computer aided design — CAD), автоматизированное проектирование (computer aided engineering — CAE), редактирование и компили- рование языков программирования, программы интег- рированной среды разработки (Integrated Development

Environments), интерфейсы для прикладного програм- мирования (Application Programmer Interfaces).

Инструментальное программное обеспечение — програм- мное обеспечение, предназначенное для использования в ходе проектирования, разработки и сопровождения программ. Обычно этот термин применяется для акцентирования отличия данного класса ПО от прикладного и системного программного обеспечения.

Виды инструментального ПО:

текстовые редакторы

интегрированные среды разработки

SDK

компиляторы

интерпретаторы

линковщики

парсеры и генераторы парсеров (см. Javacc)

ассемблеры

отладчики

профилировщики

генераторы документации

средства анализа покрытия кода

средства непрерывной интеграции

средства автоматизированного тестирования

системы управления версиями

и др.

Лингвистическое программное обеспечение (англ. lingware = linguistic + software) — компьютерные программы и данные, обеспечивающие анализ, обработку, хранение и поиск аудиодан- ных, рисунков (OCR) и текстов на естественном языке.

Можно выделить следующие виды лингвистического про- граммного обеспечения:

обработка текста на естественном языке:

электронные словари: Викисловарь, Multitrans, ForceMem и др.

орфокорректоры (или спеллчекеры): MS Word, ispell, aspell, myspell и др.

поисковые системы

системы машинного перевода: Socrat, Stylus и др.

системы распознавания символов OCR: Fine reader.

114

— 115

i,b

речевые системы:

системы анализа речи: Dragon, IBM via voice, системы синтеза речи: Агафон.

системы голосового перевода (распознавание и синтез): Speereo.

текстовый редактор — editor, text editor; вспомогательный — auxiliary, AUX, secondary; развлечение — amusement, entertainment; верстка — page-proof; профилировщик — profiler; непрерыв- ный — continuous; распознавание — recognition

12. Talking points:

1. Computer software: definition, major classes.

2. Computer software operation.

3. Software quality.

4. Software reliability and testing.