2. Жизненный цикл программного
обеспечения — период времени, который
начинается с момента принятия решения о
необходимости создания программного продукта
и заканчивается в момент его полного изъятия из
эксплуатации. Этот цикл — процесс построения и
развития программного обеспечения(ПО).
3. Обобщенный жизненный цикл можно представить в
виде следующей последовательности этапов,
которые, в свою очередь, можно также разбить на
стадии:
1. планирование разработки;
2. определение требований к системе;
2.1 выработка требований
2.2 анализ требований
3. проектирование системы;
3.1 проектирование архитектуры системы;
4. 3.2 детальное проектирование компонент системы, в
т.ч. для программного обеспечения;
- общее проектирование программного обеспечения;
- проектирование отдельных программных
компонент;
4. реализация и тестирование системы;
4.1 создание отдельных компонент системы, в т.ч. для
программного обеспечения;
- создание отдельных программных модулей;
- тестирование отдельных программных модулей;
5. 4.2 тестирование компонент системы, в т.ч.
программного обеспечения как единого компонента
системы;
4.3 интегрирование отдельных компонент в систему;
5. выпуск системы;
6. эксплуатация системы;
7. завершение разработки.
6. ISO/IEC 12207 «System and software
engineering — Software life cycle
processes» — стандарт ISO,
описывающий процессы жизненного
цикла ПО.
7. Данный стандарт устанавливает общую структуру
процессов жизненного цикла программных средств, на
которую можно ориентироваться в программной
индустрии. Стандарт определяет
- процессы;
- виды деятельности и задачи, которые используются
при приобретении программного продукта или услуги,
а также при поставке, разработке, применении по
назначению, сопровождении и прекращении
применения программных продуктов.
8. Модель жизненного цикла программного
обеспечения — структура, содержащая процессы
действия и задачи, которые осуществляются в ходе
разработки, использования и сопровождения
программного продукта.
Эти модели можно разделить на 3 основных
группы:
- инженерный подход;
- c учетом специфики задачи;
- cовременные технологии быстрой разработки.
9. Совершенно простая модель, характерная для
студентов. Именно по этой модели большинство
студентов разрабатывают лабораторные работы.
Данная модель имеет следующий алгоритм:
1. Постановка задачи
2. Выполнение
3. Проверка результата
4. При необходимости переход к первому пункту
Модель устаревшая. Характерна для 1960-1970 гг.
инженерный подход
10. Алгоритм данного метода имеет ряд преимуществ перед алгоритмом
предыдущей модели, но также имеет и ряд весомых недостатков.
инженерный подход
11. Преимущества :
-Последовательное выполнение этапов проекта в
строгом фиксированном порядке
-Позволяет оценивать качество продукта на каждом
этапе
Недостатки :
-Отсутствие обратных связей между этапами
-Не соответствует реальным условиям разработки
программного продукта.
12. Данная модель является почти эквивалентной по
алгоритму предыдущей модели, однако при этом
имеет обратные связи с каждым этапом жизненного
цикла, при этом порождает очень весомый
недостаток: 10-ти кратное увеличение затрат на
разработку.
инженерный подход
13. Данная модель имеет более приближенный к современным методам алгоритм,
однако все еще имеет ряд недостатков. Является одной из основных практик
экстремального программирования.
14. Модель на основе разработки
прототипа
Данная модель основывается на разработки
прототипов и прототипирования продукта.
Прототипирование используется на ранних стадиях
жизненного цикла программного обеспечения :
1. прояснить не ясные требования (прототип UI);
2. выбрать одно из ряда концептуальных
решений (реализация сцинариев);
3. проанализировать осуществимость проекта.
c учетом специфики задачи
15. Классификация протопипов:
- горизонтальные и вертикальные
- одноразовые и эволюционные
- бумажные и раскадровки
Горизонтальные прототипы — моделирует
исключительно UI не затрагивая логику обработки и базу
данных.
Вертикальные прототипы — проверка архитектурных
решений.
Одноразовые прототипы — для быстрой разработки.
Эволюционные прототипы — первое приближение
эволюционной системы.
16. Спиральная модель представляет собой процесс
разработки программного обеспечения, сочетающий
в себе как проектирование, так и постадийное
прототипирование с целью сочетания преимуществ
восходящей и нисходящей концепции.
c учетом специфики задачи
17.
18. Преимущества:
- Быстрое получение результата
- Повышение конкурентоспособности
- Изменяющиеся требования — не проблема
Недостатки:
- Отсутствие регламентации стадий
19. Инкрементная модель (англ. increment – увеличение,
приращение) подразумевает разработку информационной
системы с линейной последовательностью стадий, но в
несколько инкрементов (версий), т. е. с запланированным
улучшением продукта.
В начале работы над проектом определяются все
основные требования к системе, после чего выполняется ее
разработка в виде последовательности версий. При этом
каждая версия является законченным и работоспособным
продуктом. Первая версия реализует часть
запланированных возможностей, следующая версия
реализует дополнительные возможности и т. д., пока не
будет получена полная система.
c учетом специфики задачи
20.
21. Данная модель жизненного цикла характерна при разработке сложных
и комплексных систем, для которых имеется четкое видение (как со
стороны заказчика, так и со стороны разработчика) того, что собой
должен представлять конечный результат (информационная система).
Разработка версиями ведется в силу разного рода причин:
отсутствия у заказчика возможности сразу профинансировать весь
дорогостоящий проект;
отсутствия у разработчика необходимых ресурсов для реализации
сложного проекта в сжатые сроки;
требований поэтапного внедрения и освоения продукта конечными
пользователями. Внедрение всей системы сразу может вызвать у ее
пользователей неприятие и только «затормозить» процесс перехода на
новые технологии.
Достоинства и недостатки этой стратегии такие же, как и у
классической. Но в отличие от классической стратегии заказчик
может раньше увидеть результаты. Уже по результатам разработки и
внедрения первой версии он может незначительно изменить
требования к разработке, отказаться от нее или предложить
разработку более совершенного продукта с заключением нового
договора.
22. Третьей группе принадлежат такие
модели как экстремальное
программирование (XP), SCRUM,
инкриментальная модель(RUP)
