2014-02-04
2907
Анализ вариантов создания и развития ИС
Для создания ИС могут применяться два подхода: создание своими силами или заказ стороннему изготовителю. Аргументом в пользу первого подхода является то, что свои специалисты лучше знают условия и традиции конкретного предприятия, они всегда рядом и могут непосредственно контактировать с любым работником, за их работу не нужно платить тех больших денег, которые требуют за готовую систему сторонние изготовители, и т. д. Последний аргумент является исключительно весомым, поскольку оплата труда на предприятии обычно уступает оплате труда в специализированных фирмах.
Однако полная стоимость владения ИС во втором варианте может оказаться ниже.
В таких условиях представляет интерес систематизированное сопоставление условий создания или развития ИС в разных вариантах ее формирования, т. е. при создании ИС своими собственными силами или с привлечением сторонних специалистов и организаций (табл. 1). Этот анализ может быть проведен на основе рассмотрения особенностей комплекса средств обеспечения по этапам жизненного цикла («айсберг»).
Информационная система как изделие в разных вариантах тоже имеет существенные отличия.
Следует отметить, что в настоящее время преобладающим является создание ИС путем адаптации типовых программных продуктов, выпускаемых профессиональными изготовителями.
Таблица 1
Анализ вариантов создания и развития ИС
Функции, выполняемые разработчиками в проекте подразделяются на организационные и производственные. Первые создают условия для выполнения проектных заданий, вторые непосредственно связаны с этими заданиями.
Согласно концепции Microsoft Solution Framework (MSF) выделяются следующие группы функций – так называемые области функциональной специализации (functional area). Определено шесть ролевых кластеров, которые соответствующим образом структурируют проектные функции разработчиков (рис. 2.1).
• Управление продуктом (product management). Ключевая цель кластера – обеспечивать удовлетворение интересов заказчика. Для ее достижения кластер должен содержать следующие области компетенции:
– планирование продукта;
– планирование доходов;
– представление интересов заказчика;
– маркетинг.
• Управление программой (program management). Задача – обеспечить реализацию решения в рамках ограничений проекта, что может рассматриваться как удовлетворение требований к бюджету проекта и к его результату. Области компетенции кластера:
– управление проектом;
– выработка архитектуры решения;
– контроль производственного процесса;
– административные службы.
• Разработка (development). Первостепенной задачей кластера является построение решения в соответствии со спецификацией. Области компетенции кластера:
– технологическое консультирование;
– проектирование и осуществление реализации;
– разработка приложений;
– разработка инфраструктуры.
• Тестирование (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) – отвечает за создание и ведение общей библиотеки проекта, которая содержит все проектные рабочие продукты, а также за соответствие рабочих продуктов стандартам.
Первые две позиции в приведенном перечне отведены заказчику и планировщику ресурсов, которые имеют лишь внешнее отношение к разработке проекта, – они не являются членами команды. Заказчик – это лицо, заинтересованное в получении результатов. Планировщик решает задачи распределения финансовых, трудовых и технических ресурсов для разных проектов внутри фирмы. При правильной организации разработки с этими действующими лицами приходится сталкиваться лишь менеджеру проекта.
В заключение приведем перечень ключевых ролей, характеризующих наиболее типичные ситуации для программных проектов:
• архитектор проекта;
• проектировщики подсистем;
• руководители команд разработки подсистем;
• специалист по пользовательскому интерфейсу;
• эксперт предметной области.
