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

Работа добавлена на сайт samzan.net:

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

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

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

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

3 курс, 1 семестр

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

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

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

2005

Содержание

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 .1. Основные понятия и определения

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

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

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

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

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

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

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

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

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

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

Б. Шоу

В истории технологии программирования можно выделить три этапа.

*Осмысление опыта разработки больших систем. Понимание того, что не важно не только НА КАКОМ ЯЗЫКЕ ПРОГРАММИРОВАНИЯ разрабатывается программа, но и КАК это делается. Проведение первых международных и национальных конференций (конец 60-х —-е годы ХХ века).

•г. —НАТО проводит первую конференцию по инженерии программирования

•г. —-я международная конференция IЕЕЕ.

•г. —-я Всесоюзная конференция по технологии программирования.

Разработка новых технологических подходов (начало 70-х годов ХХ века —настоящее время).

•г. —Дугласом Россом (Douglas Ross) разработана технология проектирования сложных систем SАВТ (Structured Аnаlуsis and Design Тесhnique). Стандартизована под названием IDЕF (Integrated DEFinition).

•г. —Харланом Миллзом (Нагlаn Мills) сформулированы основные идеи технологии стерильного цеха.

•г. —в октябре появилась первая пробная версия Унифицированного метода. Этот проект с 1996 года известен как UML (Uпifiеd Моdе1iпg Language). С точки зрения технологических подходов особый интерес представляет рациональный унифицированный процесс.

Принятие стандартов на состав процессов жизненного цикла программного обеспечения (середина 80-х годов ХХ века —настоящее время). Попытки решить проблему качества программных продуктов.

•г. —впервые утвержден стандарт жизненного цикла для проектирования программных систем (для систем военного назначения по заказам Министерства обороны США).

•г. —в Великобритании создан международный консорциум, разрабатывающий на постоянной основе проекты стандартов и технологии быстрого создания приложений DSDM(Dynamic Systems Development Меtod).

•г. —принят международный стандарт ISO 12207:1995 “Information Technology —Software Life Cycle Ргосеsses”, регламентирующий состав процессов жизненного цикла программного обеспечения.

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

1.3.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).

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

Мы будем рассматривать два набора (множества) технологических процессов. Первый набор —классический, включающий основные процессы,  сложившиеся исторически в результате практического опыта разработки программного обеспечения. Второй набор —стандартный, т. е. основанный  на стандарте 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).

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

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

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

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

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

Конфуций

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

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

Максимизация скорости разработки. Это направление в большей степени обращено к искусству, импровизации и поиску. Гибкие и адаптивные технологические подходы поддерживают именно этот путь. Особенность разработки определяется появлением новых классов систем. За последние несколько десятков лет такими классами были, например, системы “клиент-сервер”, распределенные системы, интерактивные системы, системы интернет-приложений. С точки зрения технологий, задача разработки интернет-приложений является очень специфичной. Базироваться на классических технологических подходах ей не позволяют следующие особенности:

•задача, как правило, не будет четко определена и специфицирована;

•заказчики не смогут точно сформулировать свои требования;

•как только система будет завершена, она устареет;

•система должна правильно взаимодействовать с независимо разработанными программами.

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

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

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

Книги банальны. Гениальна только жизнь

Томас Карлейль

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

“Мифический человеко-месяц, или как создаются программные системы Брукс [1999]. Считается, что без прочтения этой книги не может состояться ни один крупный руководитель программного проекта. Первое издание книги вышло в 1975 году. Спустя 20 лет Фредерик Брукс выполни ревизию своих старых идей и добавил новые.

‘Программное обеспечение и его разработка’[Фокс 1985]. Автор излагает общие проблемы создания программного обеспечения, его сопровождения и использования с обилием конкретного материала.

“Путь камикадзе. Как разработчику программного обеспечения выжить безнадёжном проекте” [Йордан 2000]. Книга написана профессионалом, понимающим все современные проблемы и сложности в создании программного продукта.

“Объектно-ориентированный анализ и проектирование с примерами приложений на С++ [1998]. Прекрасное практическое руководство по созданию объектно-ориентированных систем. Считается, что благодаря этой работе объектно-ориентированное проектирование и систем обозначений были взяты тысячами программистами для применения реальных разработках в различных предметных областях.

“Проектирование программного обеспечения экономических информационных систем” [Вендров 2000]. Особенность этой книги в изложении международных и отечественных стандартов на процессы жизненного цикла программного обеспечения. Достаточно подробно описан ряд промышленных технологий.

Часть работы “Методология программирования” [Турский1981] посвящен проектированию программ. Классическим учебником по технологии программирования считается книга “Software Engeniring” [Sommerville 1992] Рекомендации по управлению разработкой программного продукта подробно изложены в работе “The New Software Engeniring” [Conger 1994].

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

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

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

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

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

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

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

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

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

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

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

- препятствует созданию или развитию программного продукта;

- приводит к ошибкам в программном продукте.

Наиболее интересными являются инновационные решения. Инновация —нововведение, изменяющее уже существующую результативную систему, как правило, с положительным эффектом или предлагающее новое решение некоторой проблемы в обозначенные время и месте [Косовский, Хитров 1997]. Инновация включает в себя и изобретения, и открытия, и просто новшества. Результативная инновация —это инновация, изменяющая уже существующее решение с улучшением некоторых его характеристик, либо предлагающая к ранее не решенной проблеме решение, приносящее положительный эффект. Примеры результативных инноваций в программировании —создание глобальной сети Интернет и разработка интегрированной среды программирования.

В научном творческом поиске [Шевчук, Харахоркина, Журавлев, Армен 1998] отрицательный результат, как правило, также имеет существенное значение. С самого начала научного поиска следует понять —где проходит гран между знанием и незнанием. Научный поиск отличает определенное достоинство. заключающееся в верности критерию сдержанности и проверка идей, систематичности объяснений.

Поиск решения может включать эвристические правила. В качестве примеров укажем подход, предложенный Д. Пойа [Пойа 1957] для решения нов задач, и алгоритм решения изобретательских задач Г. С. Альтшуллера (http://www.triz.minsk.by/index0.htm) Роль интуиции в творческом поиске исследуется в книге “Интуиция и искусственный интеллект” [Грановская, Березная 1991].

Предложим несколько советов по организации поиска решения зада [Косовский, Хитров 1997]

* Ждать, пока решение не придет в голову. Лишь при затянувшемся ожидании следует переходить к другим советам. Следует заметить, что особенно эффективен этот совет для ответа на следующие вопросы: ‘Что такое любовь?”, “Что такое старость?”.

* Следует понять —в чем смысл вопроса. Зачем вообще решать эту задачу. Здесь уместен принцип “выковыривания изюминки” —чтобы начать выковыривать изюминку, надо сначала найти булку с изюмом.

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

* Фиксировать внимание к произвольным мыслям и ощущениям.

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

Эдвард де Боно (Edward de Bono) выделяет два типа мышления с соответствующими подходам и решения задач

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

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

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

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

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

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

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

Одностраничный документ

Разработка руководства пользователя по ОреnМР.

Краткий обзор

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

Предлагается разработка документации “Руководство пользователя по ОреnМР”.

Введение

Название проекта: Руководство пользователя по ОреnМР.

Дата подготовки документа: 19 августа 2005 версия 1.5.

Описание особенностей поставки

Документ “Руководство пользователя по ОреnМР” будет доступен как на сервере компании в сети Интернет, так и в бумажной копии.

Поскольку в данной реализации проекта “Волхов” не будут включены все особенности спецификации ОреnМР, необходимо четко указать, какие из них будут реализованы, а какие нет.

* Полная  спецификация по OpenMP доступна в Интернете (http://www.openmp.org/)

Пользователи документа

Пользователь —опытный программист на языках С, С++, Pascal, FORTRAN понимающий преимущества распараллеливания программ на многопроцессорных ЭВМ.

Сравнительный анализ

Многие разработчики компиляторов (например, компании SGI, Sun, IBM] уже включили поддержку ОреnМР. Описание ОреnМР они включают как отдельные главы в руководство пользователя по компиляторам с языков С++, Раscal и FORTRAN. С нашей точки зрения, лучшим решением будет иметь единый документ для всех компиляторов.

Описание технического процесса

* Исследовать возможность импортирования спецификаций ОреnМР посредственно из документа.

* Определить с помощью инженеров, реализующих поддержку ОреnМ какие особенности спецификации ОреnМР войдут в состав текущей версии компилятора.

* Разработать проект “руководства” и определить способ его распространения (совместно с группой маркетинга).

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

* Включить информацию о “руководстве пользователя” в документ “Новости компании Компилятор++”

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

Выяснить право использовать фрагменты оригинальной спецификации ОреnМР (это позволит сэкономить время, необходимое для разработки оригинальной части документации).

Список основных документов

Спецификация ОреnМР.

Основные даты

•  Завершение проектирования “руководства” —апрель 2005 г.
•  Первый вариант полного “руководства ” –август 2005 г.

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

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

М. Твен

Практически всегда перед принятием решения проводится экспертиза идеи и проекта, который на ней основан. Специалисты должны в течение не скольких дней изучить и проанализировать идею. В их задачу входят два основных момента [Баранов 1998].

* Подтвердить или поправить все предположения, на которых базируется проект. На основании этих предположений будут делаться все дальнейшие построения.

* Выявить и охарактеризовать все критические моменты в проекте. Специалисты должны указать —что не предусмотрено, и к каким последствиям это может привести.

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

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

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

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

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

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

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

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

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

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

* Наличие формализованной модели для разработки программного продукта.

* Наилучшая расстановка приоритетов и ресурсов.

* Принятие ясных и документированных решений.

* Соблюдение многочисленных стандартов.

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

* Тесное взаимодействие с группами поддержки и продаж.

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

Предпринимательская деятельность фирмы строится исходя из этой задачи, объединяющей пять направлений [Пашкус, Мисько 1991].

* Стратегию в области исследования и развития.

* Оперативную стратегию.

* Финансовую стратегию.

* Маркетинговую стратегию.

* Стратегию человеческих отношений.

Согласно этим направлениям управление можно поделить на три составные части: производственную, финансовую и маркетинг.

Разделим управление (менеджмент) как систему принятия решений в области управления фирмой и поделим всех служащих компании на четыре уровня

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

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

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

* Инженеры (внеменеджментовые служащие). Именно инженеры заняты разработкой и созданием программного продукта.

Лидерами команд разработчиков обычно являются два специалиста, тесно работающих вместе по всем направлениям разработки.

* Управляющий (менеджер) проекта —руководитель, обладающий организационными знаниями и опытом.

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

Заметим, что часто в небольших проектах и командах обе задачи исполняет один человек.

Обязанности управляющего

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

Совместная деятельность менеджера и лидера проекта включает:

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

* распределение работ;

* выбор наилучшей стратегии.

Исключительная ответственность менеджера заключается:

* В организации взаимосвязей внутри организации;

* В управлении сотрудниками. Менеджер ищет и привлекает лучших специалистов и экспертов для решения возникающих проблем;

* в руководстве проектом и контролем его выполнения. Менеджер следит за ежедневное руководство данным проектом. Хороший менеджер видит различные проблемы от группы, он “гасит” нагоняи от заказчика вышестоящего руководства;

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

* в ответственности за поступление средств.

О том, что руководитель —это профессия

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

Еще раз обратимся к понятию “проект” и выделим четыре характеристики делающих деятельность —проектом [Баранов 1998].

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

* Координированное выполнение взаимосвязанных действий. Здесь следует ещё раз вспомнить сложность разработки программного продукта. Взаимосвязи в проекте не всегда очевидны. Некоторые задания должны выполнятся строго последовательно, а некоторые —строго параллельно.

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

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

О том, что проектом не является

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

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

Менеджер не должен позволять вмешиваться кому-либо другому в руководство проектом. На ежедневное руководство в среднем у него должно уходить 50% рабочего времени. Если менеджер тратит менее 50% времени на руководство, это означает, скорее всего, что он плохой руководитель и проект ждут серьезные проблемы.

О том, куда уходит время

Существует так называемый “феномен 5-го телефонного звонка”. Он заключается в том, что нужный, но неизвестный пока человек находится в среднем после пятого телефонного звонка. Это объясняет, почему руководитель тратит так много времени на деятельность, связанную с осуществлением руководства.

Метод “Кнута и Пряника” —алгоритм, описанный в известной монографии Кнута [Кнут 2000) и позднее модифицированный русским программистом Пряником.

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

Руководителям было издавна известно, что людей следует побуждать к действиям для достижения некоторого желательного результата. Мотивация —это процесс побуждения себя и других к деятельности для достижения некоторых целей [Овсянко 1999]. Исторически первый подход к мотивации имеет название метод “кнута и пряника”. Он заключался в побуждении либо под угрозой наказания, либо с использованием поощрения, либо комбинацией этих двух методов. Существует ряд психологических принципов, лежащих в основе теории мотивации.

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

* Инстинкты —автоматическая предрасположенность людей вести себя Определенным образом. Некоторые люди находят удовольствие в том, Чтобы ходить на работу, поскольку “рождены работать”.

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

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

Потребность —осознанная недостаточность чего-либо. Именно потребности заставляют людей действовать определенным образом. Выделяя основные группы потребностей.

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

* Вторичные, являющиеся психологическими (например, потребность в уважении).

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

Абрахам Маслоу (Abraham Maslow) в 40-х годах ХХ века разделил потребности на пять категорий.

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

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

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

* Потребности в уважении, включающие внутренние (самоуважение, личные достижения) и внешние (статус, признание) факторы уважения.

* Потребность в самовыражении, заключающаяся в самореализации и росте как личности.

Перечисленные потребности образуют возрастающую иерархию. В момент времени поведение человека определяется самой сильной из неудовлетворенных потребностей. Однако потребности высших уровней не мотивируют человека, пока не удовлетворены хотя бы частично потребности низших уровней. Менеджеры, работающие на международном уровне должны иметь в виду, что относительная значимость различных потребностей людей может меняться в разных странах [Овсянко 1999].

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

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

Лао Цзы

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

Особенности европейского менеджмента

Европейский менеджмент имеет очень хорошую теоретическую базу, основанную на работах Макса Вебера (Германия), Анри Файоля (Франция), Кароля Адамецки (Польша) и многих других. Приведем несколько принципов  управления Файоля [Психология 2000]

* Дисциплина, т. е. послушание и уважение к достигнутым соглашениям между фирмой и ее работниками. Дисциплина предполагает также справедливо применяемые санкции.

* Вознаграждение персонала, в том числе справедливая зарплата.

* Справедливость: сочетание доброты и правосудия.

* Корпоративный дух, т. е. гармония персонала, его сплочение.

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

Особенности американского менеджмента

Менеджеры как социальная группа составляют в Америке около 15% работающего населения. Условием квалифицированного руководства считается соблюдение трех правил.

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

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

*  Контролируй исполнение.

Американский менеджмент поощряет конкуренцию среди инженеров [Психология 2000]. Конкуренция представляется им необходимым условием социального и личностного развития. Это приводит к ряду негативных явлений, например, сокрытию информации друг от друга и поиску более лёгкого, а не оптимального пути решения задачи. Наиболее слабым местом американского менеджмента является использование человеческого фактора в управлении.

Об особенностях американского менеджмента в области разработки программного обеспечения и о влиянии передовых информационных технологий на современный бизнес достаточно подробно рассказано в книге Билла Гейтса (Вill Gats) [Гейтс 2001].

О книге Билла Гейтса

Следует понимать, что данная книга предназначена для менеджеров, которые хотят познакомиться с передовыми методами ведения бизнеса. Программисты не найдут в ней практически ничего полезного для своей профессиональной работы. Интересную семантику заложили издатели в оформление обложки книги. Там крупными буквами написано Билл Гейтс и под именем нарисован значок @. Значок соответствует в английском языке предлогу “at” (являющемуся атрибутом адресов электронной почты), но традиционно произносится русскоязычными программистами как ‘собака’. Это подчеркивает неоднозначное отношение программистов к Биллу Гейтсу.

Особенности японского менеджмента

На основе анализа деятельности японских компаний, Й. Олстон сформулировал пять основных принципов японского менеджмента [Психология 2000]

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

•кружки качества;

•практика стимулирования всех работников к совершенствованию профессиональных умений и навыков. Здесь очень интересно то, что японская традиция “минарай” —наблюдение за опытными рабочими с целью освоения их навыков —очень близка русской традиции наставничества;

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

Рабочий стремится сделать свою работу лучше. Методы реализации этого принципа:

•пожизненный найм работников;

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

* Рабочие образуют “семью”: Методы реализации принципа:

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

•свободное время работники фирмы проводят вместе;

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

•  Группа важнее отдельной личности. Этот принцип основан на традиционной японской ценности —никто не должен быть эгоистичным и думать только о себе.
•  Партнёрство и сотрудничество в производственных отношениях.

Особенности российского менеджмента

Понимание необходимости целенаправленной подготовки специалистов для управленческой деятельности на научной основе сложилось в нашей стране лишь в 60-е годы ХХ века. Российский менеджмент должен учитывать особенности национальной психологии, исторический опыт, традиции и ценности. которые веками складывались в России. Существует ряд приоритетных ценностей, на которые российский менеджмент должен опираться [Психология 2000].

* Социальные права личности.

* Честь и достоинство личности.

* Согласие и сотрудничество в обществе.

* Справедливость, основанная на понимании и принятии правовых норм.

* Профессионализм и мастерство. Коллективизм, поддержка и взаимопомощь.

* Духовность и психическое здоровье в основе деловой и поведенческой практики.

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

В основе методов управления проектами лежат методики сетевого планирования, разработанные в конце 50-х годов ХХ века [Филипс, Гарсиа-Диас]. С помощью этих методик руководитель проекта может:

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

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

* координировать и контролировать выполнение работ для соблюдения Календарного графика и завершения проекта в срок.

Следующие два метода были разработаны параллельно и независимо.

* Метод Критического Пути (МКП). Метод разработан фирмой “Дюпон де Немур”. Первоначально назывался методом Уолкера-Келли, по именам создателей. Позже получил название МКП (СРМ —Сгitical Раth  Меthod).

* Метод анализа и оценки программ ПЕРТ (РЕRT —Ргоgram Evaluation and Review Technique) Метод был разработан корпорацией “Локхид” и консалтинговой фирмой “Буз, Аллен энд Гамильтон” и применен в военно-морских силах США для ускорения разработки баллистической ракеты “Поларис” для подводных лодок.

Для описания современных проектов, в которых связи между работами значительно сложнее, данные средства оказались недостаточными. Метод сетевого планирования описывает зависимости работ средствами теории [1999].

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

Подчеркнем в виде неформальных требований необходимость наличия плана [Баранов 1998].

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

* План определяет роль каждого человека в исполнении проекта.

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

* План —это точка отсчета для любых последующих изменений.

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

Заметим, что первое действие процесса планирования —это принятие решения о начале планирования.

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

* Построение списка задач.

* Составление графиков выполнения работ.

* Оценка затрат.

* Выделение требуемых ресурсов.

* Распределение ответственности.

* Определение зависимостей между задачами.

* Проведение персональных назначений на задачи.

* Определение времени выполнения задачи.

* Оценка рисков, связанных с конкретными задачами.

* Выявление критических путей.

* Создание инфраструктуры управления.

В рамках планирования управляющий решает также организационные  задачи:

* Анализ документации на полноту, содержание, аккуратность.

* Назначение начальной и конечной дат работ.

* Определение интерфейсов приложения и планирование работ по детальному проектированию интерфейсов.

Работа не может начаться раньше, чем будут выполнены все предшествующие ей работы. Продолжительность выполнения всего проекта не может быть меньше, чем сумма продолжительностей работ, входящих в любой путь от начального до заключительного события. Длиной пути назовем сумму продолжительностей работ, входящих в путь. Критическим путем будем называть путь наибольшей длины [Романовский 1999]. Наибольший риск выполнения проекта будет иметь задержка в работах на критическом пути.

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

Существует несколько методик оценок времени и затрат для составления планов и расчетов [Баранов1998].

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

* Снизу вверх по составленному графику работ. данные по трудозатратам и времени берем от исполнителей.

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

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

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

•формуле трапеций: (О+2*р+n)/4;

•формуле Симпсона: (О+4*Р+n)/6.

О формуле для оптимистов

Оптимистам после ряда провала сроков можно предложить “осторожную” формулу: О*Рi*е, где Рi и е —известные математические константы.

Распределение работ

Распределение  работ включает определение уровня квалификации для исполнителей задач, составление списка потенциальных участников проекта и “отображение” исполнителей на задачи. Типичной проблемой может быть сопоставление требуемым рабочим местам тех потенциальных исполнителей, чей уровень квалификации не полностью соответствует требуемому. Существует несколько эвристических правил для персональных назначений [Conger 19941.

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

* Определить последовательность работ для каждого исполнителя.

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

О важности выбора

Одного и того же можно достичь разными способами. Предложение единственного пути может говорить о профессиональной непригодности руководителя в условиях свободного рынка [Баранов 1998]. Он должен изложить не менее трех способов решения задачи и продемонстрировать понимание этих способов. Только тогда можно обсуждать достоинства и недостатки одного из этих подходов. Только тогда можно выбрать тот, который в данной ситуации наиболее годится, т.е. наиболее подходящий.

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

Став бригадиром, я упростил этот процесс до мыслимого предела

В. Ерофеев. «Москва —Петушки»

Продолжающиеся непрерывные неудачи в крупных программных проектах заставили министерство обороны США сформировать подразделение, которое получило название Сеть менеджеров по разработке программного обеспечения (Software Program Managers Network —SРМN) (http://www.spmn.com).Для этой организации были сформулированы четыре главных цели ее работы

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

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

* Дать возможность руководителям проектов применять лучшие мировые практические навыки с учетом локальной корпоративной культуры.

* Дать возможность быстро изучить и внедрить эти навыки в свою работу с помощью соответствующих методик обучения и программных систем.

Одним из основных результатов работы данной организации стал документ, рекомендующий 16 основных практик (навыков), включающих 9 основных и 7 поддерживающих.

Перечислим основные практики.

* Формальное управление рисками. Рекомендуется постоянно вести и анализировать списки основных важнейших рисков. У сотрудников не должно быть никаких иллюзий о допустимости рисков.

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

* Формальные проверки проекта. Экспертизы, проверки, сквозной контроль —все те действия, которые позволяют устранить ошибки как можно раньше.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На сегодняшний день в профессиональном программировании применяются две основные методологии —структурная и объектно-ориентированная. На этапе анализа и проектирования нам важно принципиальное различие между этими методологиями, заключающееся в разных способах декомпозиции систем [Вендров 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 (один-к-одному);

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Превосходно, Ватсон, Вы делаете успехи. Правда, Вы упустили все существенные детали, зато хорошо усвоили метод

Артур Конан Дойль. “Приключения Шерлока Холмса”

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

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

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

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

* Таблицы решений.

* Сети Петри.

* Диаграммы зависимости.

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

* Диаграммы функционального моделирования.

Диаграмма потоков данных (Data Flow Diagram —DFD) —информационная модель, основные компоненты которой —различные потоки данных, переносящие информацию от одного модуля к другому.

Компонентами диаграммы потоков данных являются:

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

* процессы —совокупность операций по преобразованию входных данных в выходные в соответствии с определенным алгоритмом;

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

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

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

Диаграмма функционального моделирования (Structured Analisis and Design Technique  —SADT) —модель, состоящая из диаграмм, фрагментов текста и глоссария , имеющих ссылки друг на друга.

В состав диаграммы входят:

* блоки, изображающие активность моделируемой системы;

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

•управляющая информация входит в блок сверху;

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

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

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

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

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

* КОК-карты (класс-ответственность-кооперация).

* Диаграммы вариантов использования.

* диаграммы классов.

* диаграммы состояний.

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

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

Карты класс-ответственность-кооперация (class-responsibility-collsboration) предназначены для описания классов. Первоначально они были созданы для обучения объектному языку (http://c2.com/doc/oopsla89/paper.html).

* Ответственность —это высокоуровневое описание функций, которые выполняет класс. Здесь применяется идея отказаться от описания конкретных элементов данных и процессов и вместо этого несколькими предложениями описать ответственность класса.

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

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

Диаграмма классов (class diagram) служит для представления структуры модели системы в терминологии классов объектно-ориентированного программирования. Диаграмма классов не содержит информации о временных аспектах функционирования системы.

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

* Ассоциации, представляющие некоторое отношение или связь.

* Обобщения, представляющие иерархическое строение и наследование классов.

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

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

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

Диаграмма объектов (object diagram) может понадобиться, если потребуется рассмотреть взаимосвязи между отдельными объектами.

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

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

* вариант использования (use case) —типичное взаимодействие пользователя и системы. Оно охватывает некоторую очевидную для пользователя функцию, решая некоторую дискретную задачу;

* актер (асtor) —любая внешняя по отношению к моделируемой системе сущность, которая взаимодействует с системой и использует ее функции и возможности;

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

диаграмма состояний (statechart diagram) отражает модель поведения объектов в реальном или абстрактном мире. Все объекты имеют некоторый срок жизни:

* сначала они появляются или создаются;

* затем эволюционируют, проходя через определенные стадии существования;

* и, наконец, исчезают или умирают.

Для представления этого жизненного цикла предлагается модель состояний, состоящая из:

* множества состояний; состояние —положение объекта, в котором применяется определенный набор правил, линий поведения, предписаний и физических законов;

* множества событий; событие —абстракция инцидента или сигнала в реальном мире, который сообщает о перемещении чего-либо в новое состояние;

* множества правил переходов; правила определяют, какое новое состояние достигается, когда с объектом в данном состоянии происходит некоторое событие;

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

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

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

* Генераторы событий, создающие событие, как результат работы.

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

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

Обратим внимание на то, что диаграммы деятельности можно считать частным случаем диаграмм состояний.

Диаграмма последовательности (sequence diagram) предназначена для моделирования еще одной разновидности взаимодействия —взаимодействия времени. С ее помощью отслеживается поведение взаимодействующих групп объектов. Диаграмма имеет два измерения.

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

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

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

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

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

* для обозначения простого (не вложенного) потока управления.

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

* Для возврата из вызова процедуры.

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

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

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

* Процедурно-ориентированные подходы, в которых первично проектирование функциональных компонентов.

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

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

О классах целевых систем

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

Как правило, подходы используют две основные группы средств моделирования [Вендров 2000]

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

* Диаграммы, моделирующие данные и их отношения. Например, диаграммы “сущность-связь”.

О применении методов к российской специфике

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

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

* Подход Йордона и ДеМарко.

* Подход Гейна-Сарсона.

* Подход Константайна.

* Подход Джексона.

* Подход Варнье-Орра.

* Подход Мартина.

* Подход промышленной технологии DATARUN

* Подход промышленного метода Огасlе.

Подход Йордона и ДеМарко (Edward Уоrdоп and Тоm DеМагсо) является процедурно-ориентированным и наиболее часто используемым (по статистике в 36,5% случаев) [Калянов 1996]. Подход фокусирует внимание на потоках данных.

В нем интегрированы следующие средства:

* диаграммы потоков данных;

* словари данных, являющиеся каталогами всех элементов данных, присутствующих в диаграммах потоков данных;

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

Подход Гейна-Сарсона (Сhris Gane and Tom Sarson)  очень близок к предыдущему. Статистика утверждает, что он применяется в 20,2% случаев [Калянов 1996]. Главной отличительной чертой подхода является наличие этапа моделирования данных, определяющего содержимое хранилищ данных в диаграммах потоков данных в третьей нормальной форме. Этот этап включает:

* построение списка элементов данных, располагающихся в каждом хранилище данных;

* анализ отношений между данными и построение соответствующей диаграммы связей между элементами данных;

* представление всей информации по модели в виде связанных нормализованных таблиц.

Подход Джексона (Мichael Jackson) ориентирован на данные. Базовая процедура проектирования включает четыре этапа [Калянов 1996] [Кинг 1991].

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

* Этап проектирования программ. Формирование структуры программы комбинированием структур данных. Идентификация всех связей между компонентами структур данных.

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

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

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

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

•  Подход на основе языка UML.
•  Подход Шлеер-Меллора.

* Подход Гради Буча

* Подход Джеймса Рамбо (Оbject Modelling Technique —ОМТ)

* Подход Ивара Якобсона (Object – Oriented Software Enginiring —ООSE)

Подход на основе универсального языка моделирования UML (Unified Modeling Language) включает следующие основные типы диаграмм:

* диаграммы вариантов использования,

* диаграммы классов;

* диаграммы состояний;

* три диаграммы поведения (две последние из них также называют диаграммами взаимодействия):

•диаграммы деятельности;

•диаграммы последовательности;

•диаграммы кооперации;

две диаграммы реализации:

•диаграммы компонентов;

•диаграммы развертывания.

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

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

* диаграммы вариантов использования;

* диаграммы классов;

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

На третьей фазе —построения —продолжается итеративная работа с такими типами диаграмм, как:

* диаграммы классов;

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

К ним добавляются следующие Типы диаграмм, которые определяют взаимодействие:

* диаграммы последовательности;

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

В случае сложного поведения системы разрабатывается еще одна группа диаграмм:

*  диаграммы состояний.

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

•не следует стремиться к построению диаграмм всей системы;

* 80% проектов можно воплотить, используя 20% средств языка UML как правило, наиболее часто используют диаграммы классов и диаграмм деятельности.

Подход Шлеер-Меллора (Sally Shlaer and Stephen МеIIог) использует три группы средств для создания модели предметной области.

* Информационное моделирование —для определения отношений между данными (информацией). При этом используется один тип диаграмм:

Диаграммы классов.

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

* Моделирование процессов —для определения функций, которые система должна выполнить. Используются:

•диаграммы деятельности;

•диаграммы последовательности.

Для анализа больших предметных областей используются диаграммы, смыслу близкие к следующим диаграммам языка UML

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

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

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

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

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

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

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

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

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

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

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

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

Важнейшая технологическая задача, возникающая в процессе программирования, —соответствие единому стилю программирования. Под стилем программирования обычно понимают [Тассел 1985] набор приемов или методов программирования, которые используют опытные программисты, чтобы получить правильные, эффективные, удобные для применения и легко читаемые программы. Правила хорошего стиля —результат соглашения между опытными программистами. Обычно принципы хорошего стиля программирования являются результатом здравого смысла, исходящего из опыта. Это не набор обязательных правил, установленный раз и навсегда. Брайан Керниган (Вгiап Кernighan) и Роб Пайк (Rob Pike) [Керниган, Пайк 2001] уточняют, что код должен быть прост и понятен, т. е. обладать следующими свойствами:

* очевидная логика;

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

* использование соглашений, принятых в языке разработки;

* осмысленные имена;

* аккуратное форматирование;

* развернутые комментарии;

* отсутствие хитрых трюков и необычных конструкций.

Правило стандартизации стиля заключается в том, что если существует более одного способа сделать что-либо и выбор произвольный, то следует остановиться на одном способе и всегда его придерживаться. Особое значение имеет единый стиль программирования в процессе работы над программным текстом в коллективных разработках. В большинстве крупных проектов существуют внутренние документы, определяющие стиль программирования команды разработчиков. Известным примером является документ по стилю программирования разработок GNU (http://www.gnu.org/prep/standards_toc.html). Применение таких документов приводит к использованию единого стиля, а следовательно, к повышению читабельности и сопровождаемости программ, а во многих случаях и предотвращению большого класса ошибок. Обратим внимание на то, что есть универсальные рекомендации, а есть рекомендации, связанные с конкретными языками.

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

Структура файлов

Приведем рекомендации по именованию файлов.

* Заголовочные файлы должны иметь расширение h Файлы с программой на языке С должны иметь расширение с, а с программой на языке С++ —сс (в операционной системе Unix) или срр (в операционной системе Windows).

* Имена файлов ДОЛЖНЫ отличаться уже первыми восемью символа Обоснование: Некоторые устаревшие, но, тем не менее, широко используемые операционные системы накладывают ограничения на длину имени файлов.

* Все файлы должны иметь различные имена, даже если они находятся в разных каталогах.

Опишем рекомендации по длине строк.

* Строки не должны быть длиннее 80 символов. Обоснование: Многие текстовые редакторы и системы печати текстов программ ориентирована именно на это максимальное количество символов в строке. Исторически это объясняется текстовым режимом отображения символов на экране 25 строк по 80 символов.

* Лучше всего, если длина строк программы значительно короче 80 символов.

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

* Следует соблюдать следующий порядок в заголовочных файлах программы на языке С++:

* комментарий к файлу, который оформляется как блочный комментарий. Комментарий может начинаться указанием на лицензию, которая определяет права собственности на данный файл. Комментарий обычно продолжается идентификационной строкой системы управления версиями файлов. Например, для утилиты SССS  строка может выглядеть так: %Z %M% %I% %E% и включать символ идентификации SССS, имя файла, номер версии и дату последней идентификации. Комментарий должен содержать краткое описание файла

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

#if !defined(FILENAME_H)

#define FILENAME_H

•импортируемые интерфейсы. Как правило, они определяются с помощью #iпсlude –директив;

•объявления;

•завершающая защитную проверку директива условной компиляции

#endif

** Для файлов кода на языке С++ рекомендуется такая последовательность

•комментарий к файлу;

* импортируемые интерфейсы,

•локальные объявления;

•экспортируемые определения.

Лексические соглашения

Приведем рекомендации по написанию идентификаторов.

* Не начинайте и не заканчивайте идентификаторы символом подчеркивания.

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

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

* Разделяйте части идентификаторов символом подчеркивания, а не написанием с большой буквы очередной части идентификатора.

* Идентификаторы должны начинаться со строчной буквы.

Опишем соглашения об именовании.

*Смысл всех имен должен быть понятен при чтении программы.

* Имена, используемые в ограниченном контексте, могут быть очень короткими. Традиционно имена i и j используются для обозначения счетчиков, р и q для указателей, s s для строковых, а сh для литерных переменных. В данном случае ясность достигается краткостью.

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

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

* Имена перечислимых типов могут иметь единый префикс.

Приведем рекомендации по употреблению комментариев.

* Блочные комментарии следует применять для описания дополнительной информации о файле, классе, функции или переменной.

* Строковые комментарии следует использовать для коротких заметок в одну-две строки.

Языковые детали

Рекомендации по выравниванию.

* Стандартная величина отступа равна четырем пробелам.

* Табуляционный отступ равен восьми пробелам.

Об отступах

Величина отступа сильно зависит от языка программирования/ Существуют языки программирования в которых вложенность блоков определяется отступом (например, Occam или Руthon). Со стандартным отступом такие программы становятся просто неправильными

Рекомендации по написанию выражений.

* Бинарные операторы должны быть Отделены от операндов одним белом.

* Унарные операторы не следует отделять от операнда пробелом, ТОЛЬКО ЭТОГО не требуют правила языка.

* Используйте скобки, чтобы улучшить читаемость. Не следует добавлять пробелы к введенным скобкам.

* Старайтесь размещать выражение на одной строке.

* Если выражение переносится на следующую строку, то знак бинарной операции следует оставить на первой строке.

Рекомендации по объявлению переменных.

* В каждом объявлении должна объявляться только одна переменная.

* Объявление переменной ДОЛЖНО занимать одну строку.

* За типом переменной должны следовать пробел, имя переменной и комментарий с кратким описанием переменной.

* Если переменная является указателем, то символ * следует присоединять к типу.

Рекомендации по написанию Определения функций.

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

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

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

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

* Определение функции всегда начинается в самом левом столбце файла,

* Различные части функции следует отделять пустой строкой.

Рекомендации по написанию условного оператора.

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

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

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

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

* Если часть then или е1se состоит из простого оператора, то открывающая и закрывающая фигурные скобки могут быть опущены.

Пример форматирования условного оператора приведен в листинге 3.1.

Листинг 3.1. Пример форматирования условного оператора

if (********) {

=========;

}

else if (+++++++) {

---------------;

}

else {

_________ ;

}

Рекомендации по написанию оператора выбора: основные соглашения в этом случае выглядят так же, как и для условного оператора. Пример выравнивания оператора выбора приведен в листинге 3.2.

Листинг 3 2 Пример форматирования оператора выбора

switch ( i) {

case 1;

**********;

break;

сазе 2: {

+++++++++;

break;

}

__________;

break;

}

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

Типичные примеры форматирования оператора цикла

Листинг З З Пример форматирования оператора цикла

for ( i  = ************;

i> =  --------------;

i  =  0000000000) {

;

;

}

do {

;

;

} while (????????????) ;

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

Защитное программирование (defensive ргоgramming —это такой стиль написания программ, при котором появляющиеся ошибки легко обнаруживаются и идентифицируются программистом [Тасел 1985].

Существуют три основных принципа защитного программирования.

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

Теперь дадим несколько рекомендаций по защитному программированию [Тассел 1985].

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

О необходимости защитного программирования

•  К сожалению, излишняя самоуверенность или доверчивость по отношению к своим коллегам ведет к тому, что программисты не всегда пользуются защитным программированием. Следует заметить, что периодически все-таки случается то, что “не может быть никогда”. Например, сбой в другом модуле программы может привести к такой ситуации в данном модуле, которая теоретически не должна была случиться.

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

На выбор языка программирования влияют четыре основных фактора.

•  Сравнительная пригодность языка программирования для данной задачи.
•  Избранная методология. Часто говорят, что язык поддерживает ту или иную методологию. Обычно это означает, что применение этого языка совместно с указанной методологией в совокупности дадут значительно больший эффект.
•  Степень важности для разработчика многочисленных характеристик и свойств, которые могут быть присущи или не присущи избираемому языку программирования.
•  Степень знакомства программистов с языком программирования. Результаты исследований говорят о том, что производительность программиста, работавшего на некотором языке более трех лет, возрастает на треть по сравнению с программистом такого же уровня, но без опыта работы на данном языке [Boehm 1981]. Исследование специалистов компании IВМ показало даже более существенные результаты. Программисты с длительным опытом программирования на некотором языке имеют производительность в три раза большую, чем программисты с минимальным опытом программирования [Walston Fеliх 1977].

.5. Ввод программы в действие

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

•  Индивидуальная доставка (как правило, разработка для конкретного заказчика).
•  Коробочная доставка.
•  Доставка через Интернет.

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

•  Работа с программой осуществляется через Интернет, как правило, среды интернет-броузера. Пользователи имеют возможность получить из сети исполняемый код (или его клиентскую часть) и начать работу с самой новой версией данного продукта. С подавляющим большинством таких приложений пользователи работают бесплатно. Однако ряд компаний развивают идею продажи сервисов работы с некоторым программным продуктом за определенную повременную оплату.
•  Возможность скачать из сети программу и установить ее на своих компьютерах, подобно установке программы, поставляемой в коробке. Интернет неожиданно просто решает проблему распространения программно обеспечения и доставки его до пользователя. На смену десятилетия “коробочных продуктов” (1985—) пришли “продукты из Интернет”. Причем в Интернете есть две группы программных продуктов:
•  свободно распространяемые программные продукты;
•  коммерческие программные продукты. На последние сначала можно получить временный регистрационный ключ (как правило, срок г действия около месяца), самостоятельно выяснить достоинства и недостатки продукта и принять решения о необходимости пользоваться им в дальнейшей работе. Если программный продукт подходит пользователя, то он может получить постоянный регистрационный ключ после оплаты стоимости программного продукта.

    Следует отметить, что в целом ряде случаев (например, работа с программ через Интернет) такое действие, как инсталляция (установка) программ уходит в прошлое. Тем не менее, приведем правила хорошего тона подготовке инсталляции

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

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

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

Гете

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

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

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

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

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

Существуют две основные стратегии тестирования:

-тестирование программы как черного ящика, при котором программа рассматривается как объект, внутренняя структура которого неизвестна.

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

Существуют также разновидности тестирования:

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

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

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

Типичные ошибки

Мы уже говорили о необходимости защитного программирования, которое позволяет предупредить многие ТИПИЧНЫЕ ошибки. Обратим внимание на две категории наиболее распространенных ошибок программистов.

•  Ошибки общего (несинтаксического) характера, остающиеся в программах после выполнения синтаксического контроля.

•Группа логических ошибок. Например, неполный учет возможных условий или неверное указание ветви алгоритма после проверки условия.

•Ошибки в циклах. Например, неверные границы начала и конца.

•Ошибки при работе с данными.

•Ошибки ввода-вывода.

•Ошибки в описании переменной. Например, отсутствие инициализации переменной.

•Ошибки при работе с массивами.

•Отсутствие начального обнуления элементов.

Ошибки специального вида, особенно трудные для диагностирования.

•Ошибки при написании параллельных программ. Например, ошибки в расстановках семафоров.

•Ошибки, связанные с применением препроцессора.

•Ошибки, связанные с неправильным результатом операций.

•Исчезающие ошибки.

Тестовые данные

Для тестирования программ методом черного ящика [Канер Фолк, Нгуен 20001 готовятся определенные группы тестов.

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

•Класс корректных тестовых случаев, отражающих типичную “нормальную” ситуацию.

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

* Для тестирования граничных значений.

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

* Для тестирования тех утверждений, которые приводятся в документации.

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

* Использование справочников;

* Вычисление вручную;

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

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

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

Тестирование программ в процессе разработки

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

* Тестирование сверху вниз. Применяется, если программа разрабатывается сверху вниз. В данном случае используются “заглушки” —фрагменты кода, имитирующие еще не написанные части программы.

* Тестирование снизу вверх. При этом, как правило, дополнительно должна быть создана небольшая программа —“драйвер”, организующая взаимодействие уже написанных модулей.

Отслеживание ошибок

Проблема или ошибка может быть рассмотрена как некоторый объект в системе, который может находиться в одном из восьми состояний.

* Проблема или ошибка зарегистрирована.

* Выполнен первичный анализ (эксперт подтвердил факт наличия ошибки).

* Понятна причина, вызвавшая ошибку.

* Выполнен окончательный анализ проблемы или ошибки.

* Принято решение о начале работы над исправлением.

* Выполнено исправление ошибки.

* Исправление интегрировано в основное пространство. Подтверждено исправление ошибки.

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

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

1. Следует начать с изучения уже доступных исходных и результирующих данных.

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

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

Обратим особое внимание на два достаточно простых случая отладки. Их анализ может быть достаточно легко выполнен при помощи пошагового отладчика.

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

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

О первом выловленном баге

На компьютерном жаргоне ошибка в программе называется багом (от англ.bug —жучок). Происхождение этого термина связывают с мошкой, извлеченной в 1947 году из реле компьютера “Марк 11”. Грейс Мюррей Хоппер приклеила ее в журнал с примечанием “первый случай выловленного бага”.

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

Под сопровождением будем понимать все действия по повышению надежности программного продукта после завершения отладки и разработку усовершенствованных версий. Пожалуй, основным принципом сопровождения является закон Биледи (Laszlo Веladу): используемый программный продукт подвергается непрерывным изменениям для поддержания его экономической выгоды [Гласс, Нуазо 19831].

Перечислим четыре основные класса задач, решаемых на этапе сопровождения.

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

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

Для решения указанных задач выбирается один из следующих, наиболее подходящих типов сопровождения [Conger 1994], под которым будем понимать степень вмешательства в программу:

•  незначительные (локальные) изменения;
•  реструктурирование кода —повторная разработка небольшой части про граммы. При этом интерфейс этой части с остальной программой остается неизменным;
•  реинжиниринг —перестройка существующего программного продукта. Обычно реинжиниринг применяется для приведения кода программы в соответствие с современными методологиями программирования (например, объектно-ориентированной);
•  программирование заново.

На выбор типа сопровождения влияют два фактора.

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

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

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

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

Самодокументируемость изменений.

•  Пассивное и активное сопротивление изменениям. За некоторое время внесения изменения программист должен разослать письмо с описание изменения и фрагментами изменяемого кода остальным участникам разработки. Программист сможет внести изменения только в следующих случаях:
•  если никто из коллег не выступит против (в случае пассивного сопротивления);
•  если все одобрят изменение (в случае активного сопротивления).

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

Функционирование на нескольких аппаратных платформах.

Наличие большого количества пользователей.

Необходимость тщательного тестирования.

Наличие устаревших алгоритмов.

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

Источниками (“возбудителями’) основных классов задач сопровождения могут быть:

•  пользователи компилятора, находящие ошибки;
•  разработчики взаимозависимых компонентов (например, отладчика);
•  инженеры, сопровождающие компилятор (например, предлагая повысить эффективность компилятора).

Теперь рассмотрим —как четыре основных класса задач по сопровожден решаются применительно к компиляторам.

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

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

•  Повышение эффективности. Например, оптимизация алгоритмов семантического анализа.
•  Повышение надежности. Информацию к размышлению здесь можно получить после обработки программы на языке С утилитой расширенного синтаксического анализа 1iп или утилитой поиска ошибок времени исполнения beheck.
•  Необходимость соответствия стандарту языка. В случае изменения стандарта или появления комментариев к стандарту, компилятор дол жен все эти изменения учитывать.
•  Необходимость соответствия популярному диалекту языка. Как это ни печально, но иногда даже полностью соответствующий стандарту компилятор должен допускать (в специально задаваемом пользователем режиме) обработку конструкций, допускаемых другим популярным компилятором. Обычно это диктуется соображениями экономической выгоды.

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

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

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

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

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

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

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

О. Хайям

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

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

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

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

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

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

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

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

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

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

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

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

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

3.1.2. Поставка

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

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

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

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

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

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

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

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

3.1.3 Разработка

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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. Организационные процессы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.3.4. Обучение

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

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

Взаимосвязь между процессами

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

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

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

Операторы и пользователи имеют эксплуатационную точку зрения.

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

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

* Менеджеры имеют управленческую точку зрения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

•Этап-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”, Они обнаружили, что пациенты распространяют информацию о зубных врачах следующим образом. Если зуб вылечен хорошо, то человек рассказывает об этом в среднем трем своим знакомым. Если плохо —тогда одиннадцати. Именно такова психология людей и заказчиков в том числе. Именно это надо учитывать и добиваться полного удовлетворения заказчиков и пользователей, создавая о себе хорошую славу.

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

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

Уточним лишь, что традиционно понимается под различными типами версий и критериями, к ним предъявляемыми.

* Версия разработчика является ранней версией для внутреннего использования и тестирования (с учетом инсталлирования и лицензирования).

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

* На этапе бета-версии продукт должен удовлетворять специальным “бета критериям” (например, должны быть исправлены все ошибки высокого и среднего приоритетов) и быть готовым к внешнему тестированию. Бета версия содержит инсталляционную программу. Может быть полезно предоставление бета-тестерам информации об обнаруженных ошибках в некоторых случаях это может помочь найти причину ошибки.

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

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

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

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

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

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

О. Хайам

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

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

Подход кодирование и исправление

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

Все ошибки обнаруживаются, как правило, к концу кодирования и требуют исправления через повторное кодирование.

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

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

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

* Для доказательства некоторой программной концепции.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Спиральная модель (sрiгаl model) была предложена Барри Боэмом (Ваггу Воеm) в середине 80-х годов ХХ века с целью сократить возможный риск разработки. Фактически, это была первая реакция на устаревание каскадной модели. Спиральная модель использует понятие прототипа —программы, реализующей частичную функциональность создаваемого программного продукта. Создание прототипов осуществляется за несколько витков спирали, каждый из которых состоит из “анализа риска”, “некоторого процесса” и верификации (рис. 10). Обращение к каждому процессу предваряет “анализ риска”, причем, если риск превышения сроков и стоимости проекта оказывается существенной, то разработка заканчивается. Это позволяет предотвратить более крупные денежные потери в будущем.

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

Рис. 10. Спиральная модель.

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

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

Рациональный унифицированный процесс

Рациональный процесс (rational unified prосеss) [Фулер, Скотт 1999] [Рамбо, Джекобсон 2000] вобрал в себя лучшее из технологических подходов каскадной группы. В нем выделяются четыре основные фазы, рассмотренные ранее.

А вот в период прохождения этих фаз и функционируют процессы (на пример, анализ и проектирование), которые к тому же состоят из ряда последовательных итераций (рис. 11).

Основные особенности данного подхода таковы:

* итеративность с присущей ей гибкостью;

* контроль качества; возможность выявить и устранить риски как можно

раньше;

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

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

* возможность конфигурирования настройки и масштабирования.

Рис. 11. Рациональный унифицированный процесс.

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

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

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

Синтезирующее программирование предполагает синтез программы по ее спецификации. В отличие от программы, которая написана на алгоритмическом языке и предназначена для исполнения на вычислительной машине после трансляции в исполняемый код, документ на языке специфика является лишь базисом для последующей реализации. Для получения реализации необходимо решить перечисленные ниже основные задачи (http://case.ispras.ru/PublicScripts/cgi-bin/lib.cgi/code_generation/autoreferat.html)/

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

* Выбрать язык реализации и аппаратно-программную платформу для реализации.

* Зафиксировать отображение понятий языка спецификаций на язык реализации и аппаратно-программную платформу.

* Осуществить трансформацию представления (из спецификации в исполняемую программу на языке реализации).

* Отладить и протестировать исполняемую программу.

Автоматическая генерация программ по спецификациям возможна для многих языков спецификаций, среди которых особо выделим SDL, ASN.1, LOTOS, Estelle, UML..

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

Сборочное программирование предполагает, что программа собирается путем переиспользования уже известных фрагментов (рис. 12).

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

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

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

* Повышение эффективности межмодульных интерфейсов; важность аппаратной поддержки модульности.

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

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

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

* Объектно-ориентированное сборочное программирование. Подход базируется на методологии объектно-ориентированного программирования и предполагает распространение библиотек классов в виде исходного кода и упаковку классов в динамически компонуемую библиотеку.

* Компонентное сборочное программирование. Основные идеи подхода —распространение классов в бинарном виде и предоставление доступа к методам класса через строго определенные интерфейсы, что позволяет снять проблему несовместимости компиляторов и обеспечивает смену версий классов без перекомпиляции использующих их приложений. Существуют конкретные технологические подходы, поддерживающие компонент сборочное программирование —СОМ (DСОМ, СОМ+), СОRВА, .Net.

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

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

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

Наиболее известная технология конкретизирующего программирования это подход с применением паттернов проектирования [Гамма, Хелм, Джонсон, Влиссидес 2001]. Паттерн (шаблон) проектирования (design pattern) описание взаимодействия объектов и классов, адаптированных для решения общей задачи проектирования в конкретном контексте. Проектировщик знакомый с паттернами, может сразу применять их к решению новой задачи, конкретизируя их. Паттерны проектирования упрощают повторное использование удачных проектных и архитектурных решений.

Паттерн состоит из четырех основных элементов:

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

* задачи —описания того, когда следует применять паттерн для конкретизации;

* решения —абстрактного описания элементов дизайна и отношений между ними;

* результатов —следствий применения паттерна.

Дополнительно к паттернам существуют каркасы (framework) —наборы взаимодействующих классов, составляющих повторно используемый дизайн для конкретного класса программ. Каркас диктует определенную архитектуру приложения, в нем аккумулированы проектные решения, общие для проектной области. Например, существуют каркасы, которые используются для разработки компиляторов.

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

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

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

Основные идеи технологии стерильного цеха (cleanroom process model) были предложены Харланом Миллзом в середине 80-х годов ХХ века. Технология складывается из следующих частей (рис. 13) [1994]:

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

* инкрементальное планирование разработки;

* формальная верификация;

* статистическое тестирование.

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

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

- черного ящика с фиксированными аргументами (стимулами) и результатами (ответами);

- ящика с состоянием, в котором выделяется внутреннее состояние;

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

Замечание о методе ящиков

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

Использование ящиков определяют следующие три принципа:

- все определенные при проектировании данные скрыты (инкапсулированы) в ящиках;

- все процессы определены как использующие ящики последовательно или параллельно;

- каждый ящик занимает определенное место в системной иерархии. Черный ящик представляет собой точную спецификацию внешнего, видимого с пользовательской точки зрения поведения. Ящик получает стимулы S от пользователя и выдает ответ R. Каждый ответ черного ящика определяется его текущей историей стимулов SH, как следующая функция:

(S, SH)  => ( R )

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

- Clear 3 1 4

- Cleaг 3 1 4 +

Если следующим стимулом будет число 1, то на основании первой истории калькулятор выдаст ответ 3141, а на основании второй —. Определять поведение черных ящиков очень удобно с помощью табличных спецификаций.

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

(S, OS) => (R, NS)

Здесь OS —старое состояние, а NS —новое. Хотя с пользовательской точки зрения поведение черного ящика и ящика с состоянием выглядит одинаково. истории стимулов заменяются ссылками на старое состояние и новое состояние, требуемое преобразованием.

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

(S, OS) => (R, NS) by procedure

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

Рис. 14. Пример проектирования процедуры прозрачного ящика

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

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

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

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

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

- логическое, в котором программа извлекается как конструктивное доказательство из спецификации, понимаемой как теорема;

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

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

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

Одной из наиболее интересных современных работ в области формальных генетических подходов является В-технология [Abrial 1996]. На ее основе была осуществлена разработка системы управления парижским метрополитеном “МЕТЕОR”.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Наиболее концентрированно идеи быстрой разработки программ оказались выражены в подходе экстремального программирования (ехtreme programming) (http//www.extremprogramming.org). Две основные черты, присущие быстрым  разработкам, являются базовыми и в этом подходе. Методы, объединённые в данном подходе, не являются принципиально новыми. Однако именно их рациональное объединение и совокупное использование даёт существенные результаты и успешно выполненные проекты [Бек 2000] Наибольшую пользу подход экстремального программирования может нести в разработке небольших систем, требования к которым четко не определены и вполне могут измениться.

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

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

Рис. 17. Работа над проектом на основе экстремального программирования

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

Программисты сами пишут тесты для тестирования программы. Эти тесты пишутся до начала кодирования.

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

Цель каждой итерации (рис. 18) —включить в версию несколько новых историй. На собрании по планированию итерации определяется, какие именно истории будут реализованы и каким образом это будет сделано командой разработчиков.

Рис. 18. Итерация

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

Рис.19. Разработка

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

Рис. 20. Коллективное владение кодом

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

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

В основу подхода адаптивной разработки (Adapnive Software Development –ASD)  положены три нелинейные перекрывающие друг друга фазы —обдумывание, сотрудничество и обучение. Автор данного подхода Джим Хайсмит (Jim Highsmith) обращает особое внимание на использование идей из области сложных адаптивных систем.

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

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

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

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

Исследовательское программирование имеет следующие особенности:

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

- нет возможности предвидеть объем ресурсов для достижения того или иного результата;

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

- работа связана с конкретными исполнителями и отражает их личностные качества.

В основе исследовательского программирования в большей степени, чем в других подходах, лежит искусство.

Компьютерный дарвинизм.

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

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

Подход состоит из трех основных процессов:

- Макетирования (прототипирования).

- Тестирования.

- Отладки.

Одной из интересных особенностей подхода является максимально возможное распараллеливание процессов тестирования и отладки.

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

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

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

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

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

Ж. Ренар

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

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

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

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

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

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

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

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

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

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

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

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

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

С. П. Капица

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Маркетинг.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Роб Томсет (Rob  Thomsett) [Thomsett 1990] предложил восемь ключевых ролей в проекте (рис. 23).

Председатель. Выбирает путь, по которому команда движется вперед к общим целям. Умеет обнаружить сильные и слабые стороны команд обеспечить наибольшее применение потенциала каждого ее участника

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

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

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

Исполнитель. Работник, собственно занимающийся написанием кода. Как правило, он не обладает широтой кругозора.

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

Дипломат. Поддерживает силу духа в участниках проекта. Оказывает им помощь в трудных положениях. Пытается улучшить взаимоотношения в команде.

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

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

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

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

Коллективная разработка предполагает большое количество различных действий, причем степень совместной деятельности может существенно изменяться от одного действия к другому. Можно выделить четыре типа совместной деятельности [Robilard 2000].

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

- Созываемая деятельность, которая имеет место в случае решения двух или более программистов собраться вместе для решения некоторого технического вопроса. Такие собрания обычно не планируются заранее и в них участвуют только действительно заинтересованные в решении проблем программисты. На эту деятельность уходит около 14% рабочего времени

- Естественная совместная деятельность имеет место, когда как минимум двое программистов работают над одной и той же задачей одновременно и обмениваются информацией о выполняемой работе. Эта деятельность занимает около 41% рабочего времени.

- Индивидуальная деятельность имеет место, когда программист работает над задачей, которая не выполняется в то же самое время никаким другим программистом и поэтому маловероятно его взаимодействие по этому предмету с любыми другими программистами группы. Эта деятельность занимает также около 41% рабочего времени.

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

Совершенство в проекте достигается не тогда, когда нечего добавить, а тогда, когда нечего убавить.

Антуан де Сент-Экзюпери.

Идеология общинной (“базарной”) модели разработки сформулирована в программной статье Эрика Раймонда (Егiс Raymond) «Собор и Базар». Общинная модель характеризуется тремя основными факторами.

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

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

. Большое количество внешних тестеров (бета-тестеров), позволяющих быстро обнаруживать ошибки и проблемы в программе.

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

1. Каждая хорошая программа начинается с энтузиазма разработчика.

. Хорошие программисты знают, что можно написать, а великие —можно переписать.

. При правильном отношении интересная проблема найдет вас сама.

4. Когда вы теряете интерес к программе, ваша последняя обязанность передать ее компетентному преемнику.

5. Следует выпускать ранние и частые версии программ.

. Обнаружить проблему и исправить ее могут разные люди.

. Иногда использовать идеи пользователей лучше, чем свои идеи.

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

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

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

Эпикур

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

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

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

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

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

ISO 9126 является стандартом на качество продукта, определяющим атрибуты и характеристики качества, включая измерения количественной этих характеристик;

“Усовершенствованием практики” например, является усовершенствование управления конфигурацией программного обеспечения, тестирования т. п.;

ISO 9000 [ISO 9000 1992] —это совокупность стандартов, декларирую требования для качественных систем. С точки зрения разработки программного обеспечения наиболее полезны “руководящие указания по применению ISO 9001 при разработке поставке и обслуживании программного обеспечения” [ISO 9001 1992];

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

•модель зрелости процесса разработки программного обеспечения Capability Maturity Model for Software (СММ), предложенная Software Engineering Institute(SEI).

•определение возможностей и улучшение процесса создания программного обеспечения. ISO/IEC 15504 Software Process Improvement and Capability determination (SPICE)

Два важнейших утверждения лежат в основе достижения качества.

- Качество начинается с удовлетворения потребностей разработчиков.

- Качество доказывается удовлетворением потребностей пользователей

Подходы к достижению качества таковы:

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

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

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

- достижение качества должно планироваться;

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

В настоящее время не существует общепринятых критериев качества программного обеспечения.

Стандарт ISO 9000-3, п. 6.4.1

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

Современные стандарты уточняют понятие качества, вводя совокупность черт и характеристик, которые влияют на его способность удовлетворять заданные потребности пользователей. Перечислим ряд таких характеристик [Жоголев 1996].

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

- Надежность (завершенность, устойчивость, восстанавливаемость).

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

- Эффективность (по времени и по ресурсам). Эффективность —это отношение уровня услуг, предоставляемых программным продуктом пользователю при заданных условиях, к объему используемых ресурсов.

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

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

- Добротность (рациональная организация, продуманность, непереусложнённость)

Две наиболее интересные характеристики рассмотрим подробнее.

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

Существуют следующие подходы по обеспечению надежности:

- предупреждение ошибок;

- самообнаружение ошибок;

- самоисправление ошибок;

- обеспечение устойчивости к ошибкам.

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

1. Количественные критерии, связанные с различными способами оценки (метриками) сложности программ. Укажем примеры численных характеристик.

•Меры Холстеда [Холстед 1981], включающие ряд формул, оценивающих длину, объем, уровень и интеллектуальное содержание программ

•Оценка сложности управляющего графа программы. Фрагмент программы может быть оценен цикломатическим числом ее управляющего графа, которое равно m —n + 2, где m —число дуг, а n —число вершин управляющего графа. Считается, что цикломатическое число не должно превышать 10.

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

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

- Структурные критерии, связанные с оценкой организации управления в программе и отражением организации управления в программном теле.

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

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

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

Д. Вейнберг

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

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

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

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

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

В модели определено пять уровней зрелости организации

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

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

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

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

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

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

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

Уровень 0. Процесс не выполняется.

Уровень 1. Выполняемый процесс.

Уровень 2. Управляемый процесс.

Уровень 3. Установленный процесс.

Уровень 4. Предсказуемый процесс.

Уровень 5. Оптимизирующий процесс.

Во время оценки и улучшения качества процессов выполняются действия [Терехов, Туньон 1999], описанные ниже.

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

2. Оценка возможности улучшения данного процесса на основе определения текущих возможностей.

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

О роли министерства обороны

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

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

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

Анекдот по мотивам землетрясения и выступления Б. Гейтса 28-го февраля 2001 г.

Пропагандистом “достаточно хорошего” программного обеспечения является Эдвард Йордон [Йордон 2001]. Подчеркнем, что он применяет это понятие к “безнадежным проектам”, которые связаны жесткими ограничениями на время, бюджет и людские ресурсы. В большинстве безнадежных проектов заказчик может быть удовлетворен системой, которая достаточно дешева, достаточно производительна, обладает необходимыми возможностями, достаточно устойчива и будет готова достаточно скоро. Фактически, эти характеристики можно считать определением “достаточно хорошего” программного обеспечения.

Оказывается, что даже “достаточно хорошее” программное обеспечение создать сложно. Приведем часть из совокупности причин, дающих этому объяснение [2001].

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

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

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

Джеймс Бах (James Bach) [Bach 1995] указывает следующие необходимые условия для создания “достаточно хорошего” программного обеспечения:

- утилитарная стратегия —искусство количественного анализа и максимизации чистого выигрыша в неопределенных ситуациях;

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

- героические команды —не могучие гениальные программисты, а обычные умелые специалисты, способные к эффективному сотрудничеству;

- динамическая инфраструктура —противоположность бюрократии и засилью политики;

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

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

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

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

Стандарт —общепринятое определение компонента технических или программных средств, являющихся результатом соглашения. Профиль —юридических и/или фактических стандартов, ориентированных на выполнение конкретной задачи [Козлов1999].

Стандарты можно классифицировать следующим образом:

- по типу установления требований:

•устанавливающие требования к объекту;

•устанавливающие требования к процессу;

- по масштабу:

•международные;

•государственные;

•отраслевые

•предприятий

- по степени юридического оформления:

•принятые юридически;

•действующие фактически.

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

Международные организации, входящие в структуру ООН:

•International Organization for Standardization (ISO) —международная организация по стандартизации.

В 1947 году представители 25 стран решили создать организацию, основной задачей которой стала бы координация разработок и унификация международных стандартов. Новая организация получила название International Organization for Standardization (ISO).

•Intenational Electronical Commision (IЕС) —международная электротехническая комиссия.

•International Telecommunication Union - Telecommunication (ITU-T) —международный союз по телекоммуникации —телекоммуникация. До 1993 года эта организация называлась International Telegraph and Telephone Cosultative Committee —международный консультативный комитет по телефонии и телеграфии.

Промышленные, профессиональные или административные организации.

•Institute of Electrical and Electronic Engineers (IЕЕЕ) —институт инженеров по электротехнике и электронике.

•Internet Activity Board (IАВ) —совет управления деятельностью Интернета.

Промышленные консорциумы.

•Object Manadgement Group (OMG) - группа управления объектами.

•Х/Open —консорциум, организованный группой поставщиков компьютерной техники.

•Open Software Foundation (0SF) —фонд открытого программного обеспечения.

В 1987 году ISO и IEC объединили свою деятельность в области стандартизации  информационных технологий и создали единый орган —Joint Technical Commitee (JTC1) —объединенный технический комитет 1. Этот комитет предназначен для формирования системы базовых стандартов в области информационных технологий.

06 абсолютной стандартизации

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

56

1. Место и роль Алжира в установлении равноправного сотрудничества и безопасности в Средиземноморье
2. Б класе.Страна-Украина
3. Вони мають цікавити як неврологів так і терапевтів урологів гінекологів ендокринологів та інших спеціалі
4. Економічна теорія Основні етапи розвитку економічної теорії
5. Реферат- Экономическое регулирование охраны окружающей среды
6. Война в Камбодже
7. Это обусловлено крайней важностью вопроса
8. 69 Товщина оболонки мм 2 Товщина закінцівки під зварювання
9. Каждый актер классифицировался как хороший или плохой судя по тому как он мог использовать жесты и другие т
10. Учет нематериальных активов на примере ООО Юник
11. Основные направления финансового сотрудничества исламских банков со странами СНГ
12. Термины по истории за XX век
13. Лицей 57 Города Прокопьевска Кемеровской области Сценарий торжественной линейки посвящён
14. х гг. а ее основными инициаторами выступили психологи из США Мартин Селигман Э
15. Монолит именуемое в дальнейшем
16. Принципы гражданского судопроизводства
17. тема документації УНІФІКОВАНА СИСТЕМА ОРГАНІЗАЦІЙНОРОЗПОРЯДЧОЇ ДОКУМЕНТАЦІЇ Вимоги до оформл
18. статья След статья Великий философ Древней Греции Платон справедливо полагал что половины бы конфликтов
19. принято считать временем утверждения абсолютной монархии
20. Реферат- Токио самый большой город мира

Материалы собраны группой SamZan и находятся в свободном доступе