МОДЕЛИ ЖЦ ПО

Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО (под моделью ЖЦ понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ.

Модель ЖЦ зависит от специфики ИС и специфики условий, в которых последняя создается и функционирует). Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки. Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.

К настоящему времени наибольшее распространение получили следующие модели ЖЦ:

- каскадная (водопадная) модель (70-85 г.г.);

- спиральная модель (86-90 г.г.).

- инкрементальная модель

Каскадная модель процесса

Анализ требований - сбор требований к продукту. Результатом анализа, как правило, является некоторый текст/документ(ТЗ).

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

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

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

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

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

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

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

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

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

Спиральная модель.

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

Для этого может быть несколько причин:

- необходимость предупреждения рисков;

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

Версии продукта называют прототипами. Каждый виток спирали соответствует созданию фрагмента или версии ПО.

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

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

Т.о. уточняется план-график дальнейшей работы.

Минусы:

1. Требуется более искусное управление

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

3. Трудность в определении момента перехода на следующий этап.

4. Переход осуществляется в соответствии с планом даже если не все работы выполнены.

5. Слишком большое количество витков потребует увеличения затрат, больших затрат.

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

Инкрементальная модель.

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

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

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

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

Инкрементальная разработка проходит лучше всего, если следующая стадия п+1 начинается по возможности после того, как обновление всех модулей на стадии п закончено, и хуже всего, если время, требуемое на обновление модулей, значительно превышает выбранный интервал. Для того чтобы убедиться в этом, представьте, что необходимо изменить модуль 789, который зависит от семи других модулей: 890, 23, 489, 991, 7653, 2134 и 2314. Если изменение занимает девять недель, то модуль 789 должен быть построен исходя из предполагаемого состояния всех семи модулей через девять недель. Эту работу очень трудно скоординировать, так как каждая из семи частей может быть изменена до девяти раз (еженедельно), причем каждое новое изменение может основываться на исследовании эффективности предыдущих изменений.

1 План управления программным проектом

2 Проектная документация программного обеспечения

3 Спецификация требований к программному обеспечению

 

Развитие инкрементального подхода. XP-процессы.

- экстремальное программирование XP (Кент Бек, 1999). Оно ориентировано на очень малые приращения функциональности.

- модель быстрой разработки приложений RAD (Rapid Application Development). RAD-модель обеспечивает эстремально короткий цикл разработки. Быстрая разработка достигается за счет использования компонентно ориентированного конструирования. Если требования полностью определены, а проектная область ограничена, RAD- процесс позволяет группе создать полностью функциональную систему за 60-90 дней.

Выделяют следующие этапы:

- бизнес-моделирование. Моделируются информационные потоки между бзнесм-функциями.

- моделирование данных. Информационный поток отображается в набор объектов данных.

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

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

- тестирование и объединение. Применение повторно используемых компонентов уменьшает время тестирования.

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

Недостатки применения RAD:

1. Для больших проектов требуются значительные людские ресурсы для создания групп.

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

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

В современной программной инженерии выделяют два семейства процессов разработки:

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

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

Экстремальное программирование - это облегченный процесс (Кент Бек, 1999). Он ориентирован на группы малого и среднего размера, работающие в условиях неопределенных и быстро изменяющихся требований. В группу входит до 10 сотрудников, работающих в одном помещении.

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

Базовые действия на каждой итерации: кодирование, тестирование, выслушивание заказчика, проектирование.

Динамизм обеспечивается следующими характеристиками:

- непрерывная связь с заказчиком;

- простота (всегда выбирается минимальное решение)

- быстрая обратная связь (модульное и функциональное тестирование)

- смелость в проведении профилактики возможных проблем.

Базис XP образуют 12 методов:

1. Игра планирования - Локальный заказчик обеспечивает набор "истории", которые описывают требуемую функциональность. К каждой новой версии в текущий набор "историй" вносятся наиболее важные истории.

2. Частая смена версий новые версии каждые 2 недели.

3. Метафора -вся разработка проводится на основе простой общедоступной истории о том как работает система. Истории обеспечивают заказчики.

4. Простое проектирование

5. Тестирование - непрерывное написание тестов для модулей. Входным критерием для написания кода является отказавший тестовый вариант. Заказчики участвуют в тестировании.

6. Реорганизация - система реструктуризируется, но ее поведение не меняется. Цель упростить систему, улучшить взаимодействие или добавить в нее гибкость.

7. Парное программирование -весь код пишется двумя программистами, работающими на одном компьютере.. Оно приводит к повышению качества и уменьшению времени цикла на 40-50%, при увеличении затрат на ресурсы на 15%

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

9. Непрерывная интеграция -интегрирование системы несколько раз в день по мере завершения каждой задачи.

10. 40-часовая неделя -нельзя работать сверхурочно.

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