2015-04-20
2003
Таблица 1.1 Взаимосвязи между стадиями и процессами ЖЦ ПО
| Наименование процессов и действий | Стадия | ||||||
| Ф | П | Р | Т | В | Э | С | |
| Основные процессы | |||||||
| Приобретение | |||||||
| Инициирование приобретения | • | ||||||
| Подготовка заявочных предложений | • | ||||||
| Подготовка и корректировка договора | • | ||||||
| Надзор за деятельностью поставщика | • | • | • | • | • | ||
| Приемка и завершение работ | • | • | |||||
| Поставка | |||||||
| Инициирование поставки | • | ||||||
| Подготовка ответа на заявочные предложения | • | ||||||
| Подготовка договора | • | ||||||
| Планирование | • | ||||||
| Выполнение и контроль | • | • | • | • | • | ||
| Проверка и оценка | • | • | • | • | • | ||
| Поставка и завершение работ | • | . • | |||||
| Разработка | |||||||
| Подготовительная работа | • | ||||||
| Анализ требований к системе | • | • | |||||
| Проектирование архитектуры системы | • | ||||||
| Анализ требований к ПО | • | • | |||||
| Проектирование архитектуры ПО | • | ||||||
| Детальное проектирование ПО | • | ||||||
| Кодирование и тестирование ПО | • | ||||||
| Интеграция ПО | • | ||||||
| Квалификационное тестирование ПО | • | • | |||||
| Интеграция системы | • | ||||||
| Квалификационное тестирование системы | • | • | |||||
| Установка ПО | • | ||||||
| Приемка ПО | • | ||||||
| Эксплуатация | |||||||
| Подготовительная работа | • | ||||||
| Эксплуатационное тестирование | • | ||||||
| Эксплуатация системы | • | ||||||
| Поддержка пользователей | • | ||||||
| Сопровождение | |||||||
| Подготовительная работа | • | • | |||||
| Анализ проблем и запросов на модификацию ПО | • | • | |||||
| Модификация ПО | • | • | |||||
| Проверка и приемка | • | • | |||||
| Перенос ПО в другую среду | • | ||||||
| Снятие ПО с эксплуатации | • | ||||||
| Вспомогательные процессы | |||||||
| Документирование | |||||||
| Подготовительная работа | • | • | • | • | • | • | • |
| Проектирование и разработка | • | • | • | • | • | • | • |
| Выпуск документации | • | • | • | • | • | • | • |
| Сопровождение | • | • | • | • | • | • | • |
| Управление конфигурацией | |||||||
| Подготовительная работа | • | ||||||
| Идентификация конфигурации | • | ||||||
| Контроль конфигурации | • | • | • | • | • | ||
| Учет состояния конфигурации | • | • | • | • | • | ||
| Оценка конфигурации | • | • | • | • | • | ||
| Управление выпуском и поставка | • | • | • | ||||
| Обеспечение качества | |||||||
| Подготовительная работа | • | • | |||||
| Обеспечение качества продукта | • | • | • | • | • | • | • |
| Обеспечение качества процесса | • | • | • | • | • | • | • |
| Обеспечение прочих показателей качества системы | • | • | • | • | • | • | • |
| Верификация | |||||||
| Подготовительная работа | • | • | • | • | • | • | |
| Верификация | • | • | • | • | • | • | |
| Аттестация | |||||||
| Подготовительная работа | • | ||||||
| Аттестация | • | • | |||||
| Совместная оценка | |||||||
| Подготовительная работа | • | • | • | • | • | • | |
| Оценка управления проектом | • | • | • | • | • | • | |
| Техническая оценка | • | • | • | • | • | • | |
| Аудит | |||||||
| Подготовительная работа | • | • | • | • | • | • | |
| Аудит | • | • | • | • | • | • | |
| Разрешение проблем | |||||||
| Подготовительная работа | • | • | • | • | • | • | |
| Разрешение проблем | • | • | • | • | • | • | |
| Организационные процессы | |||||||
| Управление | |||||||
| Инициирование и определение области управления | • | • | • | • | • | • | |
| Планирование | • | • | • | • | • | • | • |
| Выполнение и контроль | • | • | • | • | • | • | • |
| Проверка и оценка | • | • | • | • | • | • | • |
| Завершение | • | • | |||||
| Создание инфраструктуры | |||||||
| Подготовительная работа | • | ||||||
| Создание инфраструктуры | • | • | |||||
| Сопровождение инфраструктуры | • | • | • | • | • | • | |
| Усовершенствование | |||||||
| Создание процесса | • | • | |||||
| Оценка процесса | • | • | • | • | • | • | |
| Усовершенствование процесса | • | • | • | • | • | ||
| Обучение | |||||||
| Подготовительная работа | • | • | • | • | |||
| Разработка учебных материалов | • | • | • | • | |||
| Реализация плана обучения | • | • | • | • | • | • | • |
К настоящему времени наибольшее распространение получили следующие две основные модели ЖЦ ПО: каскадная модель (1970 -1985 гг.) и спиральная модель (1986 — 1990 гг.).
|
|
|
|
|
|
В однородных ЭИС 70-х и 80-х гг. прикладное ПО представляло собой единое целое. Для разработки такого типа ПО применялся каскадный подход (другое название — водопад (waterfall)) (рис. 1.3). Принципиальной особенностью каскадного подхода является следующее: переход на следующую стадию осуществляется только после того, как будет полностью завершена работа на текущей стадии, и возвратов на пройденные стадии не предусматривается. Каждая стадия заканчивается получением некоторых результатов, которые служат в качестве исходных данных для следующей стадии. Требования к разрабатываемому ПО, определенные на стадии формирования требований, строго документируются в виде технического задания и фиксируются на все время разработки проекта. Каждая стадия завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков. Критерием качества разработки при таком подходе является точность выполнения спецификаций технического задания.
Рис. 1.3. Каскадная схема разработки ПО
При этом основное внимание разработчиков сосредоточивается на достижении оптимальных значений технических характеристик разрабатываемого ПО: производительности, объема занимаемой памяти и др.
|
|
|
Преимущества применения каскадного способа заключаются в следующем:
· на каждой стадии формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности;
· выполняемые в логичной последовательности стадии работ позволяют планировать сроки завершения всех работ и соответствующие затраты.
Каскадный подход хорошо зарекомендовал себя при построении ЭИС, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования, с тем чтобы предоставить разработчикам свободу реализовать их технически как можно лучше. В эту категорию попадают сложные системы с большим количеством задач вычислительного характера, системы реального времени и др.
В то же время этот подход обладает рядом недостатков, вызванных прежде всего тем, что реальный процесс создания ПО никогда полностью не укладывался в такую жесткую схему. Процесс создания ПО носит, как правило, итерационный характер: результаты очередной стадии часто вызывают изменения в проектных решениях, выработанных на более ранних стадиях. Таким образом, постоянно возникает потребность в возврате к предыдущим стадиям и уточнении или пересмотре ранее принятых решений. В результате реальный процесс создания ПО принимает иной вид (рис. 1.4).
Изображенную на рис. 1.4 схему часто относят к отдельной модели, так называемой модели с промежуточным контролем, в которой межстадийные корректировки обеспечивают большую надежность по сравнению с каскадной моделью, хотя и увеличивают весь период разработки.
Рис. 1.4. Реальный процесс разработки ПО
Основным недостатком каскадного подхода являются существенное запаздывание с получением результатов и, как следствие, достаточно высокий риск создания системы, не удовлетворяющей изменившимся потребностям пользователей. Практика показывает, что на начальной стадии проекта полностью и точно сформулировать все требования к будущей системе не удается. Это объясняется двумя причинами: 1) пользователи не в состоянии сразу изложить все свои требования и не могут предвидеть, как они изменятся в ходе разработки; 2) за время разработки могут произойти изменения во внешней среде, которые повлияют на требования к системе. В рамках каскадного подхода требования к ЭИС фиксируются в виде технического задания на все время ее создания, а согласование получаемых результатов с пользователями производится только в точках, планируемых после завершения каждой стадии (при этом возможна корректировка результатов по замечаниям пользователей, если они не затрагивают требования, изложенные в техническом задании). Таким образом, пользователи могут внести существенные замечания только после того, как работа над системой будет полностью завершена. В случае неточного изложения требований или их изменения в течение длительного периода создания ПО пользователи получают систему, не удовлетворяющую их потребностям. В результате приходится начинать новый проект, который может постигнуть та же участь.
|
|
|
Для преодоления перечисленных проблем в середине 80-х гг. была предложена спиральная модель ЖЦ (рис. 1.5). Ее принципиальной особенностью является следующее: прикладное ПО создается не сразу, как в случае каскадного подхода, а по частям с использованием метода прототипирования. Под прототипом понимается действующий программный компонент, реализующий отдельные функции и внешние интерфейсы разрабатываемого ПО. Создание прототипов осуществляется в несколько итераций, или витков спирали. Каждая итерация соответствует созданию фрагмента или версии ПО, на ней уточняются цели и характеристики проекта, оценивается качество полученных результатов и планируются работы следующей итерации. На каждой итерации производится тщательная оценка риска превышения сроков и стоимости проекта, чтобы определить необходимость выполнения еще одной итерации, степень полноты и точности понимания требований к системе, а также целесообразность прекращения проекта. Спиральная модель избавляет пользователей и разработчиков ПО от необходимости полного и точного формулирования требований к системе на начальной стадии, поскольку они уточняются на каждой итерации. Таким образом, углубляются и последовательно конкретизируются детали проекта, и в результате выбирается обоснованный вариант, который доводится до реализации.
Разработка итерациями отражает объективно существующий спиральный цикл создания системы. Неполное завершение работ на каждой стадии позволяет переходить на следующую стадию, не дожидаясь полного завершения работы на текущей. При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации. Главная же задача - как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований.
Спиральная модель не исключает использования каскадного подхода на завершающих стадиях проекта в тех случаях, когда требования к системе оказываются полностью определенными.
Основная проблема спирального цикла — определение момента перехода на следующую стадию. Для ее решения необходимо ввести временные ограничения на каждую из стадий жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков.
Рис. 1.5. Спиральная модель жизненного цикла программного обеспечения
1.2.2
ПОДХОД RAD
Одним из возможных подходов к разработке прикладного ПО в рамках спиральной модели ЖЦ является получивший широкое распространение способ так называемой быстрой разработки приложений, или RAD (Rapid Application Development). Подход RAD предусматривает наличие трех составляющих:
· небольших групп разработчиков (от 3 до 7 человек), выполняющих работы по проектированию отдельных подсистем ПО. Это обусловлено требованием максимальной управляемости коллектива;
· короткого, но тщательно проработанного производственного графика (до 3 месяцев);
· повторяющегося цикла, при котором разработчики по мере того, как приложение начинает обретать форму, запрашивают и реализуют в продукте требования, полученные в результате взаимодействия с заказчиком.
Команда разработчиков должна представлять собой группу профессионалов, имеющих опыт в проектировании, программировании и тестировании ПО, способных хорошо взаимодействовать с конечными пользователями и трансформировать их предложения в рабочие прототипы.
Жизненный цикл ПО в соответствии с подходом RAD включает четыре стадии:
1) анализ и планирование требований;
2) проектирование;
3) реализация;
4) внедрение.
На стадии анализа и планирования требований пользователи осуществляют следующие действия:
· определяют функции, которые должна выполнять система;
· выделяют наиболее приоритетные функции, требующие проработки в первую очередь;
· описывают информационные потребности. Формулирование требований к системе осуществляется в основном силами пользователей под руководством специалистов-разработчиков. Кроме того, на данной стадии решаются следующие задачи:
· ограничивается масштаб проекта;
· устанавливаются временные рамки для каждой из последующих стадий;
· определяется сама возможность реализации проекта в заданных размерах финансирования, на имеющихся аппаратных средствах и т.п.
Результатом стадии должны быть:
· список расставленных по приоритету функций будущего ПС ЭИС;
· предварительные модели ПО.
На стадии проектирования часть пользователей принимает участие в техническом проектировании системы под руководством специалистов-разработчиков. Для быстрого получения работающих прототипов приложений используются соответствующие инструментальные средства (CASE-средства). Пользователи, непосредственно взаимодействуя с разработчиками, уточняют и дополняют требования к системе, которые не были выявлены на предыдущей стадии. На данной стадии выполняются следующие действия:
· более детально рассматриваются процессы системы;
· при необходимости для каждого элементарного процесса создается частичный прототип: экранная форма, диалог, отчет, устраняющий неясности или неоднозначности;
· устанавливаются требования разграничения доступа к данным
· определяется состав необходимой документации.
После детального определения состава процессов оценивает количество так называемых функциональных точек (function point) разрабатываемой системы и принимается решение о разделении ЭИС на подсистемы, поддающиеся реализации одной командой разработчиков за приемлемое для RAD-проектов время (до 3 месяцев). По функциональной точкой понимается любой из следующих элементов разрабатываемой системы:
· входной элемент приложения (входной документ или экранная форма);
· выходной элемент приложения (отчет, документ, экранная форма)
· запрос (пара "вопрос/ответ");
· логический файл (совокупность записей данных, используемая внутри приложения);
· интерфейс приложения (совокупность записей данных, передаваемых другому приложению или получаемых от него).
Далее проект распределяется между различными командами разработчиков. (Опыт разработки крупных ЭИС показывает, что для повышения эффективности работ необходимо разбить проект на отдельные слабо связанные по данным и функциям подсистемы. Реализация подсистем должна выполняться отдельными группами специалистов. При этом необходимо обеспечить координацию ведения общего проекта и исключить дублирование результатов работ каждой проектной группы, которое может возникнуть в силу наличия общих данных и функций.) В случае использования CASE-средств это означает деление функциональной модели системы (диаграммы потоков данных для структурного подхода (см. главу 2) или диаграммы вариантов использования для объектно-ориентированного подхода (см. главу 3)). Результатом данной стадии должны быть:
· общая информационная модель системы;
· функциональные модели системы в целом и подсистем, реализуемых отдельными командами разработчиков;
· точно определенные интерфейсы между автономно разрабатываемыми подсистемами;
· построенные прототипы экранных форм, отчетов, диалогов.
Все модели и прототипы должны быть получены с применением тех CASE-средств, которые будут использоваться в дальнейшем при построении системы. Данное требование обусловлено необходимостью избежать неконтролируемого искажения данных при передаче информации о проекте со стадии на стадию.
В отличие от имевшего место ранее подхода, при котором использовались специфические средства прототипирования, не предназначенные для построения реальных приложений, а прототипы выбрасывались после того, как выполняли задачу устранения неясностей в проекте, в подходе RAD каждый прототип развивается в часть будущей системы. Таким образом, на следующую стадию передается более полная и полезная информация.
На стадии реализации выполняется непосредственно сама быстрая разработка приложения:
· разработчики производят итеративное построение реальной системы на основе полученных на предыдущей стадии моделей, а также требований нефункционального характера (требований к надежности, производительности и т.п.);
· пользователи оценивают получаемые результаты и вносят коррективы, если в процессе разработки система перестает удовлетворять определенным ранее требованиям.
Тестирование системы осуществляется в процессе разработки.
После окончания работ каждой отдельной команды разработчиков производится постепенная интеграция данной части системы с остальными, формируется полный программный код, выполняется тестирование совместной работы данной части приложения, а затем тестирование системы в целом. Реализация системы завершается выполнением следующих работ:
· осуществляется анализ использования данных и определяется необходимость их распределения;
· производится физическое проектирование базы данных;
· формулируются требования к аппаратным ресурсам;
