Жизненный цикл программного продукта

1. ЖИЗНЕННЫЙ ЦИКЛ ПРОГРАММНОГО ПРОДУКТА

проф. В.П.Котляров
[email protected]
Факультет технической кибернетики. Кафедра информационных и управляющих систем
1/11

2. Программный продукт

Программное изделие (продукт) – должен быть разработан в
соответствии с международными, государственными, фирменными
стандартами и другими нормативными документами, изготовлен по
утвержденной ТП, принят по соответствующим стандартам и
техническим условиям (ТУ), иметь регистрационный номер, код
классификации промышленной продукции, товарный знак изготовителя..
Факультет технической кибернетики. Кафедра информационных и управляющих систем
2/11

3. Основные этапы эволюции ПО

Реальный мир
Абстрактный мир моделей
представления знаний
Требования/
Requirements
Спецификации/
Specifications
Зачем мы делаем ПП ?
Что должно получиться в
результате ?
Как мы собираемся
разработать ПП, чтобы он
удовлетворял требованиям ?
1
2
Эксплуатация и
сопровождение /
Maintenance
Что получилось в
результате ?
8
65%
ошибок
Реализация/
Development
Как мы реализуем
спецификацию на языке
программирования ?
35%
ошибок
3,4,5,6,7
Факультет технической кибернетики. Кафедра информационных и управляющих систем
3/11

4. Модель Жизненного Цикла

Факультет технической кибернетики. Кафедра информационных и управляющих систем
4/11

5. Модель Жизненного Цикла

20%
1
АНАЛИ&
РАЗРАБОТКА
ТРЕБОВАНИЙ
SRS
FS
8
20%
2
РАЗАБОТКА
СПЕЦИФИКАЦИЙ
HLD
DD
7%
3
КОДИРОВА
НИЕ на ЯЗ.
ПРОГРАМ.
10%
20%
4
ОТЛАДКА и
ТЕСТИРОВАНИЕ
10%
АВТОНОМНОЕ
ИНТЕГРАЦИОННОЕ
5%
НАСТРОЙ
КА на
ЦЕЛЕВ
СРЕДУ И
ОКРУЖЕН
TESTLOG
+100%
5
20%
6
СИСТЕМНОЕ
ТЕСТИРОВАН.
8%
7
ДОКУМЕНТИР
ОВАНИЕ и
ПОСТАВКА
USER’sMANUAL
СОПРОВОЖДЕНИЕ
Факультет технической кибернетики. Кафедра информационных и управляющих систем
5/11

6. ЖЦПП и его фазы

1 этап. Анализ требований – создание документа, в котором на основе
потребности в автоматизации какого либо процесса и данных предыдущего
опыта производится формализация целей, требований, критериев,
предъявляемых пользователем к будущей услуге, также оценивается
экономическая целесообразность инвестиций в реализацию
Разработка требований – создание документа, в котором в терминах
предметной области формализуется совокупность свойств, функций,
характеристик, режимов использования, состояний и ситуаций будущего
продукта, важных для пользователя и Заказчика. Спецификация
требований (Requirement Specification) – документ, содержащий
достаточно точное точное и полное описание объекта проектирования,
разработанное на основе анализа требований. Спецификация - точное и
полное описание задачи, которое человеку, участвующему в ее решении
легче написать, понять и прочесть, чем программу реализации этой задачи
на языке программирования. Язык спецификаций – как правило, язык более
высокого уровня, чем язык программирования, например, естественный
язык неформальных спецификаций, или формальный язык спецификаций,
как UCM, SDL, MSC, UML.
Факультет технической кибернетики. Кафедра информационных и управляющих систем
6/11

7. Пример TRS

Пример
документа
TRS
Факультет технической кибернетики. Кафедра информационных и управляющих систем
7/11

8.

Пример
документа
TRS
Факультет технической кибернетики. Кафедра информационных и управляющих систем
8/11

9.

Пример
документа
UIS
Факультет технической кибернетики. Кафедра информационных и управляющих систем
9/11

10. ЖЦП и его фазы.

2 этап. Разработка реализационных спецификаций – создание
документов, в которых зафиксированы решения по структурам данных,
алгоритмам, интерфейсам и протоколам проектируемой системы, в
частности определена платформа и архитектура приложения.
Реализационные спецификации (Specification) представляют собой
иерархическую систему документов, в которой высокоуровневые
описания дизайна (High Level Design - HLD) дополняются детальными
спецификациями (Detail Design - DD). Таким образом дизайн создает
систему документов, являющихся заданием на реализацию.
Наилучший дизайн – формальное описание системы на формальном языке
спецификаций, таком как UCM, SDL, MSC, UML.
3 этап. Кодирование – преобразование реализационных спецификаций в
коды, которые должны удовлетворять спецификациям требований. На этом
этапе спецификации вручную или автоматически трансформируются в
программные модули, заданные в виде кода на выбранном языке
программирования. Результат кодирования – получение исполняемого кода.
4 этап. Отладка и тестирование – проверка кода в процессе исполнения
на соответствие требованиям и спецификациям.
Факультет технической кибернетики. Кафедра информационных и управляющих систем
10/11

11. Разработка реализационных спецификаций

automatically
manually
automatically
Факультет технической кибернетики. Кафедра информационных и управляющих систем
11/11

12.

Пример
TRM
Факультет технической кибернетики. Кафедра информационных и управляющих систем
12/11

13. ЖЦП и его фазы.

Выделяют несколько стадий проверки
– на уровне модулей– модульное тестирование (Unit Testing),
- на уровне межмодульных связей – интеграционное тестирование
(Integration Testing)
- на уровне изделия – системное тестирование (System Testing)
5 этап. Настройка на окружение и целевую платформу – обеспечивается
в процессе целевой компиляции. Настройка обеспечивает адаптацию кода к
типу и характеристикам микроконтроллера и операционной системы,
требуемым ресурсам, особенностям окружающей среды (environment) и
оптимизацию характеристик программного обеспечения.
6 этап. Системное тестирование – проверка кода в процессе исполнения
на соответствие требованиям и спецификациям в модельной и/или
реальной среде исполнения и окружении.
7 этап. Документирование – процесс создания и комплектации изделия
эксплуатационной и пользовательской документацией, выполненной в
соответствии с международными (ISO/IEEE), государственными
(ЕСПД/ANSI/…) и фирменными стандартами.
Факультет технической кибернетики. Кафедра информационных и управляющих систем
13/11

14. Интеграция процессов верификации и тестирования для мультиплатформенных решений

Requirements text (English,
UML, MSC,…)
Formalized
requirements
Verification verdict
(errors in
requirements)
VRS
MSC Test scenarios
Executing test scripts
Agent application
Test cases scripts (С/С++,
Java, TTCN, PTF, FlexAuto …)
TAT
Генерации тестов и тестовых процедур для любой целевой платформы)
Факультет технической кибернетики. Кафедра информационных и управляющих систем
14/11

15. ЖЦП и его фазы.

Превращение программного обеспечения в продукт – путем фиксации
программных средств на носителе вместе с пакетом инсталляции и
комплектации изделия документацией.
Поставка - тиражирование программного продукта (воспроизведение
носителя) и поставка Заказчику.
8 этап. Сопровождение – процесс, осуществляемый параллельно с его
эксплуатацией, направленный на обеспечение требуемого качества работы
ПО на всем периоде его использования и заключающийся в выявлении и
устранении ошибок (дефектов), оставшихся после разработки. На этом
этапе осуществляется модернизация системы при выявлении недостатков,
приводящих к корректировке спецификаций на систему. Протяженность
этапа сопровождения ограничивается моральным износом ПО, когда
программное изделие заменяется более совершенной, в проектировании
которой учтен опыт разработки и эксплуатации предшествующей системы.
Сопровождение включает поставку системы пользователю, ввод в
эксплуатацию, выявление и устранение ошибок в процессе эксплуатации и
дальнейшее расширение системы в случае необходимости.
Факультет технической кибернетики. Кафедра информационных и управляющих систем
15/11

16. Требования и формализация

Факультет технической кибернетики. Кафедра информационных и управляющих систем
16/11

17. Требования и формализация

Факультет технической кибернетики. Кафедра информационных и управляющих систем
17/11

18. Требования и TRM

Факультет технической кибернетики. Кафедра информационных и управляющих систем
18/11

19. Требования и TRM

Факультет технической кибернетики. Кафедра информационных и управляющих систем
19/11

20. Требования и TRM

Факультет технической кибернетики. Кафедра информационных и управляющих систем
20/11

21. Требования и TRM

Факультет технической кибернетики. Кафедра информационных и управляющих систем
21/11

22. Требования и TRM

Факультет технической кибернетики. Кафедра информационных и управляющих систем
22/11

23. Требования и TRM

Факультет технической кибернетики. Кафедра информационных и управляющих систем
23/11

24.

UCM диаграмма фрагмента проекта CARRadio
Main Map
Факультет технической кибернетики. Кафедра информационных и управляющих систем
24/11

25.

UCM диаграмма фрагмента проекта CARRadio
Main Map
Map for Stub OnOff
Факультет технической кибернетики. Кафедра информационных и управляющих систем
25/11

26.

UCM диаграмма фрагмента проекта CARRadio
Main Map
Map for Stub OnOff
Map for Stub Frequency
Факультет технической кибернетики. Кафедра информационных и управляющих систем
26/11

27.

UCM диаграмма фрагмента проекта CARRadio
Main Map
Map for Stub OnOff
Map for Stub AM
Map for Stub Frequency
Факультет технической кибернетики. Кафедра информационных и управляющих систем
27/11

28.

Из верифицированного в тестовый сценарий
Исходная символьная трасса
MSC сценарий
Факультет технической кибернетики. Кафедра информационных и управляющих систем
28/11

29. Интеграция процессов верификации и тестирования для мультиплатформенных решений

Requirements text (English,
UML, MSC,…)
Formalized
requirements
Verification verdict
(errors in
requirements)
VRS
MSC Test scenarios
Executing test scripts
Agent application
Test cases scripts (С/С++,
Java, TTCN, PTF, FlexAuto …)
TAT
Генерации тестов и тестовых процедур для любой целевой платформы)
Факультет технической кибернетики. Кафедра информационных и управляющих систем
29/11

30. Спасибо за внимание!

Факультет технической кибернетики. Кафедра информационных и управляющих систем
30/11