1

Министерство образования и науки Российской Федерации Ярославский государственный университет им. П. Г. Демидова

Кафедра динамики электронных систем

И. В. Апальков

Технологии программирования

Методические указания

Рекомендовано Научно-методическим советом университета для студентов,

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

Ярославль 2011

2

УДК 519.71 ББК 3973.2–018я73 А 76

Рекомендовано Редакционно-издательским советом университета

в качестве учебного издания. План 2010/2011 учебного года

Рецензент кафедра динамики электронных систем

Ярославского государственного университета им. П. Г. Демидова

А 76 Апальков, И. В. Технологии программирования :

методические указания / И. В. Апальков; Яросл. гос. ун-т им. П. Г. Демидова. – Ярославль: ЯрГУ, 2011. – 56 с.

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

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

Предназначено для студентов, обучающихся по направ-лениям подготовки магистров 010800.68 Радиофизика, 210400.68 Телекоммуникации, 210300.68 Радиотехниика (дисциплина «Компьютерные технологии в науке и образовании», блок ДНМ), очной формы обучения.

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

УДК 519.71 ББК 3973.2–018я73

Ярославский государственный

университет им. П. Г. Демидова, 2011

3

Часть 1. Жизненный цикл программного обеспечения

1.1. Введение Жизненным циклом программного обеспечения (software life

cycle) называется последовательность деятельностей, выполняе-мых в процессе разработки программного обеспечения (ПО) и приводящих к созданию результатов. Обычно под результатами понимаются объекты, такие как исходный код или руководство пользователя, однако результатами могут являться также договоренности или расчеты. Как правило, деятельности и результаты тесно связаны. Контрольные точки (milestone) – некоторые события, по которым можно судить о степени завершенности проекта. Например, событие появления оконча-тельной версии руководства пользователя может быть исполь-зовано в качестве контрольной точки. Контрольные точки явля-ются основой организации проекта, поскольку они позволяют руководителю оценить состояние проекта.

1.1.1. Виды деятельностей в жизненном цикле ПО Оценка применимости (feasibility) – определение полезности

или целесообразности разработки. Анализ рынка (market analysis) – оценка потенциального спроса

на данный продукт. Задание требований (requirements) – определение функциональ-

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

Выявление требований (requirement elicitation) – получение требований со стороны пользователя.

Анализ предметной области (domain analysis) – определение стандартных для данной области задач и терминов.

Планирование проекта (project planning) – определение плана разработки ПО.

Анализ затрат (cost analysis) – составление сметы затрат.

4

Планирование (scheduling) – составление календарного плана разработки.

Гарантия качества ПО (software quality assurance) – определе-ние деятельностей, которые помогут удостоверить качество программного продукта.

Схема декомпозиции работ (work-breakdown structure) – дробление проекта на подзадачи.

Проектирование (design) – определение механизма, посредством которого будет обеспечиваться необходимая функциональность.

Проектирование архитектуры (architectural design) – проек-тирование структуры системы.

Проектирование интерфейсов (interface design) – определение интерфейсов взаимодействия между частями системы.

Детальное проектирование (detailed design) – разработка алго-ритмов для отдельных частей системы.

Реализация (implementation) – построение ПО. Тестирование (testing) – выполнение программы с различны-

ми наборами входных данных, удостоверяющих ее корректность. Модульное тестирование (unit testing) – тестирование,

производимое непосредственно программистом-разработчиком. Интеграционное тестирование (integration testing) – тестиро-

вание ПО вцелом. Системное тестирование (system testing) – тестирование ПО в

условиях, схожих с эксплуатационными. Альфа-тестирование (alpha testing) – тестирование, произво-

димое потребителем в организации разработчика. Бета-тестирование (beta testing) – тестирование, производимое

потребителем вне организации разработчика. Приемочное тестирование (acceptance testing) – тестирование

на соответствие требованиям заказчика. Регрессивное тестирование (regression testing) – сравнение ре-

зультатов тестирования предыдущей версии ПО с результатами тестирования новой версии ПО для подтверждения того, что но-

5

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

Распространение (delivery) –обеспечение пользователей про-граммным решением.

Установка (installation) – развертывание ПО на оборудовании потребителя.

Обучение (training) – обучение пользователей правилам рабо-ты с ПО.

Служба поддержки (help desk) – ответы на вопросы пользова-телей.

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

1.1.2. Виды документов Техническое задание (statement of work) – предварительное

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

Спецификация программных требований (software require-ments specification) описывает как, что и в каких условиях будет выполнять готовое ПО.

Объектная модель (object model) отражает основные объекты и/или классы.

Сценарии вариантов использования (use case scenarios) описывают последовательности возможных режимов работы ПО с точки зрения пользователя.

План проекта (project schedule) описывает порядок выполне-ния задач с указанием временных рамок и ресурсоемкости каж-дой задачи.

План тестирования (software test plan) описывает процедуру тестирования ПО, гарантирующую его правильное фун-кционирование.

Приемочные тесты (acceptance tests) – тесты, формируемые заказ-чиком, которые позволяют определить пригодность системы.

Программный проект (software design) – описание структуры ПО.

6

Архитектурный проект (architectural design) – структура верхнего уровня, включающая взаимосвязи в системе.

Рабочий проект (detailed design) – проект модулей или объектов нижнего уровня.

План обеспечения качества (software quality assurance plan, SQA plan) описывает деятельности, необходимые для обеспечения качества ПО.

Руководство пользователя (user manual) – описание способа использования готового программного продукта.

Исходный код (source code) – фактический программный код продукта.

Акт технического испытания (test report) описывает, какие тесты были проведены и как себя вела себя система во время тестов.

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

1.2. Модели жизненного цикла ПО Наиболее распространенными моделями жизненного цикла

ПО являются линейная последовательная модель, модель прото-типов, инкрементальная модель и спиральная модель Боэма.

1.2.1. Линейная последовательная модель Линейная последовательная модель (рис. 1.1) также назы-

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

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

7

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

Рис. 1.1. Каскадная модель

1.2.2. Прототипирование Эта модель жизненного цикла включает построение прото-

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

1.2.3. Инкрементальная модель Инкрементальная модель была предложена Д. Л. Парнасом.

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

8

1.2.4. Спиральная модель Боэма Диаграмма модели представляет собой спираль, которая,

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

Вопросы к части 1 1. Каким образом поэтапная модель жизненного цикла

способствует управлению разработкой ПО? 2. Укажите две обязательные характеристики контрольной

точки. 3. Для каждого из следующих документов укажите, на ка-

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

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

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

Ответы на вопросы к части 1 1. Разделение жизненного цикла ПО на этапы повышает

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

9

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

3. Документация жизненного цикла ПО:

Окончательное руководство пользователя

Этап реализации

Архитектурный проект Этап проектирования План по обеспечению качества ПО Этап планирования проекта Спецификация модулей Этап проектирования Исходный код Этап реализации Техническое задание Этап предварительной оценки План тестирования Этап определения требований Предварительное руководство пользователя

Этап определения требований

Рабочий проект Этап проектирования Смета затрат Этап планирования проекта План проекта Этап планирования проекта Акт технического испытания Этап тестирования Документация Этап реализации

4. Последовательность выполнения задач: Анализ рынка → Проектное планирование, оценка

стоимости, спецификация требований (могут решаться параллельно) → Проверка требований → Высокоуровневое проектирование → Низкоуровневое проектирование → Анализ проекта → Реализация → Функциональное тестирование → Системное тестирование → Приемочное тестирование.

5. Диаграмма, описывающая инкрементальную модель жизненного цикла ПО, приведена на рис. 1.2.

10

Рис. 1.2. Инкрементальная модель жизненного цикла

Часть 2. Модель процесса разработки ПО

2.1. Модель процесса разработки ПО Модель процесса разработки ПО (software process model) опи-

сывает действия, производимые при разработке ПО. Модель про-цесса разработки ПО обычно включает: задачи; артефакты (фай-лы, данные и т. д.); деятелей; точки ветвления (опционально).

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

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

11

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

Модели процесса разработки ПО могут быть описывающи-ми (descriptive) и предписывающими (prescriptive). Описывающая модель отражает то, что происходило в процессе разработки проек-та, зачастую она создается в результате постанализа. Описывающая модель может быть использована для выявления проблем, возникающих в процессе разработки программного обеспечения.

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

Пример 2.1. На рис. 2.1 представлена модель процесса модульного тестирования ПО. Задачи в модели выполняются двумя деятелями: специалистом по тестированию и руководите-лем группы программистов. Модульное тестирование осущест-вляется специалистом с использованием исходного кода и плана тестирования. Результатом тестирования является артефакт – протокол испытаний. Руководитель проверяет протокол испы-таний и утверждает его. На рис. 2.1 не отражены действия, осу-ществляемые в случае, если результаты тестирования оказались неудовлетворительными. Можно считать, что тестирование про-водится до тех пор, пока результат не будет удовлетворительным. Аналогично, если руководитель не готов утвердить результаты, то тестирование производится заново.

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

12

Рис. 2.1. Модель процесса модульного тестирования

Рис. 2.2. Модель процесса модульного тестирования с точкой ветвления

2.2. Диаграммы потока данных Одной из наиболее фундаментальных моделей, используе-

мых при разработке ПО, является диаграмма потока данных (data flow diagram). На этой диаграмме отражается динамика дан-ных между несколькими компонентами. Под компонентами по-нимаются задачи, программные модули и даже функциональные абстракции, которые будут включены в ПО. Диаграмма потока данных не содержит деятелей, а последовательность выполняе-мых действий обычно определяется последовательностью блоков на диаграмме.

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

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

действий может быть определена из расположения блоков); – отображенный на диаграмме процесс может исполняться

как единовременно, так и продолжительное время; – две стрелочки, выходящие из блока, означают, что

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

13

Пример 2.3. Процесс модульного тестирования, рассмотрен-ный в примере 2.1, может быть представлен в виде диаграммы потока данных (рис. 2.3).

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

Пример 2.4. Вычисление математического выражения (x+y)∙(w+z) может быть представлено последовательностью дейст-вий, приведенной на рис. 2.4.

Рис. 2.3. Диаграмма потока данных для процесса модульного тестирования

Рис. 2.4. Диаграмма математического выражения (x+y)∙(w+z)

2.3. Модели сети Петри Модель сети Петри состоит из условных узлов, стрелочек,

узлов событий и маркеров (token). Если на входе узла события условные узлы отмечены маркером, то событие является возмож-ным. После наступления события маркерами помечаются все выходные условные узлы, а входные узлы освобождаются от

14

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

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

Существует множество моделей, основанных на модели сети Петри.

Пример 2.5. Модель сети Петри процесса тестирования приведена на рис. 2.5.

2.4. Объектные модели В объектно ориентированном программировании и задача в

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

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

15

Рис. 2.5. Модель сети Петри

Выделяют три основных вида отношений: наследование,

агрегирование и ассоциацию. Отношение наследования (inheritance) указывает на то, что объект, расположенный у «оперения» стрелочки, является частным случаем объекта, расположенного у «наконечника». Например, в качестве более абстрактного объекта может выступать транспортное средство, а в качестве более конкретного – автомобиль, поскольку авто-мобиль – одно из транспортных средств. Отношение агрегиро-вания (aggregation) указывает на то, что объект, расположенный у «оперения» стрелочки, является компонентом объекта, расположенного у другого конца. Например, если объемлющий объект – автомобиль, то в качестве компонента может выступать двигатель. Последний тип отношений – это ассоциация (association). В этом случае отношение указывает на то, что один из объектов каким-либо образом связан с другим объектом. Отношение «отец – сын» является примером ассоциации. Ассо-циация может быть как односторонней, так и двусторонней.

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

Пример 2.6. Нарисуйте объектную модель обычной библио-теки. В модели, представленной на рис. 2.6, в качестве объектов

16

используются «библиотека», «книга», «экземпляр книги» и «читатель».

Методы объектов не представлены на диаграмме. Объект «библиотека» связан с объектами «книга» и «читатель» отношением агрегирования, то есть библиотека объединяет в себе читателей и книги. Отношение между объектами «книга» и «экземпляр» не является ни агрегацией, ни наследованием. Объект «книга» представляет собой абстракцию книги (назва-ние, автор, год издания и прочее), тогда как «экземпляр» – это физический предмет, который был взят читателем в библиотеке. Отношение между «читателем» и «экземпляром» называется «получение». Со стороны «экземпляра» читатель выполняет роль «взявшего», а со стороны «читателя» книга выполняет роль «взятого». Кратность (0..1) указывает на то, что «экземпляр» может быть не выдан вовсе или получен только одним читателем. Кратность (0..*) свидетельствует о том, что читатель за один раз может «взять» как несколько книг, так и ни одной.

Пример 2.7. Составьте объектную модель генеалогического древа, содержащего информацию о членах семьи.

Модель (рис. 2.7) показывает, что каждый имеет роди-тельскую семью. В каждом браке имеется человек-отец и человек-мать. На диаграмме не представлены методы объектов и некоторые атрибуты.

17

Рис. 2.6. Объектная модель библиотеки

Рис. 2.7. Объектная модель генеалогического древа

2.4.1. Зависимость по существованию

Можно уточнить отношения между объектами посредством ввода дополнительного типа отношений, называемого зависимос-тью по существованию (existence dependency, ED). Отношение зави-симости по существованию возникает между классами объектов при одновременном выполнении двух условий: экземпляры младшего (зависимого, дочернего) класса могут существовать только при существовании экземпляра старшего (родительского) класса (1), каждый экземпляр дочернего класса ассоциирован с единственным экземпляром родительского класса (2).

Пример 2.8. Составьте объектную модель библиотеки, используя отношение типа «зависимость по существованию».

В модели, представленной на рис. 2.6, все отношения, кроме «займа» и отношения «библиотека – книга», удовлетворяют требованиям, предъявляемым к зависимости по существованию. Отношение «получение» не удовлетворяет требованиям, так как объект «экземпляр» существует до появления объекта «чита-тель». Однако может быть создан объект «получение», удовле-творяющий отношению зависимости по существованию. Объект «книга» не может быть дочерним по отношению к объекту «библиотека», так как книги существуют сами по себе, вне зависимости от библиотеки. Также в диаграмму, представленную

18

на рис. 2.8, добавлен объект «человек», который подчеркивает, что часть объекта «читатель» не имеет зависимости по существованию с объектом «библиотека».

Рис. 2.8. Объектная модель библиотеки с использованием зависимости по существованию

2.4.2. Диаграммы экземпляров На диаграммах объектов отображаются типы объектов (клас-

сы). То есть блок «автомобиль» описывает атрибуты и функции всех экземпляров автомобилей. Отношения между экземплярами объектов на объектной диаграмме не всегда очевидны. На диа-грамме экземпляров (instance diagram) отражается возможное соче-тание экземпляров объектов, что может помочь уточнить отно-шения между ними.

Пример 2.9. Нарисуйте диаграмму экземпляров семьи, состоящей из Фреда, его жены Сью, их детей – Билла, Тома и Мэри, и родителей Фреда – Майка и Джин (см. рис. 2.9).

19

Рис. 2.9. Диаграмма экземпляров для семейного древа Фреда

2.5. Диаграммы вариантов использования Диаграмма вариантов использования (use case diagram) – од-

на из диаграмм унифицированного языка моделирования (Unified Modeling Language, UML). На ней отображаются деятели и функ-ции системы. Деятели изображаются человечками, а функции – овалами. Деятели связываются с выполняемыми ими функциями.

Пример 2.10. Нарисуйте диаграмму вариантов использо-вания для библиотеки (см. рис. 2.10).

Рис. 2.10. Диаграмма вариантов использования для библиотеки

20

Функции в овалах – это методы классов объектной модели. Объект «читатель» может «взять книгу» из библиотеки и «вер-нуть» ее. Деятель «библиотекарь» никак не был отражен в объектной модели (рис. 2.6), а в рассматриваемой диаграмме с его помощью показывается, что некоторые функции, к примеру «поиск книги в каталоге» и «поиск книги на стеллажах», недо-ступны «читателю».

2.6. Сценарии

Сценарий (scenario) – описание одной из возможных после-довательностей действий, которая может произойти в данной предметной области.

Пример 2.11. Напишите сценарий для библиотеки. Фред – «читатель» – идет в библиотеку и берет книгу. Спустя

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

2.7. Диаграммы последовательности Диаграммы последовательности (sequence diagram) отно-

сятся к диаграммам унифицированного языка моделирования, вертикальные линии на которой отражают экземпляры классов. Каждая такая вертикальная линия подписывается сверху. Надпись состоит из названия класса и названия конкретного экземпляра класса, разделенных между собой двоеточием. К примеру, линия (рис. 2.11) обозначена как «читатель:Фред», где «читатель» – это название класса, а «Фред» соответствует названию экземпляра данного класса. Горизонтальные стрелки соответствуют вызовам функций, при этом их направление показывает, из какого класса в какой сделан вызов. Название функции подписывается над стрелкой, а продолжительность выполнения отображается в виде широкого блока на вертикальной линии. Возвраты из функций обычно на диаграмму не наносятся, а многократные вызовы одной и той же функции показываются в виде одной стрелки.

Пример 2.12. Нарисуйте диаграмму последовательности для сценария в примере 2.11 (см. рис. 2.11).

21

Рис. 2.11. Диаграмма последовательности для сценария библиотеки

Эта диаграмма намного более точно соответствует этапу

проектирования, нежели модель, приведенная в примере 2.8. Здесь представлены функции, которые не были отражены в предыдущих объектных моделях. Кроме того, последователь-ность вызовов, изображенная на диаграмме, зависит от конкрет-ного исполнения проекта.

2.8. Иерархические диаграммы Иерархические диаграммы (hierarchy diagrams) показывают

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

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

22

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

Рис. 2.12. Иерархическая диаграмма

2.9. Граф потока управления Граф потока управления (control flow graph, CFG) отражает

структуру выполнения кода. Каждый узел (окружность) пред-ставляет собой некоторую часть программы, в которой поток управления имеет единственный путь. То есть у каждой такой части существует единственный вход и единственный выход, и если исполняется один оператор из этой части, то исполняются и все остальные. Ребра графа, соединяющие узлы, показывают возможные пути перехода управления в программе. Если возмож-но, что блок кода B будет выполняться после блока кода A, то на графе соответствующие им окружности должны быть соединены ребром.

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

Пример 2.14. Нарисуйте граф потока управления для нижеприведенного кода задачи «Треугольник».

read x,y,z; type = “неравносторонний”; if (x == у or x == z or у == z) type = “равнобедренный”; if (x == у and x == z) type = “равносторонний”; if (x > = y+z or у >= x+z or z >= x+y) type = “не треугольник”; if (x <= 0 or у <= 0 or z <= 0) type = “некорректные данные”; print type;

23

На рис. 2.13 узел «a» отражает первые две строки кода и условие, стоящее в первом операторе if. Стоящая в этом операторе ин-струкция «type = равнобедренный» выполняется в узле «равнобедренный». Аналогично, узел «c» отражает условие следующего оператора if, а узел «равносторонний» – инструкцию этого условного оператора.

Рис. 2.13. Граф потока управления для программы «Треугольник»

2.10. Диаграммы состояний Состояние автомата или программы – это совокупность всех

возможных значений переменных, регистров и т. д. На диаграм-ме состояний (state diagram) указываются как состояния системы, так и возможные переходы между ними. Количество таких возможных состояний огромно. Существуют подмножества состояний, в которых автомат ведет себя похожим образом. Такие подмножества можно объединять в группы и заменять единственным обобщенным состоянием. Многие программы удобно описывать именно при помощи диаграмм состояний.

Правила построения диаграммы состояний следующие: – должно быть задано единственное начальное состояние; – из начального состояния должен быть возможен переход в

любое другое; – из любого состояния должен быть возможен переход в

конечное состояние; – любому переходу между состояниями должно соответство-

вать некоторое событие, вызывающее этот переход, и это собы-тие также должно быть отражено на диаграмме.

Пример 2.15. Нарисуйте диаграмму состояний стека фиксированного размера (см. рис. 2.14).

24

Рис. 2.14. Диаграмма состояний стека фиксированного размера

При построении диаграмм состояний возможны два подхода. На рис. 2.14 указываются только допустимые (или безошибоч-ные) переходы. Предполагается, что любой переход, изобра-женный на диаграмме, допустѝм. К примеру, нет перехода «push» (помещение данных в стек) из состояния заполненного стека. Другой подход заключается в изображении всех состояний, включая те, которые приводят к ошибкам.

Пример 2.16. Нарисуйте диаграмму состояний стека, включающую в себя все, в том числе и ошибочные, переходы (см. рис. 2.15).

Рис. 2.15. Диаграмма состояний с ошибочными переходами

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

Пример 2.17. Нижеприведенный код соответствует проце-дуре «push» в стеке конечного размера:

int push(int item) { if (stackindex == MAX) {return ERROR;} stack[stackindex++] = item; return 0; } В приведенном коде можно выделить два состояния, в

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

25

значение переменной stackindex равно нулю. Первое состояние связано с условием «stackindex == MAX», а второе – с условием «stackindex != max». Анализ приращения переменной показы-вает, что второе состояние соответствует (для данного метода) условию «stackindex < MAX». Анализ процедуры «pop» выявит также пустое состояние стека.

2.11. Решетчатые модели Решеткой (lattice) называется математическая структура,

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

Пример 2.18. Нарисуйте решетчатую модель стека (см. рис. 2.16), содержащую атрибуты (массив параметров (s-array), индекс вершины стека (index)) и функции («push», «pop», «val» (возвращает верхнее значение) и «depth»).

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

Рис. 2.16. Решетчатая модель стека

26

Вопросы к части 2 1. В чем отличие между моделью жизненного цикла програм-

много обеспечения и моделью процесса? 2. В чем отличие между описывающей и предписывающей

моделью процесса? 3. Почему точки принятия решений более характерны для

предписывающих моделей процесса, нежели для описывающих моделей?

4. Почему задачи в модели процесса должны быть отделены артефактами?

5. Почему задача в модели процесса не может быть запущена до тех пор, пока не сформированы входные артефакты?

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

7. Каким образом в примере 2.3 можно отличить «отчет о тестировании» после тестирования всех модулей от «отчета о тестировании» после тестирования единственного модуля?

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

решения? 12. Как изменяется объектная модель от этапа постановки требо-

ваний до этапа проектирования? 13. Определите тип отношений (наследование, агрегирование,

ассоциация) в парах. Автомобиль – автомобиль марки Линкольн; человек – студент;

библиотека – читатель; книга – экземпляр; автомобиль – водитель; читатель – библиотечная книга; группа – студенты.

14. Определите, относятся приведенные ниже выражения к названию класса или к названию экземпляра класса:

Мой автомобиль; человек; Фред; транспортное средство; профессор; информационный отдел.

27

15. Какова взаимосвязь между сценарием и диаграммой состояний, показывающей все возможные последовательности действий?

16. Как направлена стрелка между классами на диаграмме взаимодействия?

17. Объясните, почему отношение агрегирования относится к предметной области, а не к области реализации (программному коду).

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

Задания к части 2 1. Нарисуйте модель процесса к задаче покраски стен в

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

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

3. Нарисуйте диаграмму потока данных для библиотеки. 4. Нарисуйте диаграмму потока данных для фабрики. 5. Нарисуйте диаграмму потока данных для продовольствен-

ного магазина. 6. Нарисуйте объектную модель бинарного дерева. 7. Нарисуйте диаграмму экземпляров для объектной модели

бинарного дерева. 8. Нарисуйте объектную модель продовольственного

магазина. 9. Нарисуйте объектную модель фабрики. 10. Напишите дополнительный сценарий к примеру 2.11,

содержащий действия читателя по выбору книги. 11. Нарисуйте диаграмму состояния графического интер-

фейса пользователя, имеющего главное меню, файловое меню с

28

командами «открыть файл» и «выход». При этом учтите, что в процессе работы открытым может быть только один файл.

12. Дополните объектную модель библиотеки на рис. 2.17, включив в нее возможность зарезервировать книгу читателем в случае, если все экземпляры уже выданы.

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

Ответы на вопросы к части 2 1. Модель жизненного цикла программного обеспечения отражает основные этапы и результаты, тогда как мо-дель процесса описывает за-дачи нижнего уровня, необ-ходимые и созданные арте-факты, а также деятелей, ответственных за каждую из задач. Рис. 2.17. Объектная модель

библиотеки 2. Описывающая модель отражает то, что происходит при

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

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

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

29

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

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

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

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

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

10. Маркируется каждый выходной узел стартового состояния. 11. Предметная область – часть материального мира, состоя-

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

12. Изначально объектами являются сущности предметной области. При переходе к этапу проектирования объекты превра-щаются в сущности пространства решения.

13. Отношения и их виды:

Автомобиль – автомобиль марки Линкольн Человек – студент Библиотека – читатель Книга – экземпляр Автомобиль – водитель Читатель – библиотечная книга Группа – студенты

Наследование Наследование Агрегирование Общая ассоциация Общая ассоциация Общая ассоциация Агрегирование

14. Выражения и их отношения к классам и к экземплярам:

30

Мой автомобиль Человек Фред Транспортное средство Профессор Информационный отдел

Экземпляр Класс Экземпляр Класс Класс Экземпляр

15. Сценарий – это лишь один из возможных путей прохода через

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

Над стрелкой указывается название вызываемой функции. 17. И агрегирование, и ассоциация реализуются одинаково.

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

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

Ответы на задания к части 2 1. См. рис. 2.18. 4. См. рис. 2.21. 7. См. рис. 2.24. 2. См. рис. 2.19. 5. См. рис. 2.22. 8. См. рис. 2.25 3. См. рис. 2.20. 6. См. рис. 2.23. 9. См. рис. 2.26.

10. а) Фред приходит в библиотеку и не находит подходящую книгу; б) Фред приходит в библиотеку и забирает две книги. Затем он еще раз приходит в библиотеку и забирает еще три книги. Последние три книги он возвращает вовремя. Первые две книги он возвращает с опозданием.

31

Рис. 2.18. Модель процесса покраски стен

а)

32

б)

Рис. 2.19. Модель процесса интерактивного занятия: а) подготовка; б) выполнение заданий

Рис. 2.20. Диаграмма потока данных библиотеки

Рис. 2.21. Диаграмма потока данных фабрики

33

Рис. 2.22. Диаграмма потока данных продовольственного магазина

Рис. 2.23. Объектная модель бинарного дерева

Рис. 2.24. Диаграмма реализации бинарного дерева

34

Рис. 2.25. Объектная модель супермаркета

Рис. 2.26. Объектная модель фабрики

11. См. рис. 2.27. Отметим, что хотя команда «закрыть файл» не была явно указана в задании, необходим выход из состояния «открытый файл».

Рис. 2.27. Диаграмма состояний графического интерфейса пользователя

35

12. См. рис. 2.28.

Рис. 2.28. Объектная модель библиотеки

13. См. рис. 2.29.

Рис. 2.29. Конечный автомат для библиотеки

36

Часть 3. Управление программным проектом 3.1. Введение

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

Управление программным проектом затруднено, поскольку до-вольно тяжело судить о степени готовности объекта, который не-возможно окинуть взором. Во множестве других областей судить о готовности продукта значительно легче. Множество программных проектов застывает на 90% выполнения и не может сдвинуться дальше. Множество техник управления программными проектами направлены на преодоление трудностей с обозреваемостью.

3.2. Подходы к управлению При управлении программным проектом важно определить

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

3.3. Командные подходы Организация группы людей в эффективную команду – весьма

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

37

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

Команда может состоять из профессионалов примерно одина-ковой квалификации, с примерно одинаковым набором знаний и умений. Такие команды обычно не распадаются и существуют на протяжении множества проектов. Другие команды формируются «под проект» из разноплановых специалистов. Такой подход называется матричной организацией (matrix organization).

3.3.1. Группы программистов, ориентированные на руководителя

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

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

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

38

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

3.4. Важные процессы В результате многочисленных исследований был определен

ряд процессов, наиболее важных для достижения результата – разработки ПО. Среди них можно отметить: непрерывное управ-ление рисками; эмпирические планирование и оценка затрат; использование специальных метрик в управления проектом; отслеживание освоенных объемов; отслеживание выявления дефектов; особое внимание к человеческому ресурсу; использо-вание системы контроля версий; управление требованиями и отслеживание изменений требований; использование системного подхода при проектировании ПО; обеспечение совместимости данных; определение интерфейсов; «дважды спроектируй, один раз закодируй»; оценка рисков и затрат; проверка выполнения требований и проектных решений; непрерывное тестирование; частая компиляция и запуск «дымовых тестов».

Пример 3.3. Руководителю отдела информационных технологий компании «WRT» потребовалось разработать процесс разработки ПО для организации работы неопытных разработ-чиков ПО и успешного выполнения проекта.

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

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

2. Эмпирические планирование и оценка затрат. Себестоимость проекта оценивается на начальном этапе

жизненного цикла ПО. В процессе развития проекта осущест-вляются множественные повторные оценки затрат. На основе полученных оценок формируется прогноз стоимости.

39

3. Использование специальных метрик в управлении проектом. Руководитель выбирает метрики, позволяющие оценить

развитие проекта. В жизненный процесс вводятся шаги для вы-числения метрик и определения степени завершенности проекта по этим данным.

4. Оценка освоенных объемов. На разных этапах производится оценка освоенных объемов и

определение фактических затрат. 5. Отслеживание выявления дефектов. Управляющий определяет цели по количеству найденных

дефектов. В жизненный цикл включаются шаги по созданию отчетов о дефектах.

6. Особое внимание к человеческому ресурсу. Оценивается влияние процесса разработки ПО на програм-

мистов. 7. Использование системы контроля версий. Руководитель включает в процесс использование системы

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

8. Управление требованиями и отслеживание изменений требований.

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

9. Использование системного подхода при проектировании ПО. Руководитель включает шаги, обеспечивающие использова-

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

данных. 11. Определение интерфейсов. В процессе разработки определяются интерфейсы, а также

осуществляется их проверка. 12. «Дважды спроектируй, один раз закодируй». Руководитель включает шаги по анализу принятых проект-

ных решений.

40

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

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

тестирования.

3.5. Модель зрелости процесса создания ПО Модель зрелости процесса создания программного обеспе-

чения была разработана институтом программной инженерии. Модель SE-CMM (Software Engineering Capability Maturity Model) используется для оценки процесса разработки ПО в организации. В соответствии с моделью процессы и организации можно классифицировать по уровням развития:

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

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

3. Уровень регламентирования. На данном уровне регламентируется процесс разработки ПО: проводится документирование и стандартизация. Развитие проекта осуществляется с использованием стандартных процессов.

4. Уровень управляемости. На уровне управляемости осуществляется количественный контроль как процессов, выполняемых в ходе разработки, так и их результатов.

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

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

41

3.6. Индивидуальный процесс разработки ПО Индивидуальный процесс разработки ПО (Personal Software

Process, PSP) был предложен Уотсом Хэмфри с целью повыше-ния квалификации индивидуальных разработчиков программного обеспечения. В рамках предложенного подхода для определения уровня персональных навыков ведется индивидуальная статистика, которая, в частности, позволяет оценить производи-тельность разработчика. Обычно мерой производительности является количество строчек кода, написанных программистом за день (lines of code/day, LOC/day,); также дополнительно регистри-руются обнаруженные ошибки. Все это позволяет оценить различные техники разработки ПО в терминах их влияния на продуктивность и уровень ошибок. Кроме того, оценка продуктивности может использоваться в качестве меры эффек-тивности составленного плана разработки.

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

Дата Начало Завер-шение

Перерыв Общее время

Задание

01.01.2010 09:00 15:30 30 мин 360 мин 50 LOC 03.01.2010 09:00 14:00 30 мин 270 мин 60 LOC 04.01.2010 09:00 11:30 – 150 мин 50 LOC

– 12:00 14:00 – 120 мин Тестирование Программист затратил в общей сложности

360+270+150+120=900 минут (15 часов) на написание и тестиро-вание программы, состоящей из 160 строк кода. Если принять продолжительность рабочего дня равной 5 часам, то получается, что программист работал 3 полных дня, то есть его производи-тельность составляет 53 строки кода/день. Таким образом, на выполнение проекта объемом в 1000 строк кода, программисту потребуется примерно 4 недели.

42

3.7. Анализ освоенных объемов Для определения состояния развития проекта можно оценить

объем выполненных работ, то есть произвести анализ освоенных объемов (earned value analysis). Обычно данная оценка дается в процентном отношении от общего времени, за которое (в соот-ветствии с планом) должен быть выполнен проект. Анализ также может основываться на любых количественных величинах, с помощью которых можно определить степень завершеннос-ти/развития проекта.

3.7.1. Основные метрики Бюджетная стоимость работы (Budgeted Cost of Work,

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

(Budgeted Cost of Work Scheduled, BCWS) – сумма предполагае-мых затрат на каждое запланированное рабочее задание, которое в соответствии с планом должно быть выполнено к опреде-ленному времени.

Бюджет по завершении (Budget at Completion, BAC) – сумма всех BCWS, то есть суммарные предполагаемые затраты на выполнение проекта.

Плановый объем (Planned Value, PV) – выраженная в процентном отношении часть суммарных затрат, отведенная для выполнения конкретного рабочего задания: PV = BCW/BAC.

Бюджетная стоимость выполненной работы (Budgeted Cost of Work Performed, BCWP) – сумма предполагаемых затрат на конкретное рабочее задание, выполненное к определенному времени.

Фактическая стоимость выполненной работы (Actual Cost of Work Performed, ACWP) – фактические затраты на выпол-ненную работу.

3.7.2. Индикаторы состояния проекта Освоенный объем (Earned Value, EV)

EV = BСWP/BAC = PC = ∑ PV,

43

где PC (Percent Complete, PC) – доля завершенной работы, а сумма PV считается по выполненным рабочим заданиям.

Индекс выполнения плана (Schedule Performance Index, SPI)

SPI = BCWP/BCWS.

Отклонение по срокам (Schedule Variance, SV)

SV = BCWP−BCWS.

Индекс выполнения стоимости (Cost Performance Index, CPI)

CPI = BCWP/ACWP.

Отклонение по стоимости (Cost Variance, CV)

CV = BCWP−ACWP.

Пример 3.5. Компанией был выполнен ряд работ по теку-щему проекту. Ниже приведена таблица, отражающая текущее состояние развития проекта.

№ Планируемое количество

человеко-дней на выполнение

Фактическое количество

человеко-дней Планируемая дата

завершения Фактическая

дата завершения

1 5 10 25.01.2010 01.02.2010 2 25 20 15.02.2010 15.02.2010 3 120 80 15.05.2010 4 40 50 15.04.2010 01.04.2010 5 60 50 01.07.2010 6 80 70 01.09.2010

Величина BAC = 330 человеко-дней, что равно предполагаемой продолжительности выполнения всего проекта. К 01.04.2010 задания 1, 2 и 4 были выполнены. Значение метрики BCWP проекта получается суммированием величин BCWS выполненных заданий. Таким образом, BCWP = 70 человеко-дней. Освоенный объем (EV) составляет 21,2 % (= 70/330). В соответствии с планом к 01.04.2010 должны были быть выполнены задания 1 и 2, тогда как фактически было выполнено и 4-е задание, т. е. BCWP = 70 человеко-дней, а BCWS = 30 дней. В соответствии с этим SPI = 233% (= 70/30), а SV = +40 человеко-дней (= 70–30), то есть план перевыполнен на

44

40 человеко-дней. Величина метрики ACWP получается суммированием фактических затрат на задания 1, 2 и 4. В приведенном примере величина ACWP составляет 80 человеко-дней. Тем самым CPI = 87,5% (= 70/80), а CV = –10 дней (= 70–80).

Пример 3.6. Допустим, что в примере 3.5 к 01.07.2010 будет выполнено также 3-е задание, на которое будет затрачено 140 дней (т. е. к 01.07.2010 будут выполнены задания 1, 2, 3 и 4). Тогда

BCWP = 190 человеко-дней; EV = 57,5% (= 190/330); BCWS = 250 человеко-дней;

SPI = 76% (190/250); SV = –60 дней (= 190–250); ACWP = 220 человеко-дней.

По плану к 01.07.2010 должны были быть выполнены задания с 1-го по 5-е, тогда как фактически 5-е задание выпол-нено не было. Поэтому

CPI = 86,3% (= 190/220); CV = –30 дней (190–220).

3.8. Контроль ошибок В процессе разработки программного обеспечения необхо-

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

Уровень ошибок – величина, обратная интервалу времени между ошибками. То есть если ошибки обнаруживаются каждые 2 дня, то их уровень составляет 0,5 ошибок/день. Если обнаруженные ошибки не устраняются в момент их обнару-жения, то суммарный показатель уровня ошибок (отношение общего количества обнаруженных ошибок к суммарному вре-мени) является хорошей оценкой будущего уровня ошибок. Обычно большинство ошибок устраняются сразу, и уровень ошибок спадает с увеличением временных интервалов между обнаружением ошибок. Графическое отображение полученных данных позволяет визуально оценить изменения уровня ошибок. По оси X откладывается количество ошибок, а по оси Y – их уро-

45

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

Пример 3.7. Пусть интервалы времени между ошибками составляют 4, 3, 5, 6, 4, 6 и 7 дней. Обратная величина – мгновен-ный уровень ошибок – будет равна соответственно 0,25; 0,33; 0,20; 0,17; 0,25; 0,17 и 0,14. Ломаная, отображающая полученные данные, приведена на рис. 3.2. Из анализа графика следует, что уровень ошибок постепенно снижается.

Прямая линия, проведенная через точки, пересекла бы ось X в районе значения 11, то есть уровень ошибок стал бы нулевым после обнаружения 11-й ошибки. Таким образом, общее число ошибок в ПО равно 11. Так как семь ошибок были найдены, предполагается, что необходимо найти еще 4 ошибки.

1 2 3 4 5 6 7 80

0.05

0.1

0.15

0.2

0.25

0.3

0.35

Уровень ошибок

Коли

чест

во о

шиб

ок

Рис. 3.2. Уровень ошибок в ПО

3.9. Постанализ проекта Важной задачей при разработке ПО является проведение

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

46

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

Пример 3.8. В таблице приведен отчет компании по результатам постанализа.

Название проекта

Проект X Начало – 5 сентября 2010 г. Завершение – 8 декабря 2010 г.

Объем проекта Оцененный

объем Действительный

объем Оцененные

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

затраты

3 000 LOC 5 000 LOC 12 000 мин 10 000 мин

Субъективный комментарий по оценке проекта

Удовлетворительно Время выполнения было оценено

достаточно точно

Неудовлетворительно Неточная оценка объема проекта

Субъективный комментарий по процессу

Удовлетворительно

Неудовлетворительно Невыполнение задания членами

команды в срок

Субъективный комментарий по планированию

Удовлетворительно

Неудовлетворительно Недостаточно времени

для выполнения

Качество

Количество найденных ошибок Выявление требований Проектирование Модульное тестирование

Интеграционное тестирование

30

Распространение

средн. макс.

mccabe 4 30 Метод/класс 6 10

Свойства/класс 10 15 LOC/класс 150 500

Субъективная оценка качества

Удовлетворительно

Неудовлетворительно Тестирование системы не было произведено должным образом

Проблема: Неясность исходных требований

Описание: Формат входного файла был неверным

Влияние: Дополнительно потрачено 2 недели

Проблема: Описание: Влияние:

Проблема: Описание: Влияние:

47

Вопросы к части 3 1. Что понимается под обозреваемостью проекта? 2. В чем разница между проект-ориентированным и процесс-

ориентированным подходом? 3. Какой подход является предпочтительным при управлении

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

4. В чем преимущество дробления проекта на небольшие подзадачи?

5. Какой индикатор освоенных объемов может уменьшаться во время выполнения проекта?

6. Для каких индикаторов состояния проекта значение, превышающее единицу, считается хорошим?

7. В чем преимущество использования метрик, обратных SPI и CPI?

Задания к части 3 1. Нарисуйте модель процесса для слабоструктурированной ко-

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

2. Используя приведенную ниже статистику работы, оцените производительность программиста (в LOC/день), если общий объ-ем проекта №1 составляет 120 LOC, а проекта № 2 – 80 LOC (про-должительность одного рабочего человеко-дня считается равной 400 мин).

Дата Начало Завершение Перерыв Задание 01.02.2010 08:30 16:30 60 мин Проект 1 02.02.2010 09:00 17:00 30 мин Проект 1 05.02.2010 09:00 17:30 90 мин Проект 2 06.02.2010 07:30 12:00 – Проект 2

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

48

№ Планируемое количество

человеко-дней на выполнение

Фактическое количество

человеко-дней Планируемая дата

завершения Фактическая дата

завершения

1 50 70 15.01.2010 01.02.2010 2 35 20 15.02.2010 15.02.2010 3 20 40 25.02.2010 01.03.2010 4 40 40 15.04.2010 01.04.2010 5 60 10 01.06.2010 6 80 20 01.07.2010

4. Используя таблицу, приведенную ниже, рассчитайте значение PV и индикаторов состояния развития проекта через каждые полмесяца (с 1 января по 1 сентября).

№

Планируемое количество

человеко-дней на выполнение

Фактическое количество

человеко-дней

Планируемая дата завершения

Фактическая дата завершения

1 30 37 01.01.2010 01.02.2010 2 25 24 15.02.2010 15.02.2010 3 30 41 01.03.2010 15.03.2010 4 50 47 15.04.2010 01.04.2010 5 60 63 01.05.2010 15.04.2010 6 35 31 15.05.2010 01.06.2010 7 55 58 01.06.2010 01.06.2010 8 30 28 15.06.2010 15.06.2010 9 45 43 01.07.2010 15.07.2010

10 25 29 01.08.2010 15.08.2010 11 45 49 15.08.2010 01.09.2010

5. Преподавателю необходимо проверить 40 домашних и 40 экзаменационных работ. Как правило, проверка экзаменацион-ной работы занимает в 3 раза больше времени, чем проверка домашней работы. Рассчитайте значение PV для каждой экзаменационной и зачетной работы. Если за 5 часов препо-даватель проверил половину экзаменационных работ, то сколько времени ему потребуется для проверки оставшихся работ?

6. Пусть интервалы времени между ошибками составляют 6, 4, 8, 5, 6, 9, 11, 14, 16 и 19 дней. Постройте график, отражающий уровень ошибок в ПО, а также укажите, сколько времени потребуется для устранения всех ошибок.

7. Пусть дата начала проекта – 1 января, дата окончания – 1 июня, текущая дата – 1 марта. Определите недостающие в таблице данные, вычислите значения PV, EV, SPI, SV и CV. Определите, соблюдается ли расписание. Обоснуйте свой ответ.

49

№ Планируемое количество

человеко-дней на выполнение

Фактическое количество

человеко-дней

PV Планируемая дата

завершения Состояние

задачи

1 30 10 1 февраля 2 20 30 1 марта Выполнено 3 50 30 1 мая Выполнено 4 100 5 1 июня

Ответы на вопросы к части 3 1. Под обозреваемостью понимают свойство проекта, которое

заключается в возможности отслеживать прогресс (или его отсутствие).

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

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

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

5. В процессе разработки все индикаторы состояния проекта за исключением освоенного объема (EV) должны уменьшаться.

6. Если значение индикаторов SPI и SV больше 1, это озна-чает, что выполненный объем работ превышает запланирован-ный. Если значение CPI и CV больше 1, то фактические затраты на выполнение проекта ниже запланированных. Таким образом, при работе над проектом желательно, чтобы значение всех четы-рех индикаторов было больше 1.

7. Величины, обратные SPI и CPI, могут использоваться при планировании проекта. Так, если величина, обратная SPI, равна 2, то время выполнения проекта в 2 раза превысит запланированное. Если значение величины, обратной CPI, равно 2, то затраты на проект в два раза превысят запланированные.

50

Ответы на задания к части 3 1. См. рис. 3.3; 2. Рассчитаем время работы в течение

каждого дня: 1) (16:30-8:30)∙60 – 60 = 420 мин; 2) (17:00-9:00)∙60 – 30 = 450 мин; 3) 420 мин; 4) 270 мин.

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

120 LOC/(420 мин + 450 мин) = 120 LOC/2,175 дня = 55 LOC/день (проект № 1);

80 LOC/690 мин = 120 LOC/1,725 дня = 46,4 LOC/день (проект № 2);

200 LOC/3,9 дня = 51,4 LOC/день (средняя производитель-ность).

Рис. 3.3. Модель процесса для слабоструктурированной группы

3. Значения основных индикаторов и метрик:

BCWP = 50+35+20+40 = 145 дней; BAC = 50+35+20+40+60+80 = 285 дней; PV1=17,5%; PV2=12,3%; PV3=7%; PV4=14%; PV5=21,1%; PV6=28,1%; EV = 17,5%+12,3%+7%+14% = 50,7%; BCWS = BCWP = 145 дней; SPI = 100% (145/145); SV = 0 дней (= 145–145); CPI = 145/170 = 85,3%; CV = 145–170 = –25

Таким образом, проект исполняется в соответствии с расписа-нием, однако суммарные затраты превышают запланированные.

51

4. Значения основных метрик для приведенного проекта:

BCW PV ACW Планируемая дата Фактическая дата 1 30 0,070 37 01.01.2010 01.02.2010 2 25 0,058 24 15.02.2010 15.02.2010 3 30 0,070 41 01.03.2010 15.03.2010 4 50 0,116 47 15.04.2010 01.04.2010 5 60 0,140 63 01.05.2010 15.04.2010 6 35 0,081 31 15.05.2010 01.06.2010 7 55 0,128 58 01.06.2010 01.06.2010 8 30 0,070 28 15.06.2010 15.06.2010 9 45 0,105 43 01.07.2010 15.07.2010

10 25 0,058 29 01.08.2010 15.08.2010 11 45 0,105 49 15.08.2010 01.09.2010

BAC = 430.

Рассчитаем значение основных метрик через каждые полмесяца:

Дата BCWS BCWP ACWP EV SPI SV CPI CV 01.01.2010 30 0 0 0,00 0,00 -30 0,00 0 15.01.2010 30 0 0 0,00 0,00 -30 0,00 0 01.02.2010 30 30 37 0,07 1,00 0 0,81 -7 15.02.2010 55 55 61 0,13 1,00 0 0,90 -6 01.03.2010 85 55 61 0,13 0,65 -30 0,90 -6 15.03.2010 85 85 102 0,20 1,00 0 0,83 -17 01.04.2010 85 135 149 0,31 1,59 50 0,91 -14 15.04.2010 135 195 212 0,45 1,44 60 0,92 -17 01.05.2010 195 195 212 0,45 1,00 0 0,92 -17 15.05.2010 230 195 212 0,45 0,85 -35 0,92 -17 01.06.2010 285 285 301 0,66 1,00 0 0,95 -16 15.06.2010 315 315 329 0,73 1,00 0 0,96 -14 01.07.2010 360 315 329 0,73 0,88 -45 0,96 -14 15.07.2010 360 360 372 0,84 1,00 0 0,97 -12 01.08.2010 385 360 372 0,84 0,94 -25 0,97 -12 15.08.2010 430 385 401 0,90 0,90 -45 0,96 -16 01.09.2010 430 430 450 1,00 1,00 0 0,96 -20

5. Пусть одна домашняя работа проверяется преподавателем за 1 единицу времени, тогда проверка экзаменационной работы занимает 3 единицы времени. Общее время проверки всех работ

52

составляет 40∙1 + 40∙3 = 160 ед. В этом случае PVдомашн. работы = 0,625%, а PVэкзам. работы = 1,875%. За 5 часов было проверено 20 экзаменационных работ, т. е. выполнено 37,5% работы. Общее время, которое потребуется преподавателю на проверку всех работ, составляет 5/0,375 = 13,33 часа, то есть на проверку оставшихся работ будет затрачено примерно 8,33 часа.

6. Уровень ошибок равен величине, обратной интервалу времени между ошибками. График, отражающий уровень ошибок в ПО, приведен на рис. 3.4.

Если продолжить график, то он пересечет ось X примерно на уровне 15. Таким образом, общее количество ошибок в ПО – 15 и требуется найти еще 5 ошибок.

Аналогично можно построить график, отображающий уро-вень ошибок, откладывая по оси X сумму времени между ошибками (рис. 3.5).

1 2 3 4 5 6 7 8 9 100

0.05

0.1

0.15

0.2

0.25

Количество ошибок

Уров

ень

ошиб

ок

Рис. 3.4. Зависимость уровня ошибок от количества ошибок

53

0 20 40 60 80 100 1200

0.05

0.1

0.15

0.2

0.25

Время

Уров

ень

ошиб

ок

Рис. 3.5. Изменение уровня ошибок

В этом случае график пересечет ось X примерно на уровне 160, т. е. для устранения всех ошибок ПО необходимо провести тестирование еще 62 единиц времени. При линейной аппрокси-мации данного графика пересечение с осью Y будет на уровне 0,25. При этом площадь под аппроксимирующей линией состав-ляет 0,5∙160∙0,25 = 20 ошибок. Это означает, что требуется найти еще 10 ошибок. Разница между данными двумя оценками вызва-на погрешностями аппроксимации.

7. Значения основных метрик для приведенного проекта:

BAC = 200; BCWS = 50; BCWP = 70; ACWP = 60; EV = 70/200 = 0,35; SV = 70–50 = 20; SPI = 70/50 = 1,4; CV = 70–60 = 10; PV1=15%; PV2=10%; PV3=25%; PV4=50%.

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

54

Список литературы

1. Parnas, D. Designing Software for Erase of Extension and Contraction / D. Parnas // IEEE Transaction on Software Engineering. – 1979. – March. – P. 128–138.

2. Boehm, B. A Spiral Model for Software Development and Enhancement / B. Boehm // IEEE Computer. –1988. – May. – P. 61–72.

3. URL: http://www.omg.org, url: http://www.rational.com 4. Snoeck and Dedene. Existence Dependency: The Key to

Semantic Integrity between Structural and Behavioral Aspects of Object Types // IEEE TOSE. – 1998. – April.

5. Software Project Managers Network. – URL: http:// www.spmn.com

6. Software Engineering Institute. – URL: http://www.sei.cmu.edu

7. Humphrey, W. Introduction to the Personal Software Process / W. Humphrey. – Addison-Wesley, 1997.

8. Макконел, С. Совершенный код / С. Макконел. – СПб.: Питер, 2007.

9. Кулямин, В. В. Технологии программирования. Компонентный подход / В. В. Кулямин. – М.: Бином. Лаборатория знаний, 2007.

10. Брукс, Ф. Мифический человеко-месяц, или Как создаются программные системы / Ф. Брукс. – М.: Символ-Плюс, 2010.

11. Рейнвотер, Дж. Х. Как пасти котов. Наставление для программистов, руководящих другими программистами / Дж. Х. Рейнвотер. – СПб.: Питер, 2011.

55

Оглавление

Часть 1. Жизненный цикл программного обеспечения ........................... 3

1.1. Введение ................................................................................................ 3

1.1.1. Виды деятельностей в жизненном цикле ПО ............................ 3

1.1.2. Виды документов .......................................................................... 5

1.2. Модели жизненного цикла ПО ........................................................... 6

1.2.1. Линейная последовательная модель ........................................... 6

1.2.2. Прототипирование ........................................................................ 7

1.2.3. Инкрементальная модель ............................................................. 7

1.2.4. Спиральная модель Боэма ............................................................ 8

Вопросы к части 1 ....................................................................................... 8

Ответы на вопросы к части 1 ..................................................................... 8

Часть 2. Модель процесса разработки ПО ................................................. 10

2.1. Модель процесса разработки ПО ..................................................... 10

2.2. Диаграммы потока данных ............................................................... 12

2.3. Модели сети Петри ............................................................................ 13

2.4. Объектные модели ............................................................................. 14

2.4.1. Зависимость по существованию ................................................ 17

2.4.2. Диаграммы экземпляров ............................................................ 18

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

2.6. Сценарии ............................................................................................. 20

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

2.8. Иерархические диаграммы ................................................................ 21

2.9. Граф потока управления .................................................................... 22

56

2.10. Диаграммы состояний ..................................................................... 23

2.11. Решетчатые модели .......................................................................... 25

Вопросы к части 2 ..................................................................................... 26

Задания к части 2 ....................................................................................... 27

Ответы на вопросы к части 2 ................................................................... 28

Ответы на задания к части 2 .................................................................... 30

Часть 3. Управление программным проектом ......................................... 36

3.1. Введение .............................................................................................. 36

3.2. Подходы к управлению ..................................................................... 36

3.3. Командные подходы .......................................................................... 36

3.3.1. Группы программистов, ориентированные на руководителя ....................................................................... 37

3.4. Важные процессы ............................................................................... 38

3.5. Модель зрелости процесса создания ПО ......................................... 40

3.6. Индивидуальный процесс разработки ПО ...................................... 41

3.7. Анализ освоенных объемов .............................................................. 42

3.7.1. Основные метрики ...................................................................... 42

3.7.2. Индикаторы состояния проекта................................................. 42

3.8. Контроль ошибок ............................................................................... 44

3.9. Постанализ проекта ............................................................................ 45

Вопросы к части 3 ..................................................................................... 47

Задания к части 3 ....................................................................................... 47

Ответы на вопросы к части 3 ................................................................... 49

Ответы на задания к части 3 .................................................................... 50

Список литературы......................................................................................... 54

57

Учебное издание

Апальков Илья Владимирович

Технологии программирования

Методические указания

Редактор, корректор М. В. Никулина Верстка Е. Л. Шелехова

Подписано в печать 07.06.11. Формат 60×84 1/16. Бум. офсетная. Гарнитура "Times New Roman".

Усл. печ. л. 3,49. Уч.-изд. л. 2,58. Тираж 50 экз. Заказ

Оригинал-макет подготовлен в редакционно-издательском отделе

Ярославского государственного университета им. П. Г. Демидова.

Отпечатано на ризографе.

Ярославский государственный университет им. П. Г. Демидова. 150000, Ярославль, ул. Советская, 14.

58

59

И. В. Апальков

Технологии программирования