Файл: Информационный менеджмент.pdf

5.2. Анализ вариантов создания и развития ИС

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

Однако полная стоимость владения ИС во втором варианте может оказаться ниже.

В таких условиях представляет интерес систематизированное сопоставление условий создания или развития ИС в разных вариантах ее формирования, т. е. при создании ИС своими собственными силами или с привлечением сторонних специалистов и организаций (табл. 5.1). Этот анализ может быть проведен на основе рассмотрения особенностей комплекса средств обеспечения по этапам жизненного цикла («айсберг»).

Информационная система как изделие в разных вариантах тоже имеет существенные отличия.

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

Таблица 5.1

Анализ вариантов создания и развития ИС

60

Продолжение таблицы 5.1

61

5.3. Функциональные роли в коллективе разработчиков

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

Согласно концепции Microsoft Solution Framework (MSF) выделяются сле-

дующие группы функций – так называемые области функциональной специализации (functional area). Определено шесть ролевых кластеров, которые соответствующим образом структурируют проектные функции разработчиков

(рис. 2.1).

•Управление продуктом (product management). Ключевая цель кластера – обеспечивать удовлетворение интересов заказчика. Для ее достижения кластер должен содержать следующие области компетенции:

– планирование продукта;

– планирование доходов;

– представление интересов заказчика;

– маркетинг.

•Управление программой (program management). Задача – обеспечить реализацию решения в рамках ограничений проекта, что может рассматриваться как удовлетворение требований к бюджету проекта и к его результату. Области компетенции кластера:

– управление проектом;

– выработка архитектуры решения;

– контроль производственного процесса;

– административные службы.

•Разработка (development). Первостепенной задачей кластера является построение решения в соответствии со спецификацией. Области компетенции кластера:

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

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

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

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

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

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

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

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

•Удовлетворение потребителя (user experience). Цель кластера – по-

вышение эффективности использования продукта. Области компетенции кластера:

62

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

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

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

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

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

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

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

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

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

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

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

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

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

ипроизводственных функций, которые объединяются с целью определить роль.

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

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

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

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

63

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

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

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

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

•Разработчик информационной поддержки (Information Developer) –

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

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

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

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

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

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

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

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

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

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

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

64