Эпизод -03 «Генезиса модели процесса»

В следующем блоге будет обсуждаться последовательность операций и этапы предлагаемой «Модели процесса очистки». Может потребоваться краткое введение в модель процесса Panduring и необходимость предложить такую ​​модель процесса во время этой пандемии.

Episode 01:Pandemic has exposed the vulnerabilities of _* ?
Episode 02: The Panduring Process Model

Фазы и процессы

Модель состоит из трех основных этапов.

1. Этап проектирования

2. Этап реализации

3. Этап интеграции

По сути, существует 6 процессов, которые могут охватывать фазы.

1. Разработка требований

2. Исследования

3. Дизайн

4. Реализация

5. Тестирование

6. Развертывание и поддержка

Объяснение потока процессов

● Первоначально проект начинается с буферного времени. Это время используется для подготовки и организации падения в модель после смены модели. В каком бы состоянии вы ни находились своей предыдущей модели, буферное время будет уделять особое внимание подготовке соответствующих SRS (Спецификация требований к программному обеспечению), SDS (Спецификация разработки программного обеспечения), методологической документации (MD). Эти документы никогда не должны быть исчерпывающими, но они должны давать общее представление, а поскольку итеративность может включать более подробную информацию позже. Модель Panduring требует соблюдения предписанной в ней ступенчатой ​​структуры. После определенного времени изучения требований можно перейти к процессу исследования (не раньше, чем через 2 недели после начала разработки требований).

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

● Находясь в фазе исследования в течение нескольких недель, может начать первоначальный дизайн с общей идеи (даже без методологического документа, но с выпущенным SRS, а не раньше, чем через 5 недель после начала проекта). Затем будет выпущен официальный методологический документ, после чего можно будет завершить разработку и составить паспорта безопасности.

● Только после выпуска SDS начнется процесс внедрения. Здесь не будет итераций от дизайна к реализации, и разработчики будут работать над фиксированной SRS. Но это не помешает клиентам добавлять новые функции или изменять требования. Процесс разработки требований, исследований и проектирования будет продолжаться, и изменения будут добавлены в «Требования», «Дизайн» отставания. Реализация продолжает создавать прототип POC (Proof-of-concept).

● После выпуска прототипа POC, который знаменует собой выход из фазы проектирования, процесс снова начинается с разработки требований, чтобы обозначить начало фазы внедрения. Теперь «отставание требований» рассматривается (или очищается), исправляется и добавляется в SRS. Точно так же, если требуются какие-либо изменения, процесс исследования передаст их на этап проектирования. Теперь процесс проектирования очищает «отставание проектирования» и проверяет, есть ли какие-либо другие изменения, и добавляет их в SDS. Затем реализация реальной системы начинается с пересмотренных SRS и SDS. Теперь процесс разработки и процесс реализации разделены, и любые новые изменения добавляются в соответствующие невыполненные задачи.

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

● После завершения процесса будет выпущен отчет о тестировании, руководство для пользователя и разработчика, а продукт / система будут отправлены и развернуты (процесс развертывания и поддержки) и будут продолжать оказывать поддержку.

● Поддержка (часть развертывания и поддержки) представляет собой аналогичную структуру шагов от разработки требований до развертывания.

Фаза проектирования

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

После первоначальной оценки осуществимости проекта команда будет постоянно взаимодействовать для уточнения требований, проверки приоритетов, обсуждения рисков, затрат и продолжительности, а также выявления и определения SRS. Требования должны быть полностью изучены. Необходимо проанализировать первоначальные технические и ресурсные ограничения и принять решение о дальнейших действиях. Оценки стоимости и графика должны быть достоверными. Необязательно иметь полное изучение затрат и сроков, но необходимо, чтобы приблизительная идея была обсуждена и согласована. Должен быть подготовлен документ SRS (документ с хорошо проработанными функциональными, нефункциональными и предметными требованиями проекта, ключевыми функциями и основными ограничениями). Это первая веха / результат проекта.

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

Фаза, связанная с подготовкой методологических документов и документов по разработке программного обеспечения, которые развивают выбранную методологию, предписанную в методологическом документе. Этот этап является наиболее важным среди других этапов, поскольку на этом этапе принимается главное решение для оценки того, являются ли требования технически надежными, а также набор подходов к конечным системам и разработанному конструктивному проекту по выбранной методологии (следует ли выполнять проект или нет). Будет несколько итераций обсуждений между процессами проектирования, исследования и разработки требований. До выпуска SDS все изменения в SRS и методологиях будут интегрированы. Затем с помощью SDS реализация проекта начинает создавать прототип POC, который отмечает выход из фазы. Во время этой реализации проекта все требования или изменения проекта будут добавлены в соответствующие резервные журналы, а не в SRS или SDS.

Фаза реализации

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

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

Фаза интеграции

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

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

Результат

Модель процесса требует строгого сопровождения документации. Это необходимо для обеспечения ремонтопригодности кода и перехода от одной модели процесса к другой в любой момент.

1. Спецификация требований к программному обеспечению (SRS)

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

2. Документ о методологиях (MD)

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

3. Спецификация разработки программного обеспечения (SDS)

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

4. Прототип POC (прототип прототипа)

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

5. Исполняемые системы

Это будут полнофункциональные исполняемые системы, которые будут отправлены клиентам для оценки модели; как работает система; соответствует ли система установленным требованиям; вся система в порядке. Это своего рода альфа- и бета-тестирование системы.

6. Отчет об испытаниях

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

7. Руководство пользователя.

Документ, который предназначен для оказания помощи заинтересованным сторонам, пользователям определенной системы.

8. Руководство разработчика.

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

Долговечность

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

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

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

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