Конспект лекций по Технологии разработке программных продуктов

Санкт-Петербургская Инженерная Школа Электроники

Конспект лекций по

«Технологии разработке программных продуктов»

 

(для групп специальности 2203)

 

Курс, 1 семестр

 

Составил: Корец В.В.

Отредактировал и дополнил: Хлопотов М.В.

 

 

Санкт-Петербург

Содержание

1. Введение в технологии программирования. 4

1 .1. Основные понятия и определения. 4

1.2. История и эволюция. 4

1.3. Классификации.. 5

1.3.1. Классификация технологических подходов. 5

1.3.2 Классификация технологических процессов. 6

1.3.3. Классификация технологических стадий.. 6

1.4. Проблемы и перспективы развития. 6

1.5. Рекомендации по литературе. 7

2. Классические технологические процессы.. 7

2.1. Возникновение и исследование идеи.. 8

2.1.1. Возникновение идеи решения проблемы.. 8

2.1.2. Постановка задачи.. 9

2.1.3. Принятие решения о начале работы над проектом.. 9

2.2. Управление. 10

2.2.1. Управление проектом.. 10

2.2.2. Эволюция менеджмента. 13

2.2.3. Методы управления проектами.. 14

2.2.4. Планирование проекта. 14

2.2.5. Методики оценок времени и затрат. 15

2.2.6. Современные подходы к управлению проектом.. 16

2.3. Анализ требований и проектирование. 16

2.3.1. Введение в анализ требований и проектирование. 17

2.3.2. Отступление «О спецификациях». 17

2.3.3. Отступление “о классификации всего сущего”. 19

2.3.4. Проектирование архитектуры (проектирование «в большом») 19

2.3.5. Проектирование модулей (проектирование “ в малом”) 20

2.3.6. Методы анализа и построения спецификаций.. 21

2.3.7. Подходы к ведению анализа и проектирования. 24

2.4. Программирование (реализация) 26

2.4.1. Стиль программирования. 26

2.4.2. Защитное программирование. 28

2.4.3. Выбор языка программирования. 29

2.5. Тестирование и отладка. 30

2.5.1. Введение в тестирование и отладку. 30

2.5.2. Тестирование программных продуктов. 30

2.5.3. Отладка программных продуктов. 31

2.6. Эксплуатация и сопровождение. 32

2.7. Завершение эксплуатации.. 33

3. Стандартные технологические процессы.. 33

3.1. Основные процессы.. 34

3.1.1. Приобретение. 34

3.1.2. Поставка. 34

3.1.3 Разработка. 34

3.1.4. Эксплуатация. 34

3.1.5. Сопровождение. 34

3.2. Вспомогательные процессы.. 35

3.2.1. Документирование. 35

3.2.2. Управление конфигурацией.. 35

3.2.3. Обеспечение качества. 35

3.2.4. Верификация. 35

3.2.5. Аттестация. 35

3.2.6. Совместная оценка. 35

3.2.7. Аудит. 36

3.2.8. Разрешение проблем.. 36

3.3. Организационные процессы.. 36

3.3.1. Управление. 36

3.3.2. Создание инфраструктуры.. 36

3.3.3. Усовершенствование. 36

3.3.4. Обучение. 36

3.4. Основные стадии технологических подходов. 37

3.4.1. Фазы, как крупные временные рамки.. 37

3.4.2. Стадии как отражение классических процессов. 37

3.4.3. Вариант подробного разбиения стадий.. 37

3.5. Контрольные точки.. 38

4. Основные технологические подходы.. 39

4.1. Ранние технологические подходы.. 39

4.2. Каскадные технологические подходы.. 39

4.2.1. Каскадный подход. 39

4.2.2. Каскадно-возвратный подход. 40

4.2.3. Каскадно-итерационный подход. 40

4.2.4. Каскадный подход с перекрывающимися процессами. 40

4.2.5. Каскадный подход с подпроцессами.. 40

4.2.6. Спиральная модель. 40

4.3. Каркасные технологические подходы.. 40

4.4. Генетические технологические процессы.. 41

4.4.1. Синтезирующее программирование. 41

4.4.2. Сборочное (расширяемое) программирование. 41

4.4.3. Конкретизирующее программирование. 42

4.5. Подходы на основе формальных преобразований.. 42

4.5.1. Технология стерильного цеха. 42

4.5.2. Формальные генетические подходы.. 43

4.6. Группа ранних подходов быстрой разработки.. 43

4.6.1. Эволюционное прототипирование. 43

4.6.2. Итеративная разработка. 44

4.6.3. Постадийная разработка. 44

4.7. Адаптивные технологические подходы.. 44

4.7.1. Экстремальное программирование. 44

4.7.2. Адаптивная разработка. 45

4.8. Подходы исследовательского программирования. 45

5. Технологии коллективной разработки.. 46

5.1. Авторская разработка. 46

5.2. Коллективная разработка. 47

5.2.1. Технические командные роли. 47

5.2.2. Психологические командные роли.. 48

5.2.3. Типы совместной деятельности.. 49

5.3. Общинная модель разработки.. 49

6. Качество программного обеспечения. 50

6.1. Подходы к качеству программного обеспечения. 50

6.2 Характеристики качества программного обеспечения. 51

6.3 Оценка качества процесса разработки.. 52

6.3.1. Модель зрелости процесса разработки программного обеспечения. 52

6.3.2 Определение возможностей и улучшение процесса создания программного обеспечения. 52

6.4. Достаточно хорошее программное обеспечение. 53

6.5. Стандартизация информационных технологий.. 54

 

Введение в технологии программирования

 

Основные понятия и определения

Жизненный цикл программы — это весь период ее разработки и эксплуатации, начиная с момента возникновения замысла и заканчивая прекращением всех видов ее использования.

Технология программирования изучает технологические процессы и порядок их прохождения — стадии.

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

Стадия — часть действий по созданию программного обеспечения, ограниченная некоторыми временными рамками и заканчивающаяся выпуском конкретного продукта, определяемого заданными для данной стадии требованиями. Стадии состоят из этапов, которые обычно имеют итерационный характер. Иногда стадии объединяют в более крупные временные рамки называемые фазами. Итак, горизонтальное измерение отражает динамические аспекты процессов и оперирует такими понятиями как фазы, стадии, этапы, итерации и контрольные точки.

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

Простейшее представление жизненного цикла программы представлено рис. 1.

 

 

Рис. 1. Каскадный технологический подход к ведению жизненного цикла

 

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

 

История и эволюция

История учит нас тому, что из истории мы ничему не учимся Б. Шоу  

Классификации

Классификация технологических подходов

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

 

Подходы со слабой формализацией

Эти подходы не используют явных технологий и их можно применять только для очень маленьких проектов, как правило, завершающихся созданием демонстрационного прототипа. К подходам со слабой формализацией относятся так называемые ранние технологические подходы, например подход “кодирование и исправление” (см. разд. 5.1.1).

 

Строгие (классические, жесткие, предсказуемые) подходы

Данную группу подходов рекомендуется применять для средних, крупно масштабных и гигантских проектов с фиксированным объемом работ. Одна из основных требований к таким проектам — предсказуемость. В эту группу входят подходы, перечисленные ниже.

Каскадные технологические подходы.

• Классический каскадный подход (см. разд. 5.2.1).

• Каскадно-возвратный подход (см. разд. 5.2.2).

• Каскадно-итерационный подход (см. разд. 5.2.3).

• Каскадный подход с перекрывающимися процессами (см. разд. 5.2.4).

• Каскадный подход с подпроцессами (см. разд. 5.2.5).

• Спиральная модель (см. разд. 5.2.6).

 

Каркасные подходы.

• Рациональный унифицированный процесс (см. разд. 5.3.1).

 

Генетические подходы.

• Синтезирующее программирование (см. разд. 5.4.1).

• Сборочное (расширяемое) программирование (см. разд. 5.4.2).

• Конкретизирующее программирование (см. разд. 5.4.3).

Подходы на основе формальных преобразований.

• Технология стерильного цеха (см. разд. 5.5.1).

• Форматные генетические подходы (см. разд. 5.5.2).

 

Гибкие (адаптивные, легкие) подходы

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

* Ранние технологические подходы быстрой разработки

• Эволюционное прототипирование (см. разд. 5.6.1).

• Итеративная разработка (см. разд. 5 6.2)

• Постадийная разработка (см. разд. 5.6.3).

 

Адаптивные подходы.

• Экстремальное программирование (см. разд. 5.7.1).

• Адаптивная разработка (см. разд. 5.7.2).

 

Подходы исследовательского программирования.

• Компьютерный дарвинизм (см. разд. 5.8.1).

 

Классификация технологических процессов

Мы будем рассматривать два набора (множества) технологических процессов. Первый набор — классический, включающий основные процессы, сложившиеся исторически в результате практического опыта разработки программного обеспечения. Второй набор — стандартный, т. е. основанный на стандарте ISO 12207:1995. Процессы классического набора фактически являются подмножеством стандартного, выступая там как процессы или действия процессов.

В классическом наборе выделим девять технологических процессов:

 

Возникновение и исследование идеи (см. разд. 2.1).

Управление (см. разд. 2.2).

Анализ требований (см. разд. 2.3.).

Проектирование (см. разд. 2.3).

Программирование (см. разд. 2.4)

Тестирование и отладка (см. разд. 2.5)

Ввод в действие (см. разд. 2.6).

Эксплуатация и сопровождение (см. разд. 2.7.)

Завершение эксплуатации (см. разд. 2.8).

Процессы жизненного цикла, определяемые международным стандартом ISO 12207{ISO/IEC 12207:1995}, делятся на три группы.

Основные процессы.

* Приобретение

* Поставка

* Разработка

* Эксплуатация

* Сопровождение

Вспомогательные процессы.

• Документирование (см. разд. 3.2.1).

• Управление конфигурацией (см. разд. 3.2.2.).

• Обеспечение качества (см. разд. 3.2.3).

• Верификация (см. разд. 3.2.4.).

• Аттестация (см. разд. 3.2.5.)

• Совместная оценка (см,. разд. 3.2.6).

• Аудит (см. разд. 3.2.7).

• Разрешение проблем (см. разд. 3.2.8.).

Организационные процессы.

• Управление (см. разд. 3.3.1).

• Создание инфраструктуры (см. разд. 3.3.2).

• Усовершенствование (см. разд. 3.3.3)

• Обучение (см. раза. 3.3.4).

 

Классификация технологических стадий

Технологические стадии выделяются исходя из соображений разумного и рационального планирования и организации работ. Существует два основных варианта формирования промежутков времени, поддерживаемых технологическими подходами. В первом — формируются фазы, отражающие крупные временные этапы. Например, начальная фаза, середина, кризис, окончание. Во втором варианте — определяются стадии, отражающие на звания классических процессов (или их подмножества или надмножества), большая часть времени которых проходит в данной стадии. Пример взаимосвязи между стандартными процессами и стадиями показан на рис. 2.

 

Рис 2. Взаимосвязь между стандартными процессами и стадиями

 

Проблемы и перспективы развития

 

Кто хочет обрести счастье или мудрость, тот должен искать перемен.

Конфуций

В настоящее время развитие и совершенствование технологических подходов ведется по двум направлениям, которые достаточно сильно отличаются друг от… Максимизация качества. Задачи, решаемые на этом направлении — надежность,… Максимизация скорости разработки. Это направление в большей степени обращено к искусству, импровизации и поиску.…

Рекомендации по литературе

Томас Карлейль   По технологии программирования издано очень большое количество книг особого внимания заслуживают пять.

Классические технологические процессы

 

Сначала неизбежно идут: мысль, фантазия, сказка. За ними следует научный расчет, и уже, в конце концов, исполнение венчает мысль.

К. Э. Циолковский

 

Начнем знакомство с “девятки” классических технологических процессов.

 

Возникновение и исследование идеи

 

Погоня за идеей — занятие столь же захватывающее, как и погоня за китом.

Генри Норрис Рассел

 

Этот классический процесс имеет следующие действия: собственно возникновение и первичное исследование идеи, носящее максимально творческий и неформальный характер; детальное исследование идеи. Выработка концепции. Постановка задачи. Создание “одностраничного описания проекта” и разработка его расширенной версии; экспертиза идеи специалистами. Принятие решения о начале процесса планирования.

Заметим, что идея может привести либо к развитию уже существующего программного продукта, либо к созданию нового.

 

Возникновение идеи решения проблемы

- препятствует созданию или развитию программного продукта; - приводит к ошибкам в программном продукте. Наиболее интересными являются инновационные решения. Инновация — нововведение, изменяющее уже существующую…

Постановка задачи

В результате должна быть выработана концепция создаваемого или развиваемого программного продукта. Мы должны прояснить цель проекта, сформулировать… Одностраничное описание проекта включает несколько небольших разделов, кратко…  

Принятие решения о начале работы над проектом

Выясните сначала факты, а потом можете извращать их по своему усмотрению. М. Твен  

Управление

Любую техническую проблему можно преодолеть, имея достаточно времени

Закон Лермана

Вам никогда не будет хватать либо времени, либо денег

Следствие из закона Лермана

 

Этот процесс длится почти весь жизненный цикл программного продукта, но поставили мы его в данном месте потому, что одним из важнейших действий управления является планирование, которое начинается вслед за принятием решения о том, что “проекту — жить”.

 

Управление проектом

При профессиональной разработке программного продукта в крупных фирмах и компаниях предъявляются дополнительные требования к процессу разработки. … * Наличие формализованной модели для разработки программного продукта. * Наилучшая расстановка приоритетов и ресурсов.

Программистский фольклор

Руководителям было издавна известно, что людей следует побуждать к действиям для достижения некоторого желательного результата. Мотивация — это… * Гедонизм — заинтересованность людей делать то, что им приятно и уклоняться… * Инстинкты — автоматическая предрасположенность людей вести себя Определенным образом. Некоторые люди находят…

Эволюция менеджмента

Наводить порядок надо тогда, когда еще нет смуты

Лао Цзы

Основы менеджмента были заложены в начале ХХ века в европейской и американской науке. История менеджмента связана с древним Египтом философами…   Особенности европейского менеджмента

Методы управления проектами

* заблаговременно планировать работу над проектом и предвидеть возможные источники затруднений и задержки выполнения его в срок; * планировать завершение работ в нужные сроки в соответствии с требуемой… * координировать и контролировать выполнение работ для соблюдения Календарного графика и завершения проекта в срок. …

Планирование проекта

* План помогает создать ясное и четкое понимание — как будущие работы будут выполняться * План определяет роль каждого человека в исполнении проекта. * План увязывает части работ вместе. План позволяет видеть все взаимозависимости между разными частями работы.

Методики оценок времени и затрат

* Сверху вниз по крупным блокам аналогичного проекта. Поскольку аналогичный проект пройден и мы знаем реальные затраты для него, то для нового… * Снизу вверх по составленному графику работ. данные по трудозатратам и… * Методика норм работы. Учет ведется по нормам, определяемым как значение времени, уходящее на данную работу в данной…

Современные подходы к управлению проектом

Став бригадиром, я упростил этот процесс до мыслимого предела В. Ерофеев. «Москва — Петушки»  

Анализ требований и проектирование

Введение в анализ требований и проектирование

Анализ и проектирование — два достаточно близких и тесно связанных процесса Они выполняют общую задачу, результатом которой должно стать. Такое представление о системе, на основе которого будет создан программный код. Поэтому мы будем их рассматривать совместно, проводя разделение по методологиям — анализ и проектирование на основе структурной методологии и на основе объектно-ориентированной методологии.

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

Основной вопрос, который решается в это время — ‘Что должна делать будущая система?”

Проектирование — процесс жизненного цикла программы, во время которого исследуется ее структура и взаимосвязи элементов. Проектирование, как правило, является итерационным процессом. Основной вопрос, который решается в это время — “Как система будет удовлетворять полученным требованиям?’.

Проектирование должно проводиться на двух уровнях:

* Проектирование архитектуры (проектирование системы, проектирование “в большом”).

* Детальное проектирование (проектирование модулей, проектирование “в малом”).

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

На сегодняшний день в профессиональном программировании применяются две основные методологии — структурная и объектно-ориентированная. На этапе анализа и проектирования нам важно принципиальное различие между этими методологиями, заключающееся в разных способах декомпозиции систем [Вендров 2000].

*Структурная (функциональная) декомпозиция рассматривает структуру системы в терминах иерархии функций и передачи информации.

* Объектная декомпозиция рассматривает структуру объектов и связей между ними, а также поведение системы в терминах обмена сообщений между объектами.

Далее мы перечислим основные методы структурного и объектно-ориентированного анализа и проектирования. Обратим внимание на то, что в основе многих объектно-ориентированных методов лежит структурный подход, которому придана объектно-ориентированная окраска.

В основе ведения процессов анализа и проектирования лежат методы, поддерживаемые языками и системами. Методы, объединенные в некоторую совокупность (комбинацию), образуют подходы к анализу и проектированию. Подходы имеют названия, среди которых много именных. Примеры подходов — подход Йордона и ДеМарко (структурная методология) и Шлеер и Меллора (объектно-ориентированная методология).

 

2.3.2. Отступление «О спецификациях»

— Вовочка, ты уже покрасил окна?

— Да, осталось покрасить только рамы!

Анекдот о необходимости точных. спецификаций

 

Спецификация — достаточно точное и достаточно полное описание задачи, которое позволяет человеку, участвующему в решении, написать, понять и прочесть легче, чем программу решения этой задачи на доступном ему языке программирования. Более коротко спецификацию можно определить как подробное описание некоторой работы, подлежащей выполнению.

Средства спецификации — любые средства получения или построения таких описаний.

Язык спецификации — рационально оформленный и синтаксически организованный набор таких средств.

В спецификациях программ имеет смысл выделить две существенно отличающиеся части:

*Функциональные спецификации, описывающие функции системы.

*Эксплуатационные спецификации, описывающие скорость работы программы, используемые ресурсы, характеристики аппаратуры, специальные требования к надежности и безопасности.

Существует точка зрения об относительности понятия спецификации [Агафонов 1984]. Имея дело с одной и тои же задачей, данные люди в данном окружении (включающем их знания, языки и т. п.) будут склонны считать спецификацией одно, а другие люди в другой обстановке — совсем другое. Например “х:=+1” будет лучшей спецификацией задачи “увеличить х на единицу” для человека, знакомого с оператором присваивания и его обозначением.

Средства спецификации, которые допускают машинную обработку, мы будем классифицировать по уровню формализации и по способу представления [Деметрович, Кнут, Радо 1989].

По уровню формализации выделим три класса.

*Словесные спецификации, обработка которых может осуществляться Обычным текстовым редактором.

*Модельные (структурированные) спецификации, которые предполагают построение схем, диаграмм, других информационных структур.

*Формальные спецификации, получаемые строгим формальным способом с использованием математических формализмов, которые обеспечивают полное определение семантики.

Существует два основных способа представления спецификаций:

* Текстовое представление, которое подходит для словесных и формальных спецификаций.

* Представление с помощью информационных объектов. Как правило, таким способом представляются модельные спецификации.

 

Отступление “об архитектуре”

Архитектура программного продукта — это его строение как оно видно (или должно быть видно) извне его, т. е. представление программного продукта как системы, состоящей из некоторой совокупности взаимодействующих подсистем [Жоголев 1996]. В качестве таких подсистем обычно выступают отдельные программы.

Следующее определение принадлежит Криспену (http://www.sei.cmu.edu/architecture/definition.html): Архитектура состоит из (а) стратегии разделения и (б) стратегии объединения. Стратегия разделения заключается в делении монолитной системы на дискретные, полностью покрывающие её части (или компоненты). Стратегия объединения заключается в явном определении интерфейсов между этими компонентами.

И, наконец, еще одно определение содержится в работе [Буч, Рамбо, Джекобсон 2000]: Архитектура - это совокупность существенных решений касающихся:

* организации программной системы;

* выбора структурных элементов, составляющих систему, и их интерфейсов;

* поведения этих элементов, определенного в процессе взаимодействия с другими элементами;

* составления из этих структурных и поведенческих элементов все более крупных подсистем;

* архитектурного стиля, направляющего и определяющего всю организацию системы: статические и динамические элементы, их интерфейсы кооперации и способ их объединения.

Выделяют следующие классы архитектур программных продуктов [Майерс1980], такие как:

* цельная (монолитная) программа;

* комплекс автономно выполняемых программ;

* слоистая программная система;

* коллектив параллельно выполняемых программ.

Можно определить четыре структуры, которые в совокупности описывают программную архитектуру [Ахтырченко, Леонтьев 2001].

* Логическая (концептуальная) структура, включающая множество абстракций, необходимых для описания функциональных требований к системе на абстрактном уровне (уровне, не затрагивающем вопросы реализации). Данная структура строится на основе анализа проблемной области.

*Модульная структура, определяющая организацию программного средства как совокупности модулей — программных единиц, с которыми могут быть соотнесены рабочие задания, выполняемые членами команды.

* Процессная структура, описывающая поведение системы во время ее исполнения.

* Физическая структура, определяющая отображение элементов программного средства на аппаратное обеспечение.

Кроме этих четырех часто используются и другие структуры.

* Структура вызовов.

* Структура потоков данных.

* Структура потоков управления.

* Структура использования.

* Структура классов.

Практически все технологические подходы содержат рекомендации по моделированию большинства перечисленных структур.

Мери Шоу (Магу Shaw) и Дэвид Гарлан (Devid Gагlan) предложили использовать каталог архитектурных стилей [Shaw, Garlan 1996].

Независимые компоненты:

• взаимодействующие процессы;

• системы с событиями: неявный вызов и явный вызов.

Поток данных:

* пакетно-последовательный;

• каналы и фильтры.

Централизованные данные:

• хранилище;

• классная доска.

Виртуальные машины:

• интерпретатор;

• системы с правилами.

Вызов с возвратом:

• главная программа и подпрограммы;

• объектно-ориентированный;

• слойный.

Идентификация и документирование таких архитектурных стилей позволяет программистам использовать их в качестве стартовой точки. Хорошие примеры архитектурных паттернов (шаблонов) и каркасов проектирования приведены в книге [Гамма, Хелм, Джонсон, Влиссидес 2001].

 

2.3.3. Отступление “о классификации всего сущего”

 

Женщина

Исихара Икидаз (ХI Век). Из цикла ‘Стихотворения из одного слова’

 

Во многих ситуациях (например, для разработки диаграммы “сущность-связь”) нам потребуется выделить совокупность сущностей из окружающего нас мира. Следует разобраться — как удобно классифицировать окружающий нас мир.

Большинство окружающих нас объектов относится к категориям, рассмотренных в книге

[Шлеер, Меллор 1993].

* Реальные объекты — абстракции фактически существующих предметов в физическом мире.

* Роли — абстракции цели или назначения человека, части оборудования или организации.

* Инциденты — абстракции чего-то произошедшего или случившегося.

* Взаимодействия — объекты, получающиеся из отношения между другими объектами.

Образование иерархий широко используется человеком как стратегия организации информации. Иерархия предпочтений, выявленная Килем психологических экспериментов с детьми, представлена на рис. 3.

 

 

Рис. 3. Одна из классификаций всего сущего

 

Классифицировать можно даже ненаблюдаемые объекты. Их разбить можно на четыре категории, расположенные в порядке убывания научного интереса, который они представляют [Физики 1968].

* Явления, ненаблюдаемые по определению (например, невидимый объект)

* Явления, ненаблюдаемые в принципе (например, абсолютная скорость)

* Явления, ненаблюдаемые в природе (например, потомство от стерильных кроликов).

* Явления, ненаблюдаемые в обществе воспитанных людей (например, ковыряние в носу).

 

2.3.4. Проектирование архитектуры (проектирование «в большом»)

Верите ли, это бредовое сооружение Ирода – прокуратор махнул рукою вдоль колоннады, так что стало ясно, что он говорит о дворце, - положительно сводит меня сума. Я не могу ночевать в нём, мир не знал более странной архитектуры

Михаил Булгаков “Мастер и Маргарита’

 

Структурная методология

Проектирование архитектуры (проектирование “в большом”) для структурной методологии включает следующие основные методы:

* метод нисходящего проектирования:

* метод восходящего проектирования;

* метод расширения ядра.

В случае структурной методологии в качестве модульной структуры программы принято использовать древовидную структуру. В узлах такого дерева размещаются программные модули, а направленные дуги показывают статическую подчиненность модулей.

Методы нисходящего и восходящего проектирования имеют достаточно большое количество разновидностей и модификаций (например, зависящих от того — начинается кодирование до окончательного завершения проектирования или нет).

Метод нисходящего проектирования представляет собой подход функциональной декомпозиции на основе двух стратегий.

* Пошагового уточнения — при котором на каждом следующем этапе декомпозиции определяются модули очередного, более низкого уровня.

* Анализа сообщений — при котором анализируются потоки данных, обрабатываемые модулями.

Метод восходящего проектирования — подход, при котором в первую очередь определяются вспомогательные модули, которые потребуются для проектируемой программы.

Метод расширения ядра — подход, при котором основное внимание уделяется выделению множества вспомогательных модулей, а не определению функций всей программы в целом.

 

Объектно-ориентированная методология

Проектирование архитектуры для объектно-ориентированной методологи включает следующие основные методы [Шлеер, Меллор 1993]:

· Метод проектирования предметных областей;

· Метод наведения мостов.

· Метод проектирования предметных областей заключается в выделении предметной области системы с точки зрения пользователя. Предметная область — это отдельный реальный, гипотетический или абстрактный мир населенный отчетливым набором объектов, которые ведут себя в соответствии с характерными для домена правилами и линиями поведения.

· Метод наведения мостов заключается в том, что одна предметная область использует механизмы и возможности, обеспечиваемые другой предметной областью. Мост между двумя предметными областями представляет набор предложений (с точки зрения пользователя) и набор требований (с точки зрения исполнителя).

 

2.3.5. Проектирование модулей (проектирование “ в малом”)

 

Жизнь без начала и конца. Нас всех подстерегает

Александр Блок

 

Структурная методология

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

* Диаграммы ‘сущность-связь’

* Структурные карты.

* Диаграммы деятельности.

* Диаграммы Варнье-Орра.

* Диаграммы переходов состояний.

* Блок-схемы.

* Схемы экранов.

* Псевдокод.

Диаграмма “сущность-связь” (Entity-Relation Diagram - ERD) — предназначена для разработки моделей данных и обеспечивает стандартный механизм определения данных и отношений между ними.

При создании таких моделей рассматривают понятия:

* Сущность — это такая абстракция множества объектов реального мира, в которой все предметы этого множества имеют одинаковые характеристики и согласованы с одним и тем же набором правил и линий поведения. Выделяют следующие типы сущностей:

• независимая сущность представляет независимые данные, которые всегда присутствуют в системе. Отношения с другими сущностями у нее могут отсутствовать;

• зависимая сущность представляет данные, зависящие от других сущностей в системе. Она всегда имеет отношения с другими сущностями;

• ассоциированная сущность представляет данные, которые ассоциируются с отношениями между двумя и более сущностями.

** Отношение связывает две или большее количество сущностей. Отношение всегда выражается действием, и его именуют с помощью глагола. Выделяют следующие типы отношений:

* неограниченное отношение представляет собой безусловное отношение, которое существует до тех пор, пока существуют относящиеся к делу сущности;

• ограниченное отношение представляет собой условное отношение между сущностями;

• существенно-ограниченное отношение используется, когда соответствующие сущности взаимозависимы в системе.

** Связи используются для идентификации требований, в соответствии с которыми сущности вовлекаются в отношения. Каждая связь соединяет сущность и отношение и может быть направлена только от отношения к сущности. Пара значений связей, принадлежащих одному и тому же отношению, определяет тип этого отношения. Для большинства приложений достаточно использовать следующие типы отношений:

• 1:1 (один-к-одному);

• 1:М (один-ко-многим);

• М:М (многие-ко-многим);

Атрибут — абстракция одной характеристики, которой обладают все абстрагируемые как объект сущности. Атрибуты бывают:

• описательные — представляющие факты, внутренне присущие каждому экземпляру объекта;

• указательные — для дачи имени или обозначения экземпляру;

• вспомогательные — для связи экземпляра одного объекта с экземпляром другого.

Разработанные диаграммы “сущность-связь” далее практически всегда следует преобразовывать в реляционную модель, которая допускает только унарные и бинарные связи.

Псевдокод (pseudocod) — метод применения стилизованного естественного языка для описания структуры управления программы. Конструкции такого языка обычно близки к конструкциям блочных структурных языков программирования Псевдокод состоит из таких предложений, которые могла бы выполнить ЭВМ, но которые содержат вместо ключевых слов, завис от используемого языка Программирования, фразы в свободной форме.

 

Объектно-ориентированная методология

Перечислим основные методы Проектирования модулей для объектно-ориентированной методологии и рассмотрим подробно некоторые из них:

* диаграммы кооперации.

* диаграммы компонентов.

* диаграммы развертывания,

Диаграмма кооперации (соllаboration diagram) предназначена для графического представления всех структурных отношений между объектами, участвующими во взаимодействии. Кооперация служит для обозначения множества взаимодействующих с определенной целью объектов. Кооперация может быть представлена на двух уровнях/

*Спецификации, показывая роли классификаторов и ассоциаций в рассматриваемом взаимодействии.

* Примеров, указывая экземпляры и связи, образующие отдельные роли в кооперации,

Объекты на диаграмме располагаются в виде вершин графа. Cвязи соединяют вершины дугами. Связи могут быть аннотированы сообщениями, которые объекты принимают и посылают.

Диаграмма компонентов (component diagram) описывает особенности физического представления системы. Она позволяет определить архитектуру разрабатываемой системы, устанавливая зависимости между компонентами

Диаграмма развертывания (применения, размещения) (deployment diagram) отображает физические взаимосвязи между программными и аппаратными компонентами системы.

 

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

Превосходно, Ватсон, Вы делаете успехи. Правда, Вы упустили все существенные детали, зато хорошо усвоили метод Артур Конан Дойль. “Приключения Шерлока Холмса”  

Подходы к ведению анализа и проектирования.

Итак, комбинации структурных методов образуют структурные подход. Можно выделить три группы структурных подходов на основе порядка строения модели… * Процедурно-ориентированные подходы, в которых первично проектирование… * Подходы, ориентированные на данные. Для таких подходов первичными являются входные и выходные данные, а…

Программирование (реализация)

Стиль программирования

Стиль — это отражение мышления

А. Шопенгауэр

Важнейшая технологическая задача, возникающая в процессе программирования, — соответствие единому стилю программирования. Под стилем… * очевидная логика; * естественные выражения;

Защитное программирование

Существуют три основных принципа защитного программирования. · Общее недоверие. Для каждого модуля входные данные должны тщательно… · Немедленное обнаружение. Каждая ошибка должна быть выявлена как можно раньше, это упрощает установление ее…

Выбор языка программирования

· Сравнительная пригодность языка программирования для данной задачи. · Избранная методология. Часто говорят, что язык поддерживает ту или иную… · Степень важности для разработчика многочисленных характеристик и свойств, которые могут быть присущи или не присущи…

Тестирование и отладка

 

Гораздо легче найти ошибку, нежели истину.

Гете

 

Введение в тестирование и отладку

Тестирование — процесс выполнения программ с целью обнаружения факта наличия ошибок. Это классическое определение тестирования, принадлежащее Гленфорду Майерсу. Обратим внимание, в определении указан лишь один способ проведения тестирования. Существуют и методы ручного тестирования (например, инспекции и сквозные просмотры программ). Поэтому слова “процесс выполнения программ” разумно заменить на “любая деятельность, выполняемая...”.

Отладка — процесс локализации и устранения ошибок.

Тестирование начинается с разработки множества тестов и их исполнения на основе одной из выбранных методик. После сравнения результатов с эталонными начинается либо диагностика проблемы (в случае расхождения результатов), либо оценка достаточности полноты тестирования. Подготовка дополнительных тестов потребуется при недостаточной полноте тестирования, невозможности локализовать проблему с помощью имеющихся тестов и необходимости выполнить контроль сделанного исправления. (http://www.testingfaqs.org/)

 

Тестирование программных продуктов

-тестирование программы как черного ящика, при котором программа рассматривается как объект, внутренняя структура которого неизвестна. -тестирование программы как прозрачного (белого) ящика подразумевает знание… Существуют также разновидности тестирования:

Отладка программных продуктов

1. Следует начать с изучения уже доступных исходных и результирующих данных. 2. Сформулировать некоторую гипотезу, которая объясняет получение таких… 3. Подготовить новые исходные данные и провести эксперимент, который позволит доказать или опровергнуть гипотезу.

Эксплуатация и сопровождение

Перечислим четыре основные класса задач, решаемых на этапе сопровождения. · Адаптация, как правило, заключающаяся в модификации функций. · Усовершенствование, заключающееся обычно в добавлении новых функций.

Завершение эксплуатации

Ученью не один мы посвятили год

потом других учить пришел и нам черёд

Какие ж выводы из этой всей науки?

Из праха мы пришли, нас ветер унесет

О. Хайям

 

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

Стандартные технологические процессы

 

Процессы жизненного цикла определяются международным стандартом ISО/IЕС 12207 [ISO/IEC 12207:1995]. В данной книге русскоязычные формулировки стандартных процессов и действий, которые они включают, приведены согласно учебнику Вендрова [Вендров 2000]. Стандартные процессы разделяются на три группы — основные, вспомогательные и организационные процессы.

 

Основные процессы

Некоторые удавы в процессе удушения так запутывались в собственных узлах, что потом приходилось тратить много времени на их распутывание

Ф. Искандер “Кролики и удавы”

 

Приобретение

Процесс приобретения состоит из действий заказчика, приобретающего программное обеспечение. Процесс включает следующие действия:

* инициирование приобретения;

* подготовку заявочных предложений;

* подготовку и корректировка договора;

* надзор за деятельностью поставщика;

* приёмку и завершение работ.

 

Поставка

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

* инициирование поставки;

* подготовку ответа на заявочные действия;

* подготовку договора;

* планирование;

* выполнение и контроль;

* проверку и оценку;

* поставку и завершение работ.

 

Разработка

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

* подготовительная работа;

* анализ требований к системе;

* проектирование архитектуры системы;

* анализ требований к программному обеспечению;

* проектирование архитектуры программного обеспечения;

* детальное проектирование программного обеспечения;

* кодирование и тестирование программного обеспечения;

* интеграция программного обеспечения;

* квалификационное тестирование программного обеспечения;

* интеграция системы;

* квалификационное тестирование системы;

* установка программного обеспечения;

* приемка программного обеспечения.

 

Эксплуатация

Процесс эксплуатации охватывает действия оператора — организации, эксплуатирующей систему.

* подготовительную работу;

* эксплуатационное тестирование

* поддержку пользователей.

 

Сопровождение

Процесс сопровождения предусматривает действия, выполняемые службой сопровождения. Процесс включает следующие действия:

* подготовительную работу;

* анализ проблем и запросов на модификацию программного обеспечения;

* модификацию программного обеспечения;

* проверку и приемку;

* перенос программного обеспечения в другую среду;

* снятие программного обеспечения с эксплуатации.

 

Вспомогательные процессы

Документирование

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

* подготовительную работу;

* проектирование и разработку;

* выпуск документации;

* сопровождение документации.

 

Управление конфигурацией

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

* определения состояния компонентов программного обеспечения в системе;

* описания и подготовки отчетов о состоянии компонентов программного обеспечения и запросов на модификацию, обеспечение полноты, совместимости и корректности компонентов;

* управления хранением и поставкой программного обеспечения.

Процесс включает следующие действия:

* подготовительную работу;

* идентификацию конфигурации;

* контроль конфигурации;

* учет состояния конфигурации;

* оценку конфигурации;

* управление выпуском и поставкой.

 

Обеспечение качества

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

Процесс включает следующие действия:

* подготовительную работу;

* обеспечение качества продукта;

* обеспечение качества процесса;

* обеспечение прочих показателей качества системы.

 

Верификация

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

Процесс включает два действия — подготовительную работу и собственно верификацию.

 

Аттестация

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

Процесс включает два действия — подготовительную работу и аттестацию.

 

Совместная оценка

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

Процесс включает три действия — подготовительную работу, оценку управления проектом и техническую оценку.

 

Аудит

Процесс аудита представляет собой определение соответствия программного продукта требованиям, планам и условиям договора. Особенность аудиторской проверки состоит в ее независимости.

Процесс включает два действия — подготовительную работу и аудит.

 

Разрешение проблем

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

Процесс включает два действия — подготовительную работу и собственно разрешение проблем.

 

Организационные процессы

Управление

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

Процесс включает следующие действия:

* инициирование и определение области управления;

* планирование;

* выполнение и контроль;

* проверку и оценку;

* завершение.

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

 

Создание инфраструктуры

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

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

 

Усовершенствование

Процесс усовершенствования определяет оценку, измерение, контроль и усовершенствование процессов жизненного цикла.

Процесс включает три действия — создание, оценку и усовершенствование процесса.

 

Обучение

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

Основные стадии технологических подходов

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

Существует два основных варианта формирования временных рамок.

 

Фазы, как крупные временные рамки

В этом случае названия фаз отражают крупные временные рамки. Примеры такого деления присутствует в рациональном унифицированном процессе [Буч, Рамбо, Джекобсон 2000].

* Начало — определение бизнес-целей проекта.

* Исследование — разработка плана и архитектуры проекта.

* Построение — постепенное создание системы.

* Внедрение – поставка системы конечным пользователям

 

Стадии как отражение классических процессов

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

* возникновение и исследование идеи;

* планирование;

* анализ требований;

* проектирование;

* программирование (реализация);

* тестирование и отладка;

* ввод в действие;

* эксплуатация и сопровождение;

* завершение эксплуатации.

 

Вариант подробного разбиения стадий

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

* стадия возникновения и исследования идеи;

* стадия планирования проекта;

* стадия анализа и проектирования;

* стадия реализации;

* стадия версии разработчика;

* стадия оценки жизнеспособности продукта;

* стадия альфа-версии;

* стадия бета-версии;

* стадия версии первой поставки пользователю.

Каждая стадия может быть разбита на этапы, отражающие основные события ее существования.

Стадия возникновения и исследования идеи.

• Этап-1 — Исследование идеи.

• Этап-2 — Концентрация идеи в виде одностраничного описания.

• Этап-3 — Принятие решения о начале работы над проектом.

Стадия планирования проекта.

• Этап- 1 — Подготовка плана проекта.

• Этап-2 — Техническое рецензирование проекта.

• Этап-3 — Начало формирования команды разработчиков.

• Этап-4 — Обзор планов инженеров.

• Этап-5 — Исследование и поиск необходимых ресурсов.

• Этап-6 — достижение соглашения о выделении ресурсов.

• Этап-7 — Утверждение проекта.

Стадия анализа и проектирования.

• Этап-1 — Анализ и проектирование продукта.

• Этап-2 — Планирование разработки тестов и документации.

Стадия реализации.

• Этап-1 — Кодирование, разработка тестов и документации.

• Этап-2 — Интеграция кода, тестов и документации.

Стадия версии разработчика.

• Этап-1 — Объединение кодов нескольких компонентов, составляющих проект.

• Этап-2 — Стабилизация версии.

• Этап-3 — Тестирование.

• Этап-4 — Распространение версии.

Стадия оценки жизнеспособности продукта.

• Этап-1 — Оценка жизнеспособности продукта.

Стадия альфа-версии.

• Этап-1 — Объединение кодов нескольких компонентов, составляющих проект.

• Этап-2 — Стабилизация версии.

• Этап-3 — Формальное начало выпуска версии.

• Этап-4 — Распространение версии.

• Этап-5 — Продолжающаяся разработка.

• Этап-6 — Формальное тестирование.

• Этап-7 — Начало сопротивления изменениям.

Стадия бета-версии.

• Этап-1 — Объединение кодов нескольких компонентов, составляющих проект.

• Этап-2 — Стабилизация версии.

• Этап-3 — Создание электронного образа версии поставки.

• Этап-4 — Формальное тестирование версии.

• Этап-5 — Начало процесса помещения версии продукта на страницы в Интернете или на компакт-диски, дискеты или другие носители.

Стадия версии первой поставки пользователю.

• Этап-1 — Принятие решения о возможном переименовании бета версии в версию первой поставки пользователю в случае отсутствия ошибок и переходе к этапу 6.

• Этап-2 — Объединение кодов нескольких компонентов, составляющих проект.

• Этап-3 — Стабилизация версии.

• Этап-4 — Создание электронного образа версии поставки.

• Этап-5 — Формальное тестирование версии.

• Этап-6 — Начало процесса помещения версии продукта на страницы в Интернете или на компакт-диски, дискеты или другие носители.

• Этап-7 — Завершающий анализ работы над версией (‘разбор полётов”).

 

К моменту завершения проекта

Статистики от стоматологии вывели закон “3 к 11”, Они обнаружили, что пациенты распространяют информацию о зубных врачах следующим образом. Если зуб вылечен хорошо, то человек рассказывает об этом в среднем трем своим знакомым. Если плохо — тогда одиннадцати. Именно такова психология людей и заказчиков в том числе. Именно это надо учитывать и добиваться полного удовлетворения заказчиков и пользователей, создавая о себе хорошую славу.

 

Контрольные точки

Уточним лишь, что традиционно понимается под различными типами версий и критериями, к ним предъявляемыми. * Версия разработчика является ранней версией для внутреннего использования и… * На этапе альфа-версии продукт должен быть функционально полным, все фрагменты должны быть правильно интегрированы в…

Основные технологические подходы

 

Откуда мы пришли? Куда свой путь вершим?

В чем нашей жизни смысл? Он нам непостижим

Как много чистых душ под колесом лазурным

Сгорает в пепел, в прах, а где, скажите, дым.

О. Хайам

 

Ранние технологические подходы

Подход кодирование и исправление Подход “кодирование-исправление” (соde and fix) упрощенно может быть описан следующим образом. Разработчик начинает…

Каскадные технологические подходы

Каскадные технологические подходы задают некоторую последовательность выполнения процессов, обычно изображаемую в виде каскада. Эти подходы также иногда называют подходами на основе модели водопада.

 

Каскадный подход

Каскадный подход (pure waterfall) считается “дедушкой” технологических подходов к ведению жизненного цикла. Фактически, его можно рассматривать как отправную точку для огромного количества других подходов. Сформировался каскадный подход в период с 1970 по 1985 годы. Специфика “чистого” каскадного подхода такова, что переход к следующему процессу осуществляется только после того, как завершена работа с текущим процессом (см. рис. 1). Возвраты к уже пройденным процессам не предусмотрены.

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

 

Каскадно-возвратный подход

Основной недостаток каскадного подхода — отсутствие гибкости. Именно этот недостаток преодолевается каскадно-возвратным подходом, в котором разрешены возвраты к предыдущим стадиям и пересмотр или уточнение ранее принятых решений (рис. 3.6). Каскадно-возвратный подход отражает итерационный характер разработки программного обеспечения. Этот подход в значительной степени отражает реальный процесс создания программного обеспечения, в том числе и существенное запаздывание с достижением результата. На задержку оказывают существенное влияние корректировки при возвратах.

Рис. 6. Каскадно-возвратный подход

 

Каскадно-итерационный подход

Каскадно-итерационный подход предусматривает последовательные итерации каждого процесса до тех пор, пока не будет достигнут желаемый результат (рис. 7). Каждая итерация является завершенным этапом, и ее итогом будет некоторый конкретный результат. Возможно, данный результат будет промежуточным, не реализующим всю ожидаемую функциональность.

 

Рис. 7. Каскадно-итерационный подход

 

Каскадный подход с перекрывающимися процессами.

Классический каскадный подход позволяет выполнять каждый процесс отдельной команде. Достаточно разумным является использование команды на том же самом процессе в следующей разработке. Каскадный подход с перекрывающимися процессами (waterfall with overlapping) предполагает наличие таких специализированных команд, позволяющих до определенной степени сократить передаваемую документацию. Следующий процесс начинается до завершения текущего (рис. 8). Более того, несколько процессов могут выполняться параллельно.

 

Рис. 8. Каскадный подход с перекрывающимися процессами.

 

Каскадный подход с подпроцессами

Каскадный подход с подпроцессами (waterfall with subprocesses) очень близок подходу с перекрывающимися процессами. Особенность его в том, что с архитектурной точки зрения проект достаточно часто может быть разделен на подпроекты, которые могут разрабатываться индивидуально (рис. 9). В данном подходе требуется дополнительная фаза тестирования подсистем до объединения их в единую систему. Следует особое внимание обращать на грамотное деление проекта на подпроекты, которое должно учесть все возможные зависимости между подсистемами.

 

Рис. 9. Каскадный подход с подпроцессами.

 

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

Особенность спиральной модели — в разработке итерациями. Причем каждый следующий итерационный прототип будет обладать большей функциональностью.  

Каркасные технологические подходы

Рациональный унифицированный процесс Рациональный процесс (rational unified prосеss) [Фулер, Скотт 1999] [Рамбо,… А вот в период прохождения этих фаз и функционируют процессы (на пример, анализ и проектирование), которые к тому же…

Генетические технологические процессы

Название этой группы подходов дано под впечатлением от статьи Поттосина [1997], в которой термин “генетический” связывается с происхождением программы и дисциплиной ее создания.

Синтезирующее программирование

* Доопределить детали, которые нельзя выразить при помощи языка спецификации, но необходимые для получения исполняемого кода. * Выбрать язык реализации и аппаратно-программную платформу для реализации. … * Зафиксировать отображение понятий языка спецификаций на язык реализации и аппаратно-программную платформу.

Сборочное (расширяемое) программирование

  Рис. 12. Сборочное программирование

Конкретизирующее программирование

Наиболее известная технология конкретизирующего программирования это подход с применением паттернов проектирования [Гамма, Хелм, Джонсон, Влиссидес… Паттерн состоит из четырех основных элементов: * имени — однозначно описывающего проблему проектирования;

Подходы на основе формальных преобразований

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

Технология стерильного цеха

* разработка функциональных и пользовательских спецификаций; * инкрементальное планирование разработки; * формальная верификация;

Формальные генетические подходы

Формальное синтезирующее программирование использует математическую спецификацию - совокупность логических формул. Существуют две разновидности… - логическое, в котором программа извлекается как конструктивное… - трансформационное, в котором спецификация рассматривается уравнение относительно программы и символическими…

Группа ранних подходов быстрой разработки

Развитием и одновременно альтернативой каскадных подходов является группа подходов быстрой разработки. Все эти подходы объединяют следующие основные черты:

- итерационную разработку прототипа;

- тесное взаимодействие с заказчиком.

 

Эволюционное прототипирование

Рис. 15. Эволюционное прототипирование.  

Итеративная разработка

Первый прототип итеративной разработки (iterative delivery) уже должен включать завершенное ядро системы. Таким образом, в нем уже сосредоточена большая часть функциональности. Очередные итерации должны помочь пользователю определиться с доводкой пользовательского интерфейса, генерируемой системой отчетов и других выходных данных (рис. 16).

Рис. 16. Итеративная разработка

 

Допускается добавление незначительной функциональности, обычно не затрагивающей ядро системы.

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

 

Постадийная разработка

Постадийная разработка (steged delivery) предназначена решить недостаток двух предыдущих подходов — невозможность определения сроков завершения проекта. Начиная разработку, мы достаточно хорошо знаем — что будет собой представлять создаваемый программный продукт. Основная задача, постадийной разработки — предоставить заказчику работающую систему как можно раньше. Далее заказчик сможет добавлять новую функциональность и получать очередную версию системы. Однако каждая из версий, получаемых по завершении стадий, является работающей.

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

 

Адаптивные технологические подходы

Адаптивные технологические подходы были задуманы как подходы, поддерживающие изменения. Они только выигрывают от изменений, даже когда изменения происходят в них самих. Данные подходы ориентированы на человека, а не на процесс. В них необходимо учитывать в работе природные качества человеческой натуры, а не действовать им наперекор (http://www.martinfowler.com).

 

Экстремальное программирование

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

Адаптивная разработка

Результаты планирования (которое само здесь является парадоксальным) в адаптивной разработке всегда будут непредсказуемыми. При обычном планировании… Программисты должны активно сотрудничать между собой для преодоления… Обучение является постоянной и важной характеристикой подхода. И программисты, и заказчики в процессе работы должны…

Подходы исследовательского программирования.

- разработчик ясно представляет направление поиска, но не знает заранее, как далеко он сможет продвинутся к цели; - нет возможности предвидеть объем ресурсов для достижения того или иного… - разработка не поддается детальному планированию, она ведется методом проб и ошибок;

Технологии коллективной разработки

 

Все множество разработок в зависимости от количества участников и взаимоотношений между НИМИ может быть сведено к триаде коллективных разработок, приведенной на рис. 21.

Рис. 21. Триада коллективных разработок

 

Авторская разработка

Люблю одиночество, даже когда я один.

Ж. Ренар

 

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

Этот принцип был достаточно широко распространен в 70—80-е ХХ века. Сейчас он применяется редко [Куличёв1999]. Примерами авторских разработок являются операционная система Диспак (В.Ф. Тюрин), текстовый редактор Лексикон (Е. М. Веселов), трансляторы с языков Algol-68 (П. Наур) и Раscal (Н. Вирт).

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

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

По данным А. П. Кулаичева [Кулаичев 1999], авторская разработка может выигрывать по производительности в тридцать и более раз у коллективной разработки, что достигается за счет:

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

- исключения работ по разбиению проекта на составляющие, по распределению их между исполнителями, по координации деятельности исполнителей и контролю за их работой.

Объём программного продукта, выполненного методом авторской разработки в 5—20 раз меньше по сравнению с индустриальными аналогами.

Авторская разработка предполагает достижение профессионального успеха, известности и славы в одиночку. Такое вполне реально, следует только правильно выбрать профессиональную ‘нишу”, область ведения разработки.

Об авторской разработке

В наибольшей степени авторская разработка в наши дни применяется при создании условно-бесплатных программных продуктов (shareware)

 

Коллективная разработка

Собрать стадо из баранов легко, трудно собрать стадо из кошек.

С. П. Капица

 

Одним из основных вопросов коллективной разработки является разделение труда — от равноправных соисполнителей до организации в виде жесткой иерархии (например, бригады главного программиста).

 

О первых опытах коллективных разработок

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

 

Технические командные роли.

Равноправные соисполнители

Бригада равноправных соисполнителей обычно состоит из специалистов занимающихся примерно подобными задачами в рамках одного проекта. Естественно, специализаций в рамках одной бригады может быть несколько. Примерный состав такой бригады разработчиков:

- инженеры-разработчики (специалисты по инженерии программирования и программисты);

- технические писатели;

- инженеры тестирования;

- инженеры качества;

- специалисты по сопровождению продукта;

- специалисты по продажам продукта.

Тип работы определяет содержание и природу выполняемой работы. Приведём список типов работ и областей специализации на основе классификации Конгер [Conger 19941.

 

Разработка приложений.

- Программист.

• Специалист по инженерии программирования.

• Специалист по инженерии знаний.

 

Работа с приложениями.

• Специалист по приложениям.

• Администратор данных.

• Администратор базы данных.

 

Техническая поддержка.

• Системный администратор.

• Сетевой администратор.

• Администратор коммуникаций.

 

Обеспечение качества продукта.

• Технический писатель.

• Инженер тестирования.

• Инженер качества.

 

Маркетинг.

• Специалист по сопровождению продукта.

• Специалист по продажам продукта.

- Системное интегрирование.

• Системный интегратор.

 

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

 

Бригада главного программиста

— Почему бригада скорой помощи состоит из двух врачей?

— Один знает — куда ставить клизму, а другой — зачем!

Анекдот о специализации в команде

 

Хирлан Миллз [Брукс 1999] предложил организовывать команды (бригады) главного программиста (chief programmer teams) подобные хирургическим бригадам. Лишь один участник команды занимается основной работой, остальные оказывают ему всевозможную поддержку. Бригада главного программиста включает десять человек, выполняющих специализированные роли в команде (рис. 22).

Рис. 22. Бригада главного программиста

 

Основные члены бригады выполняют функции, перечисленные ниже.

Главный программист. Лично выполняет анализ и проектирование, создание и отладку кода, написание документации. Должен обладать талантом, большим опытом работы и существенными знаниями.

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

Администратор (он же — менеджер). Под его контролем — деньги, люди помещения, машинные ресурсы, контакты с другими группами и руководством.

Редактор. Фактически, это технический писатель. Его задача — критически переработать черновики документации (созданные главным программистом), снабдить их ссылками и библиографией и обеспечить публикацию или помещение в Интернете.

Языковед. Эксперт в тонкостях языков программирования. Может найти эффективные способы использования языка для решения сложных задач. Обычно работает с несколькими бригадами.

Инструментальщик. Разработчик специализированных инструментов утилит и скриптов. Поддерживает основной инструментарий и оказывает по нему консультации. При необходимости может осуществлять администрирование операционной системы.

Отладчик. Разработчик тестов и организатор тестирования программного продукта.

Делопроизводитель. Отвечает за регистрацию всех технических данных бригады в библиотеке программного продукта. Благодаря делопроизводителю, активные программисты освобождались от рутинных работ. (Заметим, что в настоящее время функции делопроизводителя автоматизированы и переданы репозиторию проекта).

 

Психологические командные роли

  Председатель. Выбирает путь, по которому команда движется вперед к общим… Архитектор. Он же оформитель. Придает законченную форму действий команды. Имеет четкое представление о проблемах и их…

Типы совместной деятельности

- Мандатная деятельность, обычно представленная формальными собраниями, проводимыми на регулярной основе. Обычно собрания планируются заранее, а… - Созываемая деятельность, которая имеет место в случае решения двух или более… - Естественная совместная деятельность имеет место, когда как минимум двое программистов работают над одной и той же…

Общинная модель разработки

Антуан де Сент-Экзюпери.   Идеология общинной (“базарной”) модели разработки сформулирована в программной статье Эрика Раймонда (Егiс Raymond)…

Качество программного обеспечения

 

Мы должны отыскать себе благородного мужа, которого мы имели бы всегда перед глазами, чтобы жить, точно он всегда смотрит на нас, и поступать, точно он видит наши поступки.

Эпикур

 

Завершим данную главу рассмотрением вопроса качества программного обеспечения. Неявно подразумевается требование идеального качества. Одна из возможных альтернатив качественному программному обеспечению — достаточно хорошее” программное обеспечение, которое мы также рассмотрим. Программисты-профессионалы, прекрасно понимая необходимость создания качественного программного обеспечения, видят некоторую однобокость исследований. Да, сертифицированная по ISO 9000 организация не должна потерять исходный код программ, работающих у заказчика. Однако стандарт не делает ничего позитивного в улучшении способности программировать.

 

Подходы к качеству программного обеспечения

Первое измерение ориентировано либо на продукт, либо на процесс. Для повышения качества программного обеспечения можно сосредоточиться на качестве… Второе измерение связано либо с соответствием, либо с усовершенствованием. Под… ISO 9126 является стандартом на качество продукта, определяющим атрибуты и характеристики качества, включая измерения…

Характеристики качества программного обеспечения.

В настоящее время не существует общепринятых критериев качества программного обеспечения. Стандарт ISO 9000-3, п. 6.4.1  

Оценка качества процесса разработки

Требовать и эффективности и гибкости от одной и той же программы – всё равно, что искать очаровательную и скромную жену. По-видимому, нам следует остановиться на чем-то одном из двух

Д. Вейнберг

 

В начале данного раздела мы отметили, что существует два подхода, которые могут применяться для оценки качества программного продукта.

Оценить качество конечного продукта.

Оценить качество процесса разработки.

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

 

Модель зрелости процесса разработки программного обеспечения

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

Определение возможностей и улучшение процесса создания программного обеспечения

Уровень 0. Процесс не выполняется. Уровень 1. Выполняемый процесс. Уровень 2. Управляемый процесс.

Достаточно хорошее программное обеспечение

Вчера в Сиэтле после упоминания Биллом Гейтсом о выходе бета-версии новой программы компании Мicrosoft произошло землетрясение. Пользователи с… Анекдот по мотивам землетрясения и выступления Б. Гейтса 28-го февраля 2001…  

Стандартизация информационных технологий

Стандарты можно классифицировать следующим образом: - по типу установления требований: • устанавливающие требования к объекту;