Анализ осуществимости. Технические, операционные, финансовые, социальные/политические аспекты. (Feasibility Analysis. Technical, Operational, Financial, Social/Political.)



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

Процесс оценки и пересмотра требований (Process of Review and Revision of Requirements)

Учитывая неизбежность изменений, жизненно важно определить и согласовать с заинтересованными лицами процедуры (например, в контексте деятельности по управлению изменениями) в рамках которых будут проводиться оценка и пересмотр требований. Это однозначно предполагает, что требования не будут неизменны, но могут и должны корректироваться в соответствии с заданными и детализированными процессами (например, design review – оценка дизайна). Если изменения приняты, необходимо проводить анализ зависимостей (traceability analysis) и рисков (см. далее тему 2.5 “Управление рисками” – Risk Management) для оценки влияния рассматриваемых изменений. Такой анализ необходимо проводить, в общем случае, и при рассмотрении “изменения” для принятия решения о передачи его “в работу” или отклонении (например, в силу обоснованных причин, таких как проектные решения, позволяющих отметить его как реализуемое в следующей версии), и уже более детально, если изменение требования(ий) решено реализовать (в силу, например, контрактных обязательств со стороны исполнителя) и необходимо определить, как именно такое изменение повлияет на существующую систему и какие работы необходимо выполнить, чтобы удовлетворить обновленному(ым) требованиям. SWEBOK отмечает, что управление изменениями полезно и при оценке результатов проекта (программного продукта, программной системы), так как содержание и требования формируют основу оценки успешности проекта. (см. также секцию “Контроль конфигураций” области знаний Software Configuration Management).

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

Процесс планирования является итеративным* и базируется на содержании, требованиях и оценке осуществимости проекта. Здесь стоит напомнить, что различные фазы проекта перекрываются (что, например, специально отмечает PMBOK) и вместе с определением содержания, детализацией требований и проведением анализа осуществимости, параллельно с этим сам разрабатываемый план проекта в той или иной степени детализируется и формируется определенный комплекс работ, оцениваются необходимые ресурсы и временные границы работ, и т.п. SWEBOK, основываясь на такой позиции, говорит, что при планировании также оцениваются и отбираются соответствующие процессы жизненного цикла. Там где это уместно, проект детализируется в виде структурной декомпозиции работ, для которых отмечены ассоциируемых с их завершением результаты и их характеристики. Такие характеристики, обычно, связаны с вопросами качества и другими установленными атрибутами требований, соблюдением сроков выполнения работ, усилиями, стоимостью и т.д. Ресурсы распределяются по задачам таким образом, чтобы обеспечить оптимальную продуктивность (на персональном, командном и организационном уровне), использование средств (инфраструктуры, инструментов,...) и оборудования, а также строгое соблюдение проектного расписания. Также должно проводится управление рисками и, в частности, необходимо определить “профиль рисков”, принятый соответствующими заинтересованными лицами. Как составная часть планирования, необходимо определить необходимые процессы обеспечения качества в форме соответствующих процедур и обязанностей (responsibilities) по оценке, проверке, аттестации и аудиту качества (см. область знаний “Качество программного обеспечения” – Software Quality). Безусловно, что должны быть определены процессы и обязанности в части управления планом проекта, его оценкой и порядка пересмотра различных аспектов проекта.

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

Планирование процесса (Process Planning)

С учетом содержания и требований конкретного проекта необходимо выбрать, адаптировать и использовать соответствующую модель процессов жизненного цикла (например, спиральную, с эволюционным прототипированием). Также должны быть выбраны методы и инструменты. На уровне проекта, методы и инструменты используются для декомпозиции проекта в виде набора задач (tasks), с ассоциированными входами, выходами и условиями завершения (completion), например, в форме структуры декомпозиции работ – WBS (work breakdown structure). Это влияет на высокоуровневое (первичное) определение проектного расписания и организационной структуры <проектной команды>.


Дата добавления: 2018-05-12; просмотров: 355; Мы поможем в написании вашей работы!

Поделиться с друзьями:






Мы поможем в написании ваших работ!