Лекция 4-Программная инженерия

Лекция 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.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) в техническом задании определяется желаниями заказчика получить при реализации заданные им свойства системы. При этом предусмативается спецификация, верификация и валидация требований на правильность, соответствие и полноту.

Спецификация требований к ПО - это формализованное описание функциональных, нефункциональных и системных требований, требований к характеристикам качества, а также к структуре ПО, принципам взаимодействия с другими компонентами, алгоритмам и структуре данных системы.

Валидация требований - это проверка требований, для того чтобы убедиться, что они определяют именно данную систему. Заказчик и разработчик ПО проводят экспертизу