Managing Software Deliverables: A Software Development Management Methodology by John W. Rittinghouse
Перевод Волошиновой Д.С.
Краткий обзор
Шаги, описанные в Детальной Фазе Проекта (Detailed Design Phase), сосредоточиваются вокруг детализации каждого аспекта проекта.
От оригинального анализа и планирования рассмотренного в Фазе II, Менеджер Проекта (Project Manager) должен провести свою команду через процесс производства точных спецификаций, чтобы соответствовать требованиям продуктов.
Итоговые документы спецификаций нужно проверить с потребителем в обзорном процессе перед тем, как перейти к следующей проектной фазе.
4.0.1 SEP Deliverables Checklist Таблица контрольных проверок
Представленные Результаты работ и таблица (Рисунок 4.2) контрольных проверок рассматривается Основной Командой разработчиков, чтобы помочь решить, какие результаты работы, требуются для конкретного проекта.
Вы, возможно, заметили, что наибольшая колонка слева, представленная на Рисунке, 4.2 представляет те результаты работы, которые требуются для любого проекта.
Колонка справа дает Основной Команде разработчиков гибкость, чтобы выбрать, уместен ли результат работы для проекта, на котором он работает.
Эта матрица настройки предусматривает высшую степень гибкости в проектном выполнении, но это также предписывает высшую степень последовательности в проектах в стадии реализации повсюду в среде SPMO.
Такая последовательность в конечном счете сохраняет деньги в организации и создает эффективность, которая предусматривает более быстрое выполнение и лучшее, понимание проектной методологии.
4,1 Quality Assurance Plan (QAP)План гарантии качества (QAP)
Формальный план чтобы гарантировать, что разработанный продукт удовлетворяет контракту, соответствует или превышает стандарты качества, и согласовывается с одобренными системами развития или процессам эксплуатации.
QAP определяет направления и измеряет , как продукта и качества процесса на протяжении всего проектного процесса разработки .
QAP обеспечивает завершение работ по устранению дефектов.
К ним относятся проверки высокого уровня разработки, низкого уровня разработки и проверок кода проекта.
Все эти виды проверок, которые происходят перед началом фазы развития, позволят сэкономить организации время и деньги, обнаружив ошибки и упущения в начале процесса, а не в конце. Чем лучше изучена и понятна проблема до того, как мы приступили к ее решению, тем лучше будет ее решение.
QAP позволяют Основной команде разработчиков работать с заранее определенными условиями для каждого развивающегося процесса. Эти условия включают точки входа, процесса реализации, момент выхода, и устранение специфических дефектов.
Удовлетворение каждого из этих условий для каждого процесса разработки, позволит обеспечить сохранения качества процесса.
4,2 Human Factors Plan (HFP) Планирование субъективных факторов
HFP это разрабатываемый документ, используемый для проведения исследования человеческого фактора в рамках среды проекта. Планирование субъективных факторов гарантирует, что группа не создаст условий работы, не пригодных для работников или пользователей результатами проекта.
Многие другие аспекты испытаний являются частью общего HFP. Такие ориентированные на пользователя испытания должны проводиться в связи с требованиями тестирования, интегрированного тестирования, тестирования платформы, СМИ тесты, и так далее.
В целом неплохо создать специализированную группу, посвященную исключительно Планированию субъективных факторов. Некоторые организации даже считают, что лучше иметь внешних консультантов приходящих на работу для изучения этих типов проблем.
Их аргументация состоит в том, что люди со стороны не имеют представлений о внутренней деятельности, среде, или использовании продукции и могут быть более объективными. Ниже приведен список некоторых других субъективных факторов, которые необходимо учитывать:
4,3 Доклад об учете субъективного фактора Human Factors Report (HFR)
HFR представляет собой окончательный доклад, полученный в результате исследования человеческого \ субъективного фактора (описаны в HFP). Этот доклад используется для идентификации любых относящихся к делу проблем, которые необходимо решить до внедрения проекта.
В докладе также излагаются любые изменения, которые необходимо произвести, чтобы сделать продукт более удобным для пользователей или для улучшения общей эргономики приложения.
Они включают в себя следующие четыре области:
4,4 Требования к продукту и его спецификациям (PRSpec) Product Requirements and Specifications
PRSpec включает набор необходимых характеристик, которые описывают в подробных деталях именно то, что клиент получит, когда завершенный продукт станет доступным.
Каждая отдельная функция, команда, экранная подсказка, диалог, и другие детали пользовательского интерфейса - документируется в этой группе спецификаций.
Значительная часть информации в этом документе может быть расширена с High-Level Solutions Document.
Четыре ключевых спецификаций документов, которые необходимы на данном этапе, включают в себя следующие:
Различные технические требования к спецификациям документов предназначены для того, чтобы хорошо продуманное и детализированное разложение на компоненты предложенного решения выполнялось различными членами Основной команды разработчиков и другими участниками процесса развития проекта.
В ходе сбора и формирования требований к документу, зачастую необходимо пересмотреть существующую документацию \программное обеспечение.
A Requirements Analysis Team( команде по анализу требований) может быть поручено проанализировать основные проблемы и проводить опросы клиентов или даже проведение одного или нескольких опросов пользователей. The Requirements Analysis Team( команда по анализированию требований) должна выявлять и оценивать повторно используемые компоненты системы и работать с Management Information Systems или ИТ организациями для определения вида требуемой хост- платформы.
Группа должна также определить, какие функции платформы будут использованы для осуществления мер безопасности.
Кроме того, ниже приводится ряд других общих областей используемых для анализа, когда у пользователей возникают проблемы.
Архитектура
Аудитория
Команды
Совместимость / миграции
Конкурентоспособность
Отклонения от требований
Простота использования
Функции
Будущие усовершенствования
Поддерживаемое оборудование
Информации / данных, подлежащих включению
Международные требования
Упаковка
Работоспособность
Цены / лицензионные соглашения
Публикации
Надежность
Экранные формы
Безопасность
Удобство технического обслуживания
Поддерживаемое Программное обеспечение
Стандарты / ИСО
Пользовательский интерфейс
В следующих пунктах мы раскрываем каждый из четырех ключевых спецификаций документов и обсуждаем, почему каждый из них имеет важное значение в процессе осуществления проекта.
4,5 Требования к инфраструктуре системы (SIR) System Infrastructure Requirements
В SIR документе указывается точные требования к инфраструктуре, необходимые для поддержки конечного продукта. Требования к Инфраструктуре касаются физических характеристик аппаратного и программного обеспечения среды, а также физическое окружение существующее в таких условиях.
В качестве примера можно включить аппаратное требующие SCSI кабель не в SCSI среду. Требования Инфраструктуры может быть просто адаптироваться, не SCSI условия для размещения новых SCSI устройств. Он также может быть чем-то менее техническим, таких как розетки, преобразованные из 110 на 220V.
В общем, каждый входной и выходной адаптер каждого устройства в физической среде должен быть пересмотрен для обеспечения совместимости или модернизирован в соответствии с требованиями новой системы.
Самое главное, этот документ должен быть рассмотрен местной ИТ или Management Information Systems администратором информационной системы; (который должен быть членом основной команды разработчиков) отсеивать нереальные предположения или пропущенные ранее.
Ниже приводится содержание, рекомендуемое для любого из перечня различных требований. Сведения в каждом разделе может измениться, но общий формат остается прежним. Следует также отметить, что этот документ отличается от формата User Requirements Document (URD)( Документация пользовательских требований ) описанного ранее.
Перечень требований: Содержание (рекомендуется)
Обеспечение управления
Журнал версий программного обеспечения
Введение
Цель настоящего документа
Предполагаемая аудитория
Материалы к настоящему документу
Результаты этого документа
Список дистрибьюторов
Обзор управляющей программы
Концепция
Основные проблемы, которые необходимо решить
Обзор продукта
Обзор финансов
Расписание
Бета-версия Дата
Программное обеспечение Дата выпуска
Справочная информация
Текущий пользовательский режим операции
Правовой вопрос
Похожие / зависимые проекты
Системные требования
Общие
Ключевые особенности
Среда
Простота использования
Работоспособность
Качество
Совместимость / Миграция
Сервис и поддержка
Стандарты / ИСО
Интеграция продукта
Программное обеспечение
Минимальные требования к программному обеспечению
Аппаратное оборудование
Минимальные конфигурации оборудования
Архитектура
Безопасность
Локализация
Y2K (2000 года) поддержка
Финансовые
Преимущества / Экономия
Проект бюджета
Продукты
Публикации
Упаковки
Дополнительные компоненты
Интеграция продуктов
Сервис и поддержка
Конкурсные предложения
Цены / Лицензирование
Стандартные определения для деятельности в целях развития
Как видите, цель такой точной документации охватить детали настолько подробно, как это необходимо, чтобы объяснить:
· кто нуждается в ней,
· в каких случаях она нужна им,
· почему они в ней нуждаются,
· что они будет делать, когда они получают ее,
· как она поможет их организации или команде,
· и что она требует в плане затрат времени и материалов.
4,6 спецификация требований к приложению(SRS) Software Requirements Specification
SRS документ определяет точные функциональные спецификации для каждого пункта, упомянутого в URD User Requirements Document .
Иногда эти требования называются Computer Software Configuration Item CSCI (уведомления).
Там может быть более одной функциональной характеристики по каждому пункту, упомянутых в URD.
URD следует рассматривать как высокоуровневый, четко описанный обзор требований пользователя.
SRS иногда относят к Functional Specification Document (FSD). Независимо от названия, SRS или FSD этот документ является центром разработки для каждого требования, заявленного пользователем, необходимого для удовлетворения его деловых потребностей.
Эти требования часто включены в документ, Requirements Traceability Matrix (RTM). Матрица Отслеживания Требований или так называемая Матрица трассировки
Обеспечивает метод для прослеживания функциональных требований и их выполнения через весь процесс разработки.
В этом документе требования перепроверены против всей проектной окументации, планов испытаний и так далее.
Каждое требование, упомянутое в URD ,является или должно быть найдено в RTM, а также любых новых требованиях найденных Командой разработчиков на этом пути.
Эта матрица используется группами испытателей, группами разработчиков, и т.д., чтобы они были сосредоточены на том, что они стремятся достичь.
Рисунок 4.3 показывает пример RTM.
4,7 Требования к спецификации Интерфейса(IRS) Interface Requirements Specification (IRS)
IRS документ должен трансформировать все необходимые пользователю функции в элегантный пользовательский интерфейс (UI).
Каждый уровень пользовательского интерфейса должен быть подробным, включая функциональные клавиши, горячие клавиши, пользовательские диалоги, и так далее.
Насколько это возможно, все развитие UI должно соответствовать установленным заранее стандартам для систем, в которых будет размещаться продукт.
Это не - хорошая практика, упускать функциональность существующих систем инфраструктуры, которая действует с UI, который весьма отличен от UI, найденный в существующих приложениях в организации.
Поэтому дизайн интерфейса пользователя должны быть рассмотрен Членами команды разработки и подписан Спонсором проекта, чтобы обеспечить соблюдение предписанных систем стандартов. Конечно, исключения есть, если организация решила изменить один UI стандарт на новый, и этот проект будет в авангарде этих усилий.
4,8 Требования к спецификации работоспособности (PRS) Performance Requirements Specification
PRS определяет потребности работоспособности и детализирует реализацию решений, которые обеспечат соблюдение этих потребностей.
Для программных продуктов, показатели работоспособности включают в себя время отклика, аппаратные время доступа, сетевые искажения сигнала, и так далее.
Каждый пункт следует тщательно рассматривать с точки зрения того, как он измеряется и как он используется. В идеале, эти требования должны быть оценены против других существующих систем в производственной среде.