 |
Оценка организационной готовности
|
|
|
|
Данный тип оценки должен учитывать финансовую историю компании и опыт реализации аналогичных проектов. Кроме того, крайне важными факторами являются культура организации и уровень ее зрелости. В качестве инструмента оценки организационной зрелости возможно использовать следующий диагностический подход, рассматривающий организационную готовность в разрезе 5 перспектив (см. табл. 8.5).
В заключение рассмотрения данного раздела необходимо обратить внимание, что результатом процесса оценки реализуемости редко становится однозначное утверждение или однозначный отказ от реализации проекта. Руководство компании должно комплексно рассмотреть полученные результаты и только на этом основании принимать окончательное решение.
Вопрос
Детальное планирование стадии разработки и внедрения
Задачи планирования стадии разработки и внедрения совпадают с задачами предыдущей стадии. Дополнительной задачей является подготовка персонала к завершению проекта. Решение этой задачи включает следующие действия:
· извещение менеджмента проекта, заказчика и персонал;
· подготовка оценки работы персонала;
· документирование результатов процесса управления персоналом.
Извещение менеджмента проекта заказчика и персонал подразумевает информирование менеджеров проекта о планах высвобождения их персонала, проверке исполнения договорных обязательств, обсуждении планов высвобождения с персоналом проекта.
Для выполнения оценки работы персонала используют методики и процедуры, принятые компанией. Пример методики оценки персонала предложен В.Ильиным и изложен в книге "Руководство качеством проектов. Практический опыт " [13].
|
|
|
Все накопленные знания, приобретенные во время проекта, должны быть документированы и могут включать в себя:
· организационные диаграммы проекта, описания позиций и планы управления обеспечением проекта персоналом;
· принципы, методы урегулирования конфликтов и процедуры поощрения;
· специальные навыки и квалификацию определенных членов команды, обнаруженные в процессе исполнения проекта;
· проблемы и способы их решения, зафиксированные в журнале регистрации проблем проекта.
Вопрос
В настоящее время одним из самых важных факторов эффективного развития любого предприятия является управление проектами. В зависимости от размера организации количество проектов, которые одновременно реализуются в компании, может варьироваться от одного до нескольких сотен. Поэтому, при отсутствии формализованной системы управления проектом и руководитель, и все, кто участвует в проекте, неизбежно сталкиваются с огромным множеством проблем, связанных с конфликтами целей, назначений ресурсов, отчетности. И сейчас, единственный возможный вариант успешной реализации проектов – это управление проектами с помощью автоматизированных информационных систем.
Начиная с середины 2006 г. рынок автоматизированных систем в управлении проектами стремительно развивался. Ценность таких систем становится очевидной для организаций самых разных размеров.
Рассмотрим основных конкурентов, обратив большее внимание на их достоинства. Мировыми лидерами на рынке АИС в управлении проектами являются Oracle Primavera, Microsoft Project, CA Clarity и HP PPM.
1. Primavera.
Данная информационная система разработана компанией Primavera Systems, Inc., которая была куплена корпорацией Oracle в 2008 году. Предназначена для автоматизации процессов управления проектами в соответствии с требованиями PMI, IPMA и стандартами ISO. Данное решение, как и многие АИС, имеет модульную структуру, причем все модули основаны на web-технологиях.
|
|
|
Все данные находятся в едином хранилище, которое построено на базе Oracle или Microsoft SQL Server. Удобство данной системы в том, что пользователям предлагается несколько модулей для сбора данных и их актуализации, учитывая такие факторы, как отсутствие постоянного подключения к сети, сбор данных в режиме реального времени, поддержка мобильных устройств. Также поддерживает функционал для решения задач календарно-сетевого планирования. Данное решение предлагает целую систему административной поддержки, позволяющей минимизировать риски, которые связаны с сопровождением крупномасштабных проектов. Стоит обратить внимание на высокую стоимость, что делает покупку данного решения целесообразной только для крупных и средних предприятий.
1. CA Clarity.
История автоматизированной информационной системы CA Clarity начинается в 1999 году. На сегодняшний день данное решение является основой для всестороннего управления ресурсами благодаря единой системе cтратегического планирования и финансового контроля it-услуг. Стоит отметить, что данная система является неотъемлемой частью решения для oптимизации бизнеса BSO (Business Service Optimization). Clarity рассматривает решения по управлению проектами как основу для разрабoтки интегрированного набора приложений для управления корпоративными IT-ресурсами, а сама Clarity обеспечивает не только планирование проектов, но и контроль IT-ресурсов на высших уровнях руководства.
Стоит заметить, что данное решение, в основном, ориентируется на организации среднего уровня.
1. HP Project and Portfolio Management (PPM)
Данная система представляет собой центр решений по управлению проектами, который предназначен для решения главной проблемы, с которой сталкиваются все подразделения без исключения — это невозможность выполнить часть проекта в установленные сроки, не выходя за пределы выделенного бюджета, а также с наиболее оптимальным использованием материальных и трудовых ресурсов. В основе HP PPM лежит платформа Project and Portfolio Management Foundation, которая обеспечивает совместное использование информации и автоматизацию рабочих потоков с использованием лучших практик управления бизнес-процессами IT-службы, безопасности и подготовки отчетов, что обеспечивает полное соответствие стандартам и требованиям таких программ контроля качества и управления процессами, как Six-Sigma, CMMI, IТIL, ISO-9000 и Cobit. Также начиная с 2008 года HP PPM поставляет данное решение с обновлением, суть которого заключается в расширенном управлением ресурсами, что увеличивает эффективность работы в области управления проектами.
|
|
|
4.Microsoft Project.
Корпорация Microsoft представляет решение в области управления проектами под названием Microsoft Project. Данный продукт позволяет получать необходимую информацию, управлять разными проектными работами, планами и финансами, а также сохранять согласованность работы коллектива. Одним из самых важных и существенных достоинств MS Project является интеграция с Microsoft Office, что в разы повышает производительность. Также для управления корпоративными проектами у корпорации Microsoft имеется отдельное решение Microsoft Office Enterprise Project Management (EPM), которое позволяет расширить анализ и контроль всех выполняемых работ благодаря оптимизации процесса принятия решений, повышению степени соответствия разработок стратегии развития бизнеса, более обоснованному использованию ресурсов. С недавнего времени Microsoft стал предоставлять также облегченную, но имеющую все возможности для полноценного управления проектами, online версию MS Project с низкой стоимостью аренды. (~1200/мес.), которую может позволить себе даже малое предприятие с ограниченным бюджетом.
В итоге стоит обратить внимание на схожесть интерфейсов, функций и режимов всех вышеперечисленных решений управлений проектами. Каждая организация имеет возможность сделать выбор из огромного количества программ, конкурирующих на рынке, в зависимости от бюджета и размера компании.
Вопрос
Управление требованиями
Перед тем, как управлять требованиями разберемся, что такое требование и что такое управление требованиями и зачем это нужно.
Управление требованиями — процесс, включающий идентификацию, выявление, документацию, анализ, отслеживание, приоретизацию требований, достижение соглашений по требованиям и затем управление изменениями и уведомление заинтересованных лиц. Управление требованиями — непрерывный процесс на протяжении всего жизненного цикла продукта.
|
|
|
Требование — это любое условие, которому должна соответствовать разрабатываемая система или программное средство. Требованием может быть возможность, которой система должна обладать и ограничение, которому система должна удовлетворять.
В соответствии с Глоссарием терминов программной инженерии IEEE, являющимся общепринятым международным стандартным глоссарием, требование это:
- Условия или возможности, необходимые пользователю для решения проблем или достижения целей;
- Условия или возможности, которыми должна обладать система или системные компоненты, чтобы выполнить контракт или удовлетворять стандартам, спецификациям или другим формальным документам;
- Документированное представление условий или возможностей для пунктов 1 и 2.
В соответствии со стандартом разработки требований ISO/IEC 29148, требование — это утверждение, которое идентифицирует эксплуатационные, функциональные параметры, характеристики или ограничения проектирования продукта или процесса, которое однозначно, проверяемо и измеримо. Необходимо для приемки продукта или процесса (потребителем или внутренним руководящим принципом обеспечения качества)
Так же глоссарий ITILv3 определяет такое понятие, как набор требований — документ, содержащий все требования к продукту, а также к новой или измененной ИТ-услуге.
Требование должно обладать следующими характеристиками:
- Единичность — требование описывает одну и только одну вещь.
- Завершенность — требование полностью определено в одном месте и вся необходимая информация присутствует.
- Последовательность — требование не противоречит другим требованиям и полностью соответствует документации.
- Атомарность — требование нельзя разделить на более мелкие.
- Отслеживаемость — требование полностью или частично соответствует деловым нуждам как заявлено заинтересованными лицами и задокументировано.
- Актуальность — требование не стало устаревшим с течением времени.
- Выполнимость — требование может быть реализовано в рамках проекта.
- Недвусмысленность — требование определено без обращения к техническому жаргону, акронимам и другим скрытым формулировкам. Оно выражает объекты и факты, а не субъективные мнения. Возможна одна и только одна его интерпретация. Определение не содержит нечетких фраз, использование отрицательных и составных утверждений запрещено.
- Обязательность — требование представляет собой определенную заинтересованным лицом характеристику, отсутствие которой ведет к неполноценности решения, которая не может быть проигнорирована. Необязательное требование — противоречие самому понятия требования.
- Проверяемость — реализованность требования может быть проверена.
В соответствии с ITILv3 все требования в проекте можно разделить на следующие группы:
|
|
|
- Функциональные (Functional) — реализуют саму бизнес-функцию.
- Управленческие (Manageability) — требования к доступным и безопасным сервисам; относятся к размещению системы, администрированию и безопасности.
- Эргономические (Usability) — к удобству работы конечных пользователей.
- Архитектурные (Architectural) — требования к архитектуре системы.
- Взаимодействия (Interface) — к взаимосвязям между существующими приложениями и программным средствами и новым приложением.
- Сервисного уровня (Service Level) — описывают поведение сервиса, качество его выходных данных и другие качественные аспекты, измеряемые заказчиком.
Распространенное программное обеспечение для управления требованиями
В настоящее время широкое распространение получили такие системы управления требованиями как IBM Rational RequisitePro, Telelogic DOORS, Sybase PowerDesigner и Borland Caliber RM.
Приведу краткие переводы основных функциональных возможностей приведенных систем, взятые с сайтов производителей.
IBM Rational Requisite Pro
Программное обеспечение Rational представляет лучшие практические методы определения требований и управления ими, которые обеспечивают экономию времени и средств, помогая в решении следующих задач:
- Сокращение объема доработок и ускорение выхода на рынок благодаря совместной работе с заинтересованными лицами.
- Повышение производительности труда за счет контроля над изменениями в требованиях и управлении ими.
- Минимизация расходов и рисков за счет оценки влияния происходящих изменений.
- Демонстрация соответствия требований благодаря полному отслеживанию требований.
Rational RequisitePro помогает проектным группам управлять требованиями, создавать качественные сценарии использования, расширять возможности отслеживания, повышать эффективность совместной работы, уменьшать потребность в доработках и повышать качество.
- Снижает сложность благодаря подробным представлениям с возможностью трассировки, в которых показаны отношения между родительскими и дочерними элементами.
- Снижает связанные с проектом риски, показывая требования, которые могут быть затронуты изменениями требований более низкого или более высокого уровня.
- Обеспечивает совместную работу географически распределенных рабочих групп благодаря применению полнофункционального, масштабируемого Web-интерфейса и цепочек обсуждения.
- Обеспечивает сбор и анализ сведений о требованиях с возможностью точной настройки атрибутов и фильтрации.
- Повышает производительность труда, позволяя отслеживать изменения путем сравнения версий проекта с начальными характеристиками, описанными с помощью XML.
- Обеспечивает соответствие результатов проекта поставленным задачам и бизнес-целям благодаря интеграции со средствами IBM Rational для разработки и выпуска ПО.
IBM Rational/Telelogic DOORS
IBM Rational/Telelogic DOORS — семейство решений для управления требованиями и создания сложных наукоемких изделий (авиа, судостроение, поезда, ракеты, автомобили т.п.).
Первоначально DOORS разрабатывался только как средство управления требованиями в процессе разработки программного обеспечения. Однако идеи, заложенные в DOORS, оказались успешными и в настоящий момент система используется даже в кампаниях, которые не имеют отношения к разработке программного обеспечения, но вынуждены контролировать большой объем взаимосвязанной информации, например, при разработке инженерных систем.
Из Telelogic DOORS можно получить следующую информацию:
- Статус выполнения работ по каждому требованию отдельно, а также по группе требований.
- Статус работы над всем проектом.
- Ответственное лицо для каждого требования или группы требований.
- Историю изменений требования.
- Ресурсы, которые потребуются для реализации требования еще до его внедрения в проект.
- Связь между требованиями заказчика, пунктами технического задания, программами верификации, тестирования и задачами управления проектом.
- Класс, модель или чертеж, в котором конкретное требование реализовано.
Borland Caliber RM
Borland Caliber RM – это корпоративная система управления требованиями, которая облегчает совместную работу, что позволяет группам разработчикам подходить к вехам проекта вовремя и с запланированными затратами. Borland Caliber RM также помогает командам разработчиков удостовериться, что разрабатываемое приложение удовлетворяет пожеланиям конечных пользователей за счет непрерывного сбора пожеланий на всех этапах жизненного цикла от аналитиков, разработчиков, тестировщиков и других заинтересованных в проекте лиц.
Borland Caliber RM обладает следующими функциональными возможностями:
- Централизованное хранилище требований для всех проектов, разрабатываемых IT-компанией.
- Адаптируемость — Caliber RM можно сконфигурировать для использования в любом проекте, что повышает эффективность процесса управления требованиями.
- Трассируемость требований — открытая архитектура Caliber RM позволяет связать требования с другими артефактами на всех стадиях жизненного цикла программного продукта.
- Поддержка большого числа клиентов — Caliber RM прекрасно интегрируется с такими системами разработки, как Microsoft Visual Studio, Eclipse на платформе Windows.
- Интеграция с другими продуктами Borland для поддержки полного жизненного цикла программного продукта.
Другое ПО
За кадром остались также достаточно известные системы управления требованиями, такие как:
- Sybase PowerDesigner
- OpenSource Requirements Management Tool
- RequirementsWin и другие
Новый подход к управления требованиями
Как можно понять из приведенного выше обзора программного обеспечения для управления требованиям все оно базируется на одном принципе — человек, а в данном случае, аналитик, вводит требование в систему, смотрит, нет ли такого требования в системе уже. Если требование в той или иной формулировке уже присутствует в системе, то заново его не заносит, а отмечает, как дублирующее. В связи с тем, что поиск схожих требований вручную является сложной и трудозатратной задачей, которая требует постоянного участия аналитика, то в процессе управления требованиями именно ее стоит автоматизировать в первую очередь.
Чтобы реализовать возможность поиска и повторного использования требований необходима методика идентификации требований, представленных текстом на естественном языке. Тогда, представив требование не только как текст, но и совокупность некоторых концептов или лингвистических переменных станет возможным не только выполнять поиск сходных требований, но и использовать повторно созданные в процессе реализации требования артефакты. Под артефактами в данном случае не стоит понимать только исходный код, который реализует требование, но и жизненный цикл, которое оно прошло, т.е. код не всегда можно использовать повторно из-за специфики задач, но можно получить консультацию у его разработчиков. При разработке нескольких продуктов для одной предметной области это становится актуальной задачей. Например, при адаптации системы электронного документооборота на нескольких предприятиях часто возникает ситуация, что на разных предприятиях разные документы проходят одни и те же маршруты в процессе жизненного цикла и функциональность, которая реализует эти маршрутры может быть использована повторно, пусть и без полного копирования.
Предположим, что следующие требования описывают маршруты документов соответственно на предприятиях А и Б:
А — {A, B, C, D, E}
Б — {F, B, C, D, E}
Здесь видно, что под F и А имеются в виду документы, а B, C, D, E — их маршруты.
Рассчитав расстояние Хэмминга между этими двумя требованиями мы получим единицу, так как они различны только в одной позиции и, следовательно, при реализации требования Б стоит обратить внимание на требование А и его реализацию. Естественно, решение о повторном использовании принимает уже разработчик или другое лицо, принимающее решение, но уже хорошо, когда есть варианты, где можно подсмотреть реализацию.
СТРУКТУРА ДОКУМЕНТА ОПИСЫВАЮЩЕГО ТРЕБОВАНИЯ И СПЕЦИФИКАЦИИ
ВОПРОС 37
|
|
|
