Лекция 4-Программная инженерия
.pdfЛекция 4: Методы управления проектом, риском и конфигурацией 11.1. Методы управления проектами
Управление проектом - это руководство работами команды исполнителей проекта для реализации проекта с использованием методов управления, планирования и контроля работ, управление рисками, эффективной организацией работы и коммуникационными потоками в команде исполнителей.
Основными составляющими любого проекта являются следующие:
ресурсы (людские, финансовые и технические),
время и стоимость выполнения проекта.
Основные аспекты разработки проектов:
методы управления, планирования и контроля работ;
эффективная организация проектной команды;
инструментарий менеджера проекта (например, система Project Management фирмы
Microsoft).
11.1.1Методы управления программным проектом
Метод критического пути СРМ. Оснополагающий момент в создании этого метода - исследование возможности эффективного использования вычислительной машины Univac на фирме "Dupon" при планировании и создании планов-графиков больших комплексов работ по модернизации заводов этой фирмы. В результате был создан рациональный и простой метод (Уолкера-Келли) управления проектом с использованием ЭВМ, который был назван CPM (Critical Path Method) - метод критического пути.
Критический путь - наиболее полный путь работ в сетевом графике, которые лежат на этом пути.
Метод основан на графическом представлении задач (работ) и видов действий на проекте и задании ориентировочного времени их выполнения в виде графа (рис. 11.1), в вершинах которого располагаются работы и время выполнения каждой работы под вершинами либо на дугах графа.
Граф целесообразно строить тогда, когда работы и время их выполнения являются определенными.
Рис. 11.1. Граф задания сроков выполнения работ
Метод анализа и оценки PERT. Метод PERT представляется сетевыми диаграммами с вершинами-событиями, а работа - в виде линии между двумя событиями, отображающими начало и конец работы. В целом расхождения между этими двумя методами сетевого представления графа работ - незначительные. Однако этот метод, в отличие от CMP, учитывает возникающие неопределенности во времени выполнения каждой операции.
Представление более сложных связей между работами для задания узлов графа в виде вершина-событие является более сложным, и потому этот метод реже используется на практике.
11.1.2. Планирование проекта
Планирование - это процесс распределения и назначения ресурсов (материальных и людских) с учетом стоимости и времени выполнения проекта, является необходимой предпосылкой выполнения любой, даже самой простой задачи. Неадекватное планирование может привести к срыву проекта или к получению неадекватных результатов в проекте.
Планирование и перепланирование - наиболее емкие во времени части управления проектом, в особенности на ранних стадиях проекта
Планирование заключается в составлении планов:
работ со сроками их выполнения по методу критического пути СРМ или PERT;
обеспечении требуемого качества и контроля промежуточных результатов процессов ЖЦ;
управления рисками;
аттестации результатов проектирования и деятельности исполнителей проекта;
управления конфигурацией и др.
Составляется график работ по следующей схеме (рис. 11.2):
Рис. 11.2. Шаги составления графика работ на проекте
На этапе планирования могут использоваться сетевая разбивка работ (СРР) и диаграммы Ганта [11.7]. CРР - это иерархическая структура декомпозиции задач проекта на подзадачи.
План в виде графа СРР имеет этапы, шаги и деятельности, а также начало и конечную деятельность на процессе (рис. 11.3).
Рис. 11.3. Пошаговый граф плана проекта
Диаграмма Ганта - это линейная диаграмма, на которой задачи проекта представляются сроками в виде отрезков времени, включают даты начала и окончания выполнения задач с учетом возможных задержек или других временных параметров. Другой формой представления - сетевой график работ, задаваемый в виде графа, в вершинах котрого располагаются пункты работ плана, а на дугах количество дней (недель) для их выполнения (рис. 11.4).
Рис. 11.4. Вид графа работ и сроков (на дугах) для проекта
Управление процессами на проекте состоит в определении:
начальной точки - события или набора событий, которые произошли до начала выполнения этапа процесса и для которого описывается набор условий, включая начало процесса;
продолжительности - интервала времени, за который процесс должен успешно завершить свое выполнение;
срока - даты, до которой процесс полностью или частично завершает свое выполнение;
конечной точки процесса - контрольной точки, в которой заказчик проверяет качество полученных результатов процесса.
11.1.3. Организационные аспекты управления проектом
Распределение работ по исполнителям. Состав и количество сотрудников, входящих в команду проекта, зависит от масштаба работ и опыта сотрудников. Сотрудники должны быть квалифицированными, способными выявить ошибки и неточности в проекте на самых ранних стадиях ведения проекта.
Организационная стуктура проекта. Для хорошей организации ведения проекта подбирается подходящая структура проекта на основании следующих данных:
рабочие стили членов группы;
число людей в группе;
стиль работы с заказчиками и разработчиками.
Ответственность за моделирование работ в проекте.
Рис. 11.6. Модель ответственности лиц в интегрированном проекте
11.1.4. Системы управления проектом
Стандартизация процесса управления проектом. Процесс управления проектом входит в ЖЦ стандартов ISO/IEC 12207-2002 и ISO 15504 (части 1-9) 2002.
Главные факторы осуществления задач программного проекта:
объем работ, имеющиеся ресурсы и ограничения;
стоимость выполнения задач и необходимых ресурсов;
компетентность специалистов;
методы и средства и стандарты, соответствующие выполнению задач проекта;- планы проекта и контроль их выполнения;
оценка стоимости, трудоемкости и продолжительности выполнения проекта;
измерение размера и сложности продуктов, полученных на процессах ЖЦ.
Методы и средства выполнения процесса управления проектом ориентированы на методическую и инструментально-технологическую поддержку процессов ЖЦ при разработке проекта.
11.2. Методы управления рисками в проекте
Причиной возникновения рисков являются неопределенности, существующие в каждом проекте. Риски могут быть "известные", которые можно планировать, "неизвестные", которые не идентифицированы и не могут быть спрогнозированы.
Риск - это нежелательное событие, которое может иметь непредвиденные негативные последствия.
Процедуры управления рисками:
Планирование управления рисками - это процесс принятия решений по применению и планированию управления рисками для конкретного проекта.
Идентификация рисков выполняется для определения рисков, которые способны повлиять на проект.
Качественная оценка рисков - это процесс качественного анализа идентификации рисков и оценка риска, требующего быстрого реагирования.
Количественная оценка рисков определяет вероятность возникновения рисков, влияние последствий рисков на проект и принятие решений по оценке риска.
Планирование реакций на риски - это разработка методов и технологий снижения отрицательного воздействия рисков на проект.
Мониторинг и контроль - это процедуры слежения за идентификацией рисков, обеспечению выполнения плана рисков и оценки его эффективности с учетом понижения риска.
Управление рисками основывается на рассмотрении двух основных типов рисков: общего риска для всех типов проектов и специфического риска.
11.3. Управление конфигурацией программной системы
Под конфигурацией системы понимается конкретная версия ПС для разных ОС, компьютеров и включает в себя функции, объединенные между собой процедурами связи (или развертывания) и параметрами, которые задают режимы функционирования системы в среде.
11.3.1. Управление и планирование конфигурацией
Управление конфигурацией - процесс, обеспечивающий идентификацию элементов конфигурации системы при ее создании для проведения систематического контроля, учета и аудита внесенных изменений, а также для поддержки целостности и работоспособности системы.
11.3.2. Идентификация элементов конфигурации
Идентификация конфигурации - это именование всех элементов системы на основе схемы классификации и кодирования элементов, а также методов представления и ведения версий конфигурации с использованием входящих в нее элементов.
11.3.3. Управление версиями и контроль конфигурации
Управление версиями состоит в:
интеграции или композиции корректной и окончательной версии системы из элементов конфигурации, реализованных на этапах ЖЦ, а также с учетом аппаратных средств и инструментов построения системы;
выборе инструментов построения версии, оценке возможностей среды и средств автоматизации процесса построения отдельных версий с корректной конфигурацией ПО и данных;
управление вариантами версий, включающими совокупность готовых идентифицированных элементов системы и удовлетворяющих заданным требованиям заказчика к варианту.
Контроль конфигурации - это проверка и управление изменениями системы при формировании версии и эксплуатации. Процесс создания продукта включает непрерывные корректировки, которые имеют отношение к уже согласованному и/или утвержденному базису конфигурации. В этом плане предметом проведения контроля конфигурации являются:
изменения в базис конфигурации и связанная с ними корректировка конфигурации;
дефекты и отклонения в конфигурации продукта относительно утвержденного базиса.
***********
Лекция 4 (продолжение): Методы определения требований в программной инженерии
3.1. Общие подходы к определению требований
Определение требований - Заказчик предъявляет свои потребности к автоматизации функций и задач системы и формулирует их в виде разных видов требований.
3.1.1. Классификация требований
Требования - это утверждения о функциях и ограничениях системы.
Требования - это свойства, которыми должен обладать продукт, чтобы представлять какую-то ценность для пользователей.
Требования - это спецификация того, что и как должно быть реализовано.
Требования к продукту охватывают условия пользователей на внешнее поведение системы и разработчиков на некоторые параметры системы.
Требования к ПО состоят из требований пользователей, функциональных, системных и нефункциональных требований.
Требования пользователей (user requirements) основываются на целях и задачах, которые пользователям позволит решать будущая система.
Системные требования (system requirements) определяют внешние условия для выполнения системных функций и ограничений на создаваемый продукт, а также требования к описанию подсистем (функциональных, программно-аппаратных).
Требования к атрибутам качества (quality attributes) представляют собой некоторые ограничения к свойствам функций или к системе, важных для пользователей или разработчиков.
Функциональные требования - это перечень функций или сервисов, которые должна выполнять система, а также ограничений на данные и поведение системы.
Нефункциональные требования определяют условия и среду выполнения функций (например, защита и доступ к БД, секретность и др.).
3.1.2. Анализ и сбор требований
Обсуждение проекта системы проводится в целях выработки первых впечатлений и выводов относительно целесообразности выполнения проекта и прогнозирования реальности его выполнения в заданные сроки и бюджет, которые определяет заказчик.
Анализ требований начинается после обсуждения проблематики проекта. При рассмотрении требований среди них могут оказаться
неочевидные, не одинаково важные, которые брались из устаревших источников и документов заказчика;
разные типы, которые соответствуют разным уровням детализации проекта и требующие применения методов управления ими;
постоянно изменяемые, развиваемые и уточняемые;
с уникальными свойствами или значениями;
сложные по форме и содержанию, трудные для согласования их с заказчиком.
Сбор требований. Источниками сведений для формирования требований могут быть:
цели и задачи проекта, которые формулирует заказчик разработчиком будущей системы, должны осмысливаться ими;
коллектив, выполняющий реализацию функций системы, не должен использовать старую систему, переставшую удовлетворять заказчика или персонал.
Методы сбора требований следующие:
интервью с представителями интересов заказчика системы;
наблюдение за работой действующей системы для отделения проблемных свойств, которые обусловлены кадровыми ресурсами;
примеры возможных вариантов выполнения функций, ролей ответственных лиц, запускающих эти варианты или взаимодействующих с системой при ее развертывании и функционировании.
3.1.3.Инженерия требований
Модель процесса определения требований - это схема процессов ЖЦ, которые выполняются от начала проекта и до тех пор, пока не будут определены и согласованы требования.
Управление требованиями к ПО заключается в планировании и контроле формирования требований, задании на их основе проектных решений, в преобразовании их в спецификации компонентов системы на других процессах.
Качество и процесс улучшения требований - это процесс проверки характеристик и атрибутов качества (надежность, реактивность и др.), которыми должна обладать система и ПО, методы их достижения на процессах ЖЦ.
Управление требованиями к системе - это руководство процессами формирования требований на всех этапах ЖЦ, которое включаетуправление изменениями требований, отражающих свойства программного продукта, а также восстановление источника требований. Неотъемлемой составляющей процесса управления является трассирование требований, состоящее в отслеживании правильности задания и реализации требований к системе и ПО на этапах ЖЦ и обратный процесс сверки ПС с заданными требованиями.
Основные задачи управления требованиями это:
разработка атрибутов требований,
управление вариантами требований,
управление рисками, возникающими при неточном определении требований,
контроль статуса требований, измерение усилий при формировании требований;
реализация требований на этапах ЖЦ.
Разработка и управление требованиями связана с другими областями знаний (рис. 3.2.):
Рис. 3.2. Разработка, управление требованиями и связь с задачами SWEBOK
Управление рисками состоит в контроле появления и обнаружения неадекватных ситуаций при реализации требований, оценке их влияния на другие процессы и в предупреждении рисковых ситуаций.
3.1.4. Фиксация требований
Фиксация требований (Requirement Capturing) в техническом задании определяется желаниями заказчика получить при реализации заданные им свойства системы. При этом предусмативается спецификация, верификация и валидация требований на правильность, соответствие и полноту.
Спецификация требований к ПО - это формализованное описание функциональных, нефункциональных и системных требований, требований к характеристикам качества, а также к структуре ПО, принципам взаимодействия с другими компонентами, алгоритмам и структуре данных системы.
Валидация требований - это проверка требований, для того чтобы убедиться, что они определяют именно данную систему. Заказчик и разработчик ПО проводят экспертизу