No Image

Проект разработки программного обеспечения пример

СОДЕРЖАНИЕ
3 708 просмотров
10 марта 2020

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

Зачем нужно проектировать программу и соблюдать этапы разработки?

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

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

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

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

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

Чем раньше будут обнаружены ошибки или выявлен неправильных подход в реализации того или иного действия, тем цена этих ошибок будет меньше. Иными словами, в зависимости от этапа обнаружения ошибки ее цена может меняться от 10 до 100 раз. Например, если на самом начальном этапе цена исправления ошибки будет равняться 100 рублей, то на этапе тестирования она может вылиться в 10000. Поэтому этапы разработки ПО очень важны, и разработчик должен их соблюдать и попытаться донести это видение до менеджеров, которым всегда нужен только результат. Так как они или отводят на это слишком мало времени или и вовсе не считают это необходимым, например, зачем при программировании вырабатывать какие-то требования или что-то там проектировать.

Основные этапы разработки ПО

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

Некоторым может показаться, что это слишком сложный план, но если Вы будете работать над крупным проектом, то столкнётесь со всем этим, и даже более детализированным планом.

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

Этап 1 – Определение проблемы

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

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

Определение проблемы – это фундамент всего процесса программирования!

Этап 2 – Выработка требований

Что такое требования и зачем их нужно выработать?

Требования к программе – это подробное описание всех возможностей программы и действий, которые должна выполнять программа. Такие требования иногда также называют «Функциональной спецификацией» или просто «Спецификацией».

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

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

Этап 3 – Создание плана разработки

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

Этап 4 – Разработка архитектуры системы или высокоуровневое проектирование

Архитектура системы – это каркас программы, это высокоуровневое проектирование программы.

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

Архитектура системы обычно включает:

  • Общее описание системы;
  • Основные компоненты;
  • Формат и способ хранения данных;
  • Специфические бизнес-правила;
  • Способ организации пользовательского интерфейса;
  • Подход к безопасности системы;
  • Оценки производительности;
  • Возможности масштабирования;
  • Моменты, связанные с интернациональностью, т.е. будет ли система интернациональной.

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

Этап 5 – Детальное проектирование

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

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

Но при реализации крупных проектов данному процессу отводится отдельный этап и проектирование в этом случае проводится с очень высокой степенью детальности.

Этап 6 – Кодирование и отладка

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

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

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

Этап 7 – Тестирование компонентов

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

Этап 8 – Интеграция компонентов

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

Читайте также:  Kinect xbox one обзор

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

Этап 9 – Тестирование всей системы

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

Этап 10 – Сопровождение, внесение изменений, оптимизация

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

Если Вы хотите погрузиться глубже в мир проектирования и конструирования программного обеспечения, то рекомендую почитать книгу Стива Макконнелла «Совершенный код», в которой очень детально рассказывается о том, как нужно разрабатывать программу, и как правильно писать код. С помощью нее Вы не научитесь какому-нибудь языку программирования, но Вы научитесь писать правильный код, иными словами, она для тех, кто уже владеет базовыми знаниями в программировании.

Если Вы еще не умеете программировать, и даже не знаете, с чего начать, то в этом случае я рекомендую Вам начать с книги «Как стать программистом? 14 советов по достижению поставленной цели», в ней приведены советы и рассмотрен конкретный план действий, которые помогут Вам стать программистом.

У меня на этом все, надеюсь, статья была Вам интересна. Пока!

Руководитель (заказчика ИС)

Личная подпись_Расшифровка подписи

Руководитель (разработчика ИС)

Личная подпись_Расшифровка подписи_

Эскизный проект на создание информационной системы

Система Управления Базой Данных

(наименование вида И С)

БИБЛИОТЕЧНЫЙ ФОНД РОССИЙСКОЙ ФЕДЕРАЦИИ

(наименование объекта информатизации)

(сокращенное наименование ИС)

Ведомость эскизного проекта. 362

Пояснительная записка к эскизному проекту. 363

Общие положения. 363

Основные технические решения. 363

Решения по структуре системы. 363

Решения по режимам функционирования,

работы системы. 365

Решения по численности, квалификации и функциям персонала АС. 365

Состав функций комплексов задач, реализуемых системой. 365

Решения по составу программных средств, языкам деятельности, алгоритмам процедур и операций и методам их реализации. 366

Источники разработки. 367

Ведомость эскизного проекта

На предыдущих стадиях разработки СУБД «Пенсионный Фонд» были составлены и утверждены следующие документы:

• Техническое задание на создание информационной системы СУБД «Пенсионный Фонд», разработанное на основании ГОСТ 34.602—89 на написание ТЗ на автоматизированные системы управления от 01.01.1990 г.

Пояснительная записка к эскизному проекту

Данный документ является эскизным проектом на создание Системы Управления Базой Данных для Библиотечного Фонда Российской Федерации (СУБД «Библиотека»).

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

Основные технические решения

Решения по структуре системы

СУБД «Библиотека» будет представлять собой персональную систему управления локальной базой данных, работающей на одном компьютере.

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

Общая структура базы данных:

  • • Анкеты организации, которые зарегистрированы в данном ПФ:
  • — Тип предприятия (Российская организация, Физическое лицо, Иностранная организация, Обособленное подразделение).
  • — Вид предприятия (Адвокаты, Бюджетное, Единый налог 6 %, Единый налог 15 %, Сельхозпродукция, Службы занятости, Фермерское хозяйство, Прочее).
  • — Регистрационный номер работодателя в ПФР (3 — 3 — 6).
  • — Свидетельство: серия, номер.
  • — Дата выдачи свидетельства (число_месяц_год).
  • — ИНН.
  • — КПП.
  • — Наименование.
  • — Юридический адрес:
  • • Почтовый индекс.
  • • Регион.
  • • Район.
  • • Город.
  • • Населенный пункт.
  • • Улица.
  • • Дом.
  • • Корпус.
  • • Квартира.
  • — Адрес постоянно действующего органа (при отличии от юридического).
  • • Анкеты сотрудников этих организаций:
    • — Фамилия.
    • — Имя.
    • — Отчество.
    • — Пол (М/Ж).
    • — Дата рождения (Дата).
    • — Страховой номер.
    • — Место рождения (Страна, Регион, Район, Город, Населенный пункт).
    • — Гражданство.
    • — Адрес регистрации (Страна, Почтовый индекс, Регион, Район, Город, Населенный пункт, Улица, Дом, Корпус, Квартира).
    • — Адрес места жительства фактический (Страна, Почтовый индекс, Регион, Район, Город, Населенный пункт, Улица, Дом, Корпус, Квартира).
    • — Телефон домашний.
    • — Телефон служебный.
    • — Документ (Удостовер. личность).
    • — Дата выдачи (Дата).
    • — Кем выдан ().
    • — Дата заполнения (Дата).
    • — ИНН.
    • • Сведения о стаже сотрудников этих организаций:
    • — Страховой номер.
    • — Фамилия.
    • — Имя.
    • — Отчество.
    • — Дата рождения.
    • — Территориальные условия проживания на .
    • — Таблица периодов работы со следующей структурой:
    • • Начало периода (дата).
    • • Конец периода (дата).
    • • Вид деятельности (работа, служба соцстрах, уход-дети, безр, реабилит, уход-инвд, профзаб, пересмотр).
    • • Наименование организации.
    • • Должность.
    • • Территориальные условия.
    • Решения по режимам функционирования, работы системы

      СУБД «Библиотека» будет функционировать в однопользовательском режиме, а также будет способна:

      • • просматривать записи базы данных (в том числе и при помощи фильтров);
      • • добавлять новые записи;
      • • удалять записи;
      • • при входе в систему будет запрашиваться пароль.

      Решения по численности, квалификации и функциям персонала АС

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

      Состав функций комплексов задач, реализуемых системой

      Автоматизированная система должна выполнять следующие функции:

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

      Решения по составу программных средств, языкам

      деятельности, алгоритмам процедур и операций

      и методам их реализации

      Для реализации АС будет использоваться среда программирования Boland Delphi 7.0 и язык программирования Object Pascal.

      Для подсчета пенсии будет использоваться следующий алгоритм.

      Вначале определяется стажевый коэффициент пенсионера. Он полагается равным 0,55 за общий трудовой стаж до текущей даты не менее 25 лет мужчинам и 20 лет женщинам. За каждый полный год стажа сверх указанного стажевый коэффициент увеличивается на 0,01, но не более чем на 0,20.

      Затем определяется отношение заработка пенсионера к среднемесячной заработной плате в стране. Этот заработок может быть взят за этот отсчетный период или за любые 60 месяцев работы подряд, или тот, из которого была исчислена пенсия на момент реформы. Среднемесячная зарплата в стране берется за тот же самый период.

      Отношение заработков учитывается в размере не свыше 1,2. Для пенсионеров, проживающих на Крайнем Севере, учитываемое соотношение выше: от 1,4 до 1,9 в зависимости от установленного в централизованном порядке районного коэффициента к зарплате.

      Читайте также:  Разгон видеокарты nvidia geforce gtx 760

      Затем стажевый коэффициент умножается на соотношение заработков и на 1671 руб. — утвержденную для расчетов среднемесячную зарплату в стране за 111 квартал 2001 г. Это и будет пересчитанный размер трудовой пенсии по новому законодательству в обычном случае. Если он оказался менее 660 руб., то размер пенсии «доводится» до этого гарантированного минимума.

      Если пенсионер является инвалидом I группы или достиг к 1 января 2002 г. возраста 80 лет и более, рассчитанный в этом порядке размер пенсии по старости увеличивается на 450 руб.

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

      Данный документ разрабатывался на основании ГОСТ 34.698—90 на написание ТЗ на автоматизированные системы управления от 01.01.1992 г.

      в LinkedIn

      на free-lance.ru

      в ЖЖ

      in english

      В индустрии разработки программного обеспечения (ПО) существуют много различных методологий разработки, которые представляют из себя достаточно концептуальные видения того, как следует реализовывать проекты по созданию ПО. В качестве примеров таких методологий можно привести: Rational Unified Process (RUP), Microsoft Solution Framework (MSF), Extreme Programming (XP), Agile, Capability Maturity Model Integration (CMMI) и многие другие.

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

      Как показывает опыт автора, вполне возможно создать небольшую группу разработки и начать делать софт и без четкого описания бизнес-процесса. Однако, когда число участников такой «неформальной» команды становится больше пяти человек, то потери от отсутствия четкого регламента становятся несопоставимо большими по сравнению с затратами на регламентацию бизнес-процесса и специализированное ПО для его автоматизации. Потери в данном случае могут быть как прямыми (например, бесконечные переделки одной и той же функциональности по причине несоответствия требованиям заказчика), так и косвенными (например, ухудшение психологической атмосферы в коллективе, связанное с непониманием зоны своей ответственности каждым участником команды).

      В данной статье приводится пример бизнес-процесса разработки ПО, созданный автором на основе элементов нескольких методологий (наибольшее количество элементов взято из MSF) и собственного многолетнего опыта разработки и управления разработкой ПО. Данный бизнес-процесс ориентирован на ведение крупных проектов по разработке ПО на достаточно «зрелой» стадии, когда продукт уже может эксплуатироваться заказчиками и когда речь уже идет скорее о развитии и доработках функционала, а также устранении «багов», нежели о разработке «с нуля» небольших программных продуктов.

      Содержание

      Ролевая модель

      Наименование роли Зона ответственности
      Руководитель проекта • Формирование планов
      • Контроль выполнения планов
      • Организационная работа (в том числе и с Заказчиком)
      • Концептуальная архитектура решения
      • Часть аналитической работы
      Руководитель группы • Оценка длительности и трудоемкости задач в процессе планирования
      • Контроль выполнения планов группой
      • Распределение работ внутри группы
      • Концептуальная архитектура решения
      • Часть аналитической работы
      • Организация сбора требований заказчика
      • Соответствие деятельности группы бизнес-процессу разработки
      • Работа группы с заказчиком
      Аналитик • Сбор требований заказчика
      • Разработка ТП на функциональность
      • Разработка планов тестирования
      • Концептуальное тестирование функциональности
      • Разработка пользовательской документации
      Архитектор • Архитектура решения, и соответствие ее требованиям к решению
      • Разработка РП на функциональность (определяет принципиальные моменты, в дальнейшем их детализирует в рамках РП Разработчик)
      • Контроль качества кода, и соответствие его проектным решениям по архитектуре
      • Репозиторий информации по архитектуре решения
      • Участвует в формировании планов и оценке сложности и длительности задач
      • Участвует в комплексном тестировании
      Разработчик • Разработка РП (при участии Архитектора в процессе выработки принципиальных решений)
      • Разработка функциональности
      • Качество кода
      • Исправление ошибок в коде
      • Проведение первичного тестирования кода
      • Участвует в комплексном тестировании кода
      Тестер • Тестирование функциональности
      • Написание Unit тестов
      • Участвует в разработке планов тестирования
      Билд-инженер • Сборка версии
      • Выпуск версии (после тестирования)
      • Подготовка сопроводительных документов к версии

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

      Рук-ль проекта Рук-ль группы Аналитик Архи- тектор Разра- ботчик Тестер Билд- инженер
      Руководитель проекта +
      Руководитель группы + + Аналитик + + Архитектор + + Разработчик + +
      Тестер + + +
      Билд-инженер + + Схема бизнес-процесса

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

      Бизнес-процесс включает в себя пять групп (контуров) работ:

      Контур сбора требований

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

      В частности, требованиями являются:

      Требования могут поступать из различных источников, например:

      Все требования хранятся в Репозитории требований. Подробнее о требованиях (их атрибутах и жизненном цикле) написано в разделе «Информационная модель».

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

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

      Все требования делятся на две группы с точки зрения подхода к их реализации:

      Решение о реализации мелких доработок принимается руководителем группы путем назначения требования на соответствующего разработчика (Контур небольших доработок).

      Реализация средних и крупных доработок происходит постадийно:

      Контур среднесрочного планирования

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

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

      На основании среднесрочного плана по реализации требований производится детальное планирование аналитических работ по написанию ТП с постановкой задачи по их реализации.

      Планы работ хранятся в Репозитории задач.

      Контур аналитических работ

      Согласно плану работ Аналитик производит аналитическую проработку требования и составляет документ с утвержденной структурой разделов – Технический проект с описанием логики реализации требования.

      Технический проект, подготовленный Аналитиком, согласуется с:

      После составления и согласования ТП требование помечается как готовое к включению в план разработки версии.

      Технический проект, как и остальная документация хранится в Репозитории документации.

      Контур разработки версии

      Контур разработки версии представляет из себя одну итерацию разработки: от планирования работ по версии, до ее выпуска. После выпуска одной версии, начинаются работ по следующей версии.

      Читайте также:  Как можно подключить флешку к магнитоле

      При планировании работ по версии проектная команда просматривает требования, выбирая среди них те, которые:

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

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

      Затем согласно плану Разработчик совместно с Архитектором (в части концептуальных архитектурных решений) на основании Технического проекта пишет Рабочий проект, в котором описывает реализацию соответствующего требования.

      Рабочий проект, подготовленный Разработчиком, согласуется с:

      После согласования рабочего проекта Разработчик приступает к его реализации, а Архитектор обновляет архитектурную модель решения в соответствии с Рабочим проектом.

      Для достаточно крупных требований функционал в рамках одного требования (и, соответственно, Рабочего проекта) реализуется несколькими частями. После разработки одной части происходит ее автоматическое тестирование и проверка качества кода Архитектором. Если выявляются недочеты – Разработчик их устраняет.

      После реализации всех частей одного требования Разработчик демонстрирует разработанный функционал Аналитику – происходит его концептуальное тестирование, т.е. тестирование на предмет соответствия потребностям пользователей. Если выявляются несоответствия потребностям пользователей, то происходит либо доработка Рабочего проекта и, затем, реализованного функционала либо сразу доработка функционала (в случае мелких замечаний, не требующих изменения Рабочего проекта и архитектурной модели).

      В случае успешного концептуального тестирования Разработчик приступает к реализации следующего требования в соответствии с планом работ по версии.

      Также после согласования новой функциональности Аналитик обновляет пользовательскую документацию на решение.

      После того, как все доработки, запланированные в версии, реализованы Билд-инженер производит сборку версии. Билд-инженер, формирует Сопроводительный документ к версии, в котором:

      Собранная версия тестируется Тестером при участии Аналитика согласно плану тестирования, являющегося составной частью Технического проекта, разработанного Аналитиком. Выявленные ошибки регистрируются в Репозитории требований в виде требований с типом «Ошибка тестирования версии».

      Выявленные ошибки устраняются Разрабочтиками, которые реализовывали соответствующий функционал, при необходимости модифицируется Рабочий проект и Архитектурная модель.

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

      После того как принято решение о выпуске версии Билд-инженер готовит дистрибутивы и Сопроводительный документ (актуализирует его при необходимости) и передает его для развертывания.

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

      Контур небольших доработок

      Небольшие доработки – доработки с длительностью реализации менее человеко-дня, не требующие написания Технического проекта и Рабочего проекта.

      Все небольшие доработки делятся на две группы:

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

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

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

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

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

      Участие ролей в операциях бизнес-процесса

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

      На схеме ниже в качестве примера приведено распределение работ при разработке версии с длительностью 8 недель. Рассмотрена вся проектная команда, задействованная во всех контурах работ.

      Ключевым элементом данного бизнес-процесса, проиллюстрированным на схеме, является независимое выполнение аналитических работ (Технический проект) и работ по разработке версии (Рабочий проект и реализация) друг от друга с целью обеспечения равномерной загрузки Аналитика на всей итерации разработки.

      Также важным моментом является участие Разработчика, как в плановых работах по версии, так и в устранении мелких, в т.ч. высоко критичных замечаний.

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

      Билд-инженер имеет невысокую загрузку на большей части итерации, поэтому, целесообразно совмещение этой роли с одной из следующих ролей: Разработчик, Руководитель группы, Архитектор.

      Важнейшей задачей Архитектора помимо участия в написании Рабочих проектов и контроля технической стороны проведения разработки является также ведение Репозитория архитектуры – обновления его по мере разработки новой функциональности в соответствии с Рабочими проектами.

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

      Информационная модель бизнес-процесса

      Все виды информации в рамках бизнес-процесса разработки распределяются по пяти хранилищам (репозиториям):

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

      На схеме ниже показаны примеры содержимого репозиториев и взаимосвязи между ними. Затем в таблице дается краткое пояснение по содержимому репозиториев и описаны взаимосвязи между их элементами.

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

      Группы могут быть вложенными. Требования вложенными быть не могут.

      Каждое требование содержит следующую информацию:

      Поле «Текущий статус», отражающее жизненный цикл требования, может иметь следующие значения:

      Статусы требований меняются вручную соответствующими ролями по завершении этапов работ в соответствии с бизнес-процессом.

      С каждым требованием могут быть ассоциированы элементы из следующих репозиториев:

      Весь код решения с поддержкой ветвления версий.

      Для целей срочной реализации критических доработок в рамках Репозитория кода существуют два экземпляра кода решения:

      После выпуска промежуточной версии, вносятся соответствующие изменения в Рабочую версию в полуавтоматическом режиме.

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

      Наименование репозитория Краткое описание
      Репозиторий требований
      Репозиторий архитектуры

      Хранилище с описанием архитектуры. Включает в себя следующие элементы:

      С каждым пакетом или компонентом на моделях 2-го уровня в репозитории архитектуры могут быть ассоциированы элементы из следующих репозиториев:

      Репозиторий документации

      Хранилище файлов различных типов, используемых как сами по себе (например, Договорные документы, Протоколы, Акты и др.), так и в связке с элементами из репозитория требований (ТП, РП) и репозитория архитектуры (описания компонентов, слоев).

      Репозиторий кода
      Репозитория задач (план работ)
      Комментировать
      3 708 просмотров
      Комментариев нет, будьте первым кто его оставит

      Это интересно
      © 2019 | All rights reserved.
      Adblock
      detector