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

Проектирование программного обеспечения представляет собой частный случай проектирования процессов и продуктов.

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

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

При проектировании ПО заранее разработчик имеет возможность:

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

Подготовительный этап

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

1. Подготовки.
2. Проектирования.
3. Создания, включающего дизайн, кодирование, тестирование, документирование.
4. Поддержки, включающей внедрение и сопровождение.

В процессе подготовки к проектированию должны быть решены организационные вопросы:

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

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

Этапы и результаты проектирования

Проектирование состоит из следующих этапов:

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

В результате проектирования получается техническое задание с однозначной и понятной как для заказчика, так и для исполнителя (в качестве исполнителя могут выступить руководитель проекта, программисты, тестировщики, дизайнеры и другие участники процесса разработки) иллюстрацией ответов на вопросы:

1. Что делать (содержит описание продукта, функциональных возможностей, категорию пользователей)?
2. Как делать (содержит описание архитектуры)?
3. Как проверить, достигнута ли цель (варианты тестирований, критерии оценки)?

Требования к ТЗ на разработку программного обеспечения

Приведем минимальные требования, достаточные для ТЗ, в соответствии с которыми оно должно:

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

В техническом задании должны содержаться:

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

В составе ТЗ важно уделить внимание описаниям:

• конкретных детaлей: пользователей программного продукта (их роли, права и функции), алгоритмов обработки данных, перечня закрытых и открытых протоколов, требований к безопасности данных в ходе всего жизненного цикла, списка используемых в разработке компонентов (свободных, платных);
• примеров: аналогов, интегрируемых систем с указанием ссылок на них; типичных сценариев взаимодействия системы с пользователем; входящих данных и форматов данных взаимодействия подсистем (таблиц, баз, страниц и др.); исходящих данных (видов отчетов и экспортируемых файлов);
• надежности и производительности: уровней нагрузки системы (день, месяц, максимальный), требований к сохранности и производительности, обоснования выбора оборудования запуска ПО, хостинга серверной части.