close

Вход

Забыли?

вход по аккаунту

?

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

код для вставкиСкачать
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Министерство образования и науки Российской Федерации
Ярославский государственный университет им. П. Г. Демидова
Кафедра динамики электронных систем
И. В. Апальков
Технологии программирования
Методические указания
Рекомендовано
Научно-методическим советом университета для студентов,
обучающихся по направлениям подготовки магистров
Телекоммуникации, Радиотехника, Радиофизика
Ярославль 2011
1
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
УДК 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
2
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Часть 1. Жизненный цикл
программного обеспечения
1.1. Введение
Жизненным циклом программного обеспечения (software life
cycle) называется последовательность деятельностей, выполняемых в процессе разработки программного обеспечения (ПО) и
приводящих к созданию результатов. Обычно под результатами
понимаются объекты, такие как исходный код или руководство
пользователя, однако результатами могут являться также
договоренности или расчеты. Как правило, деятельности и
результаты тесно связаны. Контрольные точки (milestone) –
некоторые события, по которым можно судить о степени
завершенности проекта. Например, событие появления окончательной версии руководства пользователя может быть использовано в качестве контрольной точки. Контрольные точки являются основой организации проекта, поскольку они позволяют
руководителю оценить состояние проекта.
1.1.1. Виды деятельностей в жизненном цикле ПО
Оценка применимости (feasibility) – определение полезности
или целесообразности разработки.
Анализ рынка (market analysis) – оценка потенциального спроса
на данный продукт.
Задание требований (requirements) – определение функциональных возможностей, которыми должно обладать программное
обеспечение (ПО).
Выявление требований (requirement elicitation) – получение
требований со стороны пользователя.
Анализ предметной области (domain analysis) – определение
стандартных для данной области задач и терминов.
Планирование проекта (project planning) – определение плана
разработки ПО.
Анализ затрат (cost analysis) – составление сметы затрат.
3
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Планирование (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) – сравнение результатов тестирования предыдущей версии ПО с результатами
тестирования новой версии ПО для подтверждения того, что но4
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
вая версия обеспечивает все функциональные возможности предыдущей версии.
Распространение (delivery) –обеспечение пользователей программным решением.
Установка (installation) – развертывание ПО на оборудовании
потребителя.
Обучение (training) – обучение пользователей правилам работы с ПО.
Служба поддержки (help desk) – ответы на вопросы пользователей.
Поддержка (maintenance) – обновления и улучшения ПО,
позволяющие использовать его длительное время.
1.1.2. Виды документов
Техническое задание (statement of work) – предварительное
описание желаемых функциональных возможностей (зачастую
составляется пользователем).
Спецификация программных требований (software requirements specification) описывает как, что и в каких условиях будет
выполнять готовое ПО.
Объектная модель (object model) отражает основные объекты
и/или классы.
Сценарии вариантов использования (use case scenarios)
описывают последовательности возможных режимов работы ПО с
точки зрения пользователя.
План проекта (project schedule) описывает порядок выполнения задач с указанием временных рамок и ресурсоемкости каждой задачи.
План тестирования (software test plan) описывает процедуру
тестирования ПО, гарантирующую его правильное функционирование.
Приемочные тесты (acceptance tests) – тесты, формируемые заказчиком, которые позволяют определить пригодность системы.
Программный проект (software design) – описание структуры
ПО.
5
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Архитектурный проект (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 г. в виде
упорядоченного набора задач.
С одной стороны, в разработке любого программного продукта встречаются типовые задачи, с другой – существует множество возможностей для дробления процесса разработки на
этапы. Это приводит к существованию различных вариантов каскадных моделей. Отметим, что в каскадной модели, приведенной
6
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
на рис. 1.1, процесс планирования проекта включен в этап
формулирования требований. Также в данной модели не показаны этапы распространения и поддержки ПО.
Рис. 1.1. Каскадная модель
1.2.2. Прототипирование
Эта модель жизненного цикла включает построение прототипа (версии ПО для временного использования). На прототипе
проверяется правильность выработанных проектных решений,
возможность удовлетворения требований, демонстрация работы
потребителям. После согласования прототипа с заказчиком разработка ПО начинает двигаться по тем же этапам, что и при использовании линейной последовательной модели. Как правило, затраченные на создание прототипа усилия окупаются, поскольку в
окончательной версии ПО обеспечиваются только необходимые
возможности.
1.2.3. Инкрементальная модель
Инкрементальная модель была предложена Д. Л. Парнасом.
Первая итерация заключается в разработке и предоставлении
потребителю версии ПО с минимальным набором возможностей.
На каждой последующей итерации осуществляется расширение
функционала вплоть до завершения проекта. Преимущество
инкрементальной модели заключается в предоставлении потребителю ограниченно-функционирующей системы на ранних
этапах разработки.
7
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
1.2.4. Спиральная модель Боэма
Диаграмма модели представляет собой спираль, которая,
раскручиваясь из центра, последовательно проходит через ряд
основных задач, таких как согласование с клиентом, планирование, анализ рисков, проектирование, создание, выпуск и
потребительская оценка.
Вопросы к части 1
1. Каким образом поэтапная модель жизненного цикла
способствует управлению разработкой ПО?
2. Укажите две обязательные характеристики контрольной
точки.
3. Для каждого из следующих документов укажите, на каком(их) этапе(ах) жизненного цикла ПО он создан: окончательное руководство пользователя, архитектурный проект, план
обеспечения качества ПО, спецификация модулей, исходный код,
техническое задание, план тестирования, предварительное
руководство пользователя, рабочий проект, смета затрат, план
проекта, акт технического испытания, документация.
4. Упорядочите следующие задачи в соответствии с каскадной моделью: приемочное тестирование, проектное планирование, функциональное тестирование, проверка требований,
оценка стоимости, высокоуровневое проектирование, анализ
рынка, низкоуровневое проектирование, системное тестирование,
анализ проекта, реализация, спецификация требований.
5. Нарисуйте диаграмму, описывающую инкрементальную
модель жизненного цикла ПО.
Ответы на вопросы к части 1
1. Разделение жизненного цикла ПО на этапы повышает
возможность визуального контроля проекта. Контроль над
проектом можно осуществлять, рассматривая этапы как контрольные точки. Детальная проработка этапов способствует
более тщательному контролю хода работ.
8
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
2. Контрольная точка, во-первых, должна иметь отношение к
процессу разработки ПО (к динамике в развитии проекта). Вовторых, должно быть очевидно, когда контрольная точка
является пройденной.
3. Документация жизненного цикла ПО:
Окончательное руководство
пользователя
Архитектурный проект
План по обеспечению качества ПО
Спецификация модулей
Исходный код
Техническое задание
План тестирования
Предварительное руководство
пользователя
Рабочий проект
Смета затрат
План проекта
Акт технического испытания
Документация
Этап реализации
Этап проектирования
Этап планирования проекта
Этап проектирования
Этап реализации
Этап предварительной оценки
Этап определения требований
Этап определения требований
Этап проектирования
Этап планирования проекта
Этап планирования проекта
Этап тестирования
Этап реализации
4. Последовательность выполнения задач:
Анализ рынка → Проектное планирование, оценка
стоимости, спецификация требований (могут решаться
параллельно) → Проверка требований → Высокоуровневое
проектирование → Низкоуровневое проектирование → Анализ
проекта → Реализация → Функциональное тестирование →
Системное тестирование → Приемочное тестирование.
5. Диаграмма, описывающая инкрементальную модель
жизненного цикла ПО, приведена на рис. 1.2.
9
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рис. 1.2. Инкрементальная модель жизненного цикла
Часть 2. Модель процесса разработки ПО
2.1. Модель процесса разработки ПО
Модель процесса разработки ПО (software process model) описывает действия, производимые при разработке ПО. Модель процесса разработки ПО обычно включает: задачи; артефакты (файлы, данные и т. д.); деятелей; точки ветвления (опционально).
При этом система используемых обозначений может быть
различной. Для обозначения задач и процессов в стандартной
модели используются овалы, артефакты представляются прямоугольниками, а деятели – изображениями контурных человечков.
В большинстве моделей процесса разработки ПО точки ветвления не указываются, однако для их отображения при необходимости используются ромбы. Для указания потока выполнения
используются стрелочки без подписей, направленные, как
правило, слева направо или сверху вниз.
Правила построения и интерпретации моделей процесса
разработки ПО: две задачи не могут быть соединены напрямую,
они должны быть отделены друг от друга посредством
артефактов; задача не может выполняться, если отсутствуют ее
входные артефакты; имеется одна или несколько стартовых задач
и одна или несколько конечных задач; от стартовой задачи
10
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
должен быть возможен переход к любой другой; должен
существовать переход от любой задачи к конечной.
Модели процесса разработки ПО могут быть описывающими (descriptive) и предписывающими (prescriptive). Описывающая
модель отражает то, что происходило в процессе разработки проекта, зачастую она создается в результате постанализа. Описывающая
модель может быть использована для выявления проблем,
возникающих в процессе разработки программного обеспечения.
Предписывающая модель указывает на то, как должен выполняться процесс разработки. Предписывающие модели используются для описания типовых процессов и служат «обучающим
материалом» для новых сотрудников.
Пример 2.1. На рис. 2.1 представлена модель процесса
модульного тестирования ПО. Задачи в модели выполняются
двумя деятелями: специалистом по тестированию и руководителем группы программистов. Модульное тестирование осуществляется специалистом с использованием исходного кода и плана
тестирования. Результатом тестирования является артефакт –
протокол испытаний. Руководитель проверяет протокол испытаний и утверждает его. На рис. 2.1 не отражены действия, осуществляемые в случае, если результаты тестирования оказались
неудовлетворительными. Можно считать, что тестирование проводится до тех пор, пока результат не будет удовлетворительным.
Аналогично, если руководитель не готов утвердить результаты,
то тестирование производится заново.
Пример 2.2. Построим модель процесса разработки, на
которой будут отражены точки ветвления (рис. 2.2), их
добавление делает модель более точной в плане описания
действий, происходящих в различных ситуациях.
11
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рис. 2.1. Модель процесса модульного тестирования
Рис. 2.2. Модель процесса модульного тестирования с точкой ветвления
2.2. Диаграммы потока данных
Одной из наиболее фундаментальных моделей, используемых при разработке ПО, является диаграмма потока данных
(data flow diagram). На этой диаграмме отражается динамика данных между несколькими компонентами. Под компонентами понимаются задачи, программные модули и даже функциональные
абстракции, которые будут включены в ПО. Диаграмма потока
данных не содержит деятелей, а последовательность выполняемых действий обычно определяется последовательностью блоков
на диаграмме.
Правила построения и интерпретации диаграммы потока
данных:
– блоки на диаграмме отражают процессы;
– стрелочки соответствуют данным;
– порядок выполнения не указывается (последовательность
действий может быть определена из расположения блоков);
– отображенный на диаграмме процесс может исполняться
как единовременно, так и продолжительное время;
– две стрелочки, выходящие из блока, означают, что
результатом выполнения процесса являются либо оба выходных
артефакта, либо только один из них.
12
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Пример 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). Если на входе узла события
условные узлы отмечены маркером, то событие является возможным. После наступления события маркерами помечаются все
выходные условные узлы, а входные узлы освобождаются от
13
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
маркеров. Условные узлы в модели сети Петри обычно представляются в виде окружностей, а узлы событий – в виде прямоугольников или горизонтальных линий.
В модели сети Петри условные узлы обычно представляют
собой некоторое условие, например, наличие плана тестирования.
Маркировка узла означает удовлетворение условия. Узел события (горизонтальная линия) соответствует событию, которое
может произойти, когда будут выполнены все требования (все
входящие условные узлы владеют маркерами). После того как
событие произошло, маркерами помечаются все узлы, следующие за данным событием.
Существует множество моделей, основанных на модели сети
Петри.
Пример 2.5. Модель сети Петри процесса тестирования
приведена на рис. 2.5.
2.4. Объектные модели
В объектно ориентированном программировании и задача в
предметной области, и ее решение в машинной области (текст
программы) описываются в терминах объектов. В программном
коде эти объекты обычно описываются классами. В процессе
разработки ПО объекты из предметов или явлений предметной
области (на этапе определения требований) превращаются в
программные структуры (на этапе проектирования).
Объектные модели описывают сущности и отношения
между ними. Каждый блок отражает тип объекта. Верхняя
часть блока используется для названия объекта, средняя – для
перечисления его атрибутов, в нижней части блока приводятся
методы. Стрелочка (или линия) между двумя блоками отражает
отношение
между
объектами.
Отношения
обычно
подписываются в районе середины стрелочки. Кроме того, на
каждом конце отношения может быть подписана кратность,
показывающая количество допустимых отношений этого типа.
14
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рис. 2.5. Модель сети Петри
Выделяют три основных вида отношений: наследование,
агрегирование и ассоциацию. Отношение наследования
(inheritance) указывает на то, что объект, расположенный у
«оперения» стрелочки, является частным случаем объекта,
расположенного у «наконечника». Например, в качестве более
абстрактного объекта может выступать транспортное средство, а
в качестве более конкретного – автомобиль, поскольку автомобиль – одно из транспортных средств. Отношение агрегирования (aggregation) указывает на то, что объект, расположенный у
«оперения» стрелочки, является компонентом объекта,
расположенного у другого конца. Например, если объемлющий
объект – автомобиль, то в качестве компонента может выступать
двигатель. Последний тип отношений – это ассоциация
(association). В этом случае отношение указывает на то, что один
из объектов каким-либо образом связан с другим объектом.
Отношение «отец – сын» является примером ассоциации. Ассоциация может быть как односторонней, так и двусторонней.
Для описания объектных моделей чаще всего используются
обозначения, соответствующие стандарту унифицированного
языка моделирования (Unified Modeling Language, UML).
Пример 2.6. Нарисуйте объектную модель обычной библиотеки. В модели, представленной на рис. 2.6, в качестве объектов
15
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
используются «библиотека», «книга», «экземпляр книги» и
«читатель».
Методы объектов не представлены на диаграмме. Объект
«библиотека» связан с объектами «книга» и «читатель»
отношением агрегирования, то есть библиотека объединяет в
себе читателей и книги. Отношение между объектами «книга» и
«экземпляр» не является ни агрегацией, ни наследованием.
Объект «книга» представляет собой абстракцию книги (название, автор, год издания и прочее), тогда как «экземпляр» – это
физический предмет, который был взят читателем в
библиотеке. Отношение между «читателем» и «экземпляром»
называется «получение». Со стороны «экземпляра» читатель
выполняет роль «взявшего», а со стороны «читателя» книга
выполняет роль «взятого». Кратность (0..1) указывает на то, что
«экземпляр» может быть не выдан вовсе или получен только
одним читателем. Кратность (0..*) свидетельствует о том, что
читатель за один раз может «взять» как несколько книг, так и
ни одной.
Пример 2.7. Составьте объектную модель генеалогического
древа, содержащего информацию о членах семьи.
Модель (рис. 2.7) показывает, что каждый имеет родительскую семью. В каждом браке имеется человек-отец и
человек-мать. На диаграмме не представлены методы объектов и
некоторые атрибуты.
16
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рис. 2.6. Объектная модель библиотеки
Рис. 2.7. Объектная модель генеалогического древа
2.4.1. Зависимость по существованию
Можно уточнить отношения между объектами посредством
ввода дополнительного типа отношений, называемого зависимостью по существованию (existence dependency, ED). Отношение зависимости по существованию возникает между классами объектов
при одновременном выполнении двух условий: экземпляры
младшего (зависимого, дочернего) класса могут существовать
только при существовании экземпляра старшего (родительского)
класса (1), каждый экземпляр дочернего класса ассоциирован с
единственным экземпляром родительского класса (2).
Пример 2.8. Составьте объектную модель библиотеки,
используя отношение типа «зависимость по существованию».
В модели, представленной на рис. 2.6, все отношения, кроме
«займа» и отношения «библиотека – книга», удовлетворяют
требованиям, предъявляемым к зависимости по существованию.
Отношение «получение» не удовлетворяет требованиям, так как
объект «экземпляр» существует до появления объекта «читатель». Однако может быть создан объект «получение», удовлетворяющий отношению зависимости по существованию. Объект
«книга» не может быть дочерним по отношению к объекту
«библиотека», так как книги существуют сами по себе, вне
зависимости от библиотеки. Также в диаграмму, представленную
17
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
на рис. 2.8, добавлен объект «человек», который подчеркивает,
что часть объекта «читатель» не имеет зависимости по
существованию с объектом «библиотека».
Рис. 2.8. Объектная модель библиотеки с использованием
зависимости по существованию
2.4.2. Диаграммы экземпляров
На диаграммах объектов отображаются типы объектов (классы). То есть блок «автомобиль» описывает атрибуты и функции
всех экземпляров автомобилей. Отношения между экземплярами
объектов на объектной диаграмме не всегда очевидны. На диаграмме экземпляров (instance diagram) отражается возможное сочетание экземпляров объектов, что может помочь уточнить отношения между ними.
Пример 2.9. Нарисуйте диаграмму экземпляров семьи,
состоящей из Фреда, его жены Сью, их детей – Билла, Тома и
Мэри, и родителей Фреда – Майка и Джин (см. рис. 2.9).
18
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рис. 2.9. Диаграмма экземпляров для семейного древа Фреда
2.5. Диаграммы вариантов использования
Диаграмма вариантов использования (use case diagram) – одна из диаграмм унифицированного языка моделирования (Unified
Modeling Language, UML). На ней отображаются деятели и функции системы. Деятели изображаются человечками, а функции –
овалами. Деятели связываются с выполняемыми ими функциями.
Пример 2.10. Нарисуйте диаграмму вариантов использования для библиотеки (см. рис. 2.10).
Рис. 2.10. Диаграмма вариантов использования для библиотеки
19
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Функции в овалах – это методы классов объектной модели.
Объект «читатель» может «взять книгу» из библиотеки и «вернуть» ее. Деятель «библиотекарь» никак не был отражен в
объектной модели (рис. 2.6), а в рассматриваемой диаграмме с
его помощью показывается, что некоторые функции, к примеру
«поиск книги в каталоге» и «поиск книги на стеллажах», недоступны «читателю».
2.6. Сценарии
Сценарий (scenario) – описание одной из возможных последовательностей действий, которая может произойти в данной
предметной области.
Пример 2.11. Напишите сценарий для библиотеки.
Фред – «читатель» – идет в библиотеку и берет книгу. Спустя
два месяца он возвращает книгу с просроченным сроком сдачи в
библиотеку.
2.7. Диаграммы последовательности
Диаграммы последовательности (sequence diagram) относятся к диаграммам унифицированного языка моделирования,
вертикальные линии на которой отражают экземпляры классов.
Каждая такая вертикальная линия подписывается сверху.
Надпись состоит из названия класса и названия конкретного
экземпляра класса, разделенных между собой двоеточием. К
примеру, линия (рис. 2.11) обозначена как «читатель:Фред», где
«читатель» – это название класса, а «Фред» соответствует
названию экземпляра данного класса. Горизонтальные стрелки
соответствуют вызовам функций, при этом их направление
показывает, из какого класса в какой сделан вызов. Название
функции подписывается над стрелкой, а продолжительность
выполнения отображается в виде широкого блока на
вертикальной линии. Возвраты из функций обычно на диаграмму
не наносятся, а многократные вызовы одной и той же функции
показываются в виде одной стрелки.
Пример 2.12. Нарисуйте диаграмму последовательности для
сценария в примере 2.11 (см. рис. 2.11).
20
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рис. 2.11. Диаграмма последовательности для сценария библиотеки
Эта диаграмма намного более точно соответствует этапу
проектирования, нежели модель, приведенная в примере 2.8.
Здесь представлены функции, которые не были отражены в
предыдущих объектных моделях. Кроме того, последовательность вызовов, изображенная на диаграмме, зависит от конкретного исполнения проекта.
2.8. Иерархические диаграммы
Иерархические диаграммы (hierarchy diagrams) показывают
структуру вызовов в системе. Каждый блок на диаграмме
соответствует функции. Если блоки соединены между собой
линией, то это означает, что одна из функций вызвала другую.
При этом все подобные вызовы отражаются на диаграмме.
Иерархические диаграммы не относятся к диаграммам
унифицированного языка моделирования и обычно не используются в объектно ориентированном программировании. Тем не
менее они могут быть очень полезны для понимания динамической структуры системы.
21
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Пример 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;
22
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
На рис. 2.13 узел «a» отражает
первые две строки кода и условие,
стоящее в первом операторе if.
Стоящая в этом операторе инструкция «type = равнобедренный»
выполняется
в
узле
«равнобедренный». Аналогично,
узел «c» отражает условие
следующего оператора if, а узел
«равносторонний» – инструкцию
этого условного оператора.
Рис. 2.13. Граф потока управления
для программы «Треугольник»
2.10. Диаграммы состояний
Состояние автомата или программы – это совокупность всех
возможных значений переменных, регистров и т. д. На диаграмме состояний (state diagram) указываются как состояния
системы, так и возможные переходы между ними. Количество
таких возможных состояний огромно. Существуют подмножества
состояний, в которых автомат ведет себя похожим образом.
Такие подмножества можно объединять в группы и заменять
единственным обобщенным состоянием. Многие программы
удобно описывать именно при помощи диаграмм состояний.
Правила построения диаграммы состояний следующие:
– должно быть задано единственное начальное состояние;
– из начального состояния должен быть возможен переход в
любое другое;
– из любого состояния должен быть возможен переход в
конечное состояние;
– любому переходу между состояниями должно соответствовать некоторое событие, вызывающее этот переход, и это событие также должно быть отражено на диаграмме.
Пример 2.15. Нарисуйте
диаграмму
состояний
стека
фиксированного размера (см. рис. 2.14).
23
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рис. 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;
}
В приведенном коде можно выделить два состояния, в
которых поведение функции различно. Заметим, что начальное
24
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
значение переменной stackindex равно нулю. Первое состояние
связано с условием «stackindex == MAX», а второе – с условием
«stackindex != max». Анализ приращения переменной показывает, что второе состояние соответствует (для данного метода)
условию «stackindex < MAX». Анализ процедуры «pop» выявит
также пустое состояние стека.
2.11. Решетчатые модели
Решеткой (lattice) называется математическая структура,
отражающая отношения между множествами. При разработке
программного обеспечения решетки используют нечасто, однако
они применяются для анализа взаимосвязей между множествами
функций и атрибутов.
Пример 2.18. Нарисуйте решетчатую модель стека (см.
рис. 2.16), содержащую атрибуты (массив параметров (s-array),
индекс вершины стека (index)) и функции («push», «pop», «val»
(возвращает верхнее значение) и «depth»).
Верхний узел содержит полное множество всех атрибутов,
нижний узел – пустое множество. Узлы подписываются в
соответствии с названиями функций, которые используют данное
подмножество атрибутов.
Рис. 2.16. Решетчатая модель стека
25
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Вопросы к части 2
1. В чем отличие между моделью жизненного цикла программного обеспечения и моделью процесса?
2. В чем отличие между описывающей и предписывающей
моделью процесса?
3. Почему точки принятия решений более характерны для
предписывающих моделей процесса, нежели для описывающих
моделей?
4. Почему задачи в модели процесса должны быть отделены
артефактами?
5. Почему задача в модели процесса не может быть запущена
до тех пор, пока не сформированы входные артефакты?
6. Почему в модели процесса обязательно должны быть пути от
начального узла до любого другого и от любого узла до конечного?
7. Каким образом в примере 2.3 можно отличить «отчет о
тестировании» после тестирования всех модулей от «отчета о
тестировании» после тестирования единственного модуля?
8. Как на диаграмме потока данных отражается поток управления?
9. При каких условиях срабатывает узел события в сети Петри?
10. Что происходит, когда срабатывает узел события в сети Петри?
11. В чем отличие между предметной областью и пространством
решения?
12. Как изменяется объектная модель от этапа постановки требований до этапа проектирования?
13. Определите тип отношений (наследование, агрегирование,
ассоциация) в парах.
Автомобиль – автомобиль марки Линкольн; человек – студент;
библиотека – читатель; книга – экземпляр; автомобиль – водитель;
читатель – библиотечная книга; группа – студенты.
14. Определите, относятся приведенные ниже выражения к
названию класса или к названию экземпляра класса:
Мой автомобиль; человек; Фред; транспортное средство;
профессор; информационный отдел.
26
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
15. Какова взаимосвязь между сценарием и диаграммой состояний,
показывающей все возможные последовательности действий?
16. Как направлена стрелка между классами на диаграмме
взаимодействия?
17. Объясните, почему отношение агрегирования относится к
предметной области, а не к области реализации (программному
коду).
18. Почему на диаграммах потока данных не отражаются
правила, по которым из одного узла можно достигнуть другого?
Задания к части 2
1. Нарисуйте модель процесса к задаче покраски стен в
комнате. Рассмотрите следующие подзадачи: выбор цвета, покупка краски, очистка стен, подготовка краски, покраска стен.
2. Преподаватель использует интерактивные занятия для дистанционного обучения студентов. Все студенты разделены на
команды, задание для каждой команды публикуется на Web-странице. При выполнении задания команда использует чат для внутреннего общения, консультируется с инструктором через онлайнфорум и высылает полученные результаты по электронной почте.
Инструктор оценивает выполнение задания и выставляет оценки
в ведомость. Нарисуйте модель процесса интерактивных занятий.
3. Нарисуйте диаграмму потока данных для библиотеки.
4. Нарисуйте диаграмму потока данных для фабрики.
5. Нарисуйте диаграмму потока данных для продовольственного магазина.
6. Нарисуйте объектную модель бинарного дерева.
7. Нарисуйте диаграмму экземпляров для объектной модели
бинарного дерева.
8. Нарисуйте
объектную
модель
продовольственного
магазина.
9. Нарисуйте объектную модель фабрики.
10. Напишите дополнительный сценарий к примеру 2.11,
содержащий действия читателя по выбору книги.
11. Нарисуйте диаграмму состояния графического интерфейса пользователя, имеющего главное меню, файловое меню с
27
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
командами «открыть файл» и «выход». При этом учтите, что в
процессе работы открытым может быть только один файл.
12. Дополните объектную модель библиотеки на рис. 2.17,
включив в нее возможность зарезервировать книгу читателем в
случае, если все экземпляры уже выданы.
13. Постройте конечный автомат для библиотеки с
возможностью резервирования книг.
Ответы на вопросы к части 2
1. Модель жизненного цикла
программного обеспечения
отражает основные этапы и
результаты, тогда как модель процесса описывает задачи нижнего уровня, необходимые и созданные артефакты, а также деятелей,
ответственных за каждую из
задач.
Рис. 2.17.
библиотеки
Объектная
модель
2. Описывающая модель отражает то, что происходит при
разработке ПО. Обычно она разрабатывается в результате
постанализа проекта. Предписывающая модель указывает на то,
что должно быть сделано при разработке программного обеспечения, включая действия при возникновении ошибок.
3. Принятие решений более характерно для предписывающих
моделей, так как в них обычно указываются действия в альтернативной ситуации. В описывающих моделях обычно изображается то, что уже произошло, и альтернативные ситуации в них
обычно не включаются.
4. Если один процесс следует за другим, то выходная информация или документ первого процесса, требуются для работы
второго. Если это не так, то процессы независимы и нет необходимости соблюдать их очередность.
28
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
5. Если второй процесс зависит от выходной информации
первого процесса, то второй процесс не может быть запущен до
тех пор, пока не завершится первый. Если это не так, то возможно параллельное выполнения процессов.
6. Если в модели процесса не существует пути от начального
узла до любого другого, то, следовательно, этот узел недостижим
и может быть исключен. Если нет пути от текущего узла к конечному, то в модели присутствует бесконечный цикл. Обе эти ситуации нежелательны и должны быть исключены.
7. Подпись над стрелкой «результаты тестирования» указывает
на то, что получено несколько результатов тестирования. Таким
образом, подразумевается, что отчет о тестировании был сформирован на основе тестирования нескольких программных модулей.
8. На диаграмме потока данных не указывается поток исполнения. По диаграмме потока данных можно судить о примерной
очередности исполнения, но не более того.
9. В сети Петри срабатывание узла события происходит тогда,
когда все его входные узлы оказываются промаркированными.
10. Маркируется каждый выходной узел стартового состояния.
11. Предметная область – часть материального мира, состоящая из существующих в нем объектов. Пространство решения
состоит из модулей программного обеспечения, обеспечивающих
решение задачи.
12. Изначально объектами являются сущности предметной
области. При переходе к этапу проектирования объекты превращаются в сущности пространства решения.
13. Отношения и их виды:
Автомобиль – автомобиль марки Линкольн
Человек – студент
Библиотека – читатель
Книга – экземпляр
Автомобиль – водитель
Читатель – библиотечная книга
Группа – студенты
Наследование
Наследование
Агрегирование
Общая ассоциация
Общая ассоциация
Общая ассоциация
Агрегирование
14. Выражения и их отношения к классам и к экземплярам:
29
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Мой автомобиль
Человек
Фред
Транспортное средство
Профессор
Информационный отдел
Экземпляр
Класс
Экземпляр
Класс
Класс
Экземпляр
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. а) Фред приходит в библиотеку и не находит подходящую
книгу; б) Фред приходит в библиотеку и забирает две книги. Затем он
еще раз приходит в библиотеку и забирает еще три книги. Последние
три книги он возвращает вовремя. Первые две книги он возвращает с
опозданием.
30
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рис. 2.18. Модель процесса покраски стен
а)
31
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
б)
Рис. 2.19. Модель процесса интерактивного занятия:
а) подготовка; б) выполнение заданий
Рис. 2.20. Диаграмма потока данных библиотеки
Рис. 2.21. Диаграмма потока данных фабрики
32
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рис. 2.22. Диаграмма потока данных продовольственного магазина
Рис. 2.23. Объектная модель бинарного дерева
Рис. 2.24. Диаграмма реализации бинарного дерева
33
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рис. 2.25. Объектная модель супермаркета
Рис. 2.26. Объектная модель фабрики
11. См. рис. 2.27. Отметим, что хотя команда «закрыть файл»
не была явно указана в задании, необходим выход из состояния
«открытый файл».
Рис. 2.27. Диаграмма состояний графического интерфейса пользователя
34
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
12. См. рис. 2.28.
Рис. 2.28. Объектная модель библиотеки
13. См. рис. 2.29.
Рис. 2.29. Конечный автомат для библиотеки
35
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Часть 3. Управление программным проектом
3.1. Введение
Управление программным проектом включает в себя
планирование, направление, мотивирование и координирование
группы разработчиков. В управлении программными проектами
используется множество подходов общего менеджмента, однако
присутствуют и специфические для разработки ПО (например,
обозреваемость проекта).
Управление программным проектом затруднено, поскольку довольно тяжело судить о степени готовности объекта, который невозможно окинуть взором. Во множестве других областей судить о
готовности продукта значительно легче. Множество программных
проектов застывает на 90% выполнения и не может сдвинуться
дальше. Множество техник управления программными проектами
направлены на преодоление трудностей с обозреваемостью.
3.2. Подходы к управлению
При управлении программным проектом важно определить
объект управления – процесс или проект. При процесс-ориентированном управлении основное внимание уделяется управлению
небольшими задачами в жизненном цикле ПО. При проекториентированном управлении основное внимание акцентируется
на команде разработчиков проекта. Это очень разнящиеся точки
зрения. В процесс-ориентированном подходе если команда не
работает в соответствии с предписаным жизненным циклом ПО,
то это может вызвать большие трудности. При проекториентированном подходе успех или провал проекта полностью
зависит от качеств команды разработчиков.
3.3. Командные подходы
Организация группы людей в эффективную команду – весьма
сложная задача. Рискованно позволять команде разрабатывать
свой собственный способ взаимодействия. Выбор правильной
организации в команде, основанной на проекте и участниках
проекта, повышает шансы успешного выполнения проекта.
36
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Один из важных аспектов – степень структурированности
команды. Некоторые группы программистов могут работать при
слабой внутренней организации, другим группам необходима строгая структурированность для достижения результатов. Как
правило, чем сильнее структурирована команда, тем меньшие по
объему (и времени выполнения) задания даются участникам. В
слабо структурированных командах задачи обычно более крупные.
Команда может состоять из профессионалов примерно одинаковой квалификации, с примерно одинаковым набором знаний и
умений. Такие команды обычно не распадаются и существуют на
протяжении множества проектов. Другие команды формируются
«под проект» из разноплановых специалистов. Такой подход
называется матричной организацией (matrix organization).
3.3.1. Группы программистов, ориентированные на
руководителя
Компанией IBM была предложена концепция команды под
руководством главного программиста, в которой отдельным
членам группы приписываются различные роли. Руководителем
команды является наиболее квалифицированный программист.
Ведение документации проекта и делопроизводство возлагаются
на членов команды непрограммистов. Младшие программисты
курируются руководителем команды.
Пример 3.1. Нарисуйте высокоуровневую модель процесса
для иерархической организации команды.
Рис. 3.1. Высокоуровневая модель процесса
для иерархической организации команды
37
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Пример 3.2. В отделе информационных технологий работает
несколько опытных разработчиков программного обеспечения и
много новых программистов. Руководитель решил разделить
сотрудников на команды, каждая из которых должна возглавляться опытным разработчиком программного обеспечения. Каждый член команды будет еженедельно получать определенные
задания, за выполнением которых следит руководитель группы,
который также отвечает за распределение новых заданий.
3.4. Важные процессы
В результате многочисленных исследований был определен
ряд процессов, наиболее важных для достижения результата –
разработки ПО. Среди них можно отметить: непрерывное управление рисками; эмпирические планирование и оценка затрат;
использование специальных метрик в управления проектом;
отслеживание освоенных объемов; отслеживание выявления
дефектов; особое внимание к человеческому ресурсу; использование системы контроля версий; управление требованиями и
отслеживание изменений требований; использование системного
подхода при проектировании ПО; обеспечение совместимости
данных; определение интерфейсов; «дважды спроектируй, один
раз закодируй»; оценка рисков и затрат; проверка выполнения
требований и проектных решений; непрерывное тестирование;
частая компиляция и запуск «дымовых тестов».
Пример 3.3. Руководителю
отдела
информационных
технологий компании «WRT» потребовалось разработать процесс
разработки ПО для организации работы неопытных разработчиков ПО и успешного выполнения проекта.
1. Непрерывное управление рисками.
Включение в жизненный цикл ПО шагов, на которых
определяются и оцениваются возможные риски. Также
вводятся задачи, позволяющие снижать риски.
2. Эмпирические планирование и оценка затрат.
Себестоимость проекта оценивается на начальном этапе
жизненного цикла ПО. В процессе развития проекта осуществляются множественные повторные оценки затрат. На основе
полученных оценок формируется прогноз стоимости.
38
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
3. Использование специальных метрик в управлении проектом.
Руководитель выбирает метрики, позволяющие оценить
развитие проекта. В жизненный процесс вводятся шаги для вычисления метрик и определения степени завершенности проекта
по этим данным.
4. Оценка освоенных объемов.
На разных этапах производится оценка освоенных объемов и
определение фактических затрат.
5. Отслеживание выявления дефектов.
Управляющий определяет цели по количеству найденных
дефектов. В жизненный цикл включаются шаги по созданию
отчетов о дефектах.
6. Особое внимание к человеческому ресурсу.
Оценивается влияние процесса разработки ПО на программистов.
7. Использование системы контроля версий.
Руководитель включает в процесс использование системы
контроля версий для всех документов. В жизненный цикл включаются шаги по внесению всех документов и изменений к ним в
систему контроля версий.
8. Управление требованиями и отслеживание изменений
требований.
Включение в жизненный цикл шагов по получению требований от пользователя и шагов по отслеживанию каждого
требования вплоть до финальной стадии разработки.
9. Использование системного подхода при проектировании ПО.
Руководитель включает шаги, обеспечивающие использование системного подхода.
10. Обеспечение совместимости данных.
Руководитель включает шаги по проверке совместимости
данных.
11. Определение интерфейсов.
В процессе разработки определяются интерфейсы, а также
осуществляется их проверка.
12. «Дважды спроектируй, один раз закодируй».
Руководитель включает шаги по анализу принятых проектных решений.
39
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
13. Оценка рисков и затрат.
Включаются шаги по определению потенциальных рисков.
14. Проверка выполнения требований и проектных решений.
Руководитель включает в жизненную модель шаги по
проверке выполнения требований и проектных решений.
15. Непрерывное тестирование.
Руководитель включает в этап реализации шаги для частого
тестирования.
3.5. Модель зрелости процесса создания ПО
Модель зрелости процесса создания программного обеспечения была разработана институтом программной инженерии.
Модель SE-CMM (Software Engineering Capability Maturity Model)
используется для оценки процесса разработки ПО в организации.
В соответствии с моделью процессы и организации можно
классифицировать по уровням развития:
1. Начальный уровень. Самый нижний уровень модели,
обычно характеризуется как хаотический.
2. Уровень повторяемости. На данном уровне осуществляется планирование, оценка затрат и функциональных возможностей. Возможно повторение ранее достигнутых успехов.
3. Уровень
регламентирования.
На
данном
уровне
регламентируется процесс разработки ПО: проводится
документирование и стандартизация. Развитие проекта
осуществляется с использованием стандартных процессов.
4. Уровень управляемости. На уровне управляемости
осуществляется количественный контроль как процессов,
выполняемых в ходе разработки, так и их результатов.
5. Уровень оптимизации. На данном уровне количественная
информация используется для непрерывного улучшения и
управления процессом разработки.
Большинство организаций изначально находятся на первом
уровне модели. Для перехода к верхним уровням модели CMM
компанией должен быть произведен ряд управленческих действий. Лишь небольшому количеству компаний удается достичь
пятого уровня.
40
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
3.6. Индивидуальный процесс разработки ПО
Индивидуальный процесс разработки ПО (Personal Software
Process, PSP) был предложен Уотсом Хэмфри с целью повышения квалификации индивидуальных разработчиков программного
обеспечения. В рамках предложенного подхода для определения
уровня персональных навыков ведется индивидуальная
статистика, которая, в частности, позволяет оценить производительность разработчика. Обычно мерой производительности
является количество строчек кода, написанных программистом за
день (lines of code/day, LOC/day,); также дополнительно регистрируются обнаруженные ошибки. Все это позволяет оценить
различные техники разработки ПО в терминах их влияния на
продуктивность и уровень ошибок. Кроме того, оценка
продуктивности может использоваться в качестве меры эффективности составленного плана разработки.
Пример 3.4. Индивидуальная
статистика
работы
программиста:
Дата
Начало
01.01.2010
03.01.2010
04.01.2010
–
09:00
09:00
09:00
12:00
Завершение
15:30
14:00
11:30
14:00
Перерыв
30 мин
30 мин
–
–
Общее
время
360 мин
270 мин
150 мин
120 мин
Задание
50 LOC
60 LOC
50 LOC
Тестирование
Программист
затратил
в
общей
сложности
360+270+150+120=900 минут (15 часов) на написание и тестирование программы, состоящей из 160 строк кода. Если принять
продолжительность рабочего дня равной 5 часам, то получается,
что программист работал 3 полных дня, то есть его производительность составляет 53 строки кода/день. Таким образом, на
выполнение проекта объемом в 1000 строк кода, программисту
потребуется примерно 4 недели.
41
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
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,
42
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
где 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
2
3
4
5
6
Планируемое
количество
человеко-дней на
выполнение
5
25
120
40
60
80
Фактическое
количество
человеко-дней
Планируемая дата
завершения
Фактическая
дата
завершения
10
20
80
50
50
70
25.01.2010
15.02.2010
15.05.2010
15.04.2010
01.07.2010
01.09.2010
01.02.2010
15.02.2010
01.04.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), то есть план перевыполнен на
43
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
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 – их уро44
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
вень. В точке пересечения графика с осью 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 ошибки.
0.35
Количество ошибок
0.3
0.25
0.2
0.15
0.1
0.05
0
1
2
3
5
4
Уровень ошибок
6
7
8
Рис. 3.2. Уровень ошибок в ПО
3.9. Постанализ проекта
Важной задачей при разработке ПО является проведение
постанализа, по которому можно судить о плюсах и минусах
текущего процесса разработки. В постанализе участвуют ключевые разработчики и представители групп пользователей. Работа
45
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
по постанализу должна заканчиваться формальным отчетом,
который рассылается всем заинтересованным лицам.
Пример 3.8. В таблице приведен отчет компании по
результатам постанализа.
Название
проекта
Проект X
Объем проекта
Начало – 5 сентября 2010 г.
Завершение – 8 декабря 2010 г.
Оцененный
объем
Действительный
объем
Оцененные
затраты
Действительные
затраты
3 000 LOC
5 000 LOC
12 000 мин
10 000 мин
Субъективный
комментарий по
оценке проекта
Удовлетворительно
Время выполнения было оценено
достаточно точно
Неудовлетворительно
Неточная оценка объема проекта
Субъективный
комментарий по
процессу
Удовлетворительно
Неудовлетворительно
Невыполнение задания членами
команды в срок
Субъективный
комментарий по
планированию
Удовлетворительно
Неудовлетворительно
Недостаточно времени
для выполнения
Качество
Субъективная
оценка качества
Количество найденных ошибок
Выявление требований
Проектирование
Модульное
тестирование
Интеграционное
3
тестирование
0
Распространение
Удовлетворительно
mccabe
Метод/класс
Свойства/класс
LOC/класс
макс.
30
10
15
500
Неудовлетворительно
Тестирование системы не было
произведено должным образом
Проблема:
Неясность
исходных
требований
Описание:
Влияние:
Формат входного файла был Дополнительно
неверным
2 недели
Проблема:
Описание:
Влияние:
Проблема:
Описание:
Влияние:
46
средн.
4
6
10
150
потрачено
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Вопросы к части 3
1. Что понимается под обозреваемостью проекта?
2. В чем разница между проект-ориентированным и процессориентированным подходом?
3. Какой подход является предпочтительным при управлении
новым проектом, кардинальным образом отличающимся от всех
предыдущих?
4. В чем преимущество дробления проекта на небольшие
подзадачи?
5. Какой индикатор освоенных объемов может уменьшаться
во время выполнения проекта?
6. Для каких индикаторов состояния проекта значение,
превышающее единицу, считается хорошим?
7. В чем преимущество использования метрик, обратных SPI
и CPI?
Задания к части 3
1. Нарисуйте модель процесса для слабоструктурированной команды. Модель должна базироваться на обсуждении решений, влияющих на управление проектом и решение сложившихся проблем.
2. Используя приведенную ниже статистику работы, оцените
производительность программиста (в LOC/день), если общий объем проекта №1 составляет 120 LOC, а проекта № 2 – 80 LOC (продолжительность одного рабочего человеко-дня считается равной
400 мин).
Дата
01.02.2010
02.02.2010
05.02.2010
06.02.2010
Начало
08:30
09:00
09:00
07:30
Завершение
16:30
17:00
17:30
12:00
Перерыв
60 мин
30 мин
90 мин
–
Задание
Проект 1
Проект 1
Проект 2
Проект 2
3. Используя таблицу, приведенную ниже, оцените значение
всех основных метрик и индикаторов состояния. Оцените,
соблюдается ли план работ, если текущая дата – 01.05.2010 г.
47
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
№
1
2
3
4
5
6
Планируемое
количество
человеко-дней на
выполнение
50
35
20
40
60
80
Фактическое
количество
человеко-дней
Планируемая дата
завершения
Фактическая дата
завершения
70
20
40
40
10
20
15.01.2010
15.02.2010
25.02.2010
15.04.2010
01.06.2010
01.07.2010
01.02.2010
15.02.2010
01.03.2010
01.04.2010
4. Используя таблицу, приведенную ниже, рассчитайте
значение PV и индикаторов состояния развития проекта через
каждые полмесяца (с 1 января по 1 сентября).
№
1
2
3
4
5
6
7
8
9
10
11
Планируемое
количество
человеко-дней на
выполнение
30
25
30
50
60
35
55
30
45
25
45
Фактическое
количество
человеко-дней
Планируемая дата
завершения
Фактическая дата
завершения
37
24
41
47
63
31
58
28
43
29
49
01.01.2010
15.02.2010
01.03.2010
15.04.2010
01.05.2010
15.05.2010
01.06.2010
15.06.2010
01.07.2010
01.08.2010
15.08.2010
01.02.2010
15.02.2010
15.03.2010
01.04.2010
15.04.2010
01.06.2010
01.06.2010
15.06.2010
15.07.2010
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.
Определите, соблюдается ли расписание. Обоснуйте свой ответ.
48
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
№
1
2
3
4
Планируемое
количество
человеко-дней на
выполнение
30
20
50
100
Фактическое
количество
человеко-дней
PV
10
30
30
5
Планируемая дата
завершения
Состояние
задачи
1 февраля
1 марта
1 мая
1 июня
Выполнено
Выполнено
Ответы на вопросы к части 3
1. Под обозреваемостью понимают свойство проекта, которое
заключается в возможности отслеживать прогресс (или его
отсутствие).
2. Процесс-ориентированный подход подобен конвейеру, где
каждый работник выполняет определенное задание. Разработчики могут выполнять одно и одинаковые задачи по нескольким
проектам. При проект-ориентированном подходе команда отвечает за развитие проекта в целом.
3. Использование процесс-ориентированного подхода требует глубокого понимания проекта. Для нового (отличного от
других) проекта предпочтительным является проект-ориентированный подход.
4. Дробление проекта на небольшие задачи приводит к более
жесткой структуре контроля. Руководитель быстрее осознает, что
проект отклоняется от плана.
5. В процессе разработки все индикаторы состояния проекта
за исключением освоенного объема (EV) должны уменьшаться.
6. Если значение индикаторов SPI и SV больше 1, это означает, что выполненный объем работ превышает запланированный. Если значение CPI и CV больше 1, то фактические затраты
на выполнение проекта ниже запланированных. Таким образом,
при работе над проектом желательно, чтобы значение всех четырех индикаторов было больше 1.
7. Величины, обратные SPI и CPI, могут использоваться при
планировании проекта. Так, если величина, обратная SPI, равна 2,
то время выполнения проекта в 2 раза превысит запланированное.
Если значение величины, обратной CPI, равно 2, то затраты на
проект в два раза превысят запланированные.
49
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Ответы на задания к части 3
1. См. рис. 3.3; 2. Рассчитаем время работы в течение
каждого дня: 1) (16:30-8:30)∙60 – 60 = 420 мин; 2) (17:009: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
Таким образом, проект исполняется в соответствии с расписанием, однако суммарные затраты превышают запланированные.
50
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
4. Значения основных метрик для приведенного проекта:
1
2
3
4
5
6
7
8
9
10
11
BCW
30
25
30
50
60
35
55
30
45
25
45
PV
0,070
0,058
0,070
0,116
0,140
0,081
0,128
0,070
0,105
0,058
0,105
ACW
37
24
41
47
63
31
58
28
43
29
49
Планируемая дата
01.01.2010
15.02.2010
01.03.2010
15.04.2010
01.05.2010
15.05.2010
01.06.2010
15.06.2010
01.07.2010
01.08.2010
15.08.2010
Фактическая дата
01.02.2010
15.02.2010
15.03.2010
01.04.2010
15.04.2010
01.06.2010
01.06.2010
15.06.2010
15.07.2010
15.08.2010
01.09.2010
BAC = 430.
Рассчитаем
полмесяца:
Дата
01.01.2010
15.01.2010
01.02.2010
15.02.2010
01.03.2010
15.03.2010
01.04.2010
15.04.2010
01.05.2010
15.05.2010
01.06.2010
15.06.2010
01.07.2010
15.07.2010
01.08.2010
15.08.2010
01.09.2010
BCWS
30
30
30
55
85
85
85
135
195
230
285
315
360
360
385
430
430
значение
BCWP
0
0
30
55
55
85
135
195
195
195
285
315
315
360
360
385
430
основных
ACWP
0
0
37
61
61
102
149
212
212
212
301
329
329
372
372
401
450
EV
0,00
0,00
0,07
0,13
0,13
0,20
0,31
0,45
0,45
0,45
0,66
0,73
0,73
0,84
0,84
0,90
1,00
метрик
SPI
0,00
0,00
1,00
1,00
0,65
1,00
1,59
1,44
1,00
0,85
1,00
1,00
0,88
1,00
0,94
0,90
1,00
SV
-30
-30
0
0
-30
0
50
60
0
-35
0
0
-45
0
-25
-45
0
через
CPI
0,00
0,00
0,81
0,90
0,90
0,83
0,91
0,92
0,92
0,92
0,95
0,96
0,96
0,97
0,97
0,96
0,96
каждые
CV
0
0
-7
-6
-6
-17
-14
-17
-17
-17
-16
-14
-14
-12
-12
-16
-20
5. Пусть одна домашняя работа проверяется преподавателем
за 1 единицу времени, тогда проверка экзаменационной работы
занимает 3 единицы времени. Общее время проверки всех работ
51
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
составляет ∙1 40 + 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).
0.25
Уровень ошибок
0.2
0.15
0.1
0.05
0
1
2
3
4
5
6
7
Количество ошибок
8
9
10
Рис. 3.4. Зависимость уровня ошибок от количества ошибок
52
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
0.25
Уровень ошибок
0.2
0.15
0.1
0.05
0
0
20
40
60
Время
80
100
120
Рис. 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%.
Проект выполняется с перевыполнением плана.
53
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Список литературы
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.
54
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Оглавление
Часть 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
55
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
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
56
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Учебное издание
Апальков Илья Владимирович
Технологии программирования
Методические указания
Редактор, корректор М. В. Никулина
Верстка Е. Л. Шелехова
Подписано в печать 07.06.11. Формат 60×84 1/16.
Бум. офсетная. Гарнитура "Times New Roman".
Усл. печ. л. 3,49. Уч.-изд. л. 2,58.
Тираж 50 экз. Заказ
Оригинал-макет подготовлен
в редакционно-издательском отделе
Ярославского государственного университета
им. П. Г. Демидова.
Отпечатано на ризографе.
Ярославский государственный университет им. П. Г. Демидова.
150000, Ярославль, ул. Советская, 14.
57
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
58
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
И. В. Апальков
Технологии
программирования
59
Документ
Категория
Без категории
Просмотров
27
Размер файла
3 448 Кб
Теги
технология, 1542, программирование, апальков
1/--страниц
Пожаловаться на содержимое документа