Архитектуры и модели программ и знаний
Лекция 3
Классический жизненный цикл разработки программ и жизненный цикл в трактовке Trustworthy Computing (SDL)
Сафонов Владимир Олегович
Профессор кафедры информатики Заведующий лабораторией Java-технологии
(http://polyhimnie.math.spbu.ru/jtl)
Санкт-Петербургский государственный университет
Email: vosafonov@gmail.com
WWW: http://www.vladimirsafonov.org
Классическая “водопадная” схема жизненного цикла разработки программы (1970е – 1980е гг.)
Требования и целиСпецификацияПроектированиеРеализацияТестирование (верификация)Производство и выпуск
Сопровождение (поддержка)
(C) Сафонов В.О. 2012
Водопадная модель: Требования и цели
Начальный этап разработкиВыработка документа (либо формализованного описания), в
котором сформулированы технические, финансовые, пользовательские, рыночные и другие требования к будущей программной системеДокумент является соглашением между заказчиком и разработчиком
Практическая форма воплощения данного этапа в фирмах- разработчиках ПО – Marketing Requirements Document (MRD)
Если на данном этапе предварительный анализ покажет нецелесообразность разработки нового ПО, разработка выполняться не будетВ последнее время развивается инженерный подход к данному
этапу – Requirements Engineering, основанный на использовании формальных методов (языков спецификаций и моделирования, в том числе – математических моделей)
(C) Сафонов В.О. 2012
Водопадная модель: Спецификация
Разработка формализованного, точного и полного, внешнего
описания разрабатываемой программной системы (описания того, ЧТО система должна выполнять, без описания того КАК), т.е. Спецификация не содержит описания реализации системыДля спецификации используются формальные методы – математические модели (таблицы, графы, алгебраические системы, логические исчисления и др.)
Спецификация должна выполняться специалистами, имеющими соответствующее математическое образование
Популярные языки спецификаций :
UML (язык моделирования архитектуры программ и процесса разработки),
SDL (язык спецификаций телекоммуникационных систем)MSC (язык спецификаций систем, основанных на передаче сообщений)
OBJ (J.A. Goguen) – язык алгебраических спецификаций
(C)Сафонов В.О. 2012
Водопадная модель: Проектирование
Дизайн внутренней архитектуры (реализации) программной системы – модулей, их взаимосвязей, структур и потоков данных, алгоритмовОсновные методы: проектирование сверху вниз, снизу вверх, расширение ядраПример метода проектирования снизу вверх:
структурное программирование (проектирование) и пошаговая детализацияРезультат данного этапа: логический проект системы, ее архитектура
Примеры концепций этапа проектирования:
иерархия классов (ООП); интерфейс
(C) Сафонов В.О. 2012
Водопадная модель: Реализация (кодирование)
Программирование (кодирование) системы по ее проекту на выбранном языке реализации (C#, Java, C++ и др.)
Ключевые проблемы: выбор языка реализации, стиль программированияТрудоемкость (по времени и людским ресурсам): 10-15% от трудоемкости всей системы
Качество выполнения данного этапа определяет качество всей программной системы; не следует доверять реализацию новичкам, а опытных программистов превращать в “системных аналитиков” и административных начальников
(C) Сафонов В.О. 2012
Водопадная модель: Тестирование (верификация)
Проверка корректности программной системы,
разработанной на предыдущих этапах
(Формальная) верификация – автоматическая проверка корректности программ, т.е. соответствия ее реализации
ее (формальным) спецификациям; несколько десятков лет
в промышленных разработках не использовалась, ввиду
сложности формальных методов; в настоящее время начинает использоваться, благодаря появлению
инструментов (например, Spec# - расширения C#
формальными спецификациями в стиле design-by-contractТестирование – либо альтернатива формальной верификации, либо дополнение к ней. Проверка
корректности программы на основе пропуска набора
тестов (программа корректна, если все тесты проходят)
(C) Сафонов В.О. 2012
Водопадная модель: Производство и выпуск
Разработка программной документации
Оформление текущего состояния разработанного
продукта в виде очередной версииПоставка текущей версии пользователям
Виды и номера версий: major release – версия со
значительными новыми возможностями, например: 2.0; minor release – версия с небольшими нововведениями, например, 2.1; bug fix release – версия, в которой нет новых
возможностей, а есть лишь исправления, например: 2.1.1
Стадии готовности версии продукта: early access, alpha, beta, FCS (first customer shipment)
Выпуску каждой версии предшествует тщательное
тестирование
(C) Сафонов В.О. 2012
Водопадная модель: Сопровождение (поддержка)
Распространение новых версий продукта, обучение пользователей, ответы на их вопросы
Исправление ошибок (bug fixing); выпуск исправленных версий (patches) с исправлениями наиболее критичных (приоритетных) ошибокРазвитие системы по запросам пользователей: реализация
расширений – requests for enhancement (RFE)
Учет и обработка ошибок – bug tracking; База данных ошибок – bug tracking database
Сопровождение продукта жизненно необходимо; без сопровожденияя продукт “умирает” (перестает использоваться)Затраты на сопровождение – порядка 70% всех затрат на разработку продуктаЛюдские ресурсы на сопровождение обычно невелики (“0.25
инженера), что может привести к неудовлетворенности пользователей
(C) Сафонов В.О. 2012
Водопадная модель: Достоинства и недостатки
Достоинства: Четкое разделение процесса разработки на этапы с ясно поставленными целями и задачами
Недостатки:
Идеализация процесса разработки (невозможно выполнить разработку большой системы, строго следуя водопадной схеме; практически неизбежны возвраты к предыдущим этапам; реальная модель разработки включает циаличность)
Частые нарушения сроков разработки; неудовлетворенность заказчика, который желает как можно скорее получить работающий продукт
(C) Сафонов В.О. 2012