Построение моделей процесса разработки ПО в рамках учебных проектов в НИУ ВШЭ - Пермь, Описание бизнес-процесса "как есть" - Методика моделирования основных процессов разработки программного обеспечения

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

Описание бизнес-процесса "как есть"

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

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

Из особенностей текущего процесса разработки ПО в университете можно отметить следующие:

    1. Всю информации о задаче и проекте студенты могут получить лишь непосредственно от своего научного руководителя, при этом он помогает формализовать общие требования к программной разработке, а также подсказывает студентам по ходу работы с пониманием отдельных деталей конечного программного продукта. 2. Процесс разработки ПО ведется итерационно, то есть, после выполнения определенной части работы, текущий результат демонстрируется научному руководителю с целью оценки текущей работы и сопутствующей возможной переработки требований, а также с целью уточнения части требований для дальнейшей работы. 3. Задачи между участниками проектных групп распределяются в процессе работы. 4. Описание всей выполненной работы содержится в одном отчете, который впоследствии хранится на кафедре.

Исходя из упомянутых особенностей текущего процесса разработки ПО, можно выделить следующие его недостатки:

    1. Информацию о задаче студенты могут получить только от научного руководителя. В случае, когда текущий учебный проект является частью более большого проекта, студентам может понадобиться дополнительное описание разработок, программного кода, и преподавателю придется искать это вручную по частям в предыдущих отчетах студентов, которые доступны зачастую в печатном виде на кафедре. Отсюда вытекает следующая проблема, вся работа по сбору и передаче опыта между студентами лежит на плечах преподавателя, что может быть затратно, когда у преподавателя несколько учебных проектных групп. Таким образом, на данный момент существует проблема передачи и сохранения опыта при работе над студенческими проектами. 2. Отсутствие отдельного документирования разработок, что может быть важно, когда данная информация понадобится другим студенческим проектным группам. Данная проблема также является частью проблемы передачи опыта, описанной в предыдущем пункте. То есть, вместо поиска нужного отчета с нужной документацией, удобней было бы хранить подобные документации в централизованном месте в цифровом виде. 3. Отсутствие четкого распределения ролей в проектных группах. Например, в начале работы не всегда определяется так называемый капитан команды, который занимается организацией работы внутри группы и взаимодействием с научным руководителем, из-за этого обычно возникают трудности в процессе коммуникации как внутри группы, так и с самим научным руководителем. Также, из-за этой проблемы, задачи изначально не всегда распределяются между участниками проектных групп, то есть они понимают общий объем работ, но не всегда понимают деталей и сопутствующих процессов, их трудоемкости. Таким образом, это ведет к неравномерному распределению задач между всеми участниками проектных команд. Это же касается и взаимодействия с преподавателем, обычно этим занимается тот студент, которому это удобно в данный момент. Таким образом каждое взаимодействие между проектной группой и научным руководителем будет различаться, так как каждый раз состав участников будет различен, что негативно сказывается на результатах самого взаимодействия [15]. Это может привести, например, к недопониманию требований, или представитель проектной группы может не знать обо всех аспектах, которые нужно было в данный момент уточнить у преподавателя.

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

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




Построение моделей процесса разработки ПО в рамках учебных проектов в НИУ ВШЭ - Пермь, Описание бизнес-процесса "как есть" - Методика моделирования основных процессов разработки программного обеспечения

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