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

У прагненні досягти найвищого рівня зрілості компанія Finport Technologies пішла шляхом повторення і передбачуваності процесів, використовуючи чітко визначений процес розробки, що вдосконалюється від проекту до проекту, і що підвищує ефективність та продуктивність Компанії в цілому.
Підхід компанії базується на перевіреній методології і всесвітньо визнаній моделі 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 (Перехід)

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

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

Основна мета цієї фази – гарантувати, що система має високу якість, проект відповідає очікуванням клієнта або перевершує їх. Результатом фази є повне завершення розробки, досягнення готовності системи і закриття проекту.
Відповідно до вище описаного, окрему ітерацію можна зобразити наступним чином: