«Учебно-методическое пособие по дисциплине Технологические подходы к разработке программного обеспечения Новиков Ф.А., канд. физ.-мат. наук, доцент кафедры Технологии программирования Санкт-Петербург 2007 УМП ...»

УМП Технологические подходы к разработке ПО 1

Санкт-Петербургский государственный университет информационных технологий,

механики и оптики

Учебно-методическое пособие

по дисциплине

«Технологические подходы к разработке

программного обеспечения»

Новиков Ф.А.,

канд. физ.-мат. наук, доцент кафедры «Технологии программирования»

Санкт-Петербург 2007 УМП Технологические подходы к разработке ПО 2 Оглавление  Введение

Цели и задачи дисциплины

Связь с другими дисциплинами

Структура и особенности курса

Тема 1. Технология программирования

1.1. Назначение технологии программирования

1.2. История развития технологии программирования

1.2.1. Дореволюционный период

1.2.2. «Революция в программировании»

1.2.3. Послереволюционный период

1.3. Типы программных проектов

1.4. Составные части технологии программирования

1.5. Проект, продукт, процесс и персонал

Тема 2. Жизненный цикл программы

2.1. Циклический характер разработки

2.2. Основные понятия технологии программирования

2.2.1. Процессы и модели

2.2.2. Фазы и витки

2.2.3. Вехи и артефакты

2.2.4. Заинтересованные лица и работники

2.3. Выявление и анализ требований

2.3.1. Требования к программному обеспечению

2.3.2. Схема разработки требований

2.3.3. Управление требованиями

2.4. Архитектурное и детальное проектирование

2.4.1. Архитектурное проектирование

2.4.2. Детальное проектирование

2.5. Реализация и кодирование

2.6. Тестирование и верификация

2.6.1. Процесс контроля качества

2.6.2. Методы «белого ящика» и «черного ящика»

2.6.3. Инспектирование и обзоры

2.6.4. Цели тестирования

2.6.5. Верификация, валидация и системное тестирование

2.7. Сопровождение и продолжающаяся разработка

Тема 3. Модели процесса разработки

3.1. Водопадные и конвейерные модели

3.2. Спиральные и инкрементные модели

3.3. Гибкие модели процесса разработки

3.4. Конструирование модели процесса

3.4.1. Выявление требований к процессу

3.4.2. Используемые фазы, вехи и артефакты

3.4.3. Выбор архитектуры процесса

3.4.4. Порядок проведения типового проекта

3.4.5. Документированные процедуры

3.4.6. Выводы

Тема 4. Модели команды разработчиков

4.1. Коллективный характер разработки

УМП Технологические подходы к разработке ПО 4.1.1. Оптимальный размер команды

4.1.2. Подчиненность участников проекта

4.1.3. Развитие команды и развитие персонала

4.1.4. Специализация, кооперация и взаимодействие

4.2. Иерархическая модель команды

4.3. Метод хирургической бригады

4.4. Модель команды равных

4.5. Конструирование модели команды

4.5.1. Особенности организации и требования к команде

4.5.2. Архитектура модели команды

4.5.3. Функции, роли и должности

4.5.4. Статико-динамическая структура команды

4.5.5. Распределение полномочий и ответственности

4.5.6. Достоинства и недостатки модели команды

Тема 5. Дисциплина программирования

5.1. Природа программирования

5.1.1. Наука программирования

5.1.2. Искусство программирования

5.1.3. Ремесло программирования

5.2. Парадигмы программирования

5.2.1. Структурное программирование

5.2.2. Логическое программирование

5.2.3. Объектно-ориентированное программирование

5.3. Циклы повышения продуктивности

5.3.1. Продуктивность программирования

5.3.2. Спецификации и модели

5.4. Программная архитектура

5.4.1. Событийное управление

5.4.2. Архитектура клиент/сервер

5.4.3. Службы

5.4.4. Трехслойная архитектура

5.5. Проектирование программ

5.5.1. Концептуальное проектирование

5.5.2. Логическое проектирование

5.5.3. Детальное проектирование

5.6. Кодирование

5.6.1. Программирование по образцу

5.6.2. Образцы проектирования

5.6.3. Доказательное программирование

5.6.4. Программирование вширь

5.6.5. Форматирование кода

5.7. Тестирование и отладка

5.7.1. Критерии приемлемости

5.7.2. Виды тестирования

5.7.3. Методы отладки

5.8. Инструментальные средства

5.9. Выводы

Предметный указатель

Литература

Совокупность известных технологических подходов к разработке программного обеспечения, или, несколько короче, технология программирования, является инженерной дисциплиной, входящей в обязательный набор знаний и умений всякого инженера, причастного к созданию и эксплуатации программного обеспечения компьютеров. Технология программирования имеет четко выделенный объект изучения – процессы разработки и сопровождения программного обеспечения, но, в настоящее время, не имеет единого метода и общепринятого способа построения. Технология программирования не является строгой математической дисциплиной, которую можно изложить последовательно, начиная с основополагающих понятий и применяя дедуктивные доказательства. Напротив, технология программирования является собранием разнородных и часто несогласованных друг с другом моделей, методик и средств. Детально изложить все используемые в технологии программирования приемы в рамках одного курса невозможно – их разнообразие слишком велико. Кроме того, технологические приемы разработки программного обеспечения очень быстро меняются, почти каждые полгода предлагаются новые подходы, и всякое изложение конкретных технологических решений в рамках учебного курса заведомо отставало бы от практики их применения в реальной жизни.

Вместо малопродуктивной попытки «объять необъятное», в данном курсе излагаются основные понятия, в терминах которых обычно формулируются реально используемые (и непрерывно обновляющиеся!) технологические модели, и приводятся некоторые примеры конструирования таких моделей. Прослушав данный курс, студент будет понимать, как строятся различные конкретные технологии программирования и, столкнувшись на практике с конкретной технологией, сможет ее понять, настроить и применить «по месту».

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

Кроме того, данная дисциплина должна содействовать расширению кругозора и развитию системного мышления студентов.

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

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

Данная дисциплина является вводной в цикле дисциплин, охватывающих различные аспекты инженерии программного обеспечения. Здесь вводится специфическая терминология, во всей общности рассматриваются основные понятия технологии программирования, даются ссылки на главные нормативные документы, приводятся обзоры различных разделов инженерии программного обеспечения, которые более детально рассматриваются в последующих курсах.

Курс имеет следующую структуру.

В первой теме рассматривается сам предмет дисциплины – технология программирования – с самых общих позиций. Здесь же вводится разделение технологии программирования на три составляющих, в соответствии с которой строится изложение курса.

Во второй теме вводится понятие жизненного цикла программы – ключевой абстракции, вокруг которой строятся все известные в настоящее время технологические подходы к программированию.

Темы с третьей по пятую раскрывают более детально составляющие технологии программирования, введенные в первой теме.

Обзорный характер изложения является важной особенностью курса. В курсе затрагивается множество разнообразных вопросов и используется большое число разнородных понятий. Центральные понятия определяются прямо в курсе, но отнюдь не все. Поэтому очень важной частью курса является изучение студентами дополнительной литературы. Такое «домашнее чтение» является основой самостоятельной и практической работы студентов в этом курсе.

Тема 1. Технология программирования Процесс создания программ для компьютеров обычно называют программированием. Однако этим же словом часто обозначают и другие виды человеческой деятельности. Например, «математическое программирование» – раздел математики, или «политическое программирование» – словосочетание, которое нетрудно встретить в средствах массовой информации. Если речь идет именно о создании программ для компьютеров, то во избежание неоднозначности используют оборот разработка программного обеспечения. В этом курсе слово программирование используется только в смысле «процесс разработки программного обеспечения», а потому для краткости и удобочитаемости везде, где это возможно, используется термин «программирование» как синоним оборота «процесс разработки программного обеспечения».

Программирование (computer programming) — это процесс создания программистом (человеком) программы (информационной структуры), предназначенной для последующего исполнения (компьютером).

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

Таким образом, в процессе программирования присутствуют явно субъект, объект и цель.

В типичном (и привычном) случае субъектом является человек, который ведет процесс осознанно, объектом является текст на формальном языке, а целью является такое выполнение программы, которое в свою очередь имеет явно обозначенную цель. Далее, если явно не оговорено противное, подразумевается именно этот типичный случай.

Замечание Спектр вариантов процесса программирования отнюдь не исчерпывается рассматриваемым типичным случаем. Например, программирующим субъектом может быть не человек, а другая программа (автоматический синтез программы по формальным спецификациям или по примерам), процесс программирования может быть не осознан (запись макроса с помощью макрорекордера). Программа может быть выражена на нелинейном языке (нейрокомпьютер) или же не иметь материального носителя (план действий в голове пользователя графического интерфейса). Целью программирования может быть публикация текста программы (а не получение результата ее выполнения) или получение невыполнимой программы (защита от несанкционированного копирования).

В настоящее время эффективность и результативность программирования в целом оставляет желать лучшего. Несмотря повсеместное распространение компьютеров и очевидное улучшение их программного обеспечения, остается весьма значительной доля проектов по разработке программного обеспечения, которые нельзя считать вполне успешными. Наряду с эффектными достижениями имеются и сравнительно многочисленные досадные неудачи. К сожалению, до сих пор слишком часто приходится делать вывод, что программирование рискованно, программы ненадежны, а программисты неуправляемы.

1.1. Назначение технологии программирования Проблемы в области программирования существуют, и отрицать это невозможно. Лучшие программисты, ведущие предприятия и компьютерное сообщество в целом постоянно тратят значительные и все возрастающие усилия на решение этих проблем. В результате в общем поле компьютерных наук выделились и дифференцировались различные дисципУМП Технологические подходы к разработке ПО лины. Дисциплина, которая направлена, прежде всего, на решение внутренних проблем программирования, получила название технологии программирования, или инженерии программных систем. Последний термин является точным переводом английского термина software engineering.

Технология программирование (software engineering) – это совокупность методов и средств, позволяющая наладить производственный процесс создания программного обеспечения.

В этом определении особо следует подчеркнуть слово «производственный», которое отражает важнейшую особенность технологии программирования. Например, в официальном определении родственной дисциплины – информатики (computer science) указание на производственный характер дисциплины отсутствует.

Информатика (computer science) – это дисциплина, изучающая общие свойства информации, а также вопросы, связанные с ее сбором, хранением и обработкой.

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

Соотношение технологии программирования (software engineering) и информатики (computer science) трудно описать в двух словах. Информатика – более общее понятие, но считать технологию программирования просто частью информатики было бы не совсем верно. В современной практике применения этих отраслей знания те вопросы, которые имеют преимущественно теоретический характер, принято относить к информатике, а сугубо практические приемы принято считать элементами технологии программирования. Например, методы математического доказательства правильности программ обычно относят к теоретической информатике, а методы тестирования – к технологии программирования, хотя это различные методы решения одной и той же задачи. Конечно, это отделение технологии программирования от информатики несколько условно и строгой границы здесь нет, но тенденция очевидна.

1.2. История развития технологии программирования Программирование – сравнительно молодая область человеческой деятельности. Как массовая профессия программирование существует около полувека, и этот срок намного меньше, чем история развития других инженерных дисциплин. Неудивительно, что программирование еще не избавилось от многих «детских болезней», характерных для всех новых видов человеческой деятельности. Но программирование развивается стремительно, а детские болезни быстро проходят.

В истории технологии программирования происходило множество событий, предлагалась и предлагается масса идей. Чтобы как-то систематизировать эти факты, мы предлагаем следующую классификацию.

Все факты истории технологии программирования делятся на три класса, которые приближенно соответствуют трем периодам.

С момента начала промышленной разработки программного обеспечения и до середины шестидесятых годов XX века вопросы собственно технологии программирования рассматривались, как правило, не отдельно, а в связи и в совокупности с другими вопросами программирования. Разумеется, технологические проблемы существовали, и предлагались методы их решения, но это не было предметом публичных общественных дискуссий.

Компьютеры были дороги, их количество было невелико, и применялись они, в основном, для специальных целей (оборона, космос и т.п.). Следует подчеркнуть, что в это время программирование не являлось массовой профессий, и было, в основном уделом талантливых и высокообразованных одиночек, специалистов в той предметной области, где применялись компьютеры. Можно сказать, что хотя программирование и было высоко профессиональным, оно не было промышленным.

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

К середине шестидесятых годов ситуация изменилась. Компьютеры стали дешевле, компактнее и производительнее. Сфера применения существенно расширилась, они стали в массовом порядке применяться в промышленности, науке, образовании. Наряду со сложными и ответственными программами (о самом существовании которых не везде можно было говорить вслух) появились, и в гораздо большем количестве, обычные программы для автоматизации производственной и иной повседневной деятельности.1 Эти обычные программы изготавливались практически в каждой организации, имевшей компьютеры, независимо от основного профиля ее деятельности. Эксплуатация программного обеспечения перестала быть таинством, доступным только посвященным, программирование стало массовой профессией.

Заметим, что общество в целом не сразу осознало социальные последствия происходящего. В это время уже хорошо были известны положительные и отрицательные последствия других видов инженерно-технической деятельности. К проектированию таких изделий, как мосты и самолеты, любители уже не допускались (все понимали, что плохо спроектированный мост может обрушиться, а самолет упасть, и это недопустимо). Проектирование в традиционных инженерных областях велось в соответствии с многочисленными стандартами, правилами, регламентами и инструкциями, в которых число требований к качеству исчисляется сотнями и тысячами. Иное дело программирование: программисты в то время в большинстве своем и не слыхивали о каких-то стандартах качества своей работы.

Да и действительно: подумаешь, программа расчета зарплаты «зависла» — это же не самолет упал!

Но низкая надежность — это только одна сторона проблемы. Хорошая технология не только улучшает качество, она еще и увеличивает производительность. А плохая технология — уменьшает. Отсутствие явно выписанной технологии — это самая плохая технология. В начале шестидесятых технология программирования, в современном понимании и как массовое явление, отсутствовала. Реальная средняя производительность труда была низкой, что хорошо видно из отраслевых нормативов производительности программирования тех лет. Еще хуже дело обстояло с результативностью. Именно тогда были проведены первые методически обоснованные исследования и появились отчеты, из которых следовало, что менее половины проектов по разработке программ являются успешными.2 В средствах массовой информации появились мрачные прогнозы (полученные простой экстраполяцией наблюдаемых значений показателей), что к концу двадцатого века все трудоспособное население будет программировать, и программ будет не хватать. Кризис программирования был налицо.

Очень быстро было предложено множество идей и подходов для выхода из кризиса.

Сейчас такие программы называются бизнес-приложениями.

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

Традиционно принято считать, что «первой ласточкой», положившей начало лавинообразному процессу сотворения технологии программирования, было письмо Э. Дейкстры в журнал Communications of the ACM в 1968 году.3 Очевидно, что письмо Дейкстры подействовало как катализатор, как манифест – за несколько лет были опубликованы, обсуждены и практически внедрены следующие фундаментальные идеи технологии программирования.

• Конструирование программ методом пошагового уточнения.

• Проектирование сверху вниз и снизу вверх.

• Структурное программирование.

• Метод хирургической бригады.

• Водопадная модель процесса разработки.

• Жизненный цикл программного продукта.

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

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

Эдсгер Вибе Дейкстра (нидерл. Edsger Wybe Dijkstra; 11 мая 1930, Роттердам (Нидерланды) — 6 августа 2002) — выдающийся нидерландский учёный, идеи которого оказали огромное влияние на развитие компьютерной индустрии.

Известность Дейкстре принесли его работы в области применения математической логики при разработке компьютерных программ. Он активно участвовал в разработке языка программирования Алгол. Будучи одним из авторов концепции структурного программирования, он проповедовал отказ от использования оператора GOTO. Также ему принадлежит идея применения семафоров для син- Дейкстра Э. Дисциплина программирования.

хронизации процессов в многозадачных сис- М.: Мир, 1978, 275 с.

темах и алгоритм нахождения кратчайшего Дал У., Дейкстра Э., Хоор К. Структурное пути на ориентированном графе с неотрица- программирование. М.: Мир, 1975. 247 с.

тельными весами рёбер. В 1972 году Дейкстра стал лауреатом премии Тьюринга.

Вирт Н. Систематическое программирование. Введение. М., Мир, 1977. 184 с.

Вирт Н. Алгоритмы + структуры данных = программы. М., Мир, 1978. 410 с.

Оригинальное название письма звучало так «A Case Against the Go To Statement». Редактор журнала, а им был Н. Вирт (!) предложил бессмертное название «Go To Statement Considered Harmful», под которым письмо и было опубликовано.

Фредерик Филипс Брукс мл., род. 19 апреля 1931 – американский менеджер, инженер и ученый, наиболее известен как руководитель разработки операционной системы OS/360. В 1975 году, обобщая опыт этой работы, написал книгу «Мифический человеко-месяц».

Повторно книга вышла в виде юбилейного издания в 1995-ом, вместе с комментариями автора и новым эссе «Серебряной пули нет».

Брукс насмешливо называл свою книгу «библией программной инженерии»: «все её читали, но никто ей не следует!»

Фредерик Брукс является лауреатом премии Тьюринга 1999 года.

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

Развитее технологии программирования продолжалось, но уже не революционным, а эволюционным путем. Взятые за основу, идеи 60-х годов развивались и совершенствовались.

Структурное программирование переросло в объектно-ориентированное, на смену водопадным моделям процесса пришли итерационные, метод хирургической бригады дал начало целому спектру моделей команды разработчиков. Но эти подходы не были революционно новыми, они улучшали и совершенствовали уже известное. Однако время не стоит на месте. Аппаратное обеспечение стремительно прогрессирует.

Сфера применения компьютеров расширяется все больше. Уже сейчас без них нигде нельзя обойтись, компьютеры применяются повсеместно. Пока еще слово «компьютер» ассоциируется у среднего жителя нашей планеты с образом персонального компьютера, с экраном и клавиатурой, а программирование ассоциируется с программированием на персональном компьютере и для персонального компьютера. Но это только пока. В самое ближайшее время компьютеры из устройств, которые используются очень часто и во многих местах, превратятся в устройства, которые используются везде и всегда. Речь идет о том, что сейчас называется встроенными системами. Персональные компьютеры выпускаются миллионами штук в год. Встроенные системы выпускаются миллиардами штук в год, а будут выпускаться многими миллиардами! И все эти устройства требуют для своей работы программного обеспечения. Не следует думать, что программировать эти устройства легко. Напротив. Уже сегодня возможности компьютера, скрытого в вашем мобильном телефоне, превосходят возможности того компьютера, которым пользовался Дейкстра, когда писал свое знаменитое письмо. Вполне вероятно, что консервативного усовершенствования старых идей, которого пока хватало для организации программирования персоИз всего спектра технологий программирования, появившихся за последнее время, только для аспектоориентированного программирования трудно указать предтечу в пионерских работах конца 60-х начала 70-х годов. Все остальные «новинки» последних лет – прямые аналоги либо хорошо забытых, либо малоизвестных работ прошлых лет.

нальных компьютеров, уже не хватит для организации программирования необозримого парка встроенных систем. Тогда технологию программирования ждут новые, действительно революционные изменения. Необходимо быть готовым к этому.

Подчеркнем, что предлагаемая классификация – не более чем мнемоническая схема для удобства запоминания и анализа. Она не раскрывает причин изменений в технологии программирования.

Множество программ неоднородно – спектр реальных и возможных программных систем очень широк. Программы можно классифицировать по множеству различных факторов.

Например:

• тип программно-аппаратной платформы, на которой выполняется программа:

встроенная систем, настольное приложение, сетевой сервис;

• размер программы (измеренный в байтах, командах, операторах, строчках кода или иных единицах);

• число пользователей: однопользовательская программа «для себя», внутренняя программа организации, программный продукт общего пользования;

• регулярность использования: разовая программа, регулярно используемая программа, постоянно работающая программа;

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

Этот список можно продолжать и продолжать, причем как в длину, указывая новые факторы, так и в ширину, указывая новые значения факторов. Огласить «весь список» очень трудно.

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

При описании технологий программирования необходимо указывать типы программных проектов, для которых данная технология применима – то есть область применимости.

1.4. Составные части технологии программирования Несмотря на то, что технология программирования начала развиваться одновременно с программированием, данная область знаний находится все еще скорее в стадии становления, нежели в стадии разработанной инженерной дисциплины, поэтому даже ее структура далеко не устоялась. Различные авторы, так же как и различные стандарты, принятые в этой области, используют несколько отличающиеся друг от друга структуры изложения технологии программирования, что дает нам известную свободу в выборе структуры изложения материала.

Мы полагаем, что технологию программирования целесообразно рассматривать в трех аспектах.

Модель процесса, т. е. порядок проведения типового проекта по разработке программного обеспечения. Сюда относятся понятия жизненного цикла программного обеспечения, определение модели процесса — выделение в нем фаз, вех, потоков работ и других составУМП Технологические подходы к разработке ПО ляющих. Характерным для данного аспекта является рассмотрение на уровне программирующей организации в целом.

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

Дисциплина программирования, т. е. методы создания конкретных артефактов, входящих в состав программного обеспечения. Сюда относятся описание и применение образцов проектирования, стандарты кодирования, методы тестирования и отладки и т. д. Характерным для данного аспекта является рассмотрение на уровне отдельного работника.

Цель любого программного проекта состоит в производстве некоторого программного продукта. То, как в рамках проекта производится продукт, представляет собой процесс.

Поскольку критичным для успеха дела является взаимодействие членов команды, мы включаем в рассмотрение персонал. Принцип четырех «П» отражен на рис. 1.

Рис. 1. Четыре «П» технологии программирования: проект, продукт, процесс и персонал Здесь использована знакомая многим нотация структурного анализа. Входом является проект, выходом – продукт, обеспечивающим механизмом – персонал, а управляющим воздействие – описание процесса.

При обсуждении технологии программирования широко используется понятие жизненного цикла программы. Жизненный цикл программы – это некоторая абстрактная модель, однако элементы принимаемого жизненного цикла являются тем материалом, из которого стоятся различные конкретные модели технологии программирования. Поэтому обсуждение понятия жизненного цикла программы необходимо должно предшествовать обсуждению элементов всякой технологии программирования.

В рамках данной темы определяются и обсуждаются наиболее общие идеи и понятия, которые интенсивно используются в последующих разделах курса.

Давно замечено, что программа за время жизни претерпевает многочисленные изменения своей формы, зависящие от состояния процесса разработки программы.

Жизненный цикл программы – это совокупность и последовательность изменений формы программы за все время ее существования.

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

Замечание Программа является преимущественно идеальным (а не материальным) объектом, поэтому в жизненный цикл включаются и те "эмбриональные" формы, в которых программа существует во время разработки. С другой стороны, материально существующие на магнитных носителях программы для больших машин не используются и не сопровождаются, а потому их жизненный цикл считается завершенным. Таким образом, программа жива, пока она жива в голове у программиста и/или пользователя.

Чего, к сожалению, не случается с программистами.

Рис. 2. Жизненный цикл программного обеспечения На приведенной схеме используются два вида графических обозначений: фигуры символизируют состояния, в которых находится программа, а стрелки – переход из одного состояния в другое. Оба типа элементов нагружены дополнительной информацией: текст внутри фигур обозначает деятельность, проводимую в данном состоянии, а текст над стрелкой – условие или событие, управляющее данным переходом.

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

Выпуск – характерная точка в жизни программы, отмечающая прохождение одного полного цикла.

Как правило, термином «выпуск» обозначают не только событие (момент в истории жизни программы), но и отчуждаемый артефакт, конкретную форму программы, появление которой отмечает данное событие.

Эта идея четко выделена в дисциплине проектирования Microsoft Solution Framework (MSF), представленной на рис. 3. В результате появляется характерная спиральная структура с периодическими выпусками очередных версий программы.

Замечание В материалах MSF используется более сложная схема из нескольких вложенных спиралей, по одной для каждой формы существования программы, которая более точно и детально отражает существо методологии программирования MSF. Для понимания основной идеи достаточно приведенной упрощенной схемы.

Рис. 3. Спиральная схема жизненного цикла программы Следует отметить три существенных момента этой схемы:

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

Программные продукты корпорации Microsoft, опыт разработки которых аккумулирует MSF, обладают именно этими свойствами. Проекты же, которые проводит типичная отечественная программирующая организация в настоящее время, обладают другими характеристиками:

• Типичная программирующая организация проводит параллельно относительно много проектов, каждый программист участвует в нескольких проектах одновременно в режиме разделения времени с мелким квантованием (недели, дни или даже • Круг заказчиков имеет тенденцию к стабилизации в смысле выделения постоянных партнеров, для которых периодически выполняются новые проекты, опирающиеся на результаты прежних, таким образом, многие проекты начинаются не с нуля.

• Каждый отдельный проект конечен и, как правило, предусматривает один6 выпуск и краткосрочное сопровождение. Если программный продукт подлежит значительной модификации, то это оформляется отдельным договором, а значит, является независимым проектом.

Чтобы учесть эти особенности, заметим следующее:

• В жизненном цикле программа взаимодействует с двумя категориями действующих лиц: заказчиком (пользователем) и (абстрактным) программистом, причем последний может быть представлен как программно (software), так и умственно (brainware).

В большинстве проектов по разработке приложений для автоматизации бизнеса предусматривается передача заказчику двух версий: прототипа на фазе опытной эксплуатации и окончательной версии на фазе внедрения. С точки зрения организации процесса эти версии необходимо различать, но с точки зрения жизненного цикла программы это один выпуск, потому что реализует один набор функций, отраженный в спецификациях.

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

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

Учет этих наблюдений приводит к модели жизненного цикла множества программ, представленной на рис. 4.

Программисты Рис. 4. Жизненный цикл множества программ Приведем некоторые примеры, иллюстрирующие и подтверждающие предлагаемую нами схему, приведенную на рис. 4. Информационная система масштаба предприятия обязана иметь "стандартный" (часто не самый лучший для конкретного случая!) интерфейс и всякие изыски в этой области категорически запрещаются просто потому, что пользователь и раньше работал с другими программами и привык к определенному типу интерфейса.

Программист из проекта в проект использует "стандартную" трехслойную архитектуру приложения (часто не самую лучшую для конкретного случая!) просто потому, что он знает эту архитектуру.

Замечание Программа может воздействовать через заказчиков и программистов не только на другие программы, но и на самое себя. Хотя на схеме направление стрелок через программиста противоположно направлению смены фаз, а направление стрелок через заказчика проходит через веху выпуска, но, поскольку модель процесса может состоять из нескольких витков, программа может воздействовать на свою более раннюю фазу на более позднем витке!

В следующих разделах этой темы мы кратко охарактеризуем основные понятия, как использованные нами в предыдущих схемах, так и применяемые в различных известных моделях жизненного цикла, с целью уточнить используемую терминологию.

2.2. Основные понятия технологии программирования В данном разделе рассматриваются общеизвестные термины, которые используются в технологии программирования. Такое рассмотрение необходимо, потому что иначе очень легко упустить некоторые тонкости, специфические для рассматриваемого предмета, положившись на «общеизвестность» терминов. По нашему мнению, едва ли не самым заметным свидетельством прогресса в технологии программирования является то, что, наконец, удалось договориться о терминах. Так или иначе, предметом технологии программирования является процесс разработки программного обеспечения.

Процесс – 1) Последовательность смены состояний в развитии чего-нибудь. 2) Последовательность действий для достижения какого-либо результата. Заметим, что два процитированных определения не являются разными определениями – это описание одного и того же предмета с разных точек зрения. Можно обратить свое внимание на смену состояний. Но что является причиной смены состояний? Очевидно, выполнение каких-то действий. Можно обратить свое внимание на выполнение действий.

Но что является результатом выполнения действий? Очевидно, смена состояний.

Чтобы иметь саму возможность делать какие-то наблюдения или проводить рассуждения относительно процесса, нужно иметь описание процесса, или его модель. Термин «модель» широко используется в различных областях человеческой деятельности, и имеет много значений. В данном случае подразумевается следующее значение.

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

Процесс разработки программ также пытались описывать самыми разными способами, но постепенно к настоящему времени сложилась традиция использовать для описания процесса программирования примерно те же средства, которые используются для самого программирования. Программы же, как всем известно, записывают как алгоритмы, выраженные на том или ином языке программирования.

Обсуждение значения этого факта мы отложим до темы 5, а здесь заметим, что языков программирования очень много (тысячи) и среди них встречаются как такие, которые предназначены для записи программ, исполняемых компьютером, так и такие, которые для этого не предназначены. Например, различные псевдокоды, блок-схемы и тому подобное. Язык программирования, если он предназначен для восприятия людьми, совсем не обязан быть формальным, точным и сугубо бедным, как «настоящий» язык программирования, подобный С++ или Java. Сейчас процессы разработки программного обеспечения принято описывать как алгоритмы, но очень неформально, с использованием понятий высокого уровня, далеких от машинной реализации. Конечно, неформальный характер таких алгоритмов приводит к тому, что у разных авторов встречаются несколько различные толкования основных элементов, из которых строится описание процессов разработки, но, тем не менее, за последние годы фактически устоялся общий набор таких основных понятий, и мы их перечисляем в следующих разделах.

Фактическая стабилизация и унификация терминологии стала наблюдаться сравнительно недавно, с начала этого века.

Но поскольку переводчики зарубежных книг по технологии программирования редко заглядывают в утвержденные терминологические ГОСТы, в отечественной литературе пока еще наблюдается некоторый разнобой в терминологии.

Большой энциклопедический словарь дает еще одно определение: порядок рассмотрения дел в судопроизводстве. Но в данном случае это значение слова «процесс» не имеет отношения к предмету.

Большой энциклопедический словарь дает еще шесть толкований этого термина.

Замечание Следует иметь в виду, что в современных технологиях программирования процесс разработки программного обеспечения рассматривается не как один последовательный процесс, а как несколько параллельных процессов, взаимодействующих друг с другом. Это накладывает дополнительные сложности алгоритмического и терминологического характера.

При описании процессов, связанных с разработкой программного обеспечения, основными структурными составляющими являются фазы и витки.

Фаза (phase) – часть процесса разработки. Обычно каждая фаза характеризуется вехой, достижение которой знаменует завершение фазы.

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

В разных источниках используются также термины стадия или этап. Мы предпочитаем термин «фаза» по следующей причине. Слова «стадия» и «этап» имеют оттенок линейной упорядоченности, подразумевается, что следующий этап меняет предыдущий, и они не совмещаются во времени. Иногда фазы действительно строго меняют друг друга, но чаще бывает так, что фазы частично перекрывают друг друга и выполняются параллельно – например, требования еще окончательно не утверждены и фаза извлечения требований еще не закончилась, но уже начаты работы по архитектурному проектированию.

Наборы фаз, которые включают в модель процесса разработки, различны в разных технологиях программирования. Чаще всего встречаются следующие фазы.

• Извлечение и анализ требований.

• Архитектурное и детальное проектирование.

• Реализация и кодирование.

• Тестирование и верификация.

• Сопровождение и продолжающаяся разработка.

Замечание К сожалению, часто одна и та же фаза в разных моделях называется по-разному. Это связано с устойчивыми традициями и вряд ли может быть изменено. Следует иметь в виду это обстоятельство, и, встречая незнакомое название фазы, тщательно проверять, не является ли название просто новым именем для хорошо знакомой фазы.

В следующих разделах упомянутые фазы рассмотрены подробнее.

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

Виток – последовательность неповторяющихся фаз в жизненном цикле программы.

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

Довольно часто используют и другой термин – итерация. Каждая фаза является достаточно крупной составляющей процесса разработки: фаза может продолжать достаточно долго, и требовать выполнения большого объема работы. Более того, фазы могут перекрываться во времени и выполняться параллельно. Таким образом, понятие фазы оказывается недостаточно четким для точного планирования, учета и измерения процесса. В то же время планирование и измерения считаются совершенно необходимыми элементами в современном процессном подходе. Нужно средство установить границы фазы более четко. Таким средством является понятие «веха».

Веха (milestone) – одномоментное идентифицируемое событие, сопровождающееся появлением и фиксацией некоторого артефакта.

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

Например, для фазы «выявление и анализ требований» главная веха – «требования определены», а результатом фазы являются сами требования.

Заметим, что совершенно необязательно считать, что каждая фаза имеет только одну веху:

их может быть сколько угодно. Например, начальная веха, которая отмечает начало фазы, промежуточные вехи, которые отмечают важные части фазы или появление важных артефактов необходимых для выполнения других фаз и так далее.

Мы уже много раз использовали слово «артефакт». Вообще говоря, это слово происходит от латинских корней [arte искусственно + factus сделанный], и означает любую искусственно созданную вещь. В последний годы этот термин активно стал применяться в технологии программирования в следующем смысле.

Артефакт (artifact) – документ или иной материал, имеющий материальную форму и отчуждаемый от разработчика.

В этом определении важно обратить внимание на слово «отчуждаемый». Поясним это на примере модельной ситуации. Допустим, что после некоторых разговоров с заказчиком один из разработчиков заявляет: «я понял, что нужно сделать». Можно ли считать, что веха «требования определены» достигнута? В некоторых ситуациях действительно достаточно иметь оракула, умеющего отвечать на любые вопросы, относящиеся к разрабатываемому программного обеспечению, по мере их возникновения. Однако в современных промышленных технологиях программирования так поступать не принято – слишком велик риск. Действительно, что делать, если оракул заболеет или уволится? Считается, что веха «требования определены» должна сопровождаться артефактом, в котором эти требования действительно определены и их можно использовать без непосредственной помощи тех лиц, которые составляли требования.

Процесс разработки программного обеспечения не является автоматическим – в нем участвуют люди. Но этот процесс, в настоящее время, не является полностью ручным – для разработки программного обеспечения используется программное обеспечение.

Иногда программисты вместо аккуратного термина «выпуск» используют слово «релиз», полученное прямой транслитерацией английского термина «release», который на самом деле в данном случае как раз и означает «выпуск».

Например, термин «итерация» применяют в одной из популярнейших моделей процесса – Rational Unified Process (RUP), название которой обычно переводят на русский язык как Унифицированный процесс.

Программы, которые используется при разработке программ, называются инструментальными, или инструментами.

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

Работник13 (worker) – набор выполняемых функций и обязанностей, назначенных сотруднику в рамках конкретного проекта.

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

Заинтересованными лицами (stockholders) называют категории людей или организации, которые тем или иным образом связаны с проектом.

Так же как и в случае с работниками, при описании модели процесса принято абстрагироваться от конкретных особенностей реальных заинтересованных лиц, и учитывать только отношения, которые данные заинтересованные лица имеют к проекту.

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

Если мы поймем, что такое требование к программной системе, то сможем определить и то, что делается в фазе «Выявление и анализ требования».

Существует большой диапазон решений этой проблемы.

• Простое решение. Понятие «требование» не определяется. Разработчик и заказчик полагаются, в этом случае, на здравый смысл. Риск такого решения определяется тем, что бизнес-цели, опыт и квалификация у заказчика и разработчика различны.

Существует целый ряд областей человеческой деятельности, прежде всего в науке и искусстве, где предположение о взаимозаменяемости сотрудников не всегда верно.

Часто используется также термин "роль". Но поскольку этот термин занят в унифицированном языке моделирования UML, мы, вслед за авторами Унифицированного процесса будем использовать термин "работник".

• Обычное решение. Дать какое-либо, возможно не очень точное или не очень понятное определение. Например Требование – это документированное указание потребности или цели пользователей либо условия и возможности, которым должен обладать продукт, чтобы удовлетворить такие возможности или цели.

Требования – это высокоуровневые обобщенные утверждения о функциональных возможностях и ограничениях системы.

Риск этого решения примерно такой же, как и для предыдущего случая.

• Стандартное решение. Использовать стандартное определение понятия «Требование».

Стандарты IEEE используют следующее определение требований.

1. Функциональность, необходимая пользователю для решения проблемы или достижения цели.

2. Функциональность, которая должна быть получена (достигнута) системой или ее компонентами для соответствия контракту, стандарту, спецификации или другим формальным документам.

3. Документальное представление пп. 1 – 2.

Таким образом, понятие «требование» в этом определении апеллирует либо к пользователям, либо к формальным документам. В любом случае подчеркивается обязательность документального представления.

Российский стандарт ГОСТ 12207 дает другое решение проблемы, в котором понятие «требование» определяется перечислением тех видов требований, которые предъявляются к программному продукту и, практически, не требуют расшифровки.

В соответствии со стандартом ГОСТ 12207 на стадии «Анализ требований» должен быть выполнен анализ требований к программным средствам. Эта работа состоит из следующих задач:

1. Разработчик должен установить и документально оформить следующие требования к программным средствам:

• функциональные и технические требования, включая производительность, физические характеристики и окружающие условия, под которые должен быть создан программный объект;

• требования к внешним интерфейсам программного объекта;

• квалификационные требования;

• требования безопасности, включая требования, относящиеся к методам эксплуатации, сопровождения, воздействию окружающей среды и травмобезопасности персонала;

и т.д. Всего расшифровка понятия «требования» в ГОСТ 12207 занимает несколько страниц.

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

Разумеется, такие требования наилучшим образом описывают программную систему. Однако в промышленных технологиях программирования сложное решение применяется не часто. Дело в том, что формальные математические требования оказываются больше по объему, требуют больше трудозатрат на разработку, и требуют более высокой квалификаУМП Технологические подходы к разработке ПО ции разработчиков, чем обычное программирование. Поэтому разработка строгих математических требований к программе оказывается дороже разработки самой программы, причем может быть даже на несколько порядков дороже. В специальных случаях приходится идти на такие затраты, но в типовом программировании для автоматизации бизнеспроцессов этого не делают.

Разработка требований – это первая из основных фаз процесса создания программных систем. Этот фаза состоит из следующих основных работ (рис. 5).

Анализ Формирование Документирование Детализация Согласование и Рис. 5. Схема процесса разработки требований • Анализ предметной области. Позволяет выделить сущности предметной области, определить первоначальные требования к функциональности и определить границы проекта.

• Анализ осуществимости. Должен выполняться для новых программных систем.

На основании анализа предметной области, общего описания системы и ее назначения принимается решение о продолжении или завершении проекта.

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

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

• Детализация требований. Разработчики детализируют требования пользователей, формируя более точные подробные системные требования.

• Согласование и утверждение требований. На этом этапе пользовательские и системные требования должны быть оформлены в виде единого документа, содержащего все функциональные и нефункциональные требования. Такой документ, обычно, называется спецификацией требований. Спецификация требований должна удовлетворять следующим характеристикам качества: корректность, однозначность, завершенность и согласованность.

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

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

• понимание пользователями возможностей системы, решаемых ею задач, может измениться;

• происходят изменения в деловой среде, техническом, программном и другом обеспечении системы, которые должны быть учтены;

• понимание разработчиками поставленных перед ними задач меняется.

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

К действиям по управлению требованиями относятся:

• определение основной (базовой) версии спецификации требований для конкретной версии продукта;

• анализ предлагаемых изменений требований, оценка воздействия и стоимости каждого изменения до его принятия;

• включение одобренных изменений при помощи определенной процедуры;

• согласование плана проекта с требованиями;

• отслеживание отдельных требований от проектирования до кода приложения и его тестирования;

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

• методы и средства управления версиями спецификации и отдельных требований;

• процесс разработки, согласования, экспертизы и утверждения базовой версии;

• процесс присвоения, контроля и изменения статуса требования;

• процесс передачи новых требований и изменений существующих требований заинтересованным лицам;

• методы анализа влияния и стоимости внесения изменения.

Кроме этого описание процесса должно содержать определение участников проекта, ответственных за выполнение каждой конкретной задачи.

Минимальной единицей управления в спецификации требований является отдельное требование, поэтому вопрос идентификации требования достаточно важен.

Форма представления требования может быть различной (текстовая, графическая и т.д.), поэтому для идентификации требования обычно используют связанный с ним набор атрибутов. Атрибутами могут быть: дата создания требования, номер текущей версии требования, номер версии продукта, для которой предназначено требование, автор требования, ответственный за реализацию требования, состояние требования, происхождение и обоснование требования, подсистема, для которой предназначено требование и т.д. Главное при выборе атрибутов, чтобы они однозначно идентифицировали требование и его состояние.

В процессе выполнения проекта требование, обычно, изменяет свое состояние от начального («предложено»), до конечного, например, «реализовано». Состояния требований позволяет оценить степень готовности проекта. Рекомендуются использовать состояния требования, приведенные в табл. 1.

Таблица 1. Состояния требования Предложено Требование запрошено авторизированным источником (proposed) Одобрено Требование проанализировано, его влияние на проект просчитано, и оно (approved) было размещено в базовой версии определенной версии продукта. Ключевые заинтересованные в проекте лица согласились с этим требованием, Реализовано Код, реализующий требование разработан, написан и протестирован.

(implemented) Требование отслежено до соответствующих элементов дизайна и кода Проверено Корректное функционирование реализованного требования подтверждеverified) но в соответствующем продукте. Требование отслежено до соответствующих вариантов тестирования. Теперь требование считается выполненным Удалено Утвержденное требование удалено из базовой версии. Следует зафиксиdeleted) ровать причины и лицо, принявшее это решение Отклонено Требование предложено, но не запланировано для реализации ни в одной (rejected) из будущих версий. Следует зафиксировать причины и лицо, принявшее В процессе управления требованиями должны быть определены лица, которые могут изменить состояние требования. Управление статусом позволяет численно определить степень готовности проекта, считая, например, что основная часть работы закончена, если все требования имеют состояние «Проверено» или «Удалено».

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

Диаграмма состояний для типового процесса внесения изменений в спецификацию приведена на рис. 6.

Запрос на изменение Рис. 6. Процесс внесения изменений в спецификацию требований 2.4. Архитектурное и детальное проектирование Существуют такие типы проектов по разработке программного обеспечения, которые не нуждаются в фазе проектирования: после того, как требования определены, можно сразу приступать к реализации и кодированию. Однако такая возможность встречается очень и очень редко. Для того, чтобы действительно можно было безнаказанно пропустить фазу проектирования, необходимо наличие целого ряда благоприятных обстоятельств: либо это чрезвычайно простой («учебный») проект, либо имеется высоко квалифицированная команда разработчиков, которая прежде выполняла аналогичные проекты многократно.

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

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

ошибка: сокращение сроков и трудозатрат на проектирование не только не сократит суммарных сроков и трудозатрат на разработку, а, наоборот, в лучшем случае существенно увеличит их, а в худшем случае приведет к краху проекта.

В настоящее время всю фазу проектирования обычно подразделяют на две части: архитектурное проектирование и детальное проектирование.

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

Проиллюстрируем определение аналогией со строительством. Допустим, нам нужно спроектировать и построить небольшой загородный дом на определенном земельном участке.

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

За последнее время вопросам архитектурного проектирования в технологии программирования было уделено особенно много внимания. Были предложены и реализованы на практике многочисленные типовые архитектуры. Шоу и Гарлан классифицировали архитектуры программного обеспечения с точки зрения практики [2]. Другими словами, они собрали вместе образцы программного обеспечения для различных архитектур. Их классификация, немного адаптированная, показана в табл. 2.

Таблица 2. Типы архитектур (по классификации Гарлана и Шоу) Потоки данных Последовательность пакетов Независимые процессы обработки Независимые Параллельные взаимодейст- Независимые компоненты взаимокомпоненты (in- вующие процессы действуют, обмениваясь сообщеdependent compo- Клиент-серверные системы ниями Репозиторные ар- Гипертекстовые системы Структура приложения определяется tory architectures) Доски объявлений Приведенная в табл. 2 классификация архитектур довольно поверхностна. На практике обычно используют комбинацию нескольких архитектурных идей, настраивая их с учетом особенностей проекта.

http://ru.wikipedia.org/ Продолжим аналогию со строительством. Допустим, архитектура нашего загородного дома выбрана. Теперь нужно решить такие вопросы, как выбор материалов для фундамента, несущих конструкций и кровли, количество, размеры и расположение окон и дверей, способ и место подключения к инженерным сетям и так далее, и так далее – это и есть детальное проектирование.

Фаза детального проектирования обычно предусматривает применение большого числа различных средств, инструментов и приемов. Как правило, здесь наблюдается разнообразия больше, чем в фазе кодирования и реализации. При кодировании и реализации возможностей для выбора и принятия решений не так много – все они предопределены выбранной системой программирования. Фаза детального проектирования, напротив, требует постоянного выбора среди множества возможных альтернатив. Разработанные требования и выбранная архитектура полностью предписывают, что нужно сделать, но в очень малой степени являются подсказкой при поиске ответа на вопрос как это можно сделать.

Другими словами, фаза детального проектирования – самая творческая часть процесса программирования. Именно здесь присутствуют наибольшие возможности для того, чтобы найти новое элегантное решение или совершить грубую дорогостоящую ошибку. Дать обзор всех приемов детального проектирования затруднительно. Мы приведем один пример описания процедуры детального проектирования, основанный на использовании объектно-ориентированного подхода и унифицированного языка моделирования UML (рис. 7). Элементы этой блок схемы указывают, какие артефакты необходимо разработать (или выбрать уже готовые!) на каждом шаге детального проектирования.

Рис. 7. Процесс детального проектирования Написание программ на скорую руку дает быстрый, но сомнительный результат; дисциплинированный подход, напротив, обеспечивает лучшее качество с меньшими временными затратами.

В этом разделе не предпринимается попытка охватить все аспекты программирования в духе таких книг, как [4]. Вместо этого мы обсудим некоторые принципы кодирования и дадим рекомендации, которые относятся в большей степени к компаниям, разрабатывающим программные приложения, нежели к индивидуальным кодировщикам.

Реализацией (implementation) или кодированием (coding) называется составление текста программы на языке программирования в соответствии с детальным проектом, архитектурой и требованиями.

Термин «модуль» относится к самым мелким частям реализации, которые можно поддерживать отдельно: это может быть отдельный метод или класс. Мы будем считать методы модулями самого низкого уровня.

Целью реализации является удовлетворение требований способом, определенным в детальном проектировании. Детального проекта должно быть достаточно, поскольку это документ, на котором основывается программирование. Однако часто программист исследуУМП Технологические подходы к разработке ПО ет параллельно все предшествующие документы (требования, архитектуру), что помогает сгладить несогласованность этих документов.

Инженерным анализом программы16 (reverse engineering) называется исследование и обработка текста программ с целью восстановления модели этой программы.

Когда модуль реализован, можно использовать инструменты инженерного анализа для повторной генерации аспектов детального проектирования.

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

Вообще говоря, инженерный анализ следует использовать только тогда, когда он действительно необходим. Автор наблюдал много ситуаций, когда инженерный анализ использовался для скрытия недостатков фазы проектирования. Другими словами, программисты преждевременно «ныряют» в написание кода, а затем задним числом создают «проект» из кода. Квалифицированных аудиторов таких «проектов» редко удается обмануть – отсутствие должного проектирования практически невозможно скрыть.

В настоящее время разработка программного обеспечения является интенсивно развивающейся отраслью промышленности. Время, когда программирование было уделом отдельных талантливых одиночек, которые были единственными читателями своих программ, закончилось уже лет 30 назад. Сегодня крупные программные проекты разрабатываются большими коллективами, причем развитие и сопровождение проекта часто длятся годами. За это время успевает обновиться коллектив разработчиков, нередки случаи, когда инициаторы проекта к моменту его завершения могут отсутствовать не только в организации, но и в стране.

В этих условиях естественным является требование унификации стиля программирования.

Код, написанный различными программистами, должен читаться как единое целое и быть понятен не только его авторам. Отсюда следует, что программа должна быть рационально написана и хорошо прокомментирована. Отметим, ничто так не раздражает программиста–профессионала, как небрежно написанный и код без комментариев. Так же как невозможно представить инженерный чертеж, оформленный без учета требований стандартов, так и программа должна иметь унифицированный вид. Отсюда следует необходимость составления, постоянной актуализации и строго исполнения стандартов кодирования.

Стандарт кодирования (coding standard) – сборник корпоративных или проектных правил и рекомендаций по составлению и оформлению текстов программ.

Тестирование — важнейшая фаза процесса разработки. В общем случае можно дать следующее определение.

Тестирование (testing) — это проверка соответствия требованиям.

В этом смысле тестированию подлежит не только программный код (это само собой разумеется) но и все артефакты процесса разработки.

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

щественной обязанностью. Каждая часть работы, выполненная инженером, должна быть детально проверена по крайней мере одним человеком, желательно независимым от автора работы.

В дополнение к ответственности индивидуальных разработчиков, многие организации определили процесс раздельной систематической и полной проверки всех артефактов— контроль качества. В функции контроля качества входят проверки, инспектирование и тестирование. Контроль качества должен начинаться вместе с запуском каждого проекта (рис. 8). Лучше всего привлекать контроль качества и для проверки правильности используемого процесса и актуальности документации.

вождение Рис. 8. Осуществление контроля качества 2.6.2. Методы «белого ящика» и «черного ящика»

В случае контроля качества методом «черного ящика» приложение (или какая-либо его законченная часть) анализируется как целое. Этот метод используется для проверки того, что приложение (его часть) отвечает предъявляемым требованиям. Контроль качества методом «белого (стеклянного) ящика» осуществляется на уровне компонентов, из которых построено тестируемое приложение (его часть).

Чаще всего о методах «черного» и «белого ящика» говорят в контексте тестирования. Однако эти методы применимы и к другим способам контроля качества. Метод «белого ящика» основан на рассмотрении анализируемого артефакта с точки зрения его структуры, формы и назначения; здесь применяются формальные методы и рассматриваемое в следующем разделе инспектирование. Метод «черного ящика» задается вопросом «Обладает ли построенный объект требуемым поведением?». При этом для тестирования по методу «черного ящика» достаточно иметь набор пар «вход–выход», чтобы можно было проверить правильность поведения.

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

Принцип инспектирования может быть обобщен четырьмя правилами.

• Вскрытие дефектов. Из инспектирования намеренно исключается исправление дефектов. Процесс исправления предоставлен автору. Во время инспектирования ни минуты времени не должно быть потрачено на обсуждение способов исправления дефекта. Все обсуждения должны проходить после окончания инспектирования.

• Участие коллег. Инспектирование проводится внутри группы разработчиков программного обеспечения и не предполагает вовлечения отношений начальник — подчиненный. Инспектируется текущая работа, а не способности ее автора. Автор несет ответственность только за конечный продукт, тогда как инспектирование проводится до того, как работа сдана. Однако работа, представленная автором для инспектирования, должна быть лучшим вариантом, но ни в коем случае не черновиком. Было бы пустой тратой ресурсов группы искать, находить и описывать дефекты, которые автор, приложив некоторые усилия, в состоянии найти сам.

• Распределение ролей. Каждый из участников проекта берет на себя одну из следующих ролей. При нехватке кадров один человек может выполнять сразу две роли. Обычно ведущий может одновременно быть и секретарем. Однако для достижения беспристрастной проверки автор не должен выполнять • Ведущий ответственен за правильное проведение инспектирования.

• Автор несет ответственность за свою работу и за исправление всех найденных в ней дефектов. Автор является одновременно и инспектирующим.

• Секретарь отвечает за учет описания и классификацию дефектов, как это принято в команде. Секретарь также участвует в инспектировании.

• Тщательная подготовка. Участникам инспектирования необходимо подготовиться к нему так же детально, как и самому автору. Инспектирования не являются просто посиделками, докладами руководству или образовательными семинарами. Инспектирующие должны работать на том же уровне детализации, что и автор.

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

Помимо инспектирования, многие организации применяют обзоры.

Обзор — это собрание, на котором обсуждается как уже завершенная, так и текущая работа.

Примером тому является обзор, на котором может обсуждаться альтернативная архитектура приложения. Хотя обзоры являются неотъемлемой частью проекта, они не требуют такой детальной подготовки, как инспектирование. К тому же участникам обзоров, в отличие от ситуации с инспектированием, не надо играть никаких ролей. Тем не менее, обзоры необходимо проводить, причем регулярно с участием максимального возможно чисУМП Технологические подходы к разработке ПО ла разработчиков. Обзоры задают «пульс» проекта, подтверждают его жизнеспособность и служат фактором положительной мотивации персонала.

Регулярные обзоры — это самое надежное средство добиться того, чтобы все были «в курсе» и могли избегать ошибок, порождаемых непониманием общего контекста проекта.

Невозможно протестировать программу абсолютно во всех аспектах, поскольку число вариантов работы нетривиальной компьютерной программы может быть неограниченным.

Тестирование не может доказать отсутствия ошибок в программе. Тестирование может только показать присутствие ошибок.

Тестирование часто неправильно воспринимается как процесс подтверждения корректности кода, что можно выразить таким высказыванием: «Протестируй это, чтобы убедиться, что тут все правильно». Главная цель тестирования далека от подтверждения корректности. Цель тестирования не в том, чтобы показать удовлетворительную работу программы, а в том, чтобы четко определить, в чем работа программы неудовлетворительна!

Тестирование требует значительных затрат, и нужно стараться получить от этих затрат максимальную отдачу. Для данной тестируемой программы, чем больше дефектов будет найдено на каждый человеко-час тестирования, тем выше выигрыш от вложений в тестирование.

Целью тестирования является обнаружение как можно большего числа дефектов, как можно более серьезных и как можно раньше.

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

2.6.5. Верификация, валидация и системное тестирование Верификация позволяет определить, правильно ли мы создаем приложение.

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

Валидация позволяет выяснить, правильный ли результат у нас получается.

Другими словами, удовлетворяет ли наш продукт требованиям? Это проверяется с помощью системного тестирования.

Системное тестирование – это тестирование все системы в целом.

Существует несколько видов системного тестирования.

• Контекстное модульное тестирование. После того как система собрана, становится возможным повторно протестировать модули (например, пакеты) в контексте системы.

• Тестирование интерфейсов подразумевает повторную валидацию интерфейсов между модулями.

• Цель регрессионного тестирования заключается в проверке того, что добавления к системе не уменьшили ее возможностей. Другими словами, при добавлении в систему нового модуля, следует сначала убедиться, что все старые модули не потеряли работоспособность. Только когда новый модуль прошел регрессионное тестирование, можно тестировать его работу в контексте системы.

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

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

• Тестирование инсталляции выполняется при установке программы на целевых платформах.

• Приемосдаточные испытания выполняются клиентом для валидации приемлемости программы.

2.7. Сопровождение и продолжающаяся разработка Сопровождение программного продукта включает в себя все действия, выполняемые с приложением после поставки продукта заказчику.

Сопровождение программы – это процесс изменения программной системы или компонента после поставки с целью исправления ошибок, повышения производительности или иных параметров, а также для адаптации к изменившимся условиям.

По различным оценкам сопровождение программы составляет от 40% до 90% стоимости всего жизненного цикла приложения. Можно возразить, что в указанное выше определение сопровождения включены усовершенствования, которые лучше было бы считать продолжающейся разработкой.

Продолжающаяся разработка – это разработка новых и переработка имеющихся функций программы в процессе эксплуатации.

В любом случае объем работ по сопровождению программ обычно достаточно велик.

Было подмечено любая программа, адаптацией которой к изменяющимся условиям никто не занимается, с течением времени неизбежно теряет свою ценность. Другими словами, если приложение остается неизменным, польза от него постепенно убывает.

Чтобы представить, какие проблемы возникают при сопровождении программ, вообразите приложение настолько большое, что ни один человек не может знать всех его функций и особенностей. Большую проблему в сопровождении таких программ создает эффект «ряби», возникающей при внесении изменений. Когда множество относительно безвредных изменений производятся одновременно в «удаленных уголках» больших приложений, эти изменения могут приводить к повреждению приложения как целого.

Можно упорядочить проблемы, связанные с сопровождением программ, разделив их на три категории.

• Проблемы управления: трудность выявления прибыли на инвестированный капитал.

• Проблемы обработки: для обслуживания потока запросов на сопровождение требуется жесткая координация.

• Проблемы технического характера: трудность учета всех результатов изменений;

высокая стоимость тестирования по сравнению с пользой от отдельных изменений.

Следует различать работы по сопровождению, направленные на устранение дефектов (fixing) и на усовершенствование (enhancing) приложения. Различные исследования показали, что 60–80% работ обычно относится к усовершенствованию приложения, а не к исправлению его недостатков.

Последовательность обработки запросов на сопровождение состоит из анализа, проектирования, реализации и тестирования, точно так же, как и обычная разработка. СущественУМП Технологические подходы к разработке ПО ным отличием является необходимость анализа влияния изменений на артефакты. Согласно исследованию Вейсса, 19% дефектов в приложениях образуются на этапе определения требований, 52% — на этапе проектирования и лишь 7% — в процессе программирования.

Многие другие авторы утверждают, что доля дефектов, вызванных неправильной формулировкой требований, должна быть еще выше и составляет до 30%.

В то же время практика показывает, что стоимости устранения дефектов, допущенных при разработке требований, при проектировании и при реализации относятся как 10 : 3 : 1.

Это эффект нетрудно объяснить: устранение ошибки в требованиях повлечет изменение всех артефактов проекта. Устранение ошибки кодирования потребует изменить лишь один программный модуль.

Тема 3. Модели процесса разработки Трудности конструирования реальных приложений обусловлены их сложностью, и критическую роль в преодолении этой сложности играет сам процесс конструирования.

В настоящее время можно выделить три стратегии конструирования модели процесса [8].

• Линейная стратегия. Требования определены в начале разработки, и выпуск программного обеспечения производится один раз в конце разработки.

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

• Эволюционная стратегия. Выпуск версий программного обеспечения производится многократно по ходу разработки, но требования не определены в начале разработки, они определяются по ходу разработки.

Свойства указанных стратегий можно свести в табл. 3.

Таблица 3. Характеристики стратегий конструирования Стратегия Требования опре- Множество циклов Промежуточные Далее рассматриваются некоторые известные модели, представляющие каждую из упомянутых стратегий.

В модели водопада (иногда называемой моделью конвейера) процесс разработки (жизненный цикл программного продукта) делится на фазы, которые последовательно сменяют друг друга (рис. 9).

• Анализ требований состоит в сборе требований к продукту. Результатом анализа, как правило, является некоторый текст или модель использования.

• Проектирование описывает внутреннюю структуру продукта. Обычно такое описание дается в форме диаграмм и текстов.

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

• Тестирование — это процесс сборки всего продукта из отдельных частей и проверки того, что требования удовлетворены.

Замечание Модель водопада (конвейера) является исторически первой осознанно использованной моделью процесса разработки программного обеспечения. Многие очень крупные проекты были успешно проведены с использованием этой модели.

Рис. 9. Водопадная модель процесса разработки В действительности перечисленные фазы не следуют строго последовательно друг за другом, а частично перекрываются. На практике любую из фаз можно начинать до того, как будет полностью завершена предыдущая. Но важнейшей особенностью водопадной модели является то обстоятельство, что завершив фазу, мы уже больше к ней не возвращаемся.

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

В инкрементных моделях процесс делится на витки, или итерации, каждая из которых в свою очередь делиться делится на фазы (например, анализ, планирование, разработка, стабилизация). Каждая фаза кончается вехой (концепция, спецификации, код, выпуск).

После выпуска (release) раскручивается очередной виток спирали (см. рис. 10).

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

Наиболее известной конкретной спиральной моделью процесса является модель Microsoft Solution Framework (MSF), в адаптированном виде приведенная на рис. 10.

Замечание Модель конвейера, также как и спиральная модель, может использовать вехи. Характерным для модели конвейера (водопада) является безвозвратный (не итеративный) характер процесса, в то время как в спиральных и инкрементных моделях мы вновь и вновь повторяем последовательность фаз. Таким образом, рассматриваемые модели относятся к итерационной стратегии.

Рис. 10. Модель спирального процесса Иногда представляется возможным понемногу продвигать проект вперед при практически непрерывном процессе. Такая модель процесса особенно полезна на поздних стадиях проекта, когда продукт находится на сопровождении или когда разрабатываемый продукт очень схож с созданным ранее. Например, процесс, используемый в некоторых отделениях корпорации Microsoft, предусматривает обновление программного кода и документации ежедневно к конкретному времени для интеграции и ночного тестирования. Другие организации используют для этого недельные циклы. Для поддержания соответствующего уровня инкрементальной разработки необходимо иметь четко установленную архитектуру проекта и исключительно синхронизированную систему документации. Для организации инкрементальной разработки обычно выбирается характерный временной интервал, например неделя. Затем в течение этого интервала происходит обновление исходного проекта (документации, набора тестов, программного кода и т. д.).

Рис. 11. Модель инкрементного процесса Наиболее известной инкрементной моделью является Унифицированный процесс (Rational Unified Process).

Самой яркой моделью гибкой разработки сейчас, видимо является экстремальное программирование, предложенное Кентом Беком.

Кент Бек (Kent Beck) – пионер экстремального программирования. Практикующий разработчик, менеджер и автор нескольких книг по экстремальному программированию, применению образцов проектирования и гибким процессам разработки.

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

Часто из-за длительных циклов разработки требования, предъявляемые к программному продукту к моменту его готовности, уже не совпадают с заданными изначально (рис. 12).

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

Вообще говоря, экстремальное программирование использует многие известные ранее методики, но применяет из максимально интенсивным, экстремальным образом.17 Ключевыми методиками экстремального программирования принято считать следующие.

• Динамическое планирование (planning game) – быстро сформировать приблизительный план работы и постоянно обновлять его по мере того, как условия задачи становятся все более четкими. Если со временем план перестает быть актуальным, он должен быть обновлен.

• Частые выпуски (small releases) – самая первая упрощенная версия быстро сдается заказчику, после чего через относительно короткие промежутки времени (неделя– две недели) происходит выпуск новых версий.

• Архитектурная метафора (system metaphor) –простая и понятная заказчику концепция системы.

• Простое проектирование (simple design) – в каждый момент времени система должна быть спроектирована так просто, как это возможно, так как заказчик может изменить функциональность.

• Опережающее тестирование (testing) – для любой программы должны существовать автоматические тесты. Любая функция системы, для которой нет тестов, считается несуществующей. Не должно существовать кода без тестов.

• Рефакторинг (refactoring) – постоянное улучшение качества кода с сохранением функциональности.

• Парное программирование (pair programming) – весь код пишется двумя программистами, работающими на одном компьютере.

• Коллективное владение кодом (collective ownership) – любой разработчик может улучшать любой код системы в любое время.

• Непрерывная интеграция (continuous integration) – как только код написан и протестирован, он интегрируется в общую систему. После интеграции код обновляется у всех разработчиков, т.е. в любой момент времени все разработчики работают с актуальной версией кода.

• 40-часовая рабочая неделя (no overtime) – внеурочная работа способствует ухудшению психологического климата в команде. Невозможность планирования рабочего времени отрицательно сказывается на результатах работы.

• Доступный заказчик (on-site customer) – в команде все время должен находиться представитель заказчика, действительно готовый отвечать на вопросы.

• Стандарты кодирования (coding standards) – весь код должен быть написан в едином стиле.

В экстремальном программировании применяются и многие другие методики, но по крайней мере перечисленные должны применяться совместно и интенсивно, иначе эффект не будет достигнут.