1. Життєвий цикл
розробки. Основні етапи життєвого циклу
ПЗ. Задачі кожного етапу.
Жизненный цикл программного обеспечения (ПО) — период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации[1]. Этот цикл — процесс построения и развития ПО.
Життєвий цикл ПЗ (Software Life Cycle) - період розробки й експлуатації програмного забезпечення, у якому зазвичай виділяють етапи:
розробка вимог або технічного завдання;
розробка системи або технічного проекту;
програмування або робоче проектування;
пробна експлуатація або тестування;
супровід та вдосконалення;
зняття з експлуатації.
розробка вимог або технічного завдання — это сбор требований к ПО, их систематизация, выявление противоречий, недостающей информации и т.п. розробка вимог або технічного завдання делится на три фазы: сбор, анализ и документирование.
розробка системи або технічного проекту - подразумевает собой описание свойств будущей системы, на основе анализа требований — результата предыдущего этапа
програмування або робоче проектування — это непосредственно кодирование (или программирование) — процесс написания программного кода на определённом языке программирования, с целью реализации алгоритмов, определённых на предыдущем этапе — проектировании
Тестирование — проверка и испытание законченного продукта на предмет его качества: устойчивости к нагрузкам, дружественности к пользователю (юзабилити), безопасности (устойчивости к взломам), соответствию требованиям и т.п.
Внедрение — это процесс установки и настройки программного продукта, для конкретных условий использования. Также, под внедрением подразумевают обучение пользователей работе с данным продуктом
Сопровождение — процесс поддержки программного продукта. На данном этапе устраняются ошибки («баги»), вносятся изменения с целью улучшить продукт. Эта стадия в жизненном цикле, как правило, занимает большую часть времени
Стандарт ГОСТ 34.601-90 предусматривает следующие стадии и этапы создания автоматизированной системы:
Форирование требований к АС
1. Обследование объекта и обоснование необходимости создания АС
2. Формирование требований пользователя к АС
3. Оформление отчета о выполнении работ и заявки на разработку АС
2. Разработка концепции АС
1. Изучение объекта
2. Проведение необходимых научно-исследовательских работ
3. Разработка вариантов концепции АС и выбор варианта концепции АС, удовлетворяющего требованиям пользователей
4. Оформление отчета о проделанной работе
3. Техническое задание
1. Разработка и утверждение технического задания на создание АС
4. Эскизный проект
1. Разработка предварительных проектных решений по системе и ее частям
2. Разработка документации на АС и ее части
5. Технический проект
1. Разработка проектных решений по системе и ее частям
2. Разработка документации на АС и ее части
3. Разработка и оформление документации на поставку комплектующих изделий
4. Разработка заданий на проектирование в смежных частях проекта
6. Рабочая документация
1. Разработка рабочей документации на АС и ее части
2. Разработка и адаптация программ
7. Ввод в действие
1. Подготовка объекта автоматизации
2. Подготовка персонала
3. Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями)
4. Строительно-монтажные работы
5. Пусконаладочные работы
6. Проведение предварительных испытаний
7. Проведение опытной эксплуатации
8. Проведение приемочных испытаний
8. Сопровождение АС.
1. Выполнение работ в соответствии с гарантийными обязательствами
2. Послегарантийное обслуживание
Эскизный, технический проекты и рабочая документация — это последовательное построение все более точных проектных решений. Допускается исключать стадию «Эскизный проект» и отдельные этапы работ на всех стадиях, объединять стадии «Технический проект» и «Рабочая документация» в «Технорабочий проект», параллельно выполнять различные этапы и работы, включать дополнительные.
2. Моделі на основі інженерного підходу (Модель «кодування-усунення помилок», каскадна модель, V-подібна модель).
Модель «кодування-усунення помилок»
1) поставити завдання;
2) виконувати його до успішного завершення або скасування;
3) перевірити результат;
повторити при необхідності з 1-го кроку.
Каскадна модель
Тестування – це виконання програми для виявлення дефектів у функціях, логіці і формі реалізації програмного продукту.
Супровід - це внесення змін до ПЗ, що експлуатується. Цілі таких змін:
Ø виправлення помилок;
Ø адаптація до змін зовнішнього до ПЗ середовища;
Ø вдосконалення ПЗ за вимогами замовника.
Супровід ПЗ полягає в повторному застосуванні кожного з попередніх кроків (етапів) життєвого циклу до існуючої програми, але не в розробці нової програми.
Переваги класичного життєвого циклу:
Ø чіткий план і часовий графік для всіх етапах проекту;
Ø впорядковує хід конструювання.
Недоліки класичного життєвого циклу:
Ø реальні проекти часто вимагають відхилення від стандартної послідовності кроків;
Ø цикл базується на точному формулюванні вихідних вимог до ПЗ (реально на початку проекту вимоги замовника визначені лише частково);
результати проекту доступні замовникові тільки в кінці роботи.
Переваги каскадної моделі:
Добре відома користувачам, що не мають відношення до розробки та експлуатації програми та кінцевім користувачам.
Добре спрацьовує для тих проектів, які достатньо зрозумілі, але трудно разрешимы.
Відрізняється стабільністю вимог.
Добре спрацьовує тоді, коли вимоги до якості домінують над вимогами до витрат та графіку виконання проекта.
Спрощує роботу менеджера проекту з складання плану та комплектації команди розробників.
Недоліки каскадної моделі:
В основі моделі лежить лінійна структура, в результаті чого кожна спроба повернутись на одну чи дві фази назад, щоб виправити какую-либо проблему або недолік приведе до значного збільшення затрат та сбою у графику.
Може створити помилкове враження про роботу над проектом.
Користувачі не можуть переконатися в якості розробленого проекту до завершення процесу розробки. У користувача нема можливості поступово звикнути до системи тому що процес навчання в кінці розробки системи.
Всі вимоги мають бути відомі на початку життєвого циклу.
Весь продукт розробляється за один раз, нема можливості розбити його на частини.
Кількість документації може бути надлишковою.
Нема проміжних фаз між етапами.
Коли застосовується каскадна модель:
Перенесення існуючого продукту на нову платформу.
Створення та випуск нової версії вже існуючого продукту.
V-подібна модель
Переваги класичного життєвого циклу:
Ø модель визначає продукти, які повинні бути отриманими в результаті процесу розробки, причому кожні отримані данні тестуються;
Недоліки класичного життєвого циклу:
Ø неможливе застосування з паралельними подіями;
Ø не враховані ітерації між фазами;
Ø не передбачено внесення змін вимог динамічних змін на різних етапах життєвого циклу;
Ø В модель не входять дії, які напрямлені на аналіз ризиків.
Особливе значення надається діям, спрямованим на верифікацію та атестацію продукту.
План испытания приемки заказчиком разрабатывается на этапе планирования а компоновочного системы на фазе. Этот процесс разработки обозначен пунктирной линией
Планирование проекта.. Определяются системные требования и то, каким образом будут распределены ресурсы организации с целью их соответствия поставленным требованиям
Анализ требований.. Анализ существующей на данный момент проблемы с ПО завершается полной спецификацией ожидаемой линии поведения создаваемой внешней программной системы.
Розраб.. Определяет каким образом функции ПО должны применяться при реализации проекта.
Детализир. Определяет и документально обосновывает алгоритмы для каждого компонента, который был определен на фазе построения архитектуры.
Кодир.. Выполняется преобразование алгоритмов в готовое ПО.
Модульное тестирование, проверка каждого закодированного модуля на наличие ошибок.
Интегр. Установка взаимосвязи между группами ранее поэлементно испытанных модулей с целью подтверждения того, что группы работают так же хорошо, как и модули, испытанные независимо
Сист. Проверка функционирования программной системы в целом.
Експ. Допускается модернизация и внесение поправок.
Приемочное тестиров. Позволяет пользователю протестировать функциональные возможности системы на соответствие исходным требованиям.
Когда логично применять:
Эффективна в случае, когда доступными являются информация о методе реализации решения и технология, а персонал владеет необходимыми умениями роботы с этой технологией.