|
_____________________________________________________________________________________________________________________________ Тема 9. Управление разработкой ИС _____________________________________________________________________________________________________________________________ 9.1. Управленческая роль ИТ – менеджмента на различных этапах жизненного цикла информационного продукта 9.2. Организационные формы управления проектированием ИС 9.3. Структура организации работ по проектированию ИС, характерная для организации - разработчика 9.4. Структурные схемы для информационной службы предприятия 9.1. Управленческая роль ИТ – менеджмента на различных этапах жизненного цикла информационного продукта Организация процессов разработки проекта ИС отличается значительной сложностью. К причинам, обусловливающим сложность данных процессов, следует отнести прежде всего:
Под управлением проектом подразумевается деятельность, направленная на реализацию проекта с максимально возможной эффективностью при заданных ограничениях по времени, в денежных средствах и материальных ресурсах, а также по качеству конечных результатов проекта (документированных, например, в техническом задании). Управление как процесс характеризуется следующими компонентами:
[Гвоздева Т.В., Баллод Б.А. Проектирование информационных систем: Учебное пособие. – Иваново: ИГЭУ, 2006.—352 с.] Управление проектированием, как правило, рассматривают в двух аспектах: функциональном и организационном. Функциональный аспект определяется последовательностью работ по созданию проекта. Методология создания ИС отражена в нормативных документах, подавляющее большинство которых имеет силу международных стандартов. В них определены терминология, порядок создания и внедрения, требования к частям, состав проектов. Последовательность работ, связанных с определением целесообразности создания, созданием и промышленной эксплуатацией информационных систем (ИС), оформлена в виде процесса (создания или изготовления), который имеет иерархическое описание и состоит из стадий. Каждая стадия состоит из этапов, а этапы, в свою очередь, из видов работ. ИМ реализует функции управления на протяжении всего жизненного цикла ИС, который включает фазы “зарождение”, “создание и внедрение”, “эксплуатация”, “демонтаж”. Важнейшей фазой жизненного цикла ИС является фаза “создание и внедрение”, которая состоит из шести стадий: технико – экономическое обоснование (ТЭО), техническое задание (ТЗ), технический (ТП) и рабочий (РП) проекты, внедрение (Вн), анализ функционирования. Процесс создания и внедрения включает следующие стадии, этапы и некоторые виды работ. СТАДИЯ 1. Технико-экономическое обоснование (ТЭО). Основная цель работ этой стадии состоит в формировании обоснованного с позиций заказчика системы предложения о создании ИС с определенными основными функциями и техническими характеристиками. Основными выходными документами на этой стадии являются: ТЭО создания ИС и исходные технические требования к ИС в объеме, соответствующем ГОСТ. СТАДИЯ 2. Техническое задание (ТЗ). Основными целями стадии являются: подтверждение целесообразности и детальное обследование возможности создания эффективной ИС с функциями и техническими характеристиками, сформулированными в виде исходных технических требований к системе, планирование совокупности всех НИР, ОКР, проектных и монтажно – наладочных работ, сроков их выполнения и организаций исполнителей, подготовка всех материалов, необходимых для выполнения проектных работ. Выходными документами стадии являются: ТЗ на создание ИС, содержащее технические требования и план – график работ, согласованные Заказчиком и основным исполнителем; уточненное технико-экономическое обоснование намеченных в ТЗ решений (при необходимости); научно – технический отчет, содержащий результаты проведенных предпроектных исследований; эскизный проект ИС. СТАДИЯ 3. Технический проект (ТП). Целями работ, выполняемых на этой стадии, являются разработка основных технических решений по создаваемой системе и окончательное определение ее сметной стоимости. Работы этой стадии завершаются разработкой: общесистемных решений, необходимых и достаточных для выпуска эксплуатационной документации на систему в целом, входящей в состав раздела “Автоматизация” технического проекта строительства; проектов заявок на разработку новых технических средств; документации специального математического и информационного обеспечения, включая техническое задание на программирование. Основные результаты работ стадии оформляются в виде технического проекта ИС. СТАДИЯ 4. Рабочий проект (РП). Целью работ, выполняемых на этой стадии, является выпуск рабочей документации на создаваемую систему. Работы на этой стадии завершаются выпуском рабочего проекта ИС, состоящего из проектной документации, необходимой и достаточной для приобретения, монтажа и наладки комплекса технических средств системы и документации и программного организационного обеспечений, необходимых и достаточных для наладки и эксплуатации системы, и изготовлением программ специального программного обеспечения на машинных носителях СТАДИЯ 5. Внедрение (Вн). Цель стадии и главный результат работ, выполняемых здесь – передача действующей системы в промышленную эксплуатацию. СТАДИЯ 6. Анализ функционирования (АФ). Цель работ, выполняемых на этой стадии, состоит в получении систематизированных и объективных данных о ткачестве создаваемой системы, текущем состоянии и реальном эффекте функционирования системы на основании опыта ее промышленной эксплуатации. Анализ функционирования выполняется в ходе промышленной эксплуатации и не ранее, чем через 0,5 года со дня сдачи в промышленную эксплуатацию. С этой целью определяются показатели эксплуатационной надежности для системы в целом и для отдельных реализуемых ею функций, показатели технико – экономической эффективности системы, функционально – алгоритмическая полнота (развитость) системы и социально – психологическая подготовка персонала системы. Здесь же выносится решение о возможности дальнейшей эксплуатации системы, ее модернизации и дальнейшем развитии. [Грекул В.И., Денищенко Г.Н., Коровкина Н.Л. Проектирование информационных систем Интернет-университет информационных технологий -2-е изд. – М.: Бином. Лаборатория знаний Интуит Серия: Основы информационных технологий, 2008. – 300 с.] 9.2. Организационные формы управления проектированием ИС В общем случае организационная структура управления проектированием регулирует взаимоотношения подразделений и должностных лиц в организации, устанавливает распределение ролей, полномочий и ответственности между ними, а также порядок функционально-технических связей, возникающих в процессах управления. Организационная структура и организационный механизм как система связи в данной организации образуют организационные формы управления деятельностью коллектива. Можно передать в распоряжение разработчиков самые совершенные средства проектирования, четкие формы документации, планы работ, методы контроля, но без должной организации не получить проект, удовлетворяющий потребностям заказчика. И наоборот, совершенная форма организации проектирования может компенсировать недостаток эффективных средств проектирования и в отдельных случаях даже квалификацию разработчиков. Функциональный принцип построения структуры организации используется при выполнении задач проектирования постоянного характера. Для выполнения каждого вида задач, например, разработки постановки экономических задач, информационного обеспечения и т.п., формируются функциональные подразделения из специалистов определенного профиля. Подобная организационная структура обладает высокой степенью централизации управления, ей присущ авторитарный стиль руководства. В области разработки ИС функциональная структура организации встречается весьма редко. Для построения организационных структур проектных организаций наиболее часто используется проектный принцип. На основе этого принципа формируется организационное подразделение - проектная группа (проект), которая предназначена для одноразовой разработки ИС. Специалисты проектной группы образуют автономную организационную единицу, руководитель (главный конструктор) которой имеет соответствующие полномочия и несет полную ответственность за результаты деятельности проектного коллектива, который после выполнения проекта может быть расформирован. Матричный принцип построения организационных структур предполагает формирование в организации – разработчике ЭИС из специалистов функциональных подразделений проектных групп для разработки конкретных проектов. При этом специалисты не теряют принадлежности к соответствующему функциональному подразделению и находятся в двойном подчинении: у руководителя проекта (ответственность по проекту) и у руководителя функционального подразделения (организационная ответственность). Матричные структуры применяются в условиях высокой степени кооперации функциональных подразделений. Эти структуры основаны на особом механизме взаимодействия функциональных и проектно-целевых подсистем аппарата управления проектной организации. Главная особенность матричных структур состоит в обязательном выделении конкретного лица – руководителя проекта, наделенного всей полнотой ответственности за достижение цели проектирования и значительными правами распорядительства, которые делегируют ему вышестоящим руководством. Выбор целесообразного разделения труда разработчиков ИС зависит от ряда факторов, влияющих с разной степенью на решение проблемы. Наиболее существенными факторами являются следующие:
[Гвоздева Т.В., Баллод Б.А. Проектирование информационных систем: Учебное пособие. – Иваново: ИГЭУ, 2006.-352 с.] Структуры проектной группы Открытая организационная структура проектной группы отличается тем, что закрепленного организационного распределения обязанностей нет. Каждый член коллектива разработчиков является неформальным руководителем на этапе разработки системы, где он более других квалифицирован. Обязанности на отдельных этапах распределяются между разработчиками в соответствии с их знаниями, опытом и способностями. Централизованная организационная структура проектной группы предусматривает в качестве руководителя специалиста высокой квалификации, осуществляющего административное и техническое руководство. Он же является основным посредником между группой, заказчиком проекта и внешними организациями. Децентрализованная организационная структура проектной группы имеет свойство двух вышеизложенных структур. Данная организационная структура применяется в коллективах с большой численностью разработчиков (свыше 10 человек), осуществляющих проектирование больших ЭИС, декомпозируемых на подсистемы (контуры, модули) и комплексы задач. [Белов А.А. Информационно-синергетическая концепция управления сложными системами Монография. – Иваново: ИГЭУ, 2009. – 426 с.] 9.3. Структура организации работ по проектированию ИС, характерная для организации - разработчика В организационном аспекте управление проектированием рассматриваются по уровням организационно-административной структуры с соответствующими правами и обязанностями субъектов процесса проектирования. Организация работ по проектированию ЭИС определяется порядком взаимодействия между несколькими сторонами, участвующими в этом процессе: пользователем, заказчиком, администратором и разработчиком. Пользователь – это организация или группа подразделений, которые используют результаты обработки информации на ЭВМ. Для ИС под пользователем понимают прежде всего административно-управленческий аппарат, для которого создается эта система. Пользователь выполняет следующие функции:
Заказчик – это ответственное лицо, под которым понимается организация или подразделение и которое выполняет функции:
При этом заказчик несет ответственность перед пользователем за соответствие состава и характеристик решаемых задач, режима функционирования ЭИС исходным данным пользователя, за сроки создания системы, правильность использования ресурсов в процессе проектирования. Администратор – ответственное лицо, которое выполняет эксплуатацию программно-технических средств и информационного и методологического обеспечения ЭИС (технологические и инструкционные карты). Администратор несет ответственность перед пользователем за правильность результатов работы ЭИС и их своевременность, а перед заказчиком и разработчиком – за соблюдением условий эксплуатации, требований к технической документации. Разработчик – это ответственное лицо (организация или подразделение), которое выполняет следующие функции:
Разработчик несет ответственность перед заказчиком за правильность реализации требований ТЗ на ЭИС, научно-технический уровень разработки, сроки проведения работ, качество проектной документации, правильность расхода денежных ресурсов. Под разработчиком понимается как одна организация, так и некоторая совокупность организаций, в которую входят головная организация и организации-соисполнители. [Димов Э.М., Диязитдинова А.Р., Качков Д.А. Проектирование информационных систем: Учебное пособие. – Самара: ПГАТИ, 2003. – 78 с.] Существует несколько типов схем организации работ с участием сторон, выбор которых зависит от объема заказа. 1. Если заказ имеет небольшие размеры по стоимости и по продолжительности работ, то принимают первую схему, в которой в одном лице выступают заказчик, разработчик и администратор. К преимуществу данной схемы можно отнести минимальное количество организаций – участников процесса и минимальные сроки и стоимость разработки. Однако совмещение в одной организации функций разрабатывающей стороны и принимающей стороны имеет ряд существенных недостатков:
2. Для больших и сложных заказов применяют схему, согласно которой функции разработчика отделяются от функций заказчика и администратора и выполняются другой организацией. К преимуществам данной схемы можно отнести:
Однако и эта схема имеет недостатки:
3. В том случае, если заказчик – большая организация, которая курирует разработку нескольких проектов ЭИС, применяют схему, в которой на заказчика возлагаются функции сопровождения, заказа и приемки проектов нескольких ЭИС. Преимуществами данной схемы являются:
4. Отделение заказчика от разработчика позволяет последнему привлекать к своей работе организации-соисполнителей разных уровней иерархии, что в свою очередь, позволяет использовать труд специализированных и профессиональных организаций. Основными документами, регулирующими отношения заказчика и проектировщика, являются техническое задание и договор на проведение работ. [Гвоздева Т.В., Баллод Б.А. Проектирование информационных систем: Учебное пособие. – Иваново: ИГЭУ, 2006.-352 с.] 9.4. Структурные схемы для информационной службы предприятия Пример структуры Существуют три вектора, по которым целесообразно выстраивать первый уровень в организационной иерархии: 1. функции, 2. клиенты, 3. продукты. Организация по функциям Разбиение по функциям применяется чаще всего, особенно в информационных службах. Например, Управление состоит из подразделений:
Привлекательность такого подхода состоит в следующем.
Недостатки функционального подхода также хорошо известны:
Недостатки функционального подхода частично нивелируются применением клиентской или продуктивной схемы. [Димов Э.М., Диязитдинова А.Р., Качков Д.А. Проектирование информационных систем: Учебное пособие. – Самара: ПГАТИ, 2003. – 78 с.] Организация по клиентам Организационная структура Управления в разрезе по клиентам могла бы выглядеть, например, таким образом:
Клиентская схема организации обеспечивает:
Недостатками клиентской схемы являются:
[Белов А.А. Информационно-синергетическая концепция управления сложными системами Монография. – Иваново: ИГЭУ, 2009. – 426 с.] Организация по продуктам Продуктами (результатами) деятельности информационной службы являются информационные системы, понимаемые как совокупность аппаратно-программных комплексов и услуг по сопровождению этих комплексов. Управление в разрезе по продуктам чисто условно могло бы выглядеть так:
В этом случае помимо плюсов, характерных для клиентской схемы, возникает еще один - сокращение времени на разработку новых продуктов (систем ). Среди дополнительных минусов - проблема комплексного обслуживания клиентов по набору продуктов. Дополнительно к перечисленным вариантам есть еще пара способов выстраивания первого уровня иерархии Управления:
Первый из них является скорее следствием жесткой необходимости и исторических причин, чем результатом продуманного выбора. Второй способ представляет собой хорошую альтернативу для функционального варианта, имеет дополнительные преимущества, но требует особой подготовки и аккуратности. Наибольшая трудность при использовании данного способа - правильное определение основных процессов, что само по себе задача нетривиальная, особенно если ранее эта работа находилась не на должном уровне. Тем не менее, можно представить один из вариантов данного структурного решения, при котором информационная служба разделялась на две части: одна отвечала за развитие, другая – за сопровождение. И такой подход давал хорошие результаты. [Гвоздева Т.В., Баллод Б.А. Проектирование информационных систем: Учебное пособие. – Иваново: ИГЭУ, 2006.-352 с.] Планирование и контроль проектных работ Управление проектированием ИС в функциональном аспекте рассматривается как совокупность взаимосвязанных процессов. Под процессами управления понимаются действия и процедуры, связанные с решением конкретных задач или реализацией функций управления, к которым относятся:
[Димов Э.М., Диязитдинова А.Р., Качков Д.А. Проектирование информационных систем: Учебное пособие. – Самара: ПГАТИ, 2003. – 78 с.] |