Управление проектами информатизации

– технологическое  консультирование;

– проектирование и осуществление реализации;

– разработка приложений;

– разработка инфраструктуры.

• Тестирование (test). Задача кластера – одобрение выпуска продукта только после того, как все дефекты выявлены и устранены. Области компетенции кластера:

– разработка тестов;

– отчетность о тестах;

– планирование тестов.

• Удовлетворение потребителя (user experience). Цель кластера – повышение эффективности использования продукта. Области компетенции кластера:

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

– интернационализация (эксплуатация в иноязычных средах);

– обеспечение  технической поддержки;

– обучение пользователей;

– удобство эксплуатации (эргономика);

– графический  дизайн.

• Управление выпуском (release management). Задача кластера – беспрепятственное внедрение и сопровождение продукта. Области компетенции кластера:

– инфраструктура (infrastructure);

– сопровождение (support);

– бизнес-процессы (operations);

– управление выпуском готового продукта (commercial release management).

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

• Заказчик (Customer) – реально существующий (в организации, которой подчинена команда, или вне ее) инициатор разработки или кто-либо иной, уполномоченный принимать результаты (как текущие, так и окончательные) разработки.

• Планировщик ресурсов (Planner) – выдвигает и координирует требования к проектам в организации, осуществляющей данную разработку, а также развивает и направляет план выполнения проекта с точки зрения организации.

• Менеджер проекта (Project Manager) – отвечает за развитие проекта в целом, гарантирует, что распределение заданий и ресурсов позволяет выполнить проект, что работы и предъявление результатов идут по графику, что результаты соответствуют требованиям. В рамках этих функций менеджер проекта взаимодействует с заказчиком и планировщиком ресурсов.

• Руководитель команды (Team Leader) – производит техническое руководство командой в процессе выполнения проекта. Для больших проектов возможно привлечение нескольких руководителей подкоманд, отвечающих за решение частных задач.

• Архитектор (Architect) – отвечает за проектирование архитектуры системы, согласовывает развитие работ, связанных с проектом.

• Проектировщик подсистемы (Designer) – отвечает за проектирование подсистемы или категории классов, определяет реализацию и интерфейсы с другими подсистемами.

• Эксперт предметной области (Domain Expert) – отвечает за изучение сферы приложения, поддерживает направленность проекта на решение задач данной области.

• Разработчик (Developer) – реализует проектируемые компоненты, владеет и создает специфичные классы и методы, осуществляет кодирование и автономное тестирование, строит продукт. Это широкое понятие, которое может подразделяться на специальные роли (например, разработчик классов). В зависимости от сложности проекта команда может включать различное число разработчиков.

• Разработчик информационной поддержки (Information Developer) – создает документацию, сопровождающую продукт, когда выпускается версия.

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

• Специалист по пользовательскому интерфейсу (Human Factors Engineer) – отвечает за удобство применения системы. Работает с заказчиком, чтобы удостовериться, что пользовательский интерфейс удовлетворяет требованиям.

• Тестировщик (Tester) – проверяет функциональность, качество и эффективность продукта. Строит и исполняет тесты для каждой фазы развития проекта.

• Библиотекарь (Librarian) – отвечает за создание и ведение общей библиотеки проекта, которая содержит все проектные рабочие продукты, а также за соответствие рабочих продуктов стандартам.

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

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

• архитектор проекта;

• проектировщики подсистем;

• руководители команд разработки подсистем;

• специалист по пользовательскому интерфейсу;

• эксперт предметной области.

5.4. Модели жизненного цикла ПО

5.4.1. Общепринятая модель

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

• разработка;

• сопровождение.

Фазы  разбиваются на ряд этапов (см рис. 5.1).

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

 

     Рис. 5.1. Общепринятая модель жизненного цикла  ПО

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

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

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

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

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

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

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

     Фаза  разработки заканчивается этапом тестирования (автономного и комплексного) и передачей системы в эксплуатацию – следующие два этапа.

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

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