...О нас, о горсточке счастливцев, братьев.

Шекспир. Генрих V.

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

♦ Основы: разделы 2.1-2.6.

♦ Детали: разделы 2.7-2.15

♦ Руководство по учебному проекту: План управления проектом для примера проекта Встреча.

♦ Упражнения.

♦ Примеры:.

1) План управления программным проектом (SPMP) для видеоигры Встреча.

2) План контроля качества программного обеспечения (SQAP), часть 2. Вопросы, рассматриваемые в этой главе.

♦ Понимание термина управление проектом.

♦ Организация команды.

♦ Выработка плана управления проектом.

♦ Определение рисков и их устранение.

♦ Оценка затрат на самых ранних стадиях жизненного цикла.

♦ Создание расписания проектов высокого уровня.

♦ Написание Плана управления программным проектом (SPMP).

Основы_.

2.1. Введение в управление проектом.

2.1.1.

Что такое управление проектом?.

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

2.1.2.

Составляющие управления проектом.

Управление проектом охватывает:.

♦ инфраструктуру (организационные моменты);.

♦ управляющий процесс (права и ответственности участников);.

♦ процесс разработки (методы, инструменты, языки, документация и поддержка);.

♦ расписание (моменты времени, к которым должны быть представлены выполненные фрагменты работы).

2.1.3. Основные параметры: стоимость, функциональность, качество и расписание.

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

1.

Общая стоимость проекта.

Например, увеличивать расходы.

2.

Возможности продукта.

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

3.

Качество продукта.

Например, увеличивать среднее время наработки на отказ (MTBF).

4.

Длительность проекта.

Например, сократить расписание на 20 % или отложить завершение проекта на один месяц.

Степень контроля над этими четырьмя факторами зависит от проекта. Несмотря на то, что стоимость может быть оговоренной заранее и фиксированной, зачастую существуют различные гибкие варианты. Предположим, что наш заказчик — химик, которому необходима визуализация молекул в 2В-графике. После просмотра прототипа молекулярной модели в трехмерной графике заказчик может положительно отнестись к дополнительным расходам, поскольку 3D-np0T0Tim выглядит намного лучше, чем двумерный. Возможности продукта также не являются фиксированными, как это может показаться сначала. Например, заказчик может отказаться от некоторого требования, если это сократит длительность проекта на 15 %. Хотя это может показаться ерундой, но даже показатели качества могут варьироваться. Если целевые значения показателей качества установлены слишком низко, это может привести к увеличению расходов на переделки из-за неудовлетворенности заказчика. Если же целевые значения показателей качества установлены слишком высоко, то затраты на поиски самой последней незначительной ошибки могут оказаться недопустимо высокими. Большинство заказчиков не пожелают платить тройную цену за текстовый процессор только ради того, чтобы получить версию, в которой устранен хорошо известный тривиальный дефект. Дата завершения проекта также может иногда сдвигаться. Например, руководитель может пожелать сдвинуть срок разработки, если продукт обладает столь многообещающими возможностями, что есть шанс завоевать рынок.

Один из способов визуализировать значения данных четырех переменных состоит в использования так называемых лепестковых диаграмм. В диаграммах данного типа значение каждой переменной откладывается на оси, исходящей из центра. Оси рисуются симметрично относительно центра. Конкретный пример лепестковой диаграммы показан на рис. 2.2. Поскольку в данном случае осей четыре, они перпендикулярны. На каждой оси центру соответствует наименее желательное значение показателя, а целевое значение откладывается на некотором расстоянии от центра. Таком образом, получается четырехугольник (если бы показателей было пять, то получился бы пятиугольник, и т. д.). Например, на оси «Возможности» центр соответствует значению «О % требований выполнено», а единица — «100 % требований выполнено». Фактические значения обычно находятся где-то в промежутке, хотя могут и выходить за пределы многоугольника, если удается перекрыть плановые значения показателей. Состояние проекта отражается путем закрашивания многоугольника фактических значений. Чем больше целевой многоугольник заполняется фактическим, тем точнее мы достигаем поставленных целей. Такая визуализация позволяет руководителю проекта правильно расставить приоритеты при принятии решений.

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

2.1.4. Типичная схема процесса управления проектом.

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

1.

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

2.

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

3.

Выделить организационную структуру (привлечение отделов организации) (раздел 2.3).

4.

Определить управляющий процесс (ответственность участников) (раздел 3 примера 1 в конце главы).

5.

Разработать расписание проекта (моменты сдачи частей работы) (раздел 2.6).

6.

Разработать план подбора кадров (раздел 3.5 примера 1 в конце главы).

7.

Начать управление рисками (раздел 2.4).

8.

Определить, какие документы необходимо выработать (раздел 4.2 SQAP).

9.

Начать сам процесс. Описывается в главах 3-10.

К пониманию проекта (1) относится общее представление о целях и задачах, а не сбор всех требований. Последнее является длительным процессом, начинающимся после того, как набросан примерный вариант плана проекта (главы 3 и 4). Мы также должны понять общие возможности и назначение приложения. Банковское приложение может иметь как огромные возможности, например «Автоматизация всех банковских транзакций», так и совсем скромные, например «Сортировка по номеру чека», или нечто промежуточное. Необходимо прикинуть в общих чертах количество трудозатрат и времени на проект (например, два месяца или два года).

Далее (2) требуется принять решение об использовании той или иной модели процесса разработки (водопадной, спиральной, инкрементальной, комбинированной и т. д., раздел 1.4). Затем (3) следует провести общую организацию персонала (выяснить, какие отделы компании будут задействованы в проекте, установить количество команд, определиться с контролем качества). Как только все приготовления будут завершены, можно сосредоточиться на главной задаче для успешного выполнения работы — процессе управления (4). Здесь необходимо будет определить, кто перед кем отчитывается, или задать уровневую структуру типа TSP (представленную в главе 1 и рассматриваемую подробнее в этой главе). Следующий шаг (5) — это создание общего расписания (определяющего, когда что должно быть сделано). После этого можно завершать план подряда, в котором приводится количество персонала, привлекаемого к проекту, и примерное количество человеко-дней для различных задач (например, анализа требований). Этот план не может быть конкретным (например, кто над какой функцией будет работать), так как до сих пор еще не определена архитектура приложения. Проекты практически всегда подвергаются влиянию всяких неприятностей, поэтому определение проекта и управление рисками в проекте (7) необходимо начинать одновременно. Остается подготовить соответствующий набор документов (например, документы SVVP и SRS стандарта IEEE) (8), а затем запустить непосредственно сам проект (9).

2.2. Управление персоналом проекта 2.2.1. Профессионализм.

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

Приобретение программными разработчиками навыков в планировании, составлении графиков работ, проектировании, реализации и тестировании артефактов проходит под тщательным как внутренним, так и внешним контролем. Интерес юристов к проблеме 2000 года является весомым доказательством заинтересованности общественности (то есть присутствием внешнего контроля). Применение метрик является составной частью решения проблемы. Такие авторы, как Хэмфри [55], советуют программным разработчикам не обещать заранее точной даты завершения проекта, а периодически проводить переговоры. В прошлом для разработчиков было проблематично более или менее точно рассчитать для проекта время и трудозатраты. Зачастую для этого просто не хватало инструментальных средств. По мнению автора, ситуация должна измениться. Командный процесс разработки программного обеспечения (TSP), предложенный Хэмфри, является одним из примеров достаточно конкретной процедуры для производства с использованием согласованного набора метрик.

С 1994 по 2000 год объединенная комиссия IEEE и АСМ работала над определением критериев, по которым можно выделить профессиональных разработчиков программного обеспечения.

2.2.2. Важность управления персоналом.

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

Брукс стал знаменитым благодаря своей книге «Мифический человеко-месяц» [18], которая содержит «Закон Брукса». В соответствии с этим законом привлечение большего числа людей в погибающий программный проект не помогает, а может даже и навредить. Другими словами, дополнительные человеко-месяцы, неожиданно появляющиеся в ходе проекта, на самом деле являются мифом. Однако при хорошем управлении дополнительные человеко-месяцы могут оказаться очень полезными.

Книга «Peopleware», написанная Де Марко и Листером [24], является еще одной влиятельной работой в области управления проектами. В ней авторы утверждают, что если бы они могли управлять одними и теми же программными проектами снова и снова (что неосуществимо), то делали бы это каждый раз по-другому. Книга «Peopleware» состоит из коротких эссе, в каждом из которых рассматривается одна из «проторенных дорожек», по которым проходят менеджеры, часто сожалея, что они выбрали этот путь. Обычно к ошибкам в управлении людьми ведет бездумное следование устоявшимся стереотипам и предрассудкам, которые всем известны, затвержены в фольклоре, но зачастую ложны. Например, «Возьмите оценку времени, которую назвал сотрудник, и удвойте ее», «Завинчивайте гайки», «Не позволяйте работать дома»... По наблюдениям автора, все без исключения разработчики хотят, чтобы с ними обращались, как с профессионалами, и делают все возможное, чтобы получить профессиональные результаты.

2.2.3.

Корпоративные аспекты.

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

2.2.4.

Управленческие аспекты.

Говорят, что «не бывает технических провалов, а бывают только провалы в управлении». Хотя это и не совсем правильно, однако напоминает нам о важности управления для успешного завершения деятельности по разработке. Отношение менеджера к своим подчиненным — это смесь делового интереса с интересом работы с людьми, участвующими в проекте. Несмотря на частые опасения коллектива, среднестатистический менеджер старается довести работу до конца так, чтобы при этом у подчиненных не возникало чувство недовольства или неудовлетворенности. Менеджер сам в этом заинтересован, так как недовольные сотрудники работают непродуктивно. Одной из самых трудных задач менеджера является достижение главной цели — выполнения работы при условии получения коллективом удовлетворения от проделанной работы. Например, высшее руководство может поставить условие, что работа должна быть выполнена на старом языке программирования для совместимости версий, хотя программные разработчики хотели бы опробовать новый язык или систему.

Менеджер должен сделать так, чтобы технические изыскания разработчиков имели нужное направление. Начинающие менеджеры зачастую находят довольно сложным лавирование между отданием приказаний и предоставлением свободы разработчикам. Диктатура в управлении может вызвать негодование коллектива и привести к потере мотивации. Однако излишнее попустительство может привести к потере времени и напрасно проделанной работе. Решением данной проблемы является лидерство, выяснение истинных желаний и потребностей людей, активное их распределение и объединение в попытке достижения успеха. Лидеры проекта должны варьировать степень своей ответственности в управлении, основываясь на величине проекта. В больших проектах их обязанности состоят в основном в управлении. В малых же проектах лидеры должны обеспечивать как общее управление, так и личное участие непосредственно в разработке.

2.2.4.1. Организация совещаний.

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

ОДИН ИЗ СПОСОБОВ ПЛАНИРОВАНИЯ И ПРОВЕДЕНИЯ СОВЕЩАНИЯ -.

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

1.

Прикиньте приблизительно время начала, время окончания и повестку совещания.

♦ Сначала перечислите самые важные вопросы.

2.

Подготовьте «рыбу» решений.

3.

Начинайте вовремя.

4.

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

5.

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

6.

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

7.

Следите за временем и завершайте совещание вовремя:.

♦ допускаются исключения в случае важной дискуссии;.

♦ прекращайте лишние дискуссии, делайте перерывы.

8.

Поддерживайте разговор по существу вопроса.

9.

После совещания высылайте электронной почтой основные моменты, принятые на совещании решения и его итоги.

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

Хорошей практикой является предварительная подготовка повестки дня совещания.

ОДИН ИЗ СПОСОБОВ СОЗДАНИЯ ПОВЕСТКИ СОВЕЩАНИЯ -.

1.

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

2.

Найдите добровольцев для:.

♦ записи принимаемых решений и обсуждаемых вопросов;.

♦ слежения за временем и напоминания имен участников совещания.

3.

Отчет о прогрессе проекта в соответствии с расписанием — 10 минут.

4.

Обсудите заготовки артефактов — х минут.

5.

Обсудите меры по снижению риска — 10 минут:.

♦ другие вопросы;.

♦ имеет ли место улучшение метрик и процесса?.

п. Обзор намеченных действий — 5 минут.

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

2.2.5. Человеческий фактор.

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

2.3. Варианты организации персонала.

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

2.3.1. Управление взаимодействием.

Личный опыт автора, да и многих других, показывает, что количество разработчиков, с которыми каждому из разработчиков необходимо регулярно общаться, составляет от трех до семи человек. (Хэмфри [55] предлагает от четырех до восьми человек.) Результаты различных опытов по определению количества членов команды для наиболее эффективной работы сильно разнятся. Экстремальные значения, которые могут быть полезны при определении численности команды, приведены на рис. 2.3. С одной стороны, разработчик может работать без регулярного индивидуального общения с кем бы то ни было. Однако такая изоляция обычно приводит к непониманию разработчиком предъявляемых к нему требований и, как следствие, к относительно низкому уровню эффективности. С другой стороны, разработчик может работать в такой большой команде, что из-за постоянного общения с каждым из коллег у него не останется времени на собственно разработку. Это снова приводит к относительно низкому уровню эффективности. В частности, регулярное общение означает разговор с кем-либо в течение примерно двух часов в неделю. Таким образом, если инженер регулярно общается с десятью своими коллегами, то добрая половина его рабочего времени проходит в разговорах. Организаторы проектов, планирующие проекты с командами в двадцать, а то и в сто человек, обязательно должны учитывать все вышенаписанное.

2.3.2. Варианты структуры ответственности.

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

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

Один из примеров горизонтальной структуры управления приведен на рис. 2.5.

Идея состоит в том, что участники команды равны, за исключением Гила Варнера, который является ответственным за проектирование. В идеале он поощряет участие всех разработчиков в проектировании, но если требуется, принимает решения единолично. Более детально возможная организация команды показана ниже. Если в команде пять участников, то один и тот же участник может быть ответственным за требования и по реализации, поскольку в каждый конкретный момент времени только одно из двух требует повышенной активности. Ответственность за требования можно распределить между всеми, но кто-то конкретно должен отвечать за SRS. Можно меняться ролями примерно раз в три месяца с целью приобретения опыта. Поскольку каждая роль критична, разумно предусмотреть систему подстраховки. Страхующий инженер берет обязанности на себя, если назначенный лидер не может их выполнить по каким-то причинам. Страхующий обязательно инспектирует всю работу страхуемого, чтобы быть в курсе дела.

ОДИН ИЗ СПОСОБОВ ОРГАНИЗОВАТЬ КОМАНДУ -.

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

1.

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

♦ обеспечивать активность всех аспектов проекта;.

♦ восполнять все пробелы.

3.

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

Т лидер команды: предлагает и поддерживает... SPMP;.

Т ответственный за конфигурацию:... SCMP;.

Т ответственный за качество:... SQAP, STP;.

Т отвественный за требования:... SRS;.

Т ответственный за проектирование:... SDD;.

Т Т ответственный за:... программный код.

2.

Обязанности лидера:.

♦ предложить заготовку артефакта (например, SRS, SDD);.

♦ добиться улучшения и принятия командой;.

♦ обеспечить техническую поддержку и инспектирование артефакта;.

♦ поддерживать соответствующие метрики, если нужно.

4.

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

выше.

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

С ростом числа участников проекта организация команды равных становится невозможной, поскольку количество связей по взаимодействию растет квадратично. Действительно, между тремя участниками есть три связи, четыре участника имеют шесть связей, пять человек — десять связей, то есть п человек имеют (п - 1) + (п - 2) + ... + 1 = п (п - 1)/2 связей (каждый с каждым). Таким образом, 100 человек должны участвовать в 4950 взаимодействиях! Для больших проектов альтернативой является схема организации, приведенная на рис. 2.6. В этой схеме команды равных небольшие, но один участник команды выделен для взаимодействия с другими командами. Такая схема сохраняет преимущества небольших команд, но позволяет большому количеству людей создавать большие приложения.

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

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

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

Вообще говоря, системы отчетности на практике имеют более сложную и комплексную структуру, чем в проектно-ориентированных организациях. Это происходит из-за использования матричной структуры. В матричных организациях служащие относятся к функциональным подразделениям (например, отдел разработки, отдел продаж и т. п.) и выделяются этими подразделениями для участия в том или ином проекте (табл. 2.1). Таким образом, начальник программного разработчика, отвечающий за своего подчиненного, будет членом функционального подразделения программной разработки. Однако в каждом проекте, в котором разработчик принимает участие, он подчиняется лидеру проекта. Обычно разработчиков на постоянной основе привлекают не более чем к двум проектам. Например, если бы некая организация, использующая иерархическую организацию проекта (см. рис. 2.4), имела матричную структуру, то Лайл Герберт был бы членом отдела маркетинга. При этом его начальником был бы не Эйприл Смит, а управляющий отдела маркетинга, который консультировался бы с Эйприлом при оценке работы своих подчиненных. Основным достоинством матричных организаций является профессионализм и возможность улучшения навыков. К недостаткам относится нечеткость в линиях субординации. Довольно часто компании стараются найти золотую середину между матричной и проектно-ориентированной структурами.

2.4. Выявление и уменьшение рисков.

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

2.4.1.

Что такое риски.

Риск — это нечто, что может появиться по ходу проекта, и это нечто в худшем случае может негативно повлиять на проект. Промышленные данные демонстрируют огромное количество сорванных программных проектов. Например, Rational Corporation приводит следующий факт: «более 70 % всех программных проектов находятся под угрозой или испытывают серьезные трудности». Факторы, приводящие проект к срыву, на ранних стадиях проекта проявляются в виде рисков. Таким образом, своевременное выявление того или иного риска, а также принятие соответствующих мер позволяют предотвратить срыв проекта. Существуют два типа рисков.

1.

Риски, которых можно избежать или которые можно предотвратить (устранимые).

2.

Риски, которых невозможно избежать.

Примером первого типа рисков является следующий: «Что если руководитель проекта в команде из 15 человек уходит из компании?» (риск устраняется подготовкой заместителя руководителя проекта). Пример риска второго типа: «Необходимо собрать данные о 2100 полетах путем опроса персонала аэропорта, прежде чем мы сможем поставить продукт».

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

Эффективные команды принимают наличие рисков как данность и постоянно о них думают.

2.4.2.

Обзор управления рисками.

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

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

Управление риском состоит из нескольких действий.

1.

Идентификация.

Старайтесь постоянно обнаруживать риски.

2.

Планирование устранения.

3.

Выбор приоритетов.

4.

Устранение или уменьшение.

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

2.4.3. Выявление рисков.

Идентификация риска заключается в фиксации всех факторов беспокойства и озабоченности, связанных с проектом, а затем в постоянном обдумывании всей командой других возможных опасений. Для обнаружения рисков необходим скептический склад ума. Идентификация риска сродни проведению инспектирований — глобальному поиску дефектов в плане разработки. Различают несколько категорий риска: переоценивание рабочего времени, слишком быстрые изменения требований, неготовность найти достаточно эффективный инструментарий, недостаточные навыки персонала, нехватка времени для обучения работы с новыми инструментами (например, CASE-инструментами), несовершенство языков (например, слишком медленная работа приложения). Факторы риска для самого простого проекта перечислены ниже. Они были предложены Кейлом и др. [73] в ходе исследований в США, Гонконге и Финляндии.

1.

Недостаточная вовлеченность в проект высшего руководства.

2.

Невозможность привлечения пользователей.

3.

Непонимание требований.

4.

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

5.

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

6.

Изменение области применения или целей проекта.

7.

Нехватка знаний или навыков у персонала.

Может показаться странным, что первые два риска связаны с обязательствами вкладчиков — людей, наиболее заинтересованных в выпуске приложения. (Вкладчик — это некто, претендующий на прибыль от проекта.) Причем количество вкладчиков может быть достаточно большим. Как и в большинстве коллективов, у каждого члена общества вкладчиков свои мотивации, которые порой сложно согласовать с мотивациями других людей. Ошибки при согласовании мотиваций приводят к нестабильным требованиям, которые могут разорить проект. Заметим, что большинство категорий из этого списка имеют ту же природу, что и источники риска № 1 и № 2, за исключением пункта 7. Заслуживает внимания тот факт, что технические моменты составляют всего 20 % от десяти наиболее важных факторов и рассматриваются как менее важные по сравнению с другими. Остальные факторы можно отнести к политическим и организационным. Все это можно подытожить, сказав, что львиная доля работы по предотвращению неприятностей на пути к успешному завершению проекта ложится на плечи руководителя проекта.

2.4.4. Предупреждение рисков.

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

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

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

Два риска для видеоигры Встреча идентифицированы в табл. 2.3. Риск № 1, наложение изображений, связан с манипулированием изображениями в Java. Предположим, что никто в команде не пробовал накладывать изображения. Однако это необходимо делать, поскольку изображения персонажей должны двигаться на фоне изображения зоны. Расчет приоритета и план предупреждения риска также указаны в табл. 2.3. Мы предполагаем, что данный риск действительно может стать проблемой, но более вероятно, что все обойдется, поэтому мы ставим вероятность 3. Но если это случится, то проблема будет весьма серьезной, поэтому ущерб мы оцениваем максимальным числом 10. Мы предполагаем, что стоимость предупреждения данного риска мала и оцениваем ее числом 1. План предупреждения очень прост: нужно поручить одному из инженеров изучить документацию и на практике проверить, что при наложении изображения персонажа поверх фона все происходит нормально (в частности, не видно прямоугольной границы накладываемого образа).

Риск № 2, недостаточные навыки программирования на Java, отражает тот факт, что 40 % команды не имеют достаточного опыта программирования на Java. Конечно, это вопрос оценки умений, но предложивший данный риск абсолютно уверен, поэтому вероятность равна 9. Принимая этот факт, следует признать, что данный фактор серьезно затормозит проект, но поскольку не все в команде должны программировать, ущерб оценивается числом 6. Стоимость устранения риска высока, поскольку нужно затратить много времени на обучение с отвлечением от работы, так что полагаем ее равной 8.

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

ОДИН ИЗ СПОСОБОВ ОПРЕДЕЛЕНИЯ И ПРЕДУПРЕЖДЕНИЯ РИСКОВ -.

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

1.

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

2.

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

3.

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

4.

Команда затрачивает 10 минут на поиск дополнительных рисков (на совещании).

5.

Команда затрачивает 10 минут на окончательное формирование таблицы рисков (на совещании).

♦ Назначаются разработчики, ответственные за устранение рисков.

6.

Разработчики устраняют риски (между совещаниями).

7.

Команда на еженедельных совещаниях в течение 10 минут делает обзор рисков:.

♦ ответственные за устранение рисков разработчики докладывают о прогрессе;.

+ команда обсуждает новые обнаруженные риски и добавляет их в таблицу рисков.

2.5. Инструментальные средства разработки и поддержки.

2.5.1. Модели процесса.

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

2.5.2.

Инструментальные средства.

Разработка программного обеспечения представляет собой объемный рынок, на который также поставляются инструментальные средства в помощь инженерам, занимающимся производством программных приложений. Часто этот инструментарий называют инструментарием для автоматизированной разработки программ (CASE — Computer-aided Software Engineering). В течение многих лет обсуждается, что же относится к CASE-инструменту. В свое время разработчиками CASE-инструмента было многое обещано, однако сделано было намного меньше. Компоненты CASE-инструмента могут быть, например, такими.

♦ Для обеспечения управления проектом:.

♦ работа с расписанием;.

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

♦ Для обеспечения управления конфигурациями.

♦ Для управления требованиями.

♦ Для проектирования:.

♦ функциональные;.

♦ объектно-ориентированные;.

♦ основанные на вариантах использования.

♦ Инструменты отслеживания:.

♦ перехода требований в проект;.

♦ проекта в программный код.

♦ Для обеспечения тестирования.

♦ Для обеспечения технической поддержки.

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

2.5.3.

Разрабатывать новые или покупать готовые решения?.

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

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

Итоги по двум вариантам — с закупкой и без закупки — приведены в последней строке табл. 2.4. Необходимые средства машинной графики разбиты на три группы, и для каждой приведена отдельная оценка. А именно, пакет Ajax полностью поддерживает средство № 1 — отображение сцены как ее видит игрок. С другой стороны, Ajax не полностью поддерживает отображение трехмерных сцен (средство № 2), так что здесь придется делать доработки. Наконец, нам нужно моделировать освещение из определенного источника (средство № 3). Ajax не поможет, и данное средство придется запрограммировать. Таблица, подобная табл. 2.4, может быть приложением к плану проекта или к SDD. Более реалистичная таблица получится, если сравнить затраты в долговременной перспективе, то есть учесть затраты на поддержку и сопровождение. Чем больше нам придется делать самим, тем менее привлекательной выглядит закупка.

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

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

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

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

3x8 + 8x3 + 5x2 + 1x7 = 65.

Таблицы принятия решений не являются каким-то волшебством. Они просто расщепляют сложные задачи (например: «Какой язык выбрать?») на более простые (например: «Что лучше подходит для веб-приложений — Java или С++?»).

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

2.5.5.

Документация.

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

2.5.6.

Службы поддержки.

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

2.6. Подготовка плана-графика: планирование верхнего уровня.

Используя всю накопленную к этому моменту информацию и уже проделанную работу, можно начать разрабатывать расписание проекта. Приведенную ниже форму расписания с откладыванием времени по горизонтали называют диаграммой Ганта (Gannt). На данном этапе диаграмма Ганта отражает только то, что известно о проекте на текущий момент (рис. 2.8). Заметим, что альтернативный вариант с тремя итерациями приводится в разделе 2.11.

ОДИН ИЗ СПОСОБОВ СОЗДАНИЯ ИСХОДНОГО ПЛАНА-ГРАФИКА -.

1.

Определить основные вехи проекта (обычно включая дату сдачи проекта).

2.

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

♦ например, системное тестирование начать задолго до даты сдачи проекта;.

♦ остальные шаги зависят от типа используемого процесса. Мы рассмотрим их для итеративного процесса.

3.

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

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

♦ польза: налаживание процесса разработки.

4.

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

♦ Начиная с запуска проекта.

5.

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

6.

Завершить составление плана-графика.

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

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

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

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

Детали_.

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

2.7. Интеграция унаследованных приложений.

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

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

Ругейбер и Уайт [94] приводят пример, в котором унаследованная телефонная система RT-1000 для автоматизированного распределения соединений вызывала некоторые проблемы, но приносила большой доход владельцу. Первоначально эта система стоимостью несколько миллионов долларов была создана командой из 70 разработчиков в результате более чем пяти лет работы. На ее замену потребовалась бы гораздо большая сумма и трудозатраты. Компания решила восстановить и улучшить старую систему. Среди проблем RT-1000 были:.

♦ отсутствие формального процесса при построении;.

♦ отсутствие контроля версий;.

♦ общая недостаточность документации;.

•♦• отсутствие полного списка тестов и их результатов, отсутствие автоматизации процесса тестирования;.

♦ проблема 2000 года;.

♦ реализация на нескольких языках, некоторые из которых устарели;.

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

♦ заказчики использовали формы вывода RT-1000 для обеспечения ввода других программ (в частности, дисплеев), не ставя об этом в известность владельца RT-1000.

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

♦ сократила количество открытых дефектов с 300 до 15;.

♦ передала исходный код под управление конфигурациями;.

♦ автоматизировала свыше 80 % существующих тестов;.

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

♦ получила сертификат ISO-9001 для своего процесса;.

♦ организовала постоянные посещения заказчиком организации-разработчика, таким образом улучшив отношения с заказчиком;.

♦ добавила существенно новую функциональность;.

♦ привела весь программный код к языку С.

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

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

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

void runForDuration(int numMinutes) // выполнять игру заданное время void runScenario(Scenario aScenario) // выполнить конкретный сценарий flat getScoreO // получить число очков-жизней игрока void setKeystokeCounter(boolean aToggle) // считать нажатия клавиш.

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

Унаследованные приложения также рассматриваются в главе 10 данной книги в контексте задач сопровождения и поддержки.

2.8. Оценка стоимости: предварительные расчеты.

2.8.1. Введение.

Вкладчики в проект испытывают постоянный усиленный интерес к стоимости проекта. При неправильном подсчете себестоимости даже самый фантастичный продукт может потерпеть фиаско. Простейшим случаем оценки стоимости является ситуация, когда стоимость проекта изначально фиксирована и ни при каких обстоятельствах не меняется. Несмотря на то, что некоторые высокопрофессиональные организации преуспели в варьировании различных параметров (возможности, расписания, качества) для достижения заданной стоимости, стоимость проекта совершенно не обязана быть фиксированной. Представьте, например, что проект по созданию обещающего успех продукта выходит за рамки бюджета при 90-процентной готовности продукта. Вместо того чтобы бросить исходный проект, организация сделает все возможное для отыскания дополнительных фондов на завершение оставшихся 10 % работы. Даже в том случае, если стоимость проекта фиксирована, необходимо оценивать стоимость реализации заданного набора требований, чтобы быть уверенными в том, что она соответствует заявленной стоимости. Если соответствия нет, то необходимо изменить заявленную стоимость и заново провести оценку.

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

Четырехкратная ошибка в оценке (см. рис. 2.11), взята из результатов исследования, представленного Боэмом [11]. Например, там указано, что для приложения, фактическая стоимость разработки которого составляет $100 ООО, оценка после составления концепции может варьироваться от $25 ООО до $400 ООО. Чтобы уменьшить погрешность оценок на ранних фазах проекта, применяются различные приемы, но действительно точную оценку мы получаем в конце фазы реализации (когда большая часть денег уже потрачена!). Поскольку точную раннюю оценку дать практически невозможно, следует использовать диапазон, указывая минимальную и максимальную стоимость.

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

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

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

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

1А. Используйте сравнение с предыдущими работами, чтобы непосредственно оценить стоимость и длительность проекта или количество строк кода. И (ИЛИ).

1Б. Используйте метод функционального размера для оценки количества строк кода.

1Б.1. Вычислите приближенный функциональный размер.

1Б.2. Примените процесс уточнения. 2. Используйте оценку количества строк кода для расчета трудозатрат и длительности проекта с помощью формул СОСОМО.

В следующем разделе приводится пример использования данных предыдущих проектов для оценки. Методология оценивания функционального размера (functional point) и конструктивной модели стоимости (СОСОМО — Constructive Cost Model) описаны далее.

2.8.2. Оценка количества строк кода без учета функционального размера.

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

Несколько методов оценки, в особенности СОСОМО, базируются на числе строк кода (LoC — Lines of Code). Конструктивная модель стоимости (СОСОМО — Constructive cost model) была предложена Боэмом [11], Может показаться, что на ранних стадиях проекта оценивать количество строк кода не имеет смысла, поскольку до кодирования еще далеко. Но если есть возможность сравнить один продукт с другим, то использование данной метрики становится вполне оправданным. Например, допустим, что у нас был проект по управлению спутниками и мы хотим сравнить наш новый проект, который предусматривает дополнительные возможности — мониторинг ураганов. Старый проект содержит три миллиона строк кода на Фортране. Дополнительная возможность потребует 100 ООО строк на Фортране, что видно из сравнения с другими программами отслеживания ураганов. Если новый проект потребуется сделать на другом языке, то можно использовать средние по отрасли коэффициенты для пересчета количества строк кода.

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

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

«Однажды я написал неграфическую программу моделирования одиночного процесса на С++. Эта программа занимала от 4 до 8 страниц кода. Считая от 30 до 50 некомментированных строк на странице, имеем от 120 до 400 строк. Положим, что программирование на Java потребует такого же числа строк. В первом выпуске игры Встреча потребуется запрограммировать от 4 до 15 таких простых процессов, а также запрограммировать от 30 до 90 других компонентов сопоставимого размера, для того чтобы игра была интересной. Таким образом, получаем следующий диапазон: от 120 строк х 43 компонента до 400 строк х 105 компонентов, что округленно составит от 5 000 до 42 000 строк кода. Использование графики учтем с помощью введения коэффициента, который может иметь величину от 1,5 до 4 в зависимости от сложности графических возможностей. Окончательно получаем оценку: от 7,5 тысяч строк до 170 тысяч строк».

ПРИМЕЧАНИЕ -.

Учебный пример в этой книге рассматривает прототип игры, который гораздо менее амбициозен по сравнению с проектом в этом примере оценки.

Эти данные нужно поместить в электронную таблицу, и мы сможем уточнять нашу оценку по мере продвижения проекта вперед. Заметьте, что наш диапазон 7,5-170 хорошо согласуется с рис. 2.11: на стадии формирования концепции следует ожидать, что минимум от максимума будет отличаться в 16 раз. Предшествующее вычисление является примером оценки по методу снизу вверх, поскольку мы получили оценку целого исходя из оценки -составных частей.

Далее мы разберем пример оценки по методу сверху вниз, используя данные по отрасли (или, что предпочтительнее, исторические данные организации). Допустим, мы знаем, что в среднем по отрасли производство очень хорошей видеоигры требует усилий от 5 до 20 высококлассных программистов в течение 1-2 лет. Поскольку в нашем распоряжении имеется только одна десятая часть этих ресурсов, мы предположим, что и возможности нашей игры составят одну десятую от лучших промышленных образцов. Полагая производительность программистов от 5 до 25 строк (полностью отлаженных и документированных!) в день, получаем:.

(1/10 возможностей) х (5-25 строк в день) х (5-20 программистов) х (1-2 года) х х (48-50 недель в году) х (35-60 часов неделю) « 4,2-300 тысяч строк кода.

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

В Интернете имеются свободно распространяемые инструменты оценки, например

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

2.8.3. Функциональный размер и количество строк кода.

В 1979 году Альбрехт [2] предложил фундаментальное понятие функционального размера (FP — functional points), для измерения размера любого проекта независимо от проектирования. Метод измерения функционального размера состоит в единообразном измерении всех возможностей приложения и выражении размера приложения в виде одного числа. Это число можно далее использовать для оценки числа строк кода, стоимости и сроков проекта. Функциональный размер — это весьма привлекательное понятие, поскольку оно претендует на то, чтобы измерить саму суть возможностей будущей программы. Однако нужно иметь определенный навык, чтобы применять этот метод аккуратно и последовательно.

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

Вычисление функционального размера: шаг 1.

Идентифицируйте функции (например, «поиск данных», «отображение данных»), которые должно иметь приложение. Международная группа пользователей функционального измерения (IFPUG — International Function Point Users Group) [61] опубликовала критерии, по которым выделяются «функции» в этом смысле. Рассматривается функциональность на уровне пользователя, а не на уровне программного кода. Обычная функция соответствует обработке одной экранной формы.

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

1.

Установка характеристик главного персонажа игрока.

2.

Встреча с внешним персонажем.

Вычисление функционального размера: шаг 2.

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

♦ Внешние входы. Только такие входы, которые по-разному влияют на выполняемую функцию, считаются отдельными. Например, если функция заключается в сложении двух чисел, то она имеет один вход, а не два, то есть EI = 1. С другой стороны, если на вход можно подать букву А для выполнения сложения или букву S для выполнения вычитания, то такая функция будет иметь два входа, EI = 2.

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

♦ Внешние запросы. Каждый независимый внешний запрос считается за 1.

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

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

Вычисление функционального размера: шаг 3.

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

Применяя этот процесс к двум выделенным функциям видеоигры Встреча, получим расчетные таблицы, приведенные в табл. 2.7 и табл. 2.8.

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

Вычисление функционального размера: шаг 4.

Теперь нужно определить веса для 14 общих характеристик проекта. Каждой общей характеристике присваивается вес от 0 до 5. Эти характеристики и выбранные веса применительно к проекту Встреча приведены в табл. 2.9 и 2.10. Веса указаны в форме диапазонов, что отражает нашу текущую неуверенность относительно функций приложения. Повторим еще раз, что назначение весов требует определенного опыта в использовании метода функционального размера. Например, для характеристики № 6 требуется определить, насколько вероятна потребность в оперативном вводе данных. Применительно к функции установки характеристик персонажа игрока мы уверены, что оперативный ввод данных будет нужен, поэтому ставим наивысшее значение — 5.

Сумма выбранных значений общих характеристик лежит в диапазоне от 24 до 41.

Вычисление функционального размера: шаг 5.

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

Уточненный функциональный размер = [Приближенный функциональный размер] х [0,65+0,01 х (Сумма общих характеристик)].

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

Для нашего примера достаточно разумные значения общих характеристик приведены в табл. 2.9 и 2.10. Таким образом, окончательно получаем:.

41 х [0,65 + 0,01 х (от 24 до 41)] = 41 х [от 0,89 до 1,06] » от 36 до 43.

2.8.4.

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

Функциональный размер может быть очень полезен, если он вычислен аккуратно. Например, функциональный размер может быть использован как относительная метрика для сравнения с предыдущими проектами. С помощью стандартных таблиц по функциональному размеру можно вычислить количество строк кода. В свою очередь, количество строк кода позволяет определить общую трудоемкость в человеко-месяцах и сроки проекта. Например, в [103] приведена следующая величина: 53 строки исходного кода на Java на одну единицу функционального размера. Используя этот коэффициент для игры Встреча, имеем (от 36 до 44) х 53 я 1,9-2,3 тысяч строк на Java. Как и следовало ожидать, это значительно меньше предыдущих оценок, поскольку мы вычислили функциональный размер только для двух функций игры Встреча. В Интернете имеются свободно распространяемые инструменты для вычисления функционального размера [62].

2.8.5.

Пример.

Рассмотрим в качестве примера простую систему проката видеофильмов. Пусть мы имеем приложение, ориентированное на пользователя, которое позволяет узнать, имеется ли фильм в наличии, и взять его напрокат. Мы полагаем, что это приложение использует всего два файла: один для фильмов, другой для клиентов. Вычисление неуточненного функционального размера показано в табл. 2.11. Уточняющие коэффициенты приведены в табл. 2.12, и в сумме они дают 35. Формула функционального размера дает следующий результат:.

Функциональный размер = [Неуточненный функциональный размер] х [0,65 + + 0,01 х (сумма общих характеристик)] = 33 х [0,65 + 0,01 х 35] = 33.

Таким образом, получается 33 х 53 = 1749 строк некомментированного исходного кода на Java.

2.8.6. Библиография.

Метод вычисления функционального размера изложен Джонсом [68], имеющим практический опыт применения метода. См. также [28].

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

Как только мы оценили количество строк программного кода (либо с помощью единиц функционального размера, либо методом, приведенным в разделе 2.8.2), мы можем использовать его при оценивании затрат труда и продолжительности проекта. Боэм обнаружил [И], что на самом деле трудозатраты на разработку приложений растут быстрее, чем размер приложений. Для представления данного соотношения используется экспоненциальная функция со значением показателя, близким к 1,12. Модель Боэма также гласит, что длительность проекта возрастает экспоненциально вместе с прилагаемыми к проекту усилиями. Однако в данном соотношении значение экспоненты меньше единицы и составляет около 0,35. Это отражает тот факт, что после достижения некоторого значения («колена» на кривой 2 на рис. 2.13) дополнительные усилия только растягивают время, необходимое для завершения проекта. Это проиллюстрировано на рис. 2.13 (LOC обозначает количество строк программного кода).

Используя данные из многочисленных проектов, Боэм оценил параметры рассматриваемых выше соотношений, предложив экспоненциальную зависимость. Полученные им формулы приводятся в табл. 2.13 (KLOC обозначает тысячу строк кода). Органические приложения — это самостоятельные приложения, такие как классические (например, без привлечения Web) текстовые редакторы или игра Встреча из нашего примера. Встроенные приложения являют собой интеграцию аппаратного и программного обеспечения (антиблокировочная система тормозов в автомобиле). Промежуточные — нечто среднее. Игра Встреча для случая игры в Интернете будет промежуточной: она уже не органическая, но еще и не так жестко встроена, как система управления тормозами.

В модели Боэма утверждается, прежде всего, что для разных типов приложений длительность и трудозатраты по-разному зависят от размера приложений (отличаются множителем и показателем экспоненты). Например, разработка приложения в 20 000 строк потребует 2,4 х 20

«51 человеко-месяц, если приложение органично, и потребует 3,6 х 20

« 76 человеко-месяцев, если это встроенное приложение.

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

Длительность = с х Трудозатраты^ = с х (а х KLOC) = с х a

х KLOC

На первый взгляд, формула Боэма для расчета длительности проекта может показаться несколько странной, так как зависимость между продолжительностью и прилагаемыми усилиями представляется намного проще. Если мы знаем, что работа требует 120 человеко-месяцев, и имеем в распоряжении 10 человек, не будет ли она сделана через 12 месяцев? Это может произойти, только если мы сумеем с пользой полностью занять 10 человек в проекте с первого и до последнего из 365 дней. Обычно это просто невозможно. Например, представьте себе первый день проекта: вы еще ничего не знаете о проекте, тогда какой же полезной деятельностью могут заниматься в этот день все 10 разработчиков? Таким образом, становится ясно, что при найме 10 разработчиков с первого дня проекта работа, рассчитанная на 120 человеко-месяцев, будет идти намного дольше 12 месяцев.

Формула Боэма обладает следующим интересным свойством: длительность проекта не зависит от количества привлекаемого в проект персонала! Она зависит только от объема работ. Вообще-то, формула предполагает, что в проекте имеется приблизительно необходимое количество персонала в каждый конкретный момент (один человек на первый день, 30 человек на сотый день, в соответствии с потребностями).

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

Используя формулы Боэма [11] для нашей игры Встреча (рассматриваем две базисные функции), исходя из объема 4-300 тысяч строк программного кода, мы получим трудозатраты от 10 до 1000 человеко-месяцев и продолжительность от 6 до 36 месяцев (табл. 2.14).

2.10. Командный процесс разработки программного обеспечения (TSP).

ОДИН ИЗ СПОСОБОВ ПРЕДВАРИТЕЛЬНОЙ ОЦЕНКИ -.

СТОИМОСТИ И ДЛИТЕЛЬНОСТИ ПРОЕКТА.

1.

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

2.

Используйте формулы Боэма для оценки требуемых трудозатрат.

3.

Используйте оценку трудозатрат и формулы Боэма для оценки длительности проекта.

2.10. Командный процесс разработки программного обеспечения (TSP).

Никто не хочет постоянно иметь проблемы, обычные для всех проектов, связанных с программной разработкой. Особенно если эти проблемы можно решить заранее. Командный процесс разработки программного обеспечения (TSP) предлагает большое количество методов управления программным проектом, применимых к любой командной деятельности. TSP обеспечивает необходимую направленность и последовательность действий после анализа требований и по ходу фаз разработки проекта. Участники TSP должны быть подготовлены с точки зрения PSP. Метод основан на итерациях водопадной последовательности и требует, чтобы команда «запускала» каждую итерацию на совещании, где уже было бы известно количество предварительно определенных задач. Хэмфри предусматривает наличие множества различных сценариев. Так как фаза может проводиться в несколько итераций, то для нее, возможно, потребуется несколько «запусков». Перед запуском необходимо провести некоторые предварительные мероприятия:.

♦ выбрать тип процесса, который будет использоваться;.

♦ установить уровень качества;.

+ определить метод отслеживания уровня качества;.

♦ определить, как команда будет принимать решения;.

♦ определить, что делать, если не устраивает уровень качества:.

♦ идти на компромисс;.

♦ определить, что делать, если не утвержден план:.

♦ идти на компромисс;

♦ определить роли в команде;.

♦ распределить роли.

Хэмфри рекомендует, чтобы перед запуском каждой из фаз было определено следующее:.

1) фиксированные цели команды;.

2) определенные командные роли;.

3) план развития процесса;.

4) план качества;.

5) план обеспечения проекта: компьютеры, ПО, персонал и т. д;.

6) общий план разработки и план-график;.

7) детальные планы для каждого разработчика;.

8) оценка рисков проекта;.

9) доклад о статусе проекта.

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

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

Хэмфри предложил для TSPi свое расписание продолжительностью в один семестр. Это расписание содержит три итерации (Хэмфри назвал их «циклами») (рис. 2.14).

Идея заключается в том, что данные, полученные из каждого цикла, могут быть использованы при оценивании метрик для следующего цикла. Цикл 1 сравнительно продолжителен, так как на нем команда впервые проходит последовательность из семи фаз, показанную на рис. 2.14. Эта последовательность претендует на получение минимального работающего подмножества функциональности конечного продукта. Под цикл 3 отведено достаточное количество времени для завершения всей работы. Он начинается после относительно короткого среднего цикла. Стратегия (стоящая на первом месте на рис. 2.14) касается общей направленности, в которой команда собирается проводить цикл. Для этого потребуется обсуждение требований, концепции проектирования и общего плана сборки компонентов на самом высоком уровне. Затем все это преобразуется в жесткий план (2), фиксированные требования (3) и т. д. Хэмфри [55] предоставляет многочисленные детальные сценарии для сопровождения TSPi.

2.11. План управления программным проектом (SPMP).

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

Существует множество стандартов для таких планов. Мы будем использовать стандарт IEEE 1058.1-1987 (утвержденный в 1993 году). Приведем оглавление Плана управления программным проектом (SPMP — Software Management Plan), определенное в IEEE 1058.1-1987 (мы используем его в конкретном примере в конце этой главы):.

1.

Введение.

1.1.

Обзор проекта.

1.2.

Результирующие артефакты проекта.

1.3.

Развитие SPMP.

1.4.

Ссылочные материалы.

1.5.

Определения и аббревиатуры.

2.

Организация проекта.

2.1.

Модель процесса.

2.2.

Организационная структура.

2.3.

Организационные рамки и взаимосвязи.

2.4.

Ответственность за проект.

3.

Управляющий процесс.

3.1.

Цели и приоритеты.

3.2.

Допущения, зависимости и ограничения.

3.3.

Управление рисками.

3.4.

Механизмы мониторинга и контроля.

3.5.

План расстановки кадров.

4.

Технический процесс.

4.1.

Методы, инструменты и технологии.

4.2.

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

4.3.

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

5.

Распределение работ, план-график и бюджет.

5.1.

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

5.2.

Зависимости.

5.3.

Потребности в ресурсах.

5.4.

Выделение бюджета и ресурсов.

5.5.

План-график.

Пункт 1.1 — «Обзор проекта» — должен определять проект, но не пытаться охватить все требования к нему (то есть описание его поведения). Сами требования будут приведены в Спецификации требований к программному обеспечению (SRS), которая будет рассмотрена далее в главах 3 и 4. Повторение этого материала в SPMP не обязательно и может нарушить целостность документации. Пункт 1.2 содержит список всех документов, исходных файлов и конечных программных продуктов, которые должны быть произведены. В пункте 1.3 описаны направления ожидаемого расширения и изменения SPMP. К этому времени уже должен быть разработан SCMP (см. главу 1), так что выпуск новых версий SPMP будет достаточно контролируемым.

Пункт 2.1 ссылается на тип процесса разработки, который будет использован (например, водопадный, спиральный, инкрементальный). Возможные организационные структуры мы уже рассматривали в разделе 2.3.2. В пункте 2.3 («Организационные рамки и взаимосвязи») представлены пути возможного взаимодействия между организациями. Все это зависит от заинтересованных в проекте сторон. Здесь может определяться, каким образом будет осуществляться взаимодействие между отделом разработки и отделом маркетинга, будут ли это регулярные встречи или переписка по электронной почте и т. д. Пункт 2.4 определяет границы ответственности, то есть кто за что отвечает. Например, за что несет ответственность координатор повышения эффективности команды при горизонтальной организации (см. рис. 2.5)? Отвечает ли он за общий успех проекта, предоставляет ли персональные рекомендации или занимается только руководством?.

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

Управление рисками (пункт 3.3) было рассмотрено в разделе 2.4. Раздел «Механизмы мониторинга и контроля» (пункт 3.4) определяет, кто будет управлять, контролировать и (или) осуществлять проверку проекта, а также предписывает, как и когда это должно быть сделано. Например, вышестоящий управляющий должен быть в курсе развития проекта, и для этого мы должны в этом разделе определить, каким образом его информировать. «План расстановки кадров» содержит информацию о том, кто и какое место занимает в проекте. В частности, в пункте 2 может быть задано присутствие в проекте Менеджера с конкретными обязанностями, тогда как в пункте 3.5 будет сказано, что это место займет Альберт Смит.

«Технический процесс» в пункте 4 накладывает ограничения на языки и используемые инструменты («в этом проекте должны быть использованы язык Java от корпорации Sun версии 1.2.1 и Rational Rose версии 1»). Также пункт 4 может содержать информацию о повторно используемых требованиях и использовании таких техник, как образцы проектирования (главы 5 и 6). «Функции сопровождения проекта» — раздел, посвященный действиям для поддержания процесса разработки, таким как управление конфигурациями и контроль качества. Если же функция поддержки представлена в различных документах (например, в плане управления конфигурациями или в плане качества), то в этом пункте будут ссылки на эти документы. В противном случае мы полностью специфицируем функции поддержки.

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

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

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

Наконец, пункт 5.5 завершает SPMP созданием расписания, определяющим, как и когда должны быть выполнены различные этапы процесса. Это обсуждалось нами в разделе 2.6.

2.12. Управление проектом и качество.

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

2.12.1. Метрики процесса.

2.12.1.1.

Введение.

Напомним, что 5-й уровень СММ (см. раздел 1.8.3) требует постоянного самостоятельного улучшения процесса. Хотя некоторые организации и работают на этом уровне, им необходимо помнить свои основные цели. Для того чтобы улучшить процесс управления проектом, мы должны будем измерить его эффективность с помощью метрик процесса. Эти метрики позволят нам измерить эффективность организации нашего процесса, включая последовательность шагов, предпринимаемых в ходе проекта. Мы также по отдельности измерим эффективность анализа требований, проектирования, программирования и тестирования.

2.12.1.2.

Примеры.

Одной из простейших метрик является степень обнаружения дефектов для заданной фазы обнаружения и заданной фазы появления. Например, «степень обнаружения дефектов, равная 0,2 дефекта на 100 требований на стадии реализации» означает, что на стадии реализации 500 требований в одном из них был обнаружен дефект.

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

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

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

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

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

1.

Количество дефектов на тысячу строк программного кода, выявленных в течение 12 недель после сдачи проекта.

2.

Отклонения в расписании на каждой фазе:.

(Фактическая длительность - Плановая длительность) / Плановая длительность.

3.

Отклонения в стоимости:.

(Фактическая стоимость - Плановая стоимость) / Плановая стоимость.

4.

Общее время проектирования / Общее время программирования: Должно быть не менее 50 % (Хэмфри).

5.

Степени появления и обнаружения дефектов на некоторой фазе: Например, «Один дефект на класс на фазе детального проектирования».

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

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

2.12.2. IEEE 739-1989 SQAP: часть 2.

Как уже упоминалось в главе 1 (раздел 1.6.5), все соображения, связанные с качеством в проекте, могут быть полностью отражены в таком документе, как SQAP. Представим вторую половину SQAP. Иногда удобнее, если части SQAP просто ссылаются на другие документы:.

7.

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

Может ссылаться на STD.

8.

Отчеты о проблемах и коррекционная деятельность.

9.

Инструменты, технологии и методики Может ссылаться на SPMP.

10.

Контроль программного кода Может ссылаться на SCMP.

11.

Контроль носителей.

12.

Контроль поставщиков.

13.

Сбор, сопровождение и хранение протоколов.

14.

Обучение.

15.

Управление рисками.

Может ссылаться на SPMP.

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

ОДИН ИЗ СПОСОБОВ СБОРА МЕТРИК ПРОЦЕССА -.

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

1.

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

♦ время, затраченное на исследование, реализацию и анализ результатов;.

♦ размер (например, количество строк кода);.

♦ количество дефектов, обнаруженных в модуле (например, количество строк кода), и источник обнаружения дефекта;.

♦ самостоятельная оценка качества друг у друга по шкале от 1 до 10.

2.

Задокументировать это в SQAP.

3.

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

4.

Решить, где разместить метрические данные:.

♦ в ходе развития проекта;.

♦ SQAP? SPMP? Приложения?.

5.

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

6.

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

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

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

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

Остаточная степень дефектности относится к количеству дефектных детальных требований на 100 оставшихся в документации требований после завершения фазы детальных требований. Это позволяет нам судить о том, насколько эффективной была наша деятельность. Остаточная степень дефектности получается в результате вычисления пропорции остаточной степени дефектности в организации за последние несколько проектов. Последнюю мы получаем расчетом процента дефектных детальных требований в предыдущих проектах после завершения создания документации по требованиям, то есть на стадиях проектирования, реализации и тестирования. Полученное отношение 6/4 — это степень дефектности требований, полученная для данного проекта, отнесенная к средней степени дефектности требований. Основная идея заключается в возможности сравнения степеней дефектности на предыдущем и последующем шагах. Более надежное предсказание можно получить, учитывая степень дефектности требований, полученную для предыдущих шагов (в нашем случае — в ходе персонального инспектирования). Для этого необходима линейная регрессия.

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

2.13. Улучшение процесса и модель зрелости возможностей.

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

2.13.1. Улучшение процесса, используемого в организации.

Общее улучшение процесса в первую очередь требует классификации типов работ и процессов. Классификация типов работ всецело зависит от компании. Например, в специализированном магазине это могут быть: «проверка двигателей», «компьютерная диагностика», «статистика». Таким образом, это означает, что все приложения, имеющие отношение к этому магазину, могут быть отнесены к одному из трех перечисленных типов. Благодаря такой системе можно эффективно собирать различную статистику. Пример сбора данных приводится в табл. 2.17.

Такие же таблицы могут быть созданы для приложений «компьютерной диагностики» и «статистики». Остается один вопрос: «Как мы можем использовать это для улучшения процесса?». Один из методов — попытка использования лучших частей различных процессов. Например, в соответствии с табл. 2.17, меньше всего дефектов получается во время реализации для водопадного процесса, использованного для приложений, связанных с «проверкой двигателей». Однако спиральный процесс с тремя итерациями дал наилучший общий результат. Это подсказывает нам решение проблемы. Необходимо модифицировать наш спиральный процесс из Требования (Т)-Архитектура (А)-Детальное проектирование (Д)-Реализация (Р)-Т-А-Д-Р-Т-А-Д-Р в процесс Т-А-Д-Р-Т-А-Д-Т-А-Д-Р, который сохраняет спираль с тремя итерациями, но сокращает количество итераций реализации.

2.13.2. Улучшение процесса для текущего проекта.

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

ОДИН ИЗ СПОСОБОВ УЛУЧШИТЬ ПРОЦЕСС (ПРОЕКТ).

С ПОМОЩЬЮ ОБРАТНОЙ СВЯЗИ -.

1.

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

♦ Добавить Исследование, если проводится изучение нового материала.

2.

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

♦ Старайтесь поддерживать кривую.

3.

Вычисляйте отношение качества к затрачиваемому (в процентах) времени.

4.

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

5.

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

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

Компании не могут достичь пикового уровня производительности за одну ночь, поэтому для достижения верхних уровней предпринимаются последовательные попытки. Вместо того чтобы добиваться превосходного уровня во всем сразу, используются PSP, TSP и СММ, благодаря которым осуществляются промежуточные улучшения в деятельности и технологии. Уровни СММ обеспечивают ступенчатую структуру для улучшения процесса. Компании необходимо достичь уровня 2, прежде чем перейти на уровень 3, и т. д.

2.14. Вспомогательные средства и методы управления проектом.

2.14. Вспомогательные средства и методы управления проектом.

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

2.14.1.

Распределенные и международные команды.

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

♦ Расположение в одном офисе:.

+ идеально для общения в группе;.

- продуктивность работы не оптимальна.

♦ Расположение в одном городе, но в разных офисах: достаточная степень общения.

♦ Расположение в одной стране, но в разных городах:.

- трудности с постоянным общением; + одинаковая культура.

♦ Расположение в разных странах:.

- общение затруднено;.

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

+ продуктивность работы оптимальна.

2.14.2.

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

Экстремальное программирование — это методика управления проектом и разработкой, предложенная Кентом Беком [7]. Этот раздел включен в книгу для ознакомления читателя с разнообразными методами и техниками, использовавшимися в течение долгого времени. Кроме того, в нем излагаются дополнительные идеи по использованию экстремального программирования в различных обстоятельствах. Интересными особенностями экстремального программирования являются упор на непрерывную взаимосвязь как внутри организации разработчиков, так и с заказчиком, радикальная простота (использование наиболее простого решения) и парное программирование. При парном программировании разработчики работают в парах за компьютерами, тем самым исключается изоляция. Сравнение некоторых особенностей экстремального и неэкстремального программирования приводится в табл. 2.19 [5].

Мы уже рассматривали некоторые их этих приемов в других контекстах. Например, Министерство обороны США давно имеет своих представителей в командах, выполняющих крупные заказы. Экстремальное программирование идет дальше, делая представителя заказчика одним из участников разработки (автор однажды был таким участником). В принципе, это отличная идея, хотя она влечет некоторые юридические проблемы, которые не всякая организация может легко решить. Возможно, самой характерной чертой метода Бека является программирование в парах, при котором разработчики работают только вдвоем за одним компьютером. Фактически это своеобразная форма непрерывного инспектирования. Андерсон и другие [5] сообщают превосходные результаты в своем исследовании применения экстремального программирования в корпорации Крайслер.

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

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

2.14.3. Принятие решений с помощью отбраковки.

Во время выполнения проекта часто возникает перегрузка. Например, список пожеланий «что нужно сделать» разбухает очень быстро и кажется, что может разрастаться безгранично. Обычный путь борьбы с этим явлением — устанавливать приоритеты. Однако на этом идеальном пути также очень быстро возникает перегрузка. Например, в списке «что нужно сделать» имеется 100 пунктов, а время есть только на выполнение 20 из них. Тогда упорядочивание по приоритету всех 100 пунктов — пустая трата времени. Для решения этой проблемы можно использовать отбраковку.

Суть метода отбраковки состоит в том, чтобы любой вопрос анализировать не более чем два раза. После этого мы занимаемся только пунктами из категории Немедленно. Если (если!) они все будут выполнены, то переходим к рассмотрению категории Обычное, и т. д. Если угодно, пункты можно расставить по приоритетам внутри категорий. Таким образом, мы не теряем время на определение точного порядка действий, которые никогда не будем выполнять. По данным «Business Week» [19], такой прием обработки сообщений о найденных ошибках использовался в Microsoft во время отладки Windows 2000. Принцип метода отбраковки:.

IF принадлежит к числу наиболее важных поместить в категорию НЕМЕДЛЕННО.

ELSE.

IF можно проигнорировать, не меняя существенно проект, поместить в категорию В ПОСЛЕДНЮЮ ОЧЕРЕДЬ.

ELSE.

поместить в категорию ОБЫЧНОЕ.

2.15. Подведение итогов.

Основной идеей данной главы является то, что способ управления проектом так же важен, как и технологические аспекты проекта. Йордон [112] пошел еще дальше, назвав управление проектом «серебряной пулей», которую профессиональные программные разработчики искали для решения проблем запаздывания, выхода за рамки бюджета и низкого качества программных продуктов. SPMP служит основным навигатором при управлении проектами. Ключевым аспектом является оценка расходов на проект. Этот процесс требует непрерывного отслеживания в течение всего жизненного цикла проекта. Перечислим основные моменты этой главы.

♦ Управление проектом — «серебряная пуля»?.

♦ «Человеческие» аспекты не уступают техническим.

♦ Специфицируйте SPMP.

4- Идентифицируйте и устраняйте риски.

♦ Оценивайте затраты, используя различные методы:.

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

♦ используйте на этом этапе диапазоны значений.

♦ Составьте план-график проекта с соответствующей детализацией.

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

Руководство по учебному проекту. План управления программным проектом (SPMP) для видеоигры Встреча.

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

Предполагается, что до того, как приступить к составлению SPMP, команда провела уже по крайней мере одно совещание, на котором обсудила проект в целом, выбрала лидера команды (Эд Браун) и составила SCMP и SQAP.

Этап 1. Подготовка к совещанию по планированию проекта.

Незадолго до совещания Эд просмотрел заголовки разделов SPMP, предложенные IEEE (см. оглавление IEEE 1058.1-1987 в разделе 2.11), и набросал черновик материала по каждому выбранному разделу. Для случая видеоигры Встреча лидер команды решил, что нужны разделы Цели и приоритеты (пункт 3.1 IEEE 1058.1-1987), Ответственность за проект (основные и вспомогательные роли, а также их ответственности, пункт 2.4), Управление рисками (пункт 3.3) и План-график (пункт 5.5). Кроме того, Эд написал небольшой абзац для раздела 1.1 (Обзор проекта). Он не заполнял план набора кадров (то есть не стал определять, кто будет играть какую роль), поскольку решил, что пусть лучше это сделает сама команда во время совещания на добровольной основе. Он запланировал заполнить оставшиеся разделы после совещания. По электронной почте Эд спросил, нет ли добровольца на проведение оценки стоимости проекта, поскольку это техническая работа, которую лучше делать одному, максимум вдвоем.

Заполняя раздел Цели и приоритеты, Эд перечислил возможные варианты, а не выбрал сразу самое важное, поскольку не хотел, чтобы группа считала, что все решено без ее участия и проект катится по железным рельсам. В качестве наиболее приоритетной цели он предложил такие варианты: «достичь поставленных целей по качеству», «сделать что-нибудь такое, чем мы сами будем пользоваться» (это его личный выбор) и «уложиться в план-график». Он был совершенно уверен, что группа согласится на организацию по ролям (см. раздел 2.10), поэтому он включил это в проект решения.

Эд запросил по электронной почте мнение участников о рисках, которые угрожают проекту, и попросил прислать ему мнения за 48 часов до совещания в форме, приведенной в табл. 2.2. Карен выразила сомнение в способностях группы в программировании на Java, и описала этот риск так подробно, как смогла. Кроме того, она навела справки о компаниях, предоставляющих услуги по краткосрочному обучению. Пошаговый план устранения риска она включила в письмо, которое послала Эду. Халл Фурнес затронул вопрос о наложении изображений в Java и послал сообщение об этом риске Эду. Последний включил все присланное в заготовку SPMP и назначил приоритеты.

Затем Эд составил следующую повестку дня совещания.

Совещание состоится в помещении 397 с 10:00 до 11:30 в субботу 11 сентября.

1.

Назначение секретаря совещания (5 мин — 10:05).

2.

Утверждение повестки дня (5 мин — 10:10).

3.

Обзор разделов SPMP, представленных Эдом (25 мин — 10:35).

4.

Назначение ответственных за другие разделы SPMP (20 мин — 10:55).

5.

Определение процесса проведения обзоров — по почте или на совещании (5 мин - 11:00).

6.

Мозговой штурм по выявлению дополнительных рисков (10 мин — 11:10).

7.

Обзор намеченных действий (5 мин — 11:15).

8.

Разное (10 мин — 11:25).

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

Этап 2. Начальное совещание по планированию проекта.

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

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

Дискуссия по поводу написания SPMP вышла за отведенные временные рамки, но была продуктивной, поэтому Эд не стал прерывать ее. Было решено, что еще двое участников, кроме Эда, будут писать SPMP и что все остальные будут инспектировать их работу, поскольку трудно организовать в короткое время коллективное написание документов. Через 10 минут Эд заметил, что команда начинает обсуждать мелочи и прекратил дискуссию, пообещав, что все мелкие вопросы будут решены заочно по электронной почте. На совещании было принято решение, что писатели должны закончить сочинение своих разделов SPMP к вечеру пятницы, Эд должен собрать все воедино и разослать в 15:00 в субботу. Все должны прислать свои замечания к 15:00 воскресенья, и Эд должен учесть их в окончательной версии документа. Эд должен будет решить, нужно ли проводить еще одно совещание по данному вопросу, и сообщить об этом всем до 20:00 в воскресенье. Совещание, если понадобится, будет проведено в помещении 283 в понедельник в 11 часов.

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

Этап 3. Завершение составления SPMP.

Выписывая детали документа, команда осознала, что многие вопросы не были обсуждены на совещании, в том числе Механизмы мониторинга и контроля (пункт 3.4 в IEEE 1058.1-1987, см. раздел 2.11). Этот раздел писал Халл и в первом варианте он предусмотрел множество совещаний для обзора состояний проекта. Но другие участники команды посчитали, что не нужно проводить так много совещаний. Прочитав несколько предложений, Эд завершил дискуссию по электронной почте, предложив делать обзор проекта на еженедельных совещаниях, а также на каждом совещании, посвященном началу фазы (которые он также постарался приурочить к еженедельным совещаниям). Команда согласилась с этим предложением. Кроме того, на случай, если понадобятся дополнительные совещания, был зарезервирован еще один день недели, на который они будут назначаться.

Упражнения.

Ответы и подсказки для упражнений, помеченных символами «о» или «п», приводятся в конце этой главы.

Вопросы для проверки.

П2.1". Назовите пять стадий процесса планирования программного проекта.

П2.2

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

П2.3

. Какую эффективную форму организации стоит использовать для выполнения работы в 4000 человеко-месяцев силами 100 разработчиков? Опишите четырьмя предложениями.

П2.4

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

П2.5°. Укажите те части SPMP, которые вы, возможно, не сможете составить на данной фазе. Это нужно сделать в форме ссылок на те разделы, к которым необходимо будет вернуться на более поздних стадиях работы.

П2.6". Почему нужно составлять план выявления и устранения рисков при составлении плана проекта?.

П2.7

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

П2.8°. Обычно оценка стоимости важна. Можете ли вы указать обстоятельства, при которых не стоит выполнять оценку стоимости проекта?.

П2.9

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

П2.10". Укажите один положительный и один отрицательный аспект использования метода Боэма при оценке стоимости.

П2.1Г. Что такое метрики процесса? Приведите три примера. Для чего их используют?.

Упражнения в команде.

К2.1. (SPMP) Разработайте SPMP для своего проекта. Используйте (с изменениями и улучшениями) стандарт IEEE, как показано в примере ниже. Внесите по крайней мере две итерации в план-график. Грубо оцените размер проекта.

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

Критерии оценки.

1.

Степень ясности плана и его приложений («Отлично» — все совершенно ясно и конкретно).

2.

Степень реалистичности плана и его приложений («Отлично» — все цели достижимы и нет противоречий).

3.

Степень полноты плана и его приложений («Отлично» — план включает > 95 % необходимых конкретных деталей).

4.

Степень неизбыточности плана и его приложений («Отлично» — план включает

< 5 % ненужных деталей).

5.

Полезность вашей самооценки.

К2.2. (SQAP) Создайте реалистичный план контроля качества для вашего проекта. Измерьте время, затраченное на этот план отдельными разработчиками и командой в целом.

Предоставьте соответствующие данные измерений и самооценки, как в К2.1.

Критерии: такие же, как и для К2.1.

Подсказки.

П2.1. Посмотрите на схему процесса управления проектом в разделе 2.1.4.

Ответы.

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

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

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

♦ какой процесс разработки используется;.

♦ кто, что и когда должен делать;.

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

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

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

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

П2.8. Может возникнуть искушение ответить на этот вопрос так: небольшой проект, который нужно выполнить любой ценой. Нужно согласиться, что время, затраченное на оценку, забирает слишком большую долю из времени, отпущенного на работу. Но даже это не оправдывает отказ от оценки стоимости. Можно считать, что время, необходимое для оценки объема работы, пропорционально объему работы, так что объем проекта не имеет большого значения. Отказ от оценки может быть оправдан, только если тот, кто оценивает, совершенно не умеет этого делать. Действительно, если три инженера две недели учатся оценивать стоимость проектов, а потом применяют полученные знания, чтобы оценить один двухмесячный проект, то игра не стоит свеч. В больших проектах эти две недели немного значат.

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

П2.10. Преимущества: возможность оценить сразу сроки и трудозатраты; точность формул. Недостаток: метод основан на измерении количества строк кода, а эта величина часто неизвестна.

П2.11. Метрики процесса измеряют эффективность процесса. Например, мы можем сравнить эффективность водопадной и спиральной модели для данной организации в данное время. Следующие метрики позволяют это сделать.

♦ (Общее время проектирования)/(Общее время разработки). Обычно должно быть 0,5 или чуть больше.

♦ (Число дефектов на тысячу строк)/(Среднее по компании).

♦ (Доля недокументированных требований)/(Среднее по компании).

♦ [(Фактическая продолжительность проекта)/(Плановая продолжительность проекта)]/(Среднее по компании).

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

Пример 1. План управления программным проектом (SPMP) для видеоигры Встреча.

Утверждаю.

_Дата_.

05.01.98 Эд Браун: Создание первой версии.

02.02.98 Халл Фурнас: Рецензирование и различные предложения по улучшению 16.05.98 Эд Браун: Детализирован план-график, добавлены ссылки на валидацию и верификацию.

29.05.98 Эд Браун: Проверка для выпуска.

1. Введение.

1.1.

Обзор проекта.

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

1.2.

Результирующие артефакты проекта.

Следующие материалы должны быть поставлены в указанные сроки. Версия 1 (прототип) с документацией — вторая неделя второго месяца. Версия 2 с документацией — третья неделя пятого месяца. Документация включает в себя SPMP, SQAP, SWP, SCMP, SRS, SDD, STD (с использованием стандартов IEEE), исходный код, компилированный байт-код, План сопровождения программного обеспечения и Руководство пользователя. Аббревиатуры определены в разделе 1.5.

1.3.

Развитие SPMP.

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

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

1.4.

Ссылочные материалы.

Все необходимые стандарты IEEE опубликованы в сборнике стандартов IEEE, редакция 1997 года.

Данный документ должен быть согласован с корпоративным документом «Генеральный план достижения уровня 5 СММ».

Основное руководство: Software Engineering: an Objected-Oriented Perspective. E. Braude, Wiley, 2000.

1.5.

Аббревиатуры.

CI — Configuration Item. Элемент конфигурации.

СММ — Capability Maturity Model. Модель зрелости возможностей. IEEE — Institute of Electrical and Electronics Engineers. Институт инженеров по электротехнике и радиоэлектронике.

QA — Quality Assurance. Контроль качества.

SEI — Software Engineering Institute. Институт технологий разработки программного обеспечения.

SCMP — Software Configuration Management Plan. План управления конфигурациями программного обеспечения.

SPMP — Software Project Management Plan. План управления программным проектом (данный документ).

SRS — Software Requirements Specification. Спецификация требований к программному обеспечению.

SDD — Software Design Document. Проектная документация программного обеспечения.

STP — Software Test Plan. План тестирования программного обеспечения.

2. Организация проекта 2.1. Модель процесса.

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

2.2. Организационная структура.

Организация проекта Встреча в рамках корпорации Gaming Industries Consolidated представлена на рис. 2.15. Проект организован как команда равных с назначением ролей. Роли следующие: лидер команды, ответственный за конфигурацию, ответственный за качество, ответственный за требования, ответственный за проектирование и ответственный за реализацию. Кроме того, имеется роль ответственного за связи с отделом маркетинга и с лабораторией технологии программирования. Все эти роли показаны на рис. 2.16. В проекте Встреча будет проводиться инспектирование всей работы, как это определено в SQAP. Каждый участник команды будет проводить инспектирование работы других участников (см. рис. 2.16). Инспектирование будет происходить либо групповое, либо, если не будет хватать времени, индивидуальное автором и тем, кто его замещает.

2.3.

Организационные рамки и взаимосвязи.

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

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

2.4.

Ответственность за проект.

Ответственность участников проекта показана в табл. 2.20. Ответственность за документ подразумевает следующее:.

♦ документ должен быть создан вовремя;.

♦ лидер команды определяет, кто пишет документ;.

♦ документ поддерживается в актуальном состоянии.

3. Управляющий процесс.

3.1.

Цели и приоритеты.

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

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

3.2.

Допущения, зависимости и ограничения.

[Примечание для студентов. Здесь перечисляются предположения и допущения о внешних по отношению к проекту событиях, которые могут повлиять на проект.[ Нет.

3.3 Управление рисками.

[Примечание для студентов. Определяйте риски как конкретные неприятности, которые могут произойти. Не ограничивайтесь общими словами. Например, утверждение «недостаточные навыки программирования на Java» само по себе не описывает суть проблемы. Иногда проект можно успешно выполнить и с недостаточными навыками.].

Форма для идентификации и обработки рисков показана в табл. 2.21. Каждое совещание по проекту должно включать в повестку дня пункт «мозговой штурм с целью выявления рисков». Риск № 1 «Наложение изображений» связан с возможностями манипулирования изображениями на языке Java. Предположим, что никто в команде не пробовал накладывать изображения. Накладывать изображения необходимо, поскольку изображения персонажей должны двигаться на фоне изображения зоны. Никто в команде не пробовал накладывать изображения так, чтобы не было видно прямоугольной границы накладываемого образа. Мы не знаем, легко ли это сделать, трудно или вообще невозможно.

Риск № 2, «недостаточные навыки программирования на Java», отражает тот факт, что 40 % команды не имеют достаточного опыта программирования на Java для того, чтобы реализовать движение и взаимодействие изображений персонажей. Мы предполагаем, что понадобится масштабировать игровое пространство, и в этом также нет опыта. Мы не знаем, сможем ли мы реализовать на Java те возможности, которые имеет в виду заказчик, а если сможем, то сколько это потребует времени. Это обстоятельство может серьезно повредить проекту.

3.4. Механизмы мониторинга и контроля.

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

Вся команда будет встречаться на совещании в начале каждой фазы (определение требований, проектирование, реализация) каждой итерации. Должны проводиться еженедельные совещания по проекту по вторникам с десяти утра до полудня. Следует принять все меры к тому, чтобы на этих совещаниях рассматривались сразу все общие для команды дела. Участники команды должны зарезервировать время по пятницам с 9 до 11 для проведения дополнительных совещаний, если понадобится. Лидер команды должен предупредить участников о проведении дополнительного совещания не позднее 16:30 в четверг.

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

3.5. План расстановки кадров.

Назначение ролей указано в табл. 2.23. Каждый участник команды имеет дополнительные обязанности по резервированию и инспектированию (см. рис. 2.16).

4. Технический процесс.

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

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

4.1.

Методы, инструменты и технологии.

В проекте Встреча для проектирования используется Rational Rose, а реализация ведется на языке Java. Во всех случаях используется объектно-ориентированный подход. Для документирования используется Javadoc настолько широко, насколько это возможно (подробнее см. SRS). Используемая модель процесса описана в разделе 2.1.

4.2.

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

См. SQAP, раздел 4.2.

4.3.

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

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

5. Распределение работ, план-график и бюджет 5.1. Распределение работ.

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

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

5.2.

Зависимости.

[Примечание для студентов. В этом разделе показываются взаимные зависимости различных работ. Данный раздел должен быть пересмотрен после проектирования. На данном этапе можно указать только зависимости самого верхнего уровня.] Вторая итерация зависит от результатов первой. Инженер Фурнес занят в проекте Game 123, и с вероятностью 50 % он будет недоступен в первый месяц проекта.

5.3.

Потребности в ресурсах.

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

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

Аппаратные ресурсы составят восемь компьютеров Pentium 500 МГц с операционной системой Windows 95 и системой программирования Symantec Visual Cafe версии 3.0. Каждый компьютер должен иметь не менее 128 Мбайт RAM и не менее 6 Гбайт пространства на жестком диске.

5.4. Выделение бюджета и ресурсов.

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

1.

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

2.

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

3.

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

Результаты приведены в табл. 2.23 (все величины даны в тысячах строк исходного кода на языке Java).

[Примечание для студентов. Существует множество способов представления этих данных в зависимости от потребностей руководства и разработчиков. Некоторые из них даны в табл. 2.24. До анализа требований оценки остаются очень грубыми.]

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

♦ Оценка с использованием требований заказчика до начала сбора детальных требований. Должна быть представлена.

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

Должна быть представлена.

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

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

Должна быть представлена.

♦ Оценка в конце итерации 1 до начала итерации 2. Должна быть представлена.

♦ Оценка в конце итерации 2 до начала итерации 3. Должна быть представлена.

5.5. План-график.

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

План график приведен на рис. 2.18. См. также SQAP, где приведен план-график мероприятий по контролю качества.

6.

Дополнения.

6.1.

Указатель.

Должен быть представлен.

6.2.

Приложения.

Должен быть представлен.

Пример 2. План контроля качества (SQAP), часть 2.

Первую часть SQAP см. пример 2 главы 1.

7.

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

[Примечание для студентов. Здесь определяется, как будет осуществляться управление тестированием. Данный текст может ссылаться на STD, но не должен дублировать ее.].

На первых трех итерациях все функции по контролю качества выполняет ответственный за качество. На последующих итерациях отдел контроля качества должен выделить команду по контролю качества и передать ей эти функции. Описание команды по контролю качества будет представлено. Команда проекта Встреча несет ответственность за тестирование отдельных методов и комбинаций методов в классе (модульное тестирование). Ответственный за качество (в дальнейшем — команда по контролю качества) ответственен за все остальные виды тестирования (главы 8 и 9 данной книги). Дальнейшие детали тестирования изложены в STD проекта Встреча.

8.

Отчеты о проблемах и коррекционная деятельность.

[Примечание для студентов. В этом разделе объясняется, каким образом дефекты становятся известными, описываются и устраняются. Данный раздел не воспроизводит буквально детали стандарта IEEE. Читателю следует обратиться к стандарту IEEE или к книге Хэмфри [48] для получения более детальной информации о типах и классификации дефектов.].

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

Различаются следующие значения уровня серьезности дефектов.

♦ Серьезный дефект: наличие такого дефекта влечет невыполнение требований к программному обеспечению.

♦ Тривиальный дефект: такой дефект не влияет на выполнение или сопровождение приложения.

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

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

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

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

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

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

9.

Инструменты, технологии и методики.

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

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

♦ списки контрольных вопросов будут использоваться для верификации следующих видов деятельности и документов: предварительный обзор проектных решений (PDR), критический обзор проекта (CDR), экспертиза готовности к тестированию, аудит функциональной конфигурации, аудит физической конфигурации (РСА), SRS, SDD, SPMP, рабочие папки проекта (SDF);.

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

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

Дополнительные инструменты, технологии и методы управления качеством описаны в SPMP.

10.

Контроль программного кода.

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

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

11.

Контроль носителей.

[Примечание для студентов. Здесь описываются правша обращения с дисками, лентами и т. п.].

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

12.

Контроль поставщиков.

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

13.

Сбор, сопровождение и хранение протоколов.

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

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

♦ отчеты о выполненной работе;.

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

♦ памятные записки и рекомендации;.

♦ книги учета работы команды по контролю качества; 4- отчеты об аудитах;.

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

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

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

14.

Обучение.

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

Для участников команды разработчиков должен быть организован вводный курс по качеству на 4 часа. Курс должен включать описание метрик, которые будут использоваться, и лабораторное занятие по изучению инструментов для сбора метрик. Далее, должны быть организованы ежемесячные трехчасовые занятия для того, чтобы поддерживать у разработчиков знания инструментов и методов контроля качества. Разработчики могут не присутствовать на этих занятиях, если они получают оценку «отлично», пройдя тест на сайте по адресу GCI/monthly/SQA/quiz.

15.

Управление рисками.

Команда контроля качества должна стараться обнаружить факторы риска как можно раньше. Процедуры управления рисками описаны в разделе 3.3 SPMP.

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

Этапы получения требований, обсуждаемые в этой главе, изображены на рис. 3.1.

♦ Разделы 3.1-3.7.

♦ Руководство по учебному проекту: С-требования для учебного примера.

♦ Упражнения.

♦ Пример: Спецификация требований к программному обеспечению (SRS): часть 1 (часть 2 — конец главы 4).

Учебные цели этой главы.

+ Отделить С-требования (требования заказчика) от D-требований (детальных требований).

♦ Освоить разные способы выражения С-требований:.

♦ варианты использования;.

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

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

♦ наброски пользовательского интерфейса.

♦ Быть в состоянии написать первые части SRS.

3.1. Введение в анализ требований.

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

3.1.1. Значение анализа требований.

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

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

Вообще говоря, следующее выражение (N) не является требованием для приложения.

Балансы счетов клиентов будут храниться в таблице под названием «балансы> в базе данных Access.

Второе выражение касается того, как должно быть построено приложение, а не того, что это приложение должно делать.

Требование на одном уровне часто переходит в одно или несколько конкретных требований на следующем, более подробном уровне. Чтобы понять это, представьте себе, что ваше требование для будущего дома — «видеть горы на 180 градусов вокруг». Это требование может перейти в утверждение, что «терраса справа должна иметь размеры 20 х 50 футов». Это более конкретное требование на более детальном уровне. Аналогично, утверждение (N) действительно может стать требованием на последующих уровнях процесса разработки.

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

Результатом анализа требований является документ, который обычно называют спецификацией требований, или спецификацией требований к программному обеспечению (SRS — Software Requirements Specification).

3.1.2. С-требования и D-требования.

В течение некоторого времени проходили дебаты относительно того, кому «принадлежат» требования: заказчику или разработчикам (например, [10]). Для решения этого вопроса мы разделяем анализ требований на два уровня [93, 17]. Первый уровень документирует желания и потребности заказчика и пишется на языке, понятном заказчику. Результаты иногда называют требованиями заказчика, или С-требованиями. Первичной аудиторией для С-требований будет сообщество заказчиков, а уже вторичной — сообщество разработчиков. Второй уровень документирует требования в специальной, структурированной форме. Эти документы называются требованиями разработчика, или D-требованиями. Первичной аудиторией для D-требований будет сообщество разработчиков, а уже вторичной — сообщество заказчиков.

Данная книга использует стандарт IEEE для документирования требований. Разница между С- и D-требованиями согласно основным идеям шаблона документа стандарта IEEE проиллюстрирована на рис. 3.2. В данной главе обсуждаются С-требования. D-требования описаны в главе 4.

Хотя целевые аудитории для С- и D-требований различны, заказчики и разработчики тесно сотрудничают при создании успешных продуктов. Один из способов, позволяющих обеспечить хорошее взаимодействие, — совместная работа представителей заказчика и разработчиков. Некоторые организации-разработчики даже отказываются браться за работу без предоставления такой возможности. Это принцип экстремального программирования, упомянутого в главе 1. Участие представителей заказчиков в работе инженеров широко практикуется Министерством обороны США. Например, автор этой книги однажды работал в качестве сотрудника морского флота США над системой корабля вместе с инженерамиподрядчиками.

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

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

Для иллюстрации этих моментов разберем следующее требование для научного приложения: приложение должно показывать длину гена Х12345 в системном окне (требование 7824).

Ниже приведен список действий, которые следует выполнить для этого и других требований. Каждое требование должно:.

♦ быть четко выражено;.

♦ быть легко доступно;.

+ быть пронумеровано;.

♦ сопровождаться подтверждающими тестами;.

♦ предусматриваться проектом;.

♦ быть учтено кодом;.

♦ быть протестировано отдельно;.

♦ быть протестировано вкупе с другими требованиями;.

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

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

3.1.4. Типичная схема процесса анализа требований.

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

Существует несколько способов организации SRS. Мы будем использовать — и модифицировать — стандарт IEEE 830-1993, оглавление которого приведено ниже. Содержание стандарта IEEE 830-1993 будет описано в этой главе. Раздел 3 стандарта, «Конкретные требования» (D-требования), будет расширен и использован в следующей главе.

1. Введение.

1.1.

Цель.

1.2.

Область применения.

1.3.

Определения, термины и сокращения.

1.4.

Ссылки.

1.5.

Обзор.

2.

Общее описание.

2.1.

Перспективы продукта.

2.1.1.

Системные интерфейсы.

2.1.2.

Пользовательские интерфейсы.

2.1.3.

Аппаратные интерфейсы.

2.1.4.

Программные интерфейсы.

2.1.5.

Коммуникационные интерфейсы.

2.1.6.

Ограничения по памяти.

2.1.7.

Операции.

2.1.8.

Требования по адаптации.

2.2.

Функции продукта.

2.3.

Пользовательские характеристики.

2.4.

Ограничения.

2.5.

Предположения и зависимости.

2.6.

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

3.

Конкретные требования (глава 4).

4.

Сопровождающая информация (глава 4).

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

3.1.5. Преимущества анализа требований и проблемы, связанные с ним.

Несовершенные требования (то есть не исправленные до полного завершения документа) обходятся очень дорого. По оценкам, их в 20-50 раз дороже исправить, если они попали в процесс разработки. В финансовых терминах, если стоимость обнаружения и исправления ошибки во время формулирования требований равна $100, то стоимость обнаружения и исправления того же самого дефекта в конце процесса разработки достигает от $2000 до $5000. Кто откажется вложить $100, если это будет гарантировать окупаемость от $2000 до $5000 через год или два? Думайте о поиске каждой ошибки на ранней стадии формулирования требований, как о таком вложении средств.

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

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

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

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

Важным выигрышем от анализа требований является достижение понимания и согласия относительно приложения, которое вы собираетесь создать [17]. Это базис контрактов любого вида.

Большинству из нас говорили, что «писать — значит думать», и частично это справедливо при формулировании требований. Довольно много разработчиков пытаются избежать формулирования требований, нетерпеливо приступая прямо к написанию кода. По опыту автора книги один разработчик, отрицательно относящийся к процессу, вдруг начинает производить поразительное количество кода. Затем он объявляет команде: «Я выполнил свою часть — теперь вы, ребята, можете тратить свое время на составление всех сопровождающих документов. А я пошел». Такое кодирование сравнимо с выливанием тонн бетона для постройки моста, не зная, откуда и куда он должен в итоге быть построен (не говоря уже о его финальном дизайне). Автор считает, что нежелание писать требования связано не с тем, что написание считается слишком простым, чтобы о нем беспокоиться, а с тем, что корректное написание требований на самом деле довольно сложно. Конкретные, реалистичные и измеряемые процедуры для написания требований являются профессиональным испытанием.

3.2. Взаимодействие с заказчиком 3.2.1. Источники возникновения требований.

Этот раздел сконцентрирован на вопросах взаимодействия с людьми для анализа требований. Именно люди, бесспорно, являются источниками возникновения требований. Брэкет [17] отобразил на графике приложения нескольких типов (рис. 3.4), чтобы продемонстрировать уровень, до которого требования собираются у людей, а не из других источников, таких как письменный материал. График классифицирует приложения по степени наложенных на них ограничений. Это касается требований к приложениям, которые нельзя изменить. Например, на приложение, описывающее траекторию полета ракеты, наложены ограничения силы тяжести, на химические реакции — ограничения законов физики. Чем меньше объективных ограничений имеет проблема, тем большее количество ее ограничений должно быть получено от людей. Например, в экстремальном случае — нашей видеоигре, поскольку это продукт полностью воображаемый, большинство ограничений должно быть получено от людей. В противоположном случае — системы управления ракетами ограничены скорее физикой движения, а не пожеланиями людей, и поэтому требования берутся из физических уравнений.

3.2.2. Определение заинтересованных лиц.

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

В случае готовых к употреблению («коробочных») приложений, таких как системы обработки текстов, электронные таблицы и среды разработки, разработчики уделяют основное внимание доступности приложения как можно большему числу пользователей. Хотя это может быть сложной рыночной проблемой, очевидно, что пользователи являются наиболее значительными финансово заинтересованными лицами. Для большинства крупных проектов, однако, определение наиболее важных финансово заинтересованных лиц является сложной проблемой. Заказчик часто является стороной, оплачивающей разработку приложения, но даже это не всегда корректно. Например, морской флот может платить за разработку, но каждодневными заказчиками разработчиков могут быть государственные служащие, а не морские офицеры. Но тогда разве не являются налогоплательщики заказчиками, поскольку на самом деле это они платят за приложение? Заказчиком субподрядчика является основной подрядчик. Заказчиком коробочного приложения — множество потенциальных покупателей, установленное отделом маркетинга. Когда приложение разрабатывается для внутреннего использования в компании, такого как обработка заявок в страховой фирме, заказчиком является сама компания.

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

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

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

3.2.3. Примеры пожеланий заказчиков.

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

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

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

Приведем результат С-требований для этого примера.

♦ Это ролевая игра, моделирующая все стороны жизни персонажа игрока.

♦ Игровые персонажи, не контролируемые игроком, называются внешними персонажами.

♦ У каждого игрового персонажа есть набор характеристик, таких как ста, скорость, терпение.

♦ Каждая характеристика имеет численное значение.

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

♦ Результат контакта зависит от значений характеристик и от зоны, в которой произошел контакт.

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

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

♦ Успех определяется по одному из принципов:.

♦ максимальное число очков-жизней, накопленное игроком;.

♦ выживание в течение как можно более продолжительного периода.

Полный текст отчета приведен в разделе «Общее описание» учебного примера. Примерами нерешенных вопросов являются: один или несколько персонажей игры будут находиться под контролем игрока; что конкретно происходит при общении двух персонажей; можно ли будет играть в эту игру через Интернет. Задачей инженера является выяснение этих вопросов с заказчиком.

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

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

3.2.4. Проведение опроса и документирование.

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

ОДИН ИЗ СПОСОБОВ ПРОВЕДЕНИЯ ОПРОСА ЗАКАЗЧИКА -.

Перед интервью:.

1.

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

2.

Спланируйте интервью с фиксированным временем начала и конца:.

♦ должны присутствовать как минимум два члена команды разработчиков;.

♦ приготовьтесь записывать на пленку. Во время интервью:.

3.

Сконцентрируйтесь на слушании;.

не будьте пассивны: исследуйте сами и побуждайте собеседника:.

♦ настаивайте на понимании желаний и изучении нужд;.

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

делайте подробные заметки.

4.

Спланируйте следующую встречу. После интервью:.

5.

Составьте черновик С-требований SRS, используя стандарт.

6.

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

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

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

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

После собрания делается черновик С-требований, например, в формате стандарта IEEE. Затем этот черновик посылается по электронной почте заказчикам для комментариев. Повторные опросы проводятся до полной удовлетворенности заказчиков С-требованиями.

3.3. Описание С-требований (требований заказчика).

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

3.3.1. Концепция работы.

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

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

♦ Система реального времени для предсказания погоды.

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

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

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

3.3.2. Варианты использования.

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

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

1.

Пользователь открывает меню Файл.

2.

Система показывает команды Новый и Открыть.

3.

Пользователь выбирает Открыть.

4.

Система показывает окно файлов.

5.

Пользователь вводит каталог и имя файла.

6.

Пользователь щелкает на кнопке Открыть.

7.

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

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

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

В нотации U ML овал означает вариант использования. В двух случаях действующим лицом является играющий. Каждый вариант использования является последовательностью действий, предпринимаемых игроком и игрой Встреча, как показано в варианте использования «Инициализировать». Вариант использования «Вступить в контакт с внешним персонажем» представляет собой типичную последовательность действий игры и игрока каждый раз, когда главный персонаж игрока и внешний персонаж оказываются одновременно в одном месте. В варианте использования «Установить правила» действующим лицом является разработчик игры: действующее лицо описывает возможность игры поддерживать редактирование правил взаимодействия персонажей. Обратите внимание, что вариант использования «Переместиться в соседнюю зону» исследуется в примере в конце главы, а вариант использования «Установить правила» не включен в пример.

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

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

1.

Пользователь выбирает «добавить чеки» или «согласовать счет».

2.

Если выбрано «добавить чеки»:.

3.

Происходит одно действие.

4.

Происходит другое действие.

5.

...

6.

Если выбрано «согласовать счет»:.

7.

Происходит одно действие.

8.

Происходит другое действие.

9.

...

Это было бы лучше разбить на варианты использования «Выбрать вариант», «Добавить чеки» и «Согласовать счет».

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

Очевидно, что похожие варианты использования не имеют большой ценности. Один относительно другого, варианты использования должны быть либо последовательными, либо ортогональными. Два варианта использования являются последовательными, если один непосредственно следует за другим. Ортогональные варианты использования относятся к абсолютно разным возможностям. Например, в приложении для склада товаров варианты использования для действующих лиц начальник и финансовый аналитик будут ортогональными. В примере видеоигры Встреча вариант использования «Установить правила» является ортогональным для варианта использования «Встретить внешний персонаж». В главе 4 показано, как варианты использования комбинируются для создания новых вариантов; там также представлено наследование вариантов использования.

Якобсон [63] дал начало идее о вариантах использования, заметив, что несмотря на колоссальное количество потенциальных вариантов выполнения, в большинстве приложений было задумано относительно немного типичных вариантов использования. Он предложил начинать проектирование приложения с написания вариантов использования с последующим их применением для выбора классов. Эта техника продемонстрирована в главе 4. Варианты использования также могут применяться для разработки прототипа (см. далее). Они являются основой для тестовых планов системного уровня. Мы продемонстрируем эти стратегии на нашем примере.

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

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

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

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

Предположим, например, что наш заказчик пытается объяснить тип банковского приложения, который ему нужен, начиная с депозитов на счет. Функциями депозита могут быть получить депозит от пользователя, проверить операцию по депозиту, чтобы убедиться в ее законности. Эти функции представлены кругами на рис. 3.7. Далее, тип данных, передаваемых между этими функциями, отмечен на рисунке — номер счета и размер депозита. Пользователь также участвует, и это должно быть отмечено на диаграмме. В качестве другого примера рассмотрим функцию для подведения баланса счета, которая требует входные данные из хранилища данных, как показано на рисунке. Более полная диаграмма потоков данных для банковских требований показана на рис. 3.8.

Полная диаграмма содержит хранилище данных («Банки»), представляющее собой список банков, предоставляющих депозит через этот банкомат. Здесь также показан поток данных в ответ на запрос с более подробными данными счета.

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

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

От приложения зависит, помогут диаграммы потоков данных выразить требования или нет. Например, диаграмма потоков банковских данных на рис. 3.8 разъясняет многим читателям, как приложение должно себя вести, в то время как требования к видеоигре, вероятно, не были бы внятно объяснены с помощью такой диаграммы. Диаграммы потоков данных широко используются для описания проектных решений, и мы повторно обратимся к ним в главах 5 и 6.

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

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

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

♦ Настройка: состояние, в котором можно производить настройку игры.

♦ Подготовка: снаряжение персонажа игрока такими характеристиками, как сила и ум, может выполняться в отсутствие внешних персонажей.

♦ Ожидание: в этом состоянии с игроком ничего не происходит.

♦ Контакт: состояние, когда сравниваются значения характеристик персонажа игрока и внешнего персонажа.

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

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

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

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

3.3.5. Черновик пользовательского интерфейса и других интерфейсов.

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

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

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

3.3.5.1. Шаги разработки пользовательских интерфейсов.

В [35] предлагается 11 этапов разработки пользовательских интерфейсов. Автор упростил их; каждый из этих шагов применим к процессу обработки требований заказчика и (или) процессам обработки подробных требований.

1.

Узнайте своего пользователя (С) (обработка С-требований).

2.

Поймите назначение проектируемой системы (С).

3.

Примените принципы хорошего экранного дизайна (С, D).

4.

Подберите подходящий тип окон (С, D).

5.

Разработайте системные меню (С, D).

6.

Выберите соответствующие аппаратные устройства управления (С).

7.

Выберите соответствующие экранные элементы управления (С).

8.

Организуйте и создайте раскладку окон (С, D).

9. Выберите подходящие цвета (D).

10.

Создайте осмысленные значки (С, D).

11.

Предоставьте эффективные сообщения, обратную связь и руководство (D).

Шаг 1 (знакомство с пользователем). На этом шаге рекомендуется оценить общество конечных пользователей программы. В общих чертах основные факторы намечены в табл. 3.1.

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

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

Шаг 3 (понимание принципов хорошего экранного дизайна). Перечислим некоторые основные элементы хорошего экранного дизайна.

1) Убедитесь в единообразии экранов приложения, а также в логичности каждого отдельно.

♦ Соглашения; процедуры; местоположение.

2) Сделайте предположение о том, откуда обычно пользователь будет начинать работу.

♦ Часто «первый» элемент размещают в верхнем левом углу.

3) Сделайте навигацию как можно более простой:.

♦ выровняйте похожие элементы;.

♦ сгруппируйте похожие элементы;.

♦ учтите границы вокруг похожих элементов.

4) Примените иерархию для подчеркивания порядка важности.

5) Примените принципы приятных визуальных эффектов:.

♦ баланс, симметрия, регулярность, предсказуемость;.

♦ простота, единообразие, пропорциональность, экономия.

6) Предоставьте подписи.

Здесь также отмечены несколько факторов, которые часто применяются для создания «приятного» интерфейса. Хотя это не более чем введение в область визуальных эффектов, данные принципы довольно полезны даже на этом уровне. В качестве примера мы применим некоторые из этих принципов к экрану, используемому для ввода информации о заказчиках и их счетах. Для улучшения интерфейса мы начнем с левого верхнего угла, размещая в первую очередь наиболее важные элементы и группируя похожие элементы. Улучшение программы, достигнутое в результате применения этих принципов [35], представлено на рис. 3.12 и 3.13. На рис. 3.14 показано, где использовались некоторые принципы хорошего экранного дизайна.

Шаг 4 (выбор подходящего типа окна). Цели каждого пользовательского интерфейса могут обслуживаться наиболее эффективно одним или двумя конкретными типами окон. Пять основных целей графических пользовательских интерфейсов и типы окон, удовлетворяющие каждой из них, перечислены на рис. 3.15 и 3.16. Для типов окон использована терминология Windows, хотя они и являются типовыми.

1. Цель: показать свойства объекта — Окно свойств

2. Цель: получить дополнительную информацию для выполнения конкретного задания или команды — Диалоговое окно

3. Цель:.

предоставить информацию — Окно сообщения

4. Цель:.

предоставить набор элементов управления — Окно с палитрой

5. Цель: предоставить.

дополнительную информацию — Всплывающее окно.

Рис. 3.16. Использование окон (2).

Шаг 5 (разработка системного меню). Ниже перечислены некоторые правила для создания главных меню, предложенные в [35].

♦ Сделать главное меню.

♦ Показать все уместные альтернативы (но только их).

♦ Привести структуру меню в соответствие со структурой задачи приложения.

+ Минимизировать число уровней меню.

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

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

Шаг 7 (выбор подходящих экранных элементов управления). Экранные элементы управления — это символы, появляющиеся на мониторе, с помощью которых пользователь передает программе вводимые данные и свои намерения. Сюда относятся значки, кнопки, текстовые окна, списки, изображенные на рис. 3.17. Правила организации экранных элементов управления в окне практически те же, что и для дизайна экрана в общем. Их число также обычно варьируется от пяти до девяти. Это число, однако, может быть увеличено в случае использования иерархии. Например, на рис. 3.13 имеется 20 возможностей для выбора, однако интерфейсом легко управлять, поскольку 20 элементов организованы в 6 групп.

Шаг 8 (организация и планирование окон). Правила для компоновки многочисленных окон аналогичны правилам для дизайна одиночных окон (в том числе симметрия, пропорциональность и т. д., см. шаг 3), но сюда включена также и организация окон — соприкасающиеся или каскадные. Последние термины проиллюстрированы на рис. 3.17.

Шаг 9 (выбор подходящих цветов). При использовании с умением и со вкусом цвет может обогатить экран. Использование цвета не делает автоматически пользовательский интерфейс более полезным или привлекательным, однако может легко испортить его. По выражению знаменитого дизайнера Поля Рэнда «цвет — это воплощение сложности» [91]. Инженеры-программисты, не сотрудничающие с профессиональными дизайнерами, должны быть очень умеренными и консервативными в использовании цветов. Сначала попробуйте черно-белую схему. Если есть очевидная потребность в этом, добавьте один цвет. Убедитесь, что это помогает пользователю. Серьезно подумайте перед тем, как добавлять больше цветов. Наблюдение за грамотно сделанными программами, такими как широко используемые текстовые редакторы, может подсказать, как правильно использовать цвета. Можете быть уверены, что эти интерфейсы разрабатывали опытные профессионалы, и нетренированный программист может только выиграть от имитации подобных приложений. Синий цвет широко встречается в самых разнообразных окнах. Часто рекомендуется соблюдать симметрию цветов, и эта симметрия может быть нескольких видов. Например, текстовый редактор автора данной книги использует преимущественно три градации синего, встречающиеся в симметричном наборе стандартной цветовой палитры. Другие два используемых цвета — это желтый и, в меньшей мере, зеленый. Эти цвета используются в малых количествах, только акцентируя дополнительную функциональность, и не конкурируют с основными цветами, такими как черный и серый.

3.3.5.2. Примеры черновиков требований.

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

Карандашный набросок графического пользовательского интерфейса для задания характеристик персонажа игры показан на рис. 3.18. Такие программные продукты, как Visual Basic и Java Beans, позволяют быстро создать графический пользовательский интерфейс. Желание сделать этот интерфейс частью финального продукта понятно, но это целесообразно, только если:.

♦ язык графического пользовательского интерфейса является приемлемым языком для этой части приложения;.

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

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

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

3.3.5.3. Другие интерфейсы.

Помимо пользовательских интерфейсов, приложения часто должны взаимодействовать с другими системами; в этом случае интерфейс определяется в SRS. В качестве примера может послужить интернет-приложение, взаимодействующее с серверной резидентной CGI-программой (CGI — Common Gateway Interface, общий шлюзовой интерфейс). Формат, требуемый CGI-программой, должен быть установлен, например:.

/cgi - oin/quiery?pg=&dk=.

(pg и dk — параметры серверной функции из .../query)

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

float getValueCfloat principle, int numYears).

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

3.3.6. Подведение итогов и руководство для формулирования С-требований.

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

ОДИН ИЗ СПОСОБОВ ВЫРАЗИТЬ ТРЕБОВАНИЯ ЗАКАЗЧИКА -.

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

♦ Если требование представляет собой взаимодействие пользователя и приложения, выразите его с помощью варианта использования.

1.

Дайте имена вариантам использования.

2.

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

3.

Запишите последовательность действий пользователя и приложения.

4.

Минимизируйте ветвление.

5.

Используйте общую форму.

6.

Избегайте конкретных имен и значений. Например, вместо текста «Эд кладет $300» следует написать «клиент вводит размер депозита».

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

1.

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

2.

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

3.

Покажите пути передачи данных между обрабатывающими элементами. Укажите типы данных, передаваемых в каждом случае.

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

1.

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

2.

Укажите исходное состояние с помощью специальной стрелки.

3.

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

4.

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

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

3.4.

Методологии и инструментальные средства для С-требований.

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

Структурный анализ формализует потоки данных и функциональную декомпозицию. В частности, технология структурного анализа и проектирования (SADT — Structured Analysis and Design Technique) [92] являются систематизированным подходом к работе с системными спецификациями. SADT описывает проблему на самом высоком функциональном уровне как прямоугольник с входами, ограничениями и выходами («диаграмма контекста»). Это разлагается в следующий уровень диаграммы потоков данных, который затем аналогично разлагается дальше. В результате появляется иерархия диаграмм с возрастающим уровнем детализации потоков данных. Структурный анализ рассматривает приложение с точки зрения функциональности. Эта функциональность и реализована затем в иерархии функций.

Системы реального времени могут быть эффективно описаны с помощью диаграмм переходов состояний, используемых с объектной ориентацией или без (например, [108]). В частности, Statemate — это графический инструмент, использующий переходы состояний, опирающийся на работу Харела [41]. Он предоставляет основанный на состояниях метод, с помощью которого можно планировать и анализировать сложные системы. Например, современные суда имеют несколько резервных навигационных систем. В результате комбинирования системных аварийных состояний навигационные возможности на некоторых кораблях могут находиться в одном из огромного числа возможных состояний. Это может быть трудно понять без графического представления состояний (по личному опыту автора). Уже было рассмотрено в случае игры Встреча, что структуру игры можно легко понять с помощью системы переходов состояний, управляемой событиями. Большинство обозначений Statemate заимствованы в UML.

Система PSL/PSA (Problem Statement Language/Problem Statement Analyzer) (например, [106]) была одной из ранних систем для выражения требований. Исходные версии были основаны на текстовом представлении. Типичными заголовками компонентов были: ИМЯ ПРОЦЕССА, ОПИСАНИЕ, ГЕНЕРИРУЕТ, ПОЛУЧАЕТ, ЯВЛЯЕТСЯ ЧАСТЬЮ, ИСПОЛЬЗУЕТ. Описания компонентов хранятся в базе данных; их можно получить и обработать различными способами.

3.5.

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

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

3.5.1. Быстрое прототипирование.

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

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

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

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

Как пример представьте себе приложение для электронной коммерции, в котором компания-производитель одежды желает продавать товары через Интернет, хранить информацию о клиентах и предоставлять клиентам возможность получать свое фото в одежде из каталога. Финансовая оценка для разных уровней прототипирования для программы, продающей одежду, приведена в табл. 3.2. Для каждой из четырех характеристик, рассмотренных в прототипе, сделано несколько оценок: стоимость работы; процент работы, который будет повторно использоваться в самой программе (то есть не будет отброшен); и полная прибыль от прототипа. Под полной прибылью здесь понимается оценка того, что будет получено, если характеристика будет включена в прототип, но код не будет использован в программе. Например, мы подсчитали, что если прототип «примерка одежды» будет построен, это сэкономит минимум $20 ООО при разработке. Оценка базируется на нижеследующих факторах.

♦ Предотвращение пустой траты времени на предложенные требования, которые, как видно из прототипа, не нужны (то есть минимум три ненужных требования из 100; на этап требований выделено $300 000, сэкономлено $9000).

♦ Разработка программного проекта «примерка одежды», что уменьшает риски разработки (то есть оценка того, что это сэкономит минимум одну человеко-неделю времени проектирования = $2000).

♦ Переработка, которая может возникнуть из-за изменения требований клиентом после того, как он увидит окончательный продукт (то есть переработка минимум трех требований по $3000 каждое = $9000).

Существует минимальная экономия, эквивалентная $9000 + $2000 + $9000 = - $20 000.

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

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

Как только оценки сделаны, выполняется несложная часть вычисления лучшего и худшего сценария. Это показано в табл. 3.3. Минимальное значение выгоды получается из самой пессимистичной комбинации — высоких затрат, низкой общей прибыли, и низкого процента повторного использования. Максимальная выгода рассчитывается аналогично. Например, максимальная выгода (для наиболее оптимистичной альтернативы) для части прототипа «снимки пользовательского интерфейса» будет:.

[максимальная оцененная прибыль] - [минимальная оцененная стоимость] = = $80 000 - [(минимальная оцененная стоимость) х (процент неиспользования)] = = $80 000 - [$10 000 х 50 %] - $75 000.

Усреднение — это один из способов работы с разницей между худшими и лучшими случаями. В результате получаем положительную выгоду для всех предложенных частей прототипа за исключением части «примерка одежды», которая оценена в -$4000: общий убыток $4000. Это приведет в дальнейшем к относительно низкой прибыли, высокой стоимости разработки и низкому вторичному использованию.

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

Быстрая разработка приложений (RAD — Rapid Application Development) основана на прототипировании. По мнению автора, название «Быстрая разработка приложений» вводит в заблуждение. Если бы RAD действительно была способом быстрой разработки настоящих приложений, то все бы так и работали. Этот волшебный способ стал бы нормой и не мог бы рассматриваться как «быстрый».

3.5.2. Исследование осуществимости.

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

Численные модели стоят дорого, поскольку они сами по себе являются программами, требующими от программистов выполнения всех артефактов, описанных в этой книге, таких как, например, создание отдельного SRS! Автор однажды соприкоснулся с моделированием большой системы, находящейся в разработке. Никто не воспринимал требования к модели серьезно, поскольку это «не был реальный продукт». В результате стоимость поддержки и использования модели выросла до астрономических размеров. Например, чтобы выполнить изменения, приходилось сначала искать сотрудника, «знакомого с системой». Оценки осуществимости часто встречаются в крупных оборонных программах, требующих дорогостоящего программного обеспечения и оборудования.

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

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

3.6. Корректировка проекта.

для отображения анализа С-требований.

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

3.6.1.

С-требования и размеры проекта.

Для больших проектов анализ требований клиента достаточно формален и организован. Например, министерство обороны США часто публикует запрос о предложениях только для того, чтобы разработать SRS. Такой запрос содержит только высокоуровневое описание проекта. Этот запрос можно представить себе как С-требование, а продукт фирмы-исполнителя — как D-требование. Нескольким сотрудникам министерства обороны дается задание работать с фирмой-исполнителем над SRS, причем эта фирма не обязательно должна быть фирмой, выбранной для проектирования и реализации самой программы. Чтобы убедиться в выполнимости требований, проводятся многочисленные собрания. На эти собрания приглашаются сотрудники фирмы-исполнителя, государственные чиновникиспециалисты и менеджеры, а также офицеры морского флота или воздушных сил США, и т. д. SRS может разрастись до тысяч страниц.

3.6.2.

Влияние анализа С-требований на план проекта.

Как только С-требования собраны, SPMP можно обновить (табл. 3.4). Такое обновление происходит в течение всего жизненного цикла программы.

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

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

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

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

3.7. Будущие направления и подведение итогов по С-требованиям.

3.7.1. Будущие направления.

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

В течение нескольких лет считалось, что инструменты автоматизированной разработки программ (CASE) могут значительно упростить процесс отслеживания требований. Использование таких инструментов прошло через стадии оптимизма н пессимизма. Другое направление исследований (например, [102]) идет гораздо дальше использования идей вариантов использования, предоставляя библиотеку с высокоуровневыми объектно-ориентированными образцами проектирования, с которыми инженер по требованиям пытается сопоставить проект. Некоторые считают, что многочисленные требования могут быть составлены из библиотек уже существующих вариантов использования. Было несколько попыток применить искусственный интеллект к анализу требований, в основном в форме интеллектуальных агентов; однако ни один из них не используется широко и повсеместно. Растущее взаимодействие пользователей с компьютерами произвело эффект на анализ требований, открыв новый спектр вопросов (например, [109]).

3.7.2. Подведение итогов по С-требованиям.

В этой главе описан процесс, посредством которого требования клиента к продукту добываются и записываются способом, понятным клиенту. Требования клиента документируются в форме разделов 1 и 2 SRS по стандарту IEEE 830-1993. Для этого используются различные техники выявления и формулирования С-требований.

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

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

♦ Включая пользовательский интерфейс.

♦ D-требования — для разработчиков.

♦ Необходимо использовать стандартные SRS (например, IEEE).

♦ Варианты использования очень эффективны.

♦ Повторное использование в тестовых примерах.

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

Руководство по учебному проекту. С-требования для видеоигры Встреча.

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

Этап 1. Подготовка.

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

[В этом руководстве описывается процесс для С-требований. Учебный проект в следующей главе описывает D-требования.].

Халл и Карен подготовились к сбору информации. Они классифицировали процесс по следующим этапам: подготовка, интервью, письменное изложение и проверка. Метрики, которые они выбрали, в основном были продиктованы политикой фирмы.

♦ Затраченное время.

♦ Число страниц сформулированных С-требований.

♦ Самооценка артефактов по шкале 1-10 (не установлена политикой фирмы).

♦ Дефекты, обнаруженные во время инспекции.

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

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

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

На еженедельном собрании Халл представил нижеследующий план анализа требований.

Неделя 1:.

Халл и Карен: интервью с Бетти; начать писать черновик С-требований. Ферн и Эл: поиск других источников информации по требованиям. Неделя 2:.

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

Халл и Карен: завершить черновик С-требований, связаться по электронной почте с Бетти для ее комментариев; организовать интервью с выбранными дополнительными людьми; послать им существующую спецификацию; создать законченный документ требований для 1 итерации; передать его под управление конфигурациями. Неделя 3:.

Команда: утвердить SRS для первой итерации.

Халл и Карен: провести интервью с запланированными людьми; отредактировать и расширить спецификацию; связаться по электронной почте.

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

Неделя 4:.

Команда: предоставить информацию для черновика SRS; утвердить план для анализа D-требований [следующая глава].

Халл и Карен: написать SRS и послать ее по электронной почте всем интервьюерам. Неделя 5:.

Халл и Карен: решить вопросы, затронутые интервьюерами; записать результаты; разослать по электронной почте команде; начать процесс разработки D-требований [следующая глава]. Команда: проверить С-требования.

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

Халл спланировал первое интервью с Бетти в комнате 1428 с 10:00 до 11:30. Он послал ей короткое письмо, описывающее историю проекта и создал следующий очень простой план проведения встречи:.

10:00-10:15. Халл: мотивы проекта.

10:15-11:30. Интервью с Бетти: требования заказчика.

Халл решил не предоставлять больше подробностей, поскольку он хотел, чтобы требования Бетти повлияли на оставшуюся часть собрания.

Этап 2. Интервью с заказчиком.

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

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

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

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

Бетти, Карен и Халл вместе набросали несколько экранных изображений. На одном была изображена типичная встреча, на другом — экран для ввода характеристик игровых персонажей. Состоялась дискуссия относительно ракурса игрока, то есть того, как игрок видит игровую сцену. Бетти хотела иметь ракурс «из глаз». Карен считала, что требуемая сложность для такого ракурса выведет проект за рамки бюджета. Пришли к соглашению на модифицированном виде сверху, подходящем для прототипа. Это было отображено на черновиках изображений экранов. Однако все согласились, что потребуется значительная доработка пользовательского интерфейса.

В результате создания черновых вариантов интерфейсов Карен показалось, что игру можно понять только посредством описания состояний. Бетти не была знакома с этим термином, но она довольно уверенно использовала термин «режимы» типичной ролевой игры, что оказалось той же идеей. Карен и Халл набросали требуемые режимы игры и просмотрели вместе с Карен, каким образом игра переходит из одного состояния в другое.

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

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

Этап 3. Написание спецификации требований к программному обеспечению (SRS).

Халл и Карен разбили задачу написания SRS на части. Они использовали стандарт IEEE SRS, разделы 1 и 2 (раздел 3 состоит из детальных требований, процесс для которых обсуждается в руководстве к учебному проекту в главе 4). Чтобы избежать конфликтующих записей, они постарались сделать их разделы как можно более независимыми. Халл вспомнил свой предыдущий проект, где команда потратила очень много времени на согласование частей, написанных разными людьми, в то время как было бы гораздо быстрее, если бы всем этим занимался один человек.

Они обсудили, как лучше расставить приоритеты по требованиям, поскольку становилось очевидно, что в противном случае список требований станет гораздо длиннее того, что команда сможет реально проработать. Халл хотел упорядочить все требования, но Карен указала, что затраченные на это силы будут неоправданны: большинство важнейших требований будет и так выполнено, так что их точный порядок не гак важен. Почти ничто из малоприоритетных выполнено не будет, поэтому время, потраченное на них, также пропадет. Они решили использовать метод отбраковки, чтобы упорядочить требования по трем категориям: необходимые, необязательные и желательные (что попросту означает «ни первое, ни второе»). Они также решили, что может потребоваться позднее упорядочить необходимые требования. Это сэкономило им много времени. Они описали свою схему классификации в разделе 2.6 SRS («Распределение требований»).

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

Карен подготовила черновик пользовательского интерфейса. Для этого она воспользовалась инструментом PowerPoint, вместо того чтобы создавать его с помощью Java — целевого языка. Она посчитала PowerPoint подходящим, поскольку в этой части SRS пользовательский интерфейс предполагался черновым — подробно пользовательский интерфейс определен в разделе 3 — и в любом случае он, скорее всего, должен был сильно измениться. Это помогло Халлу и Карен показать черновики Бетти и остальным, получить обратные отзывы и затем точно определить пользовательский интерфейс для D-требований.

Этап 4. Завершение.

Разделы 1 и 2 SRS были посланы Бетти по электронной почте. Она обнаружила, что Халл и Карен включили только два из трех вариантов использования, а третий вариант, описывающий движение персонажа игрока, был пропущен. Этот дефект был записан с высоким приоритетом.

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

Халл разослал членам команды разделы 1 и 2 SRS, чтобы они подготовились к проверке.

Лидер команды Эд слышал об Арлане Ховарде, специалисте по маркетингу, хорошо знакомом с индустрией видеоигр. Финансовые поручители пожелали профинансировать дальнейший анализ требований на уровне заказчика, и Халл с Карен приготовились к встрече с Ховардом. Ховард не мог уделить им более получаса времени, поскольку был очень занят. Карен разработала список вопросов и тем с приоритетами и послала его вместе с существующим черновиком глав 1 и 2 SRS. Они планировали завершить написание С-требований после разговора с Ховардом.

Команда также планировала процесс разработки D-требований [руководство учебным проектом в главе 4].

Этап 5. Метрики и итоги.

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

На следующем недельном собрании Халл и Карен подвели итог метрике (табл. 3.6, звездочкой помечены организационные нормы этого проекта). Команда согласилась с приведенными наблюдениями.

Упражнения.

Ответы и подсказки для упражнений, помеченных символами «о» или «п», приводятся в конце этой главы.

Вопросы для проверки.

П3.1

. В чем разница между С-требованием и D-требованием? П3.2". В чем достоинства и недостатки разделения требований на категории С и D?.

ПЗ.З". Что такое вариант использования?.

П3.4". Является ли следующий текст вариантом использования: «Система будет предоставлять совет начинающему пользователю Windows относительно того, как следует выполнять операции Windows».

П3.5°. Для какой из следующих программ имеет смысл создавать законченный прототип (да / нет / возможно):.

1) система отслеживания посылок в большой почтовой компании;.

2) простая система хранения информации о частных коллекциях CD-дисков;.

3) система поддержки пенсионных счетов для маленькой фирмы.

П3.6". Какое из следующих приложений требует исследования выполнимости:.

1) база данных для хранения и просмотра информации о сотрудниках;.

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

Общие упражнения.

03.1". Брэкетт считает, что чем больше ограничений наложено на программу, тем меньше можно полагаться на людей как на источник требований (см. его график на рис. 3.4, сравнивающий «приближенный процент требований, собранных у людей», с «типом программы»). Можете ли вы придумать программу, не соответствующую этому графику?.

03.2. Предположим, что вы пытаетесь описать автомобильную программу, сообщающую статус системы стартера на приборную панель. Как бы вы описали ее в общих терминах?.

03.3.

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

03.4.

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

1.

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

2.

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

3.

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

Упражнения в команде.

К3.1. Напишите С-требования для программы по выбору разработчиков. Следуйте форме IEEE 830-1993. Проследите, сколько времени у вас займет выполнение этого упражнения. Решите, какая часть требований была осознана командой. Подсчитайте, сколько времени займет получение 95% требований. Сформулируйте, как можно было бы улучшить процесс, использованный вами. Будьте конкретны и предоставьте примеры. КЗ.2.

1.

Определите человека вне команды, которому необходима небольшая программа. У этого человека вы будете узнавать С-требования, а затем покажете их ему.

2.

Вместе с вашим «заказчиком» определите метрику того, как он будет оценивать ваши С-требования. Также определите временные рамки для интервью (например, 1/2 часа).

3.

Проведите интервью с заказчиком и напишите С-требования.

4.

Попросите заказчика оценить и прокомментировать ваши С-требования в соответствии с выбранной метрикой.

Подсказки.

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

Ответы.

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

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

ПЗ.3. Вариант использования — это последовательность взаимодействий пользователя и программы в типичной ситуации.

П3.4. Это не вариант использования, поскольку здесь не продемонстрирована последовательность действий, выполненных приложением и пользователем приложения.

П3.5.

1.

Отслеживание посылок: да.

2.

Собрания CD-дисков: вероятно, слишком малое приложение, чтобы оправдать прототип.

3.

Пенсионные счета: возможно (нет, если программа предполагается для одного заказчика; возможно, если предполагается подавать ее как продукт многим заказчикам).

П3.6.

1.

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

2.

Автоматическое резюме: да.

Пример. Спецификация требований к программному обеспечению (SRS) для видеоигры Встреча, часть 1.

[Примечание для студентов. Использование стандарта для написания SRS поможет охватить все аспекты требований, о которых следует знать читателю, а также предоставит общепризнанную структуру. Существует несколько стандартов, однако мы сконцентрируемся на стандарте IEEE. Полный стандарт IEEE 830-1993 можно найти в [56]. Большинство организаций позволяют изменять стандарт, чтобы подогнать его к конкретному использованию. Использованный ниже шаблон изменяет стандарт, пропуская некоторые менее важные разделы и добавляя разделы с идеями операций и вариантов использования. Студент может сравнить заголовки нашего примера со стандартом, показанным в разделе 3.1.4. J.

[Примечание для студентов. Часть главы, в которой рассматривается пример, а именно разделы 1 и 2, описывает требования заказника (С-требования). Остальная часть документа — разделы 3 и 4, содержащие конкретные D-требования, — предоставлена в примере в конце главы 4. Не забудьте, что С-требования не имеют целью быть подробными в достаточной степени для проектирования и реализации: для этого существуют D-требования.].

История версий этого документа:.

♦

/yy/

Халл Фурнесс: исходный черновик.

♦ x/yy/zzz Карен Петере: проверка технической точности; изменения текста.

♦ x/yy/zzz Халл Фурнесс: проверка всего документа, небольшие улучшения.

♦ x/yy/zzz Карен Петере: проверка документа, внесение предложений.

♦ x/yy/zzz Карен Петере: перемещение вариантов использования в раздел 2.2.

♦

/yy/

Халл Фурнесс: коррекция стиля, смысл не изменен.

1. Введение.

1.1.

Цель.

[Примечание для студентов. Цель документа в целом (а не цель программы).].

Этот документ предоставляет все требования для видеоигры Встреча. Части 1 и 2 предназначены преимущественно для заказчиков приложения, но также будут интересны инженерам-разработчикам, разрабатывающим или поддерживающим его. Часть 3 предназначена в основном для разработчиков, но также представляет некоторый интерес и для заказчика.

1.2.

Область применения.

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

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

1.3.

Определения, термины и сокращения.

Приводятся в табл. 3.7. Таблица 3.7. Термины

1.4.

Ссылки.

План управления конфигурациями программного обеспечения (SCMP) для игры Встреча, версия 1.0.

Архитектура программного обеспечения (SDD) для игры Встреча, версия 1.2. План управления программным проектом (SPMP) для игры Встреча, версия 1.2 План контроля качества (SQAP) для игры Встреча, версия 1.0. План пользовательской документации (SUDP) для игры Встреча, версия 1.0. Документация по тестированию программного обеспечения (STD) для игры Встреча, версия 1.0.

1.5.

Обзор.

Преднамеренно пропущено.

[Примеча}1ие для студентов. Автор документа не считал необходимым заполнять этот раздел и планирует сделать обзор в разделе 2.].

2. Общее описание.

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

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

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

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

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

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

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

2.1. Перспективы продукта.

[Примечание для студентов. В этом разделе Встреча сравнивается с другими похожими или конкурирующими продуктами. Это полезный способ предоставить перспективы программы. Подзаголовок 2.1.1 этого раздела был изменен из стандарта IEEE в целях соответствия «концепции операций».].

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

2.1.1.

Концепции операций.

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

Игра Встреча может находиться в одном из следующих состояний (рис. 3.23):.

♦ Настройка

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

♦ Оповещение, система показывает окно с изображением статуса персонажей игрока.

♦ Установка характеристик: установка характеристик персонажа игрока. Этот процесс может длиться произвольное время и может производиться до тех пор, пока в окрестности персонажа игрока не появится внешний персонаж.

♦ Контакт: состояние, имеющее место каждый раз, когда внешний персонаж и главный персонаж игрока оказываются в одной зоне одновременно.

♦ Ожидание: игрок и внешний персонаж не активны.

♦ Эта схема переходов состояний прошла комплексное тестирование (прилагается).

2.1.2.

Концепции пользовательского интерфейса.

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

2.1.2.1.

Концепция зоны в пользовательском интерфейсе.

Зоны, в которых происходят встречи, будут выглядеть весьма условно (рис. 3.24).

2.1.2.2.

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

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

2.1.3.

Аппаратные интерфейсы.

Нет. В будущих версиях будет использоваться джойстик.

2.1.4.

Программные интерфейсы.

Нет.

2.1.5.

Коммуникационные интерфейсы.

Нет. В будущих версиях будет интерфейс для выхода в Интернет через модем.

2.1.6.

Ограничения по памяти.

Для игры Встреча потребуется не более 16 Мбайт оперативной памяти и 20 Мбайт вспомогательного запоминающего устройства (см. план теста; ссылка на тест будет приложена).

2.1.7.

Операции.

[Примечание для студентов. Обычные и особенные операции, требуемые от пользователя.].

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

2.1.8.

Требования по адаптации.

[Примечание для студентов. Требования к выполнению на конкретном компьютере; версии на разных языках (например, французский, японский, испанский).] Нет.

2.2. Функции продукта.

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

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

2.2.1. Вариант использования «Инициализировать».

Действующее лицо: игрок игры Встреча.

Вариант использования: текст варианта использования «Инициализировать» приведен на рис. 3.26. Вариант использования показан в контексте варианта использования «Встретить внешний персонаж» и «Установить правила». «Инициализировать» — типичная последовательность, выполняемая игроками в начале игровой сессии.

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

2.2.2. Вариант использования «Перейти в соседнюю зону».

Действующее лицо: игрок игры Встреча. Вариант использования:.

1.

Игрок щелкает на гиперссылке, соединяющей показанную зону с соседней.

2.

Система показывает соответствующую соседнюю зону вместе с персонажем игрока.

2.2.3. Вариант использования «Встретить внешний персонаж».

Действующее лицо: игрок Встречи. Вариант использования:.

1.

Система помещает внешний персонаж в зону нахождения персонажа игрока, или Игрок попадает в зону с внешним персонажем.

2.

Система осуществляет контакт двух персонажей.

3.

Система показывает результат контакта.

4.

Если персонаж игрока или внешний персонаж имеет 0 очков-жизней, игра заканчивается.

5.

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

2.3.

Пользовательские характеристики.

[Примечание для cmyde?imoe. Покажите, какие люди будут типичными пользователями программы. Например: новичок, профессионал в программном обеспечении, бухгалтер с 5-летним компьютерным стажем и т. д.] Ожидается, что пользователю будет 20-35 лет.

2.4.

Ограничения.

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

Встреча будет работать на ПК с Windows 95 или более поздней с минимальной скоростью 100 МГерц. Языком разработки будет Java.

2.5.

Предположения и зависимости.

[Примечание для студентов. Могут быть сделаны любые допущения.] Нет.

2.6.

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

[Примечание для студентов. Порядок, в котором требования будут выполняться.] Требования, описанные в разделах 1 и 2 этого документа будут называться «С-требования», в разделе 3 — «D-требования». Основной аудиторией С-требований будет сообщество заказчиков, вторичной — разработчиков. Для D-требований ситуация обратная. Эти два уровня требований должны быть согласованными. Несогласованности должны быть отмечены отдельно как дефекты. В случае, когда требование сформулировано в С-требованиях и D-требованиях, приложение будет разрабатываться согласно D-требованиям, поскольку они более подробны.

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