Роль в команде Целевая установка; ответственность

Управление продуктом Удовлетворение требований заказчика; коммуникация

между командой и заказчиком

Управление программой Менеджер проекта; планирование и контроль

Разработка Проектирование и кодирование, планирование “снизу-

вверх”

Тестирование Выявление ошибок; сборка продукта и тестирование

Обучение пользователей Улучшение продуктивности пользователей;

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

Логистика Внедрение продукта; посредничество между командой и

службами продаж, рекламы, поддержки и т.д.

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

Масштабирование для больших проектов: команда разбивается на подкоманды двух типов: команды свойств (feature teams) и функциональные команды (function teams). Первые ответственны за определенные наборы функциональных возможностей продукта, вторые существуют в пределах ролей (например, подкоманды разработки). Эти подкоманды общаются через своих выделенных представителей.

Преимущества модели команды MSF:

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

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

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

Недостатки модели команды MSF:

· Для формирования команды MSF нужны равные (равно квалифицированные и равно заинтересованные) участники.

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

Виды документации ПП:

· Проектная - результаты всех этапов разработки; используется при проектировании и сопровождении.

· Эксплуатационная - адресованная конечным пользователям и эксплуатационникам (системным администраторам)

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

- технологические инструкции по всем этапам разработки, в частности, стандарт кодирования (Coding Standard or Convention)

- шаблоны программных документов

Проектная документация (ПД)

Список проектных документов, рекомендуемых в стандарте ISO 9000-3:

1. Marketing (or Customer) Requirements

2. Software Requirements Specification

3. Project Development Plan

4. Software Design Document(s)

5. System Test Specification

6. Alpha Evaluation Plan

7. Beta Evaluation Plan

На практике каждая организация имеет свой перечень ПД и их шаблоны. Ключевое понятие: спецификация – по возможности максимально точное и полное описание (требований, проектных решений, тестов). Документы 1 и 2 из списка ISO содержат результаты анализа задачи (например, предпроектного обследования предприятия для АСУ). Вместе с документом 3 они содержат то, что принято называть техническим заданием или внешней (функциональной) спецификацией ПП. Это – основной отчуждаемый проектный документ, играющий роль контракта между производителем и потребителем и отправной точки для других проектных и эксплуатационных документов. Его рекомендуемое содержание состоит из трех частей

1. Общая характеристика

Цели, требования, ограничения – технико-экономическое обоснование проекта. Составляется системными аналитиками совместно с заказчиком.

2. Информационная и функциональная структура

Составляется системными аналитиками и программистами и адресовано в основном разработчикам как ТЗ на детальное проектирование, а также заказчикам – в части внешнего интерфейса. Здесь также обосновывается достижимость (feasibility) целей, поставленных в части 1.

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

Контракт на приемо-сдаточные испытания (acceptance test) и спецификация комплексного тестирования (system test), т.е. ТЗ на разработку соответствующих тестов. Составляется системными аналитиками.

Удельный вес и детальность проработки этих частей может быть различной для разных видов ПП, но следует придерживаться принципа приоритетности раннего связывания (”Не откладывай на завтра то, что можно сделать сегодня”) – т.е. фиксировать все характеристики и проектные решения в 1 и 2 частях, очевидные заранее, например, известные из прототипа или уже существующего аналогичного ПП. (Известно, что раннее связывание дешевле позднего - ср. статическое и динамическое связывание указателей в программировании.) Это же относится к плану тестирования, который рекомендуется разрабатывать до этапа реализации ПП. На этапе сопровождения внешняя спецификация служит "техническим паспортом" ПП.

Эксплуатационная документация (ЭД)

· Руководство пользователя (User's manual, UM)

- Назначение, принцип работы

- Интерфейс пользователя

- Учебник ("Getting started")

- Как преодолевать возможные трудности ("Troubleshooting")

- Глоссарий, индекс имен и т.д.

· Справочное руководство (Reference manual)

- Для приложения - перечень команд интерфейса (обычно в алфавитном порядке)

- Для библиотеки – API

· Руководство программиста (Programmer's manual)

- Инструкция по установке, настройке, эксплуатации

- Как преодолевать возможные трудности ("Troubleshooting")

ЭД во многом повторяет содержание ПД.

Современная тенденция: переход от печатных документов к электронным = гипертекстовым системам Help.

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