Технология разработки программного обеспечения

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

2.4.5. Оценка моделей процесса

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

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

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

До сих пор эти различные модели довольно мало сравнивались в количественном отношении. Некоторые начальные эксперименты Боэма выявили большую продуктивность каскадного жизненного цикла по сравнению с эволюционным циклом, основанным на прототипировании и использовании языков четвертого поколения в области интерактивных продуктов для конечных пользователей. Результаты показали, что при каскадном подходе осуществлялось лучшее взаимодействие с продуктом и управление рисками, в то время как принцип создания прототипов лучше взаимодействовал с пользовательскими интерфейсами. При применении последнего подхода появилась возможность экономить время, затрачиваемое на второстепенные аспекты разработки, и уделять больше внимания по-настоящему важным проблемам и рискам. Кроме этого, оба проекта имеют приблизительно одинаковую продуктивность в том, что касается скорости передачи исходных инструкций. Они также обладают сравнимой производительностью, однако эволюционный процесс требует на 40 % меньше времени на разработку, и конечный продукт имеет приблизительно на 40 % меньше исходных инструкций. Каскадный процесс сталкивается с меньшим количеством проблем при отладке и интегрировании по причине более продуманного дизайна.

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

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

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

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

Также важно подчеркнуть, что отказ от дисциплинированного подхода, заложенного в каскадной модели, не подразумевает возвращения к использованию "недисциплинированных" методов (например модели кодирования и исправления). Задача разработки по-прежнему разбивается по видам деятельности: анализ требований и спецификация, проектирование, реализация модулей, тестирование модулей, проверка взаимодействия компонентов системы и т. д. Осуществляется систематизированное управление каждым видом деятельности с использованием инструментов и методов. Меняется только разбиение процесса на фазы, внутри которых осуществляются указанные виды деятельности, порядок расположения фаз и правила перехода от одной фазы к другой. Например, в случае инкрементной разработки не весь объем анализа требований и спецификации предшествует собственно проектированию и, в свою очередь, не весь процесс проектирования предшествует реализации. Скорее всего, если приложение можно естественным образом разбить на подсистемы, то тогда станет возможным организовать процесс как последовательность "мини-каскадных" процессов, каждый из которых будет отвечать за разработку конкретной подсистемы, начиная с подсистемы, обеспечивающей выполнение основополагающих функций, с последующим распространением на другие части. Другие стратегии разработки также имеют право на существование, в зависимости от природы решаемой проблемы. В качестве заключительного замечания будет рассмотрено возможное использование каскадной модели в качестве эталонной. Парнас (Parnas) и Клементс (Clements) [1986] обратили внимание на то, что каскадный жизненный цикл определяет весьма идеализированный процесс, и вряд ли кому-то вообще удастся увидеть проект программного обеспечения, который развивался бы в соответствии с его принципами. Однако каскадную модель жизненного цикла можно использовать для апостериорного описания логического обоснования любого проекта. Документацию последнего можно будет структурировать в соответствии с идеализированным процессом, даже если фактический процесс не выполнялся как линейная последовательность шагов. При следовании структуре идеализированного процесса документация приобретает нужную структурированность и становится абсолютно понятной. В соответствии с мнением Парнаса и Клементса, реальный процесс можно подделать, если создать такую документацию, по которой производственный процесс можно было бы осуществлять в идеальных условиях. Документация, созданная способом, отражающим идеальный и чисто рациональный каскадный процесс, помогает понять систему, независимо от процесса, который применялся при создании данной системы. Кроме того, Парнас и Клементс сделали вывод о том, что информация о реальном производственном процессе заслуживает тщательного документирования: "Мы вырабатываем политику записи всех рассмотренных и отвергнутых альтернативных вариантов проектирования. Для каждого из них поясняется как причина рассмотрения, так и последующего отказа. Спустя несколько месяцев, недель или часов, можно легко выяснить, почему было сделано то-то и то-то. Через годы у специалиста по сопровождению возникнут те же вопросы, что и у нас, и он сможет легко найти на них ответы в документации".

Выводы

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

Вопросы для самоконтроля к главе 2:

1. Поясните в зачем необходим анализ осуществимости проекта?
2. Что является результатом стадии анализа осуществимости?
3. Зачем необходима выработка требований проекта?
4. Что является результатом этапа выработки требований?
5. Какие пункты может содержать спецификация требований?
6. На каком этапе вырабатывается первоначальный план испытаний системы?
7. Что является результатом этапа проектирования программной системы?
8. Чем отличается тестирование черного ящика от тестирования прозрачного ящика?
9. Какие типы верификации вы знаете?
10. Чем отличается модульное тестирование от системного тестирования?
11. Кто должен выполнять бета-тестирование и почему?
12. Дайте определение технической поддержке согласно IEEE. В чем заключается этап технического обслуживания ПО?
13. Опишите каскадные модель процесса разработки.
14. Какими недостатками обладают каскадные модели?
15. Опишите эволюционные модели.
16. Чем отличаются каскадные модели от эволюционных? Есть ли что-то общее между ними?
17. Опишите модель основанную на преобразовании.
18. Опишите спиральную модель процесса разработки ПО.

3. Унифицированный язык моделирования

Унифицированный язык моделирования (UML) - это семейство графических нотаций, в основе которого лежит единая метамодель. Он помогает в описании и проектировании программных систем, в особенности систем, построенных с использованием объектно-ориентированных (00) технологий. Это определение в чем-то упрощенное. В действительности разные люди могут видеть в UML разные вещи. Это является следствием, как собственной истории развития языка, так и различных точек зрения специалистов на то, что делает процесс разработки программного обеспечения эффективным.

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

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

UML представляет собой относительно открытый стандарт, находящийся под управлением группы OMG (Object Management Group – группа управления объектами), открытого консорциума компаний. Группа OMG была сформирована для создания стандартов, поддерживающих межсистемное взаимодействие, в частности взаимодействие объектно-ориентированных систем. Возможно, группа OMG более известна по стандартам CORBA (Common Object Request Broker Architecture - общая архитектура посредников запросов к объектам).

UML появился в результате процесса унификации множества объектно-ориентированных языков графического моделирования, процветавших в конце 80-х и в начале 90-х годов.

3.1 Способы применения UML

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

Чтобы разрешить эту сложную ситуацию, Стив Меллор (Steve Mellor) и Мартин Фаулер (Martin Fowler) независимо пришли к определению трех режимов использования UML разработчиками: режим эскиза, режим проектирования и режим языка программирования. Безусловно, самый главный из трех – это режим использования UML для эскизирования. В этом режиме разработчики используют UML для обмена информацией о различных аспектах системы. В режиме проектирования можно использовать эскизы при прямой и обратной разработке. При прямой разработке {forward-engineering) диаграммы рисуются до написания кода, а при обратной разработке (re verse-engineering) диаграммы строятся на основании исходного кода, чтобы лучше понять его.

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

При обратной разработке вы используете эскизы, чтобы объяснить, как работает некоторая часть системы. Вы показываете не все классы, а только те, которые представляют интерес и которые стоит обсудить перед тем, как погрузиться в код. Поскольку эскизирование носит неформальный и динамичный характер и вам нужно делать это быстро и совместно, то наилучшим средством отображения является доска. Эскизы полезны также и в документации, при этом главную роль играет процесс передачи информации, а не полнота. Инструментами эскизного моделирования служат облегченные средства рисования, и часто разработчики не очень придерживаются всех строгих правил UML. Cила эскизов в избирательности передачи информации, а не в полноте описания.

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

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

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