Процесс

Подход к процессу разработки

В стремлении достичь наивысшего уровня зрелости, наша Компания пошла путем повторения и предсказуемости процессов, используя чётко определённый процесс разработки, совершенствующийся от проекта к проекту и повышающий эффективность и продуктивность Компании в целом. Подход Компании базируется на проверенной методологии и всемирно признанной модели Rational Unified Process (RUP) и модели зрелости процессов разработки СММ.
 
Компания Finport Technologies использует итеративный процесс разработки программного обеспечения. Передовая практика Компании в разработке проектов, профессиональный проектный менеджмент (Project Management) и гарантия качества (QA) являются базисом успеха проекта и гарантируют, что проект будет разработан в рамках графика и бюджета.
 
Понятия «время» и «цель» являются базовыми для процесса разработки. Время проектной разработки разделено на фазы, каждая из которых состоит из итераций. Каждая итерация состоит из конкретных процессов и действий, ведущих к цели. В основном, разработка ведётся на стороне разработчика; при необходимости, определённые стадии проекта могут разрабатываться на стороне заказчика. Пошаговый процесс реализует отдельные части общего программного решения. Это позволяет минимизировать риски проекта, повысить качество коммуникации на проекте и т.п., а, значит, и качество всего проекта.


Преимущества подхода

Итеративная разработка

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

Беспрерывная проверка качества продукта

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

Процесс управления требованиями

  1. Обмен информацией осуществляется на базе определённых требований.
  2. Требования могут быть разбиты по приоритетам, отфильтрованы и прослежены.
  3. Возможна объективная оценка необходимых ресурсов и времени.

Использование архитектуры, основанной на использовании компонентных объектов

  1. Компоненты способствуют достижению гибкости архитектуры.
  2. Модульность даёт возможность чётко сфокусироваться на элементах системы, которые подвергаются изменению.
  3. Многократное использование облегчается при использовании стандартизированных структур (таких как COM+, CORBA, и EJB) и доступных коммерческих компонентов.

Визуальное моделирование

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

Контроль изменений

  1. Процесс изменения требований определён и повторяем.
  2. Запросы на изменение (change requests) облегчают коммуникацию и чёткое понимание.
  3. Статистика доли изменений является хорошей метрикой для объективной оценки статуса проекта.
  4. Реализация изменения измерима и контролируема.

Разработка и управление разработкой

Компании различают две фундаментальные группы процессов разработки ПО – процессы разработки ПО (Software Development Processes) и процессы управления разработкой (Software Management Processes).

Разделение этих процессов приблизительно отображено на рисунке:

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

Что касается процессов разработки, то они циклически повторяются с каждой итерацией.

Фазы проектного цикла

Стандартный процесс разработки в Компании описывается четырьмя фазами: начало, проработка (уточнение), конструирование и развитие. Их общепринятые названия Inception, Elaboration, Construction, Transition:

Inception (Начало)

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


Elaboration (Проработка)

Это фаза подготовки к непосредственной разработке – программированию. Основная цель - достижение уровня понимания системы, достаточного для начала её реализации, и разносторонняя подготовка к старту. Фаза включает детализацию требований, проектирование архитектурного дизайна, согласование процессов и подходов с заказчиком, подготовку конфигурации (среды разработки, нструментария и т.п.), планирование необходимых видов деятельности и требуемых ресурсов, составление тест плана. Требования к системе анализируются намного глубже, в достаточной мере определяются риски проекта для получения точной оценки проекта. Детализированные требования, сроки и ресурсы, риски и ответственности сторон описываются в Техническом Задании. Далее формируется (устанавливается и конфигурируется) среда разработки и среда поддержки проекта. В следующую фазу команда должна переходить, имея в наличии спецификацию требований, план разработки проекта, тест план, архитектуру системы.

Construction (Конструирование)

Фаза состоит из повторяющихся итераций, каждая из которых состоит из анализа, дизайна, программирования, тестирования и промежуточных поставок/инсталляций у клиента. Это позволяет минимизировать затраты на возможные изменения, так как замечания и пожелания клиента поступают уже по ходу разработки. Процесс программирования постоянно сопровождается тестированием компонентов (unit testing) и периодичным пересмотром кода (code review).  Каждая сборка (build) сопровождается тщательным QA тестированием. Заказчику версия может поставляться только после успешного прохождения проверки QA (запланированное тестирование завершено и версия удовлетворяет критерии приёма сборки). Постепенно разрабатывается необходимая проектная документация.

Transition (Переход)

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

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

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

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