Описание бизнес-процесса "как должно быть" - Методика моделирования основных процессов разработки программного обеспечения

Данный процесс отражает регламент работ по разработке программных продуктов в рамках учебных проектов, который будет использован при создании исполяемой модели в Bizagi. То есть, данный процесс отражает этапы разработки программного обеспечения так, как это должно быть в идеальном случае. Сам процесс поэтапно приведен в приложении В.

Принципы работы каждой команды студентов может на некоторых этапах отличаться от построенной модели, так как она призвана описать ситуацию в общем. То есть, для большинства случаев данная модель будет описывать рабочий процесс по проекту.

На рисунке В.1 приведен общий процесс разработки программного обеспечения, который декомпозируется в дальнейшем для этапов "Формирование первичных требований" и "Разработка программного продукта".

В общем, процесс разработки ПО включает в себя следующие этапы:

1. Распределение ролей в команде.

На данном этапе все участники распределяют роли между собой, каждая роль включает в себя определенный набор компетенций и задач, за который участник проектной группы будет ответственным. Полный перечень ролей и соответствующих им задач и зон ответственности представлен в таблице А.1 в приложении А.

При это учитывается, что один человек может совмещать несколько ролей. Для того, чтобы данное совмещение было наиболее эффективным, на основе методологии MSF были разработаны матрицы ответственности и совмещения ролей участников проектной группы [4]. Данные матрица были представлены в соответствующих таблицах в первой главе данной работы.

2. Подготовка к процессу разработки. Данный этап более подробно отображен на рисунке В.2 в приложении В.

На данном этапе происходит уточнение требований к программному продукту от научного руководителя/заказчика, параллельно с этим осуществляется поиск в TFS документаций по смежным проектам, если такие имеются.

Изначально необходимо точно сформулировать основные идеи, которые определяют цель визита к заказчику. Участники команды проекта должны очень ясно представлять себе, какого рода информация нужна и каким образом она будет использована. Только после этого необходимо переходить к разработке списка вопросов, которые будут заданы заказчику [5].

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

Краи?не важным моментом является "встраивание" информации, полученнои? в процессе интервью с заказчиком, в проектную документацию - иначе вся собранная информация не имеет никакого значения для проекта [5].

На основе полученных от обоих участников проектной группы данных формируется первоначальный перечень всех требований к разработке, как с функциональной точки зрения, так и с точки зрения архитектуры решения. Данный список заносится в рабочую область TFS, к которой имеют доступ все члены проектной команды.

На основе полученного списка требований формируется календарный план работ с использованием MS Project. Данный план должен включать не только основные этапы проекта, но и примерное разбиение по итерациям циклов разработки с примерным перечнем задач на каждую итерацию. В процессе разработки итоговое количество таких итераций может изменяться в зависимости от итоговой сложности задач или каких-либо других факторов. Каждое такое изменение должно фиксироваться в итоговом календарном плане. Следует отметить, что в TFS имеется интеграция с сервером сетевого планирования, что упростит задачу актуализации календарного плана и доступа к нему всех участников проектной команды.

3. Разработка программного продукта. Данный этап более подробно отображен на рисунке В.3 в приложении В.

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

После проработки архитектуры решения, согласно созданному календарному плану проекта, начинаются отдельные спринты разработки конечного программного продукта. В рамках каждого спринта выполняются следующие этапы:

3.1. Формирование списка задач для реализации в текущем спринте на основе перечня всех требований к программному продукту, сформированный список заносится в общую рабочую область TFS. Данный шаг выполняется аналитиком и менеджером проекта.

Процесс определения состава операции? начинается с определения степени детализации операции?. Количество операции? должно быть достаточным для того, чтобы ответственный? за выполнение работ мог отслеживать ход исполнения и осуществлять координацию работ. При этом, число операции? не должно быть слишком большим, затрудняющим оценку общего состояния проекта [5].

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

    3.2. При необходимости менеджер проекта может сдвинуть календарный план, если на этапе формирования списка задач были замечены недочеты или в предыдущей итерации разработки были временные отклонения от плана либо реализованы не все требования, которые должны были быть реализованы по плану. 3.3. Группа разработчиков самостоятельно распределяет между собой задачи, требующие реализации в текущем спринте. Это сделано, так как разработчики лучше могут оценить свой набор навыков и компетенций и распределить задачи так, чтобы увеличить качество конечного продукта [6, 13]. Все свои задачи каждый разработчик вносит в общую рабочую область TFS, таким образом, остальные участники проектной команды смогут отслеживать статус текущих работ.

При этом менеджеру проекта важно знать планируемые длительности работ, чтобы учитывать их в сводном плане.

Для определения длительности операции? можно использовать следующие инструменты и методы.

Оценка по аналогам подразумевает оценку фактической? длительности аналогичной? предыдущей? плановой? операции в качестве основы для оценки длительности будущей? плановой? операции и использует историческую информацию и экспертную оценку [5].

Параметрическая оценка. Оценочную величину длительности операции? можно вычислить путем умножения количества работы на производительность труда. Для определения длительности операции? по рабочим периодам общее количество ресурсов умножается на количество рабочего времени или производительность за рабочий? период и делится на количество привлеченных ресурсов [5].

После определения задач, их длительности и назначенных исполнителей следует процесс их реализации.

    3.4. По результатам разработки, тестировщик ищет ошибки в программном продукте. Если они есть, то цикл разработки повторяется, если нет, то разработчик документирует текущий результат и заносит всю информацию, включая описание и исходные коды, в общую рабочую область TFS. Спринт разработки завершается, когда реализованы все задачи, заданные на данный спринт либо, когда заканчивается отведенное менеджером проекта время на текущий спринт. 3.5. Если в рамках текущего спринта были реализованы все требования заказчика, то программный продукт демонстрируется ему. Если он утверждает, что нужны доработки или если в рамках текущего спринта были решены не все задачи, то начинается следующий спринт, таким образом повторяются пункты 3.1 - 3.5. Если после демонстрации заказчику, его все устраивает, то процесс разработки считается завершенным, программный продукт готов. 4. На основе всей документации, полученной на предыдущих этапах, включающей формализованное описание требований к разработке, постановку программного продукта, календарный план разработки, техническое описание архитектуры решения и каждого разработанного компонента с их исходными кодами, членами команды создается отчет о проделанной работе. При этом каждый из членов команды ответственен за соответствующий его работе раздел. Аналитик проектной команды ответственен за сбор информации от каждого члена команды, менеджер проекта отвечает формирование общего отчета.

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

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

Похожие статьи




Описание бизнес-процесса "как должно быть" - Методика моделирования основных процессов разработки программного обеспечения

Предыдущая | Следующая