ЗараменскихУЖЦИСмонография-148-272. Управление жизненным циклом информационных систем
 Скачать 3.15 Mb.
|
|
ПРИМЕР 7.8.3 Документирование требований к закупкам. В документах на закупку должны быть идентифицированы продукция, ее ха- рактеристики, соответствующие требования системы менеджмента каче- ства и связанная с ними документация. Документы должны также преду- УПРАВЛЕНИЕ ЖИЗНЕННЫМ ЦИКЛОМ ИНФОРМАЦИОННЫХ СИСТЕМ 187 сматривать ответственность покупателя, определять стоимость и дату по- ставки продукции, требования аудита (при необходимости) и права доступа в помещения поставщика. Требования заказчика должны быть отражены в до- кументах на закупку. Документы (например, «Запрос расценок») должны быть построены так, чтобы упростить сопоставимые и полные ответы потенциальных поставщиков. Документы на закупку должны быть рассмотрены до выполнения закупок с це- лью проверить, что все связанные с изделием требования и другие аспекты (такие как ответственность покупателя) полностью определены. Рассмотрим еще один стандарт, концентрирующийся на одном из двух рассмотренных в ISO 10006:2003 аспектов: качестве процессов. Важным фактором обеспечения качества является повышение степени развития со- ответствующих процессах внутри самой организации-заказчика и ее под- рядчиков. Чем раньше будут идентифицированы пути повышения зрелости данных процессов и предприняты необходимые меры, тем больше вероят- ность реализации проектов с высоким уровнем качества результатов. Для целей оценки уровня зрелости процессов управления компании в целом и процессов управления разработкой программных решений в частности применяются описанные ниже стандарт ISO 15504 и модель CMMI. ISO 15504/SPICE. Модели уровней зрелости CMM/CMMI Международный стандарт: ISO 15504:2004 «Information Techology. Process Assessment» / SPICE (Software Process Improvement and Capabili- ty Determination). Российский аналог: ГОСТ Р ИСО/МЭК 15504 «Информационные технологии. Оценка процессов». Стандарт, впервые представленный в 90-х годах, отличает фокус на мо- дели улучшения процессов, а именно: эффективности работы и возможно- стей процесса. Под «эффективностью работы» понимаются продуктивность, учет потребностей пользователей / бизнес-заказчика, а «возможности про- цесса» определяются, как правило, организацией – поставщиком услуг по разработке и сопровождению системы для формулирования целевых потен- циальных уровней совершенства этих процессов. Всего в стандарте детализируются и рассматриваются пять основных групп процессов: ‒ Процессы взаимодействия «потребитель-поставщик» (Supplier- customer). ‒ Разработка (Engineering). ‒ Поддержка (Supporting). ‒ Управление проектом (Management). ‒ Организационные процессы (Organization). Сама же структура стандарта приведена в схематичном виде на рисунке ниже. ГЛАВА 3. Особенности управления проектами по внедрению КИС 188 ЧАСТЬ 2 Проведение оценки Схема измерения Требования к базовым моделям процессов Требования соответствия ВНЕШНЕЕ Базовые модели процессов ЧАСТЬ 5 Пример модели оценки процесса, основанной на ИСО/МЭК 12207 ЧАСТЬ 4 Руководство по применению для улучшения процесса и определения возможностей ЧАСТЬ3 Руководство по проведению оценки Дополнительное руководство (включая требования к инструментам, проверке и оценщикам) Пример задокументированного процесса оценки Изначально данный стандарт исходит из концепции, согласно которой существуют определенные критерии / признаки уровня развития процессов организации. В некотором роде он опирается на методологию зрелости сис- тем управления CMM и ее модификацию для оценки процессов разработки ПО – CMMI. CMM (Capability Maturity Model) – методология, предложенная в конце 1980-х группой специалистов Университета Карнеги-Меллон и призванная сформировать систему критериев выбора организаций-подрядчиков для цели проектов разработ- ки ПО. В связи с этим она называлась SE-CMM (Software Engineering Capability Maturity Model). А ее переработанная версия, посвященная целиком зрелости про- цессов разработки программного обеспечения, получила название CMMI (Inte- grated CMM). Модели CMM/CMMI базируется на трех основных предположениях, которые применимы также и к стандарту ISO 15504. 1. Существуют несколько уровней зрелости проектной организации. Эти уровни зависят от ряда критериев и применимы также и к разраба- тывающим и внедряющим системы организациям. Всего данных уровней выделяется пять. УПРАВЛЕНИЕ ЖИЗНЕННЫМ ЦИКЛОМ ИНФОРМАЦИОННЫХ СИСТЕМ 189 2. Любая организация заинтересована в переходе на более высокий уро- вень зрелости. Это важно не только для выживания и сохранения конкурентоспособ- ности на рынке, но и для повышения внутренней эффективности и качества выполнения проектов. 3. Переход возможен только на следующий уровень. Нельзя «перескакивать» через уровни, так как одновременное внедре- ние большого числа мер для повышения зрелости резко повысит риски и может привести к непредсказуемым последствиям в случае неготовности организации к переходу. Рассмотрим описание уровней зрелости SE-CMM в их первона- чальном виде: Уровень 1 – Начальный (initial). Процесс разработки ПО представляет собой «черный ящик», не суще- ствует стандартов планирования и контроля проектов. Успех подобных про- ектов зависит целиком от компетентности, мотивации и героизма сотрудни- ков, а не от применения отработанных процессов. Схематично данный уровень зрелости может быть представлен сле- дующим образом: Уровень 2 – Повторяемый (repeatable). Созданы базовые способы контроля проектов: планирование и монито- ринг времени, стоимости, содержания и качества. Уровень 3 – Определенный (defined). Стандартные процессы документированы и внедрены в организации. Внутренняя структура «черного ящика» становится видимой. Менеджеры и команда проектов хорошо понимают свои роли и обязанности в процессах разработки. Уровень 4 – Управляемый (managed). На данном уровне организацией определяются количественно измеряе- мые цели по достижению качества как программных продуктов, так и про- цессов. На основании получаемых при измерении результатов принимаются решения. Вход Выход Вход Выход Вход Выход ГЛАВА 3. Особенности управления проектами по внедрению КИС 190 Уровень 5 – Оптимизирующий (optimizing). Проактивное устранение существующих недостатков / «узких мест» процессов и их постоянный поиск и реализация возможностей по совер- шенствованию этих процессов. Рассмотрев основные условия и особенности моделей зрелости в целом, перейдем к конкретным описаниям уровней по CMMI (ISO 15504) в отно- шении процессов разработки. CMMI отличают более детализированные описания и использование не только терминологии пяти уровней зрелости, но и концепции «непрерывной модели» оценки процессов (дополнительные введенные на каждом уровне метрики: например, PA 2.1 «Управление произ- водительностью»). Для большей наглядности и демонстрации применимости модели CMMI как части стандарта ISO 15504 к процессам создания и экс- плуатации системы приведем по уровням соответствующие комментарии. Уровень 1 – Выполняемый (performed). PA 1.1 Исполнение процесса. Комментарии в отношении процессов разработки. При разработке ПО используются типовые инструменты, основные процессы ЖЦ не регламен- тированы и исполняются в соответствии с квалификациями и опытом спе- циалистов. Сроки неопределенны в связи с сильной зависимостью от кон- кретной ситуации и отсутствием методик / регламентов в качестве базы. Уровень 2 –Управляемый (managed). PA 2.1 Управление производительностью. PA 2.2 Управление продуктом. Комментарии в отношении процессов разработки. С ростом сложности проектов по разработке и внедрению систем, ростом требований к квалифи- кации специалистов появляются процессы управления процессом и самим продуктом. Проводится документирование проводимых работ и предпри- Вход Выход Вход Выход УПРАВЛЕНИЕ ЖИЗНЕННЫМ ЦИКЛОМ ИНФОРМАЦИОННЫХ СИСТЕМ 191 нимаются первые шаги по регламентированию и формированию методик разработки, оценки и сопровождения систем. Уровень 3 –Устоявшийся (established). PA 3.1 Определение процесса. PA 3.2 Становление процесса. Комментарии в отношении процессов разработки. Третий уровень зре- лости процессов жизненного цикла программных средств предполагает их стандартизацию, возможность доработки с учетом текущих особенностей конкретного проекта. К этому моменту процессы уже описаны и для них сформированы четкие входные и выходные параметры / результаты, требо- вания и условия. Определены рекомендуемые к использованию с учетом конкретной ситуации программные средства и инструменты. Уровень 4 – Предсказуемый (predictable). PA 4.1 Измерение / оценка процесса. PA 4.2 Контроль / мониторинг процесса. Комментарии в отношении процессов разработки. На данном уровне зрелости процессов ЖЦ организации уже способны реализовывать крупно- масштабные проекты внедрения даже с учетом жестких ограничений сро- ков / стоимости / заданного уровня качества. Соответственно, управление на четвертом уровне модели предполагает сформированные количественные показатели и характеристики процессов, для которых проводится монито- ринг с последующим использованием полученной статистики и результатов для улучшения управления проектами и во избежание ошибок. Уровень 5 –Совершенствуемый (optimizing). PA 5.1 Инновации процесса. PA 5.2 Непрерывная оптимизация. Комментарии в отношении процессов разработки. Наконец, на «Совер- шенствуемом» уровне зрелости возможно снижать совокупную стоимость создания / владения системой за счет своевременного планирования, прове- дения ретроспективного анализа и использования новых, более эффектив- ных инфраструктурных ресурсов, методик организации управления проек- том, выбора оптимальных с точки зрения качества / стоимости / соответст- вия требованиям программных решений. Для каждого пункта вышеприведенного списка проводится оценка сте- пени выполнения того или иного процесса. Итоговая шкала состоит из всего четырех значений: ‒ Не реализован (0-15 %). ‒ Частично реализован (> 1-50 %). ‒ В значительной степени реализован (> 50-85 %). ‒ Полностью реализован (> 85-100 %). Таким образом, рассмотренные методологии и стандарты способствуют развитию взаимопонимания между всеми сторонами, задействованными в ГЛАВА 3. Особенности управления проектами по внедрению КИС 192 проектах разработки и внедрения информационных систем, предоставляя бизнес-ориентированным специалистам информацию о технической сторо- не внедрения, а ИТ-специалистам, в свою очередь, перспективу бизнеса и проектных менеджеров. 3.4.2.6. Управление содержанием Проектная документация Важность документации очень просто недооценить, однако именно бла- годаря ей любой человек сможет уяснить как общую картину и суть проекта, так и узнать самые незначительные детали его реализации. Сквозное доку- ментирование проекта (включающее все результаты проведенных работ, за- мечаний, разногласий, предложений, проведенных встреч) должно осуществ- ляться в обязательном порядке. Основным элементом управления проектом является регулярный отчет руководителя проекта о состоянии проекта, в ко- тором отражаются результаты выполнения работ по внедрению на момент формирования отчета. На протяжении всего проекта в отчете отражаются ра- боты, выполненные в настоящее время, находящиеся на стадии выполнения (с указанием степени завершенности) и предстоящие в ближайшем будущем. Появление промежуточных результатов в ходе реализации проекта по- зволяет начать их использование еще до завершения проекта в целом. На- пример, завершение этапа по автоматизации учета основных средств пред- приятия позволяет, не дожидаясь окончания проекта, осуществлять расчет амортизации. Название документа Автор / ответственный Частота Адресат документа Регулярная отчетность по проекту 1. Индивидуальный отчет о про- работанном времени Консультант-программист от Исполни- теля По указанию Руководи- теля проекта от Испол- нителя Руководитель проек- та от Исполнителя 2. Отчет Руководителя проекта Руководитель проекта от исполнителя (при его отсутствии – Руководитель проекта от Заказчика) Ежемесячно Куратор проекта, Ко- ординатор проекта 3. Протокол совещания Коор- динационного Совета Секретарь совещания При проведении сове- щания Отчеты Руководителя проекта 1. Регулярный отчет о состоя- нии проекта Руководитель проекта от исполнителя Ежемесячно Куратор проекта, Ко- ординатор проекта 2. Отчет о результатах этапа Руководитель проекта от исполнителя При завершении этапа 3. Протокол выполненных ра- бот Руководитель проекта от исполнителя При выполнении работ Руководитель проек- та от исполнителя Процесс решения проблем 1. Форма регистрации проблемы Консультант со стороны исполнителя Руководитель проек- та от исполнителя 2. Журнал регистрации проблем Руководитель проекта от исполнителя Куратор проекта, Ко- ординатор проекта 3. Изменения статусов проблем Руководитель проекта от исполнителя Для эффективного управления проектом важными являются все без ис- ключения составляющие. К примеру, даже такая, незначительная на первый взгляд, информация, как сведения о плане отсутствия специалистов (отпуска, УПРАВЛЕНИЕ ЖИЗНЕННЫМ ЦИКЛОМ ИНФОРМАЦИОННЫХ СИСТЕМ 193 командировки и пр.) является необходимой для планирования конкретных ра- бот проекта и соответствующего задействования специалистов. Именно из совокупности таких мелких элементов складывается качественное выполне- ние проекта внедрения и обеспечивается гарантия успеха проекта в целом. Системная документация Пристальное внимание следует уделить формированию системной до- кументации. Для формирования документации можно использовать диа- граммную технику представления управленческих процессов. Примером такой техники могут служить IDEF-диаграммы. При помощи функций опи- сываются основные процессы, которые преобразуют входящую информа- цию и формируют выходную. Количественные функции (длительность, стои- мость и т.п.) позволяют моделировать управленческие процессы и анализи- ровать варианты их улучшения. Документация системы должна включать в себя следующие элементы: информационная архитектура, программная архитектура, программно- техническая реализация. Базисом документации по поддержке и дальнейше- му развитию КИС должны стать технологические, организационные и мето- дологические составляющие. Эти составляющие представляют собой, по су- ти, правила изменения системы и могут охватывать все стадии проекта. Документация должна обладать логической полнотой и удобством пред- ставления. Предприятия, включая АСУ-подразделения, нередко страдают отсутствием или невыполнением регламентов, слабой дисциплиной в об- ласти эксплуатации и замедленном восприятии изменений системы. Язык спецификаций – важная деталь, обеспечивающая возможность «говорить на одном языке» для заказчика и подрядчика. Создание любой составной части КИС должна сопровождаться созданием структурных схем и спецификаций, заранее согласованных с заказчиком. Логическая полнота спецификаций яв- ляется обязательным условием, как и понимание их формулировок. Для того, чтобы все вышеперечисленные особенности были учтены, раз- работаны специальные методики, позволяющие применять лучшие практики управления каждой фазой проекта. Однако более того, их понимание со сто- роны бизнеса важно для соблюдения интересов предприятия (и корректного планирования ресурсов и масштабов проекта) как во время заключения с подрядчиком контракта на системную интеграцию, так и в дальнейшем при прохождении всех этапов жизненного цикла этой информационной системы. 3.4.2.7. Управление рисками Выбор и реализация стратегии управления рисками Рассматривая важнейшие моменты управления проектами, невозможно обойти стороной риски, грамотное управление которыми способно спасти ГЛАВА 3. Особенности управления проектами по внедрению КИС 194 проект, в то время как неверные действия по отношению к которым могут его «потопить». Риск – неопределенное событие (условие), реализация которого влияет на ход про- екта и достижение его целей. В любом ИТ-проекте необходимо учитывать несколько крайне важных категорий рисков, ассоциированных как со внедрением, так и с поддержкой, технологическим совершенствованием и в целом управлением системы: ‒ Организационные: ассоциированные с поддержкой руководства компании и корректностью проведенного на первом этапе обследо- вания бизнес-архитектуры компании. ‒ Ресурсные: риски проектного управления в части «треугольника ограничений»: времени, ресурсов, качества. ‒ Проектные: остальные риски проектного управления (в части кон- троля показателей проекта, управления коммуникациями, мотива- цией, интеграцией). ‒ Технологические: риски возникновения ошибок, вызванных недос- таточно точным анализом и проектированием системы на уровне архитектуры приложений, данных и технологий. Не менее важно понимать не только, какие потенциальные ошибки мож- но совершить, но и когда именно следует проявлять к каждой особое вни- мание. Рассмотрим некоторые примеры в привязке к пяти этапам управле- ния проектами по PMBoK (за основу берутся стадии проектного менедж- мента, а не жизненного цикла ИС в силу значительной зависимости рисков именно от ошибок управления). Инициирование При старте проекта крайне важна поддержка руководства компании и то, насколько высокий уровень приоритета проекта (в сравнении с другими реализуемыми в компании активностями) будет им определен. Именно здесь на первый план выходит возможный конфликт интересов Бизнеса и ИТ, в случае появления которого может быть выделено недостаточно ресур- сов, что повышает потенциальные «шансы» срыва сроков и / или снижения качества проекта в дальнейшем. Также значительные риски предполагает этап обследования, на котором неверная постановка требований (в частно- сти, из-за неэффективных коммуникаций) приведет к несоответствию ито- гового продукта ожиданиям / потребностям заказчика. |