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

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

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

0.2. Этапы разработки программного обеспечения.

В 80-е и 90-е годы в области разработки программного обеспечения (ПО) преобладали две тенденции. Одна — это быстрый рост приложений, в том числе создаваемых для Web. Другая — это расцвет инструментальных средств и парадигм (подходов к проектированию, таких как объектно-ориентированный).

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

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

♦ Управление проектом разработки — базовые сведения в главе 2, продолжение в следующих главах.

♦ Описание целевого программного продукта — главы 3 и 4.

♦ Проектирование продукта — главы 5 и 6.

♦ Разработка продукта, то есть его программирование — глава 7.

♦ Тестирование частей продукта — глава 8.

♦ Интеграция частей и тестирование продукта в целом — глава 9.

♦ Сопровождение продукта — глава 10.

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

Система разработки программного обеспечения включает в себя персонал, процесс, проект и продукт (рис. 0.1). Использованные обозначения взяты из книги «Унифицированный процесс разработки программного обеспечения» (USDP — Unified Software Development Process) Якобсона, Буча и Рамбо [64]. USDP — один из процессов для разработки программного обеспечения — описан в этой книге. Таблица, изображенная в разделе «Процесс» на рис. 0.1, объясняется в главе 1. Диаграмма в разделе «Проект» показывает инженеров, занимающихся различной работой в соответствии с их обязанностями, а потом передающих результаты другим инженерам, продолжающим их работу. Раздел «Продукт» содержит гораздо больше, чем просто объектные модули и исходный код. Например, туда включаются также документация, результаты тестов и измерений продуктивности. В соответствии с USDP мы будем называть эти продукты артефактами. В этой книге описывается, что должен содержать полный набор артефактов.

0.3. Процесс.

Содержание этого раздела представлено ниже.

♦ Процесс (главы 1 и 2).

♦ Последовательность разработки:.

♦ водопадная;.

♦ итеративная.

♦ Системы принципов разработки:.

♦ Индивидуальный процесс разработки (PSP);.

♦ Командный процесс разработки (TSP);.

♦ Модель зрелости возможностей (СММ).

♦ Стандарты:.

♦ Institute of Electrical and Electronic Engineering (IEEE) — Институт инженеров по электротехнике и радиоэлектронике;.

♦ International Standards Organization (ISO) — Международная организация по стандартизации.

Водопадный процесс (waterflow process) начинается с определения требований, предъявляемых приложению, далее переходит в фазу проектирования, затем реализации и, наконец, тестирования. Иногда в водопадный процесс включается фаза сопровождения, описанная в главе 10. В этой книге мы разделили проектирование на архитектуру (глава 5) и детальное проектирование (глава 6), а тестирование — па модульное тестирование (глава 8) и системное тестирование (глава 9). Разработка программного обеспечения редко протекает строго в «водопадной» последовательности. Процесс разработки продуктов для Web, например, имеет тенденцию менять направление, перемещаясь между спецификацией, проектированием, реализацией и тестированием. Также для разработки программного обеспечения мы часто используем итеративные процессы, в которых «водопад» повторяется несколько раз целиком или частично. Этот вопрос разбирается в главе 1. Представленный в строгой форме итеративный стиль имеет множество преимуществ.

Решения по поводу процесса разработки программного обеспечения часто принимаются на организационном уровне (уровне компании, отдела, группы разработчиков и т. д.), так что важно правильно оценивать потенциальные производительные возможности организации. В нескольких главах обсуждается такая оценка и приводится модель зрелости возможностей (СММ — Capability Maturity Model). Модель зрелости возможностей, созданная Уоттсом Хэмфри и Институтом технологий разработки программного обеспечения (SEI), описывается в главе 1.

У отдельных инженеров способности по разработке программного обеспечения могут быть развиты и оценены при помощи индивидуального процесса разработки программного обеспечения (PSP — Personal Software Process), созданного Хэмфри. Идеи СММ и PSP рассматриваются в нескольких главах этой книги. Третий уровень организации программного обеспечения — это командный процесс разработки программного обеспечения (TSP — Team Software Process) [55], описывающий процесс, следуя которому, команда разработчиков программного обеспечения выполняет свою работу. Мы уверены в том, что структурирование работы согласно системе принципов, такой как СММ, PSP и TSP, является основой профессиональной деятельности разработчика программного обеспечения в двадцать первом веке.

Хорошо продуманные стандарты документации облегчают создание полезных, надежных артефактов. В основном в этой книге используются стандарты IEEE, многие из которых одобрены Американским национальным институтом стандартов (ANSI — American National Standards Institute). Многие компании создают свои собственные стандарты. Хотя стандарты должны изменяться со временем, чтобы соответствовать развитию технологий, основа качественных стандартов остается неизменной в течение нескольких лет. Если команды разработчиков не используют стандарты или примеры, построенные на основе стандартов, то они теряют много времени в размышлениях над структурой (а не над сущностью) документа. Стандарты направляют процесс, обеспечивая инженеров, инструкторов и студентов «путеводной нитью» в их работе. На практике стандарты обычно изменяют и приспосабливают к конкретному проекту.

0.4. Проект.

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

♦ Объектно-ориентированный подход: очень полезная парадигма.

♦ Унифицированный язык моделирования (UML): нотация для проектирования.

♦ Унаследованные системы: отправная точка для улучшения или расширения существующей системы.

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

Унифицированный язык моделирования (UML — Unified Modeling Language, см. [90]) — промышленный стандарт для описания моделей — будет использоваться на протяжении всей этой книги. Обратите внимание, что UML — это не методология, а система обозначений.

В главе 5 исследуются способы разработки архитектуры приложения. Описанный подход заимствует идеи из области изучения образцов проектирования и из исследований по классификации архитектуры программного обеспечения. Глава 6 завершает обсуждение проектирования, демонстрируя, как могут быть указаны конкретные детали. Главы с 7 по 9 посвящены интеграции и тестированию приложений. В главе 10 обсуждаются сопровождение продукта, последняя и продолжающаяся стадии проекта.

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

0.5. Персонал.

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

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

0.6. Продукт.

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

Главы 3 и 4 посвящены анализу требований и объясняют, как составить требования, определяющие, каким должен быть продукт. Хотя задача написания спецификации выглядит весьма простой, на практике сложно выполнить ее хорошо. Некоторые требования описываются наилучшим образом с использованием формальных математических методов. В главе 5 объясняется, как описать архитектуру программного обеспечения, следуя классификации Гарлана и Шоу. В главе 6 описывается, как провести детальное проектирование, в том числе с использованием образцов проектирования — тех замечательных элементов «языка» проектирования, которые сильно облегчают нам обсуждение различных разработок. Глава 7 посвящена непосредственно разработке (программированию). Особое внимание в ней уделяется стандартам и формальным методам, помогающим разработчикам писать программы, правильность которых легко проверить. В главах 8 и 9 рассказывается, как тестировать приложение по частям и в целом. Там же идет речь об артефактах тестирования — в их число входят процедуры тестирования, описывающие процесс тестирования и примеры, содержащие тестовые входные параметры.

0.7. Качество.

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

♦ Инспектирование (глава 1). Командный процесс обеспечения качества, применяется на всех стадиях проекта.

♦ Формальные методы (глава 1). К ним отсносятся математические методики для доказательства правильности программы, то есть того, что она делает то, что предполагается. Применяются выборочно.

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

♦ на уровне модуля (компонента) (глава 8);.

♦ на уровне целого приложения (глава 9).

♦ Методы управления проектом (глава 2):.

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

+ управление артефактами (версиями, документами и т. д.).

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

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

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

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

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

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

0.8. Проект для студенческой команды.

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

ОДИН ИЗ СПОСОБОВ РЕШИТЬ НАЧАЛЬНЫЕ ВОПРОСЫ В КОМАНДЕ -.

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

1.

Установите план собрания и временные рамки. (В главах 1 и 2 детально рассказывается о том, как это сделать.).

2.

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

3.

Решите, как члены команды будут общаться.

4.

Определите заказчика (тех, кому нужно ваше приложение).

5.

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

Одной из распространенных причин неудачи является невыполнение рабочих обязательств одним или несколькими членами группы (см. пункт 1 выше). Гораздо лучше обсудить обязанности с самого начала, чем пытаться исправлять проблемы по ходу развития проекта. Чтобы избежать возможных трений оттого, что одни члены группы вкладывают в проект больше сил, чем другие, определите заранее количество часов в неделю, уделяемых проекту. Это также будет способствовать более эффективной работе каждого участника.

ОДИН ИЗ СПОСОБОВ ОПРЕДЕЛИТЬ ОЖИДАНИЯ УЧАСТНИКОВ КОМАНДЫ -.

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

1.

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

♦ определите ожидаемое количество часов в неделю;.

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

♦ соберите данные об известных датах отсутствия кого-либо из команды.

2.

Выберите основную цель проекта: успешная разработка или обучение.

♦ Успех в разработке рабочего продукта дает хорошее представление о руководстве, общении с заказчиком.

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

♦ Необходимо учитывать цели вышестоящего руководителя (преподавателя).

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

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

0.8.1. Общение в группе.

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

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

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

1.

Общая политика: если сомневаемся — обсуждаем. Многословие — не проблема.

2.

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

3.

Дополнительные собрания: члены группы оставляют время в понедельник с 16:00 до 18:00 свободным на случай дополнительного собрания.

4.

Стандарты: в качестве текстового редактора будет использоваться программа Ajax версии 9. Программа электронной почты — BestMail 4, а если это приложение недоступно, то проверить имеющуюся почту на совместимость, особенно это касается присоединенных файлов.

5.

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

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

6.

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

7.

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

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

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

Групповой проект — это приключение. В добрый путь!.

0.9. Обзор учебного проекта.

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

Помимо того, что компьютерные игры обладают развлекательным аспектом, они принадлежат к наиболее продаваемым программным продуктам (по сведениям журнала «Economist», 1998 г.) и связаны с серьезным бизнесом. Некоторые прогнозы обещают увеличение количества игроков в компьютерные игры до 32 миллионов к 2002 году («The Boston Globe», 21.01.00, стр. D12). Предположим, что принято решение создать новую ролевую игру, способную заинтересовать всех взрослых независимо от пола. Увы, игра Встреча еще недостаточно хороша, чтобы в нее играть (у нас просто не было достаточно средств на ее разработку), но она служит хорошим примером к тексту этой книги, показывающему, как разрабатываются программные продукты, начиная от возникновения концепции и до введения в эксплуатацию и стадии поддержки.

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

0.9.1. Компьютерная игра Встреча: введение.

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

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

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

0.9.2. Требования к игре Встреча.

Многие требования к игре Встреча могут быть выражены через взаимодействия между приложением и внешней стороной, обычно пользователем. Эти взаимодействия называются вариантами использования [63] и объясняются в главе 3. Например, вариант «Контакт с внешним персонажем» показан на рис. 0.4. «Контакт с внешним персонажем» — это последовательность действий, происходящая, когда герой и внешний персонаж находятся в одной зоне в одно и то же время. Подробные требования для Встречи могут быть изложены различными способами, например с помощью диаграмм последовательности, обсуждаемых в главе 4. Они являются графическим представлением управляющей логики программы, особенно удобным для визуализации вариантов использования.

0.9.3. Проектирование игры Встреча.

Архитектура Встречи, представленная в главе 5, раскладывается на части, показанные на рис. 0.5. Вся архитектура разбивается на две части: уровень ролевой игры и уровень игры Встреча. Уровень ролевой игры состоит из следующих модулейпакетов: ПерсонажиИгры, РолеваяИгра и ИгроваяСреда, а уровень компьютерной игры Встреча — ПерсонажиВстречи, ИграВстреча и СредаВстречи. Как будет объясняться в главе 5, уровень ролевой игры является каркасом, который можно применять для многих других игр.

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

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

0.9.4. Тестирование игры Встреча.

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

0.9.5. Документация по проекту видеоигры Встреча.

Проектная документация приблизительно соотносится с водопадным процессом разработки. В примере используются ключевые документы, описанные в стандартах IEEE. План контроля качества ПО для игры Встреча, приведенный в конце глав 1 и 2, устанавливает проектную документацию, стандарты, проверки и управление рисками. План управления конфигурациями ПО, приведенный в конце главы 1, показывает, как должны храниться коды и документы. План управления программным проектом, находящийся в конце главы 2, показывает подход к управлению проектом. Спецификация требований к ПО, приведенная в конце глав 3 и 4, описывает требования, предъявляемые к приложению. Проектная документация ПО, расположенная в конце глав 5 и 6, демонстрирует архитектуру и подробную разработку приложения. Документация по тестированию ПО, приведенная в конце глав 8 и 9, описывает способы, которыми тестировалось приложение.

Упражнения.

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

1.

Что такое инженерная наука? Дайте краткое определение.

2.

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

П2". Каковы четыре основные «П», составляющие технологию разработки программного обеспечения?.

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

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

К1". Решите, кто будет лидером вашей группы. Заметьте, что будучи лидером, вы сможете приобрести опыт, который в противном случае будет тяжело получить.

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

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

Отчет вашей команды должен быть около 4-7 страниц. Критерии оценки:.

+ понятность («Отлично» — очень понятно написано, все важные моменты объяснены, не слишком многословно);.

♦ конкретность («Отлично» — приведены конкретные процедуры, описывающие общение в группе при всех наиболее вероятных обстоятельствах);.

♦ правильность изложения темы («Отлично» — весьма ясно, что писавший понимает цели изучения данной темы; изложение правильно организовано).

Ответы.

П1.

1.

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

2.

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

П2. Процесс, проект, персонал и продукт.

Подсказки.

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

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

1.

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

2.

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

3.

Используйте общий веб-сайт или чат. Например, бесплатные услуги доступны на [20].

4.

Недостаточно определить: «Мы будем использовать программу Superword для написания текстов». Обязательно определите номер версии и обменяйтесь для верности несколькими сообщениями. Не меняйте версию по ходу проекта, не проверив ее совместимость с предыдущей.

5.

Опробуйте все выбранные методы и стандарты.

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

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