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

Другой тип классификации затрат на сопровождение был описан в работе Линца (Lienz) и Свонсона (Swanson) в 1980 г. Их анализ показал, что порядка 42 % затрат относятся на внесение изменений в требования пользователей, 17 % — на изменение формата данных, 12 % — на устранение аварийных неполадок, 9 % — на отладку процедур, 6 % — на модификацию аппаратных средств, 5 % — на исправление документации, 4 % — на повышение производительности и остальное — на прочие причины.

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

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

2.3.7. Прочие виды деятельности

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

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

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

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

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

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

2.4 Обзор моделей процесса производства программного обеспечения

2.4.1. Каскадные модели

Принцип каскадных (waterfall) моделей, ставший популярным в 1970-х гг., по-прежнему рассматривается как эталонный в большинстве учебников по программированию и используется в качестве стандарта в производственной практике. Впервые это понятие появилось в литературе конца 1950-х гг. в результате опыта разработки крупной автоматизированной системы ПВО под названием SAGE (Semi-Automated Ground Environment, полуавтоматическая наземная среда).

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

Рис 3. Каскадный процесс

На схеме показаны следующие фазы:

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

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

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

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

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

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

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

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

2.4.1.1 Критическая оценка каскадной модели

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

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

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

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

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

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

Рис 4. Каскадный процесс с явно выраженными обратными связями

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

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