Файл: Основы проектирования программ. Этапы создания программного обеспечения ( Основы разработки программ).pdf

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

Весь процесс разработки состоит из фаз.

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

Этот этап сопровождается следующей документацией:

Техническое задание (Software Requirement Specification)
Проектное предложение (Project Proposal)
План проекта (Project Plan)
Архитектура приложения (Software Architecture Document)

Техническое задание (Software Requirement Specification)определяет технические требования, в общем то, что клиент ожидает от будущей программы.

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

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

Документ Архитектура приложения заключает в себе всесторонний обзор архитектуры. Он описывает различные стороны решения. А также служит для фиксирования и передачи важных архитектурных решений при разработке.

Вторая фаза - проектирование системы

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

Этот этап сопровождается документом - Технический дизайн (Design Document).

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

разработка структуры данных,
архитектурное проектирование,
разработка интерфейсов ,
процедурное разработка.

Третья фаза представляет собой собственно процесс разработки.

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

На данном этапе создаются такие документы как, План тестирования (Test Plan) и Тестовые примеры (System Test Cases).

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

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

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

Следующая фаза - Системное тестирование.

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

Эта фаза характеризуется следующими действиями:

Прохождение тестовых примеров (Test cases running)
Исправление найденных ошибок (Bug Fixing)
Анализ запросов на изменения/исправления (Change request review)
Уточнение тестовых примеров (Update test cases)
Уточнение технического дизайна приложения (Update Design Document)

Этот этап сопровождается следующей документацией:

Уточненные Тестовые примеры (Test Cases)
Журнал испытаний (Test Log sheet)
Запрос на модификацию(Approved Change Requests)
Уточненный Технический дизайн (Updated Design Document)

Последняя фаза - Установка и интеграция.

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

В ходе данного этапа создается следующая документация:

Акт приемки системы (Sign Off on Acceptance)
Перечень ошибок (List of QA bugs)
Руководство пользователя (User Manual)
Инструкция по установке системы (Installation/Release Notes)

Участники процесса разработки ПО

Пользователь
Заказчик
Разработчик
Руководитель проекта
Аналитик
Тестировщик
Поставщик

2.3 Майлстоун

Майлстоун (milestone) — метафора, которой в software development обозначают промежуточный этап разработки проекта.

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

Майлстоун фиксирует все принятые решения, чтобы у разработчиков не возникало соблазна переделывать всё до бесконечности.

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

Milestone - этапы разработки, каждая из которых имеет свой номер (1, 2, 3 и т.д.). Это может быть как пре-альфа, как и бета, так и ранний этап разработки (раньше пре-альфы). Некоторые этапы разработки могут помечаться как pre-. Например pre-Milestone 1.

Рассмотрим каждый этап Milestone.

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

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

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

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

Бета-продукт не претендует на название финальной версией. Так как публичное тестирование производится усмотрение пользователя, то разработчик снимает с себя ответственность за ущерб, причинённый в результате использования бета-версии. Такой положение предоставляет многим производителям возможность уйти от ответственности, представляя только бета-версии продукта.

Следующая стадия используется крайне редко - Beta Escrow. Другое название стадия бета-тестирования, релиз-кандидат на Beta.

Релиз-кандидат – одна из основных стадий.

Релиз-кандидат или RC (англ. release candidate), Пре-релиз или Pre — стадия - кандидат на то, чтобы стать стабильной. В программах на этой стадии были найдены и исправлены все найденные ошибки, то есть они прошли комплексное тестирование. Тем не менее, не исключено появление некоторого числа ошибок, которые были не найдены на тестировании.

Стадия RC Escrow – это релиз, который готов получить звание релиз-кандидата. В этом релизе могут быть ещё ошибки.

Стадия релиз или RTM (англ. release to manufacturing промышленное издание) – это выпуск программного продукта, который готов к тиражированию. Обычно - это стабильная версия программного обеспечения, который прошел все предыдущие стадии. На предыдущих стадиях были исправлены основные ошибки. Также существует малая вероятность появления новых, ранее не замеченных, ошибок.

Стадия RTM Escrow – это конечный этап разработки программы, которая готова стать RTM-релизом.

Стадия Пост-релиз или Post-RTM (англ. post-release to manufacturing) - это издание продукта, у которого есть несколько отличий от RTM. Иногда из этой стадии получается первая стадия разработки следующего продукта. Такие релизы продаются, а раздаются бета-тестерам. Это может быть как и стабильная (если не замечено ошибок) либо с ошибками.

Эти стадии разработки (Beta Escrow, RC Escrow, RTM Escrow и Post-RTM) бывают редко. Beta-Escrow, RC-Escrow, RTM-Escrow - статус, указывающий, что на определенном этапе продукт не имеет серьезных ошибок в коде. Сборки с этим статусом передаются для тестирования ключевым и TAP-партнерам. Если тестирование не выявляет серьезных проблем - код подписывается для публичного тестирования

2.4 MSF

Microsoft предлагает MSF (Microsoft Solution Framework) Process Model. MSF – методология разработки программного обеспечения от компании Microsoft, опирающаяся на практический опыт компании и описывающая управление людьми и управление процессами в ходе разработки решения.

Еще есть RUP – Rational Unified Process.

Рассмотрим суть MSF. Разработка продукта согласно MSF включает следующие фазы:

Формулирование идеи (концепции) проекта.
Планирование.
Разработка.
Стабилизация решения.
Развертывание.

Каждая фаза оканчивается контрольной точкой или вехой или milestone (рис.5).

Рисунок 5 – Схема процессов MSF

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

Роли могут быть следующие.

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

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