Курс «Технология Разработки Информационных Систем», Лекции.

Лекция 1. Предмет и содержание курса. Общая картина.

Предмет и содержание курса «Технология Разработки Информационных Систем» – это обзор наиболее распространённых методологий разработки информационных систем, применяющихся в ходе технологических процессов поддержки ЖЦ программной системы, а также более подробно, процесс управления требованиями.

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

Наиболее распространёнными стандартами описания ЖЦ ПО являются:

· Российский ГОСТ 34.601-90

· Международный ISO/IEC 12207:1995 (российский аналог – ГОСТ Р ИСО/МЭК 12207-99)

Подробнее эти стандарты рассмотрены ниже.

Модель ЖЦ ПО – структура, которая позволяет определить последовательность выполнения и взаимосвязи процессов, задач и действий на протяжении ЖЦ ПО. Зависит от масштаба, сложности проекта разработки ПО и специфики проекта разработки.

Модель ЖЦ ПО определяет:

1. Стадии ЖЦ ПО

2. Результаты выполнения работ на каждой стадии

3. Ключевые события – точки завершения работ (milestones) и точки принятия решений.

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

Методологии разработки ПО определяют способ практического применения технологии, лучших практик на основе определённой модели ЖЦ ПО, ценностей и конкретных технологических процессов.

Методология разработки ПО  определяет, как конкретно будут выполняться проекты разработки и сопровождения ПО.

Технологии разработки ПО бывают в основном, двух видов:

· строгие,

o с опорой на ценности формальных методов:

§ разработка, основанная на моделях;

§ моделеориентированная архитектура;

§ строго определённый, формальный процесс верификации (проверки, тестирования) и валидации (приёмки);

o ожидается полная и согласованная документация на каждом отдельном этапе

· гибкие

o с опорой на ценности неформальных процессов согласования, общения:

§ работающий код важнее, чем формальная архитектура;

§ быстрое прототипирование
(RAD, Rapid Application Development);

§ простота, не переусложнённость решения:

· принцип KISS (Keep It Simple, Stupid)

o код должен быть настолько прост, насколько это возможно (но не проще)

· принцип YAGNI (You Ain’t Gonna Need It)

o не делайте лишнюю функциональность, которая пользователю не понадобится

· принцип MVP (Minimal Viable Product)

o определить минимальное жизнеспособное (viable ) ядро продукта,  и затем инкрементально его развивать

§ TDD, Test - Driven Development , “ test first ”
для функционального и модульного тестирования

§ BDD, Behavior Driven Development

· простой формальный язык для задания спецификаций

· сначала задать поведение системы

§ довольный пользователь важнее формальной и полной документации;

o  ожидается согласие и понимание в результате каждого процесса и готовность достижения согласия в ходе процесса инкрементального, итеративного непрерывного совершенствования (выполняя все нужные для этого процессы и действия итеративно, по спирали)

Модели ЖЦ ПО бывают в основном, двух видов:

· Последовательные

o Водопадная, каскадная модель

§ Существенно наличие полной, согласованной документации и полностью выполненных работ по окончании очередного этапа

· Итерационные, инкрементальные, эволюционные

o Каскадная с возвратами

o Эволюционная модель IID Т. Гилба

o Спиральная модель Барри Боэма

§ Существенно наличие гибкой обратной связи в ходе итераций, и понимания достигнутых итеративно ценностей

§ Определяются контрольные точки для достижения понимания

·     Concept of Operations (COO) — концепция (использования) системы;

·     Life Cycle Objectives (LCO) — цели и содержание жизненного цикла;

·     Life Cycle Architecture (LCA) — архитектура жизненного цикла; здесь же возможно говорить о готовности концептуальной архитектуры целевой программной системы;

·     Initial Operational Capability (IOC) — первая версия создаваемого продукта, пригодная для опытной эксплуатации;

·     Final Operational Capability (FOC) –— готовый продукт, развернутый (установленный и настроенный) для реальной эксплуатации.

§ На каждой итерации оцениваются риски, необходимость прекращения или ещё одной итерации, степень полноты и точности понимания требований к системе

Методологии разработки ПО определяют, как разворачивается во времени и выполняется управление проектом разработки ПО с применением строгой или гибкой технологии разработки ПО согласно выбранной модели ЖЦ ПО.

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

· Строгие

o RUP, Rational Unified Process

o TSP, Team Software Process

o PSP, Personal Software Process

· Гибкие

o XP, eXtreme Programming – экстремальное программирование

o SCRUM

o Kanban, lean programming

Также применяются такие методологии как MSF Microsoft Solution Framework, Crystal, FDD Feature Driven Development, BDD, и прочие.

С точки зрения системной инженерии, также есть классические, строгие методологии и гибкие, наподобие OMG Essense или ArchiMate. Разделы системной инженерии «ситуационная инженерия методов», Situational Method Engineering и «адаптивное управление делами (кейсами)», Adaptive Case Management позволяют составить методологию для системной инженерии по ситуации, на основе лучших практик, существующих тех. процессов (методов), технологических звеньев процессов применительно к конкретным ситуациям и технологиям.

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