5 Действия в процессе разработки программного обеспечения

Действия в процессе написания, представленные в модели водопада. Есть и другие модели, по-другому представляющие себе этот процесс.

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

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

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

Анализ области работы часто является первой ступенью лестницы проектирования нового фрагмента программного обеспечения, вне зависимости от того, является ли он добавлением к уже существующему приложению или новым приложением, подсистемой или совершенно новой системой. Принимая, что разработчики (так же как и аналитик) не являются в начале достаточно образованными в области знаний нового программного обеспечения, первая задача — это собственно исследование этой самой области знаний. Чем лучше разработчики знают область, в которой работают, тем меньше потом возникает работы. Также её проводят для того, чтобы позже не появлялось путаницы в терминологии, и пониманием того, что делает эта программа. Если аналитик использует неверную терминологию, то опять же возможны недопонимания, в результате того, что программа будет делать не то, что нужно. Эта работа исключает случаи вроде «Я знаю, что вы верите в то, что поняли, что я говорю, но я не уверен, что вы понимаете, что то, что вы слышали — это не то, что я имею в виду.»

Спецификация

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

Архитектура

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

Проектирование, реализация и тестирование

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

Распространение и поддержка

Распространение начинается после того, как код достаточно оттестирован, и признан готовым к релизу.

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

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

Модели

Водопад

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

Спецификация требований

Проектирование

Кодирование

Интеграция

Тестирование и отладка (валидация и верификация)

Установка

Поддержка

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

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

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

Гибкая модель разработки

Гибкая модель разработки создана организациями, занимающимися итерационной разработкой. Для этого используется более гибкий, централизованный на людях подход, чем использующийся в традиционных подходах. Гибкие процессы используют обратную связь вместо планирования как главный контролирующий механизм. Обратная связь ведётся посредством регулярных тестов, а также частых релизах разрабатываемого продукта. Интересно, что исследования показывают потенциал для хорошего улучшения производительности относительно стандартного «водопадного» метода. К примеру исследование, опубликованное в августе 2006 года, и базированное на опросах более чем 700 компаний, гласит о огромной прибыли при использовании этой модели. [1] Исследование было повторено в августе 2007 года с базой в 1,700 компаний.[2]

Итерационные подходы

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

Экстремальное программирование

Экстремальное программирование (XP) — самый известный итерационный процесс[источник не указан 235 дней]. В XP процесс делится на очень маленькие ступеньки, по сравнению с планируемыми процессами. Это приводит к тому, что первые шаги могут занимать дни или недели вместо месяцев или даже лет для каждой ступени в модели «водопад». Сначала пишутся автоматические тесты, чтобы описать цели разработки. Потом идёт кодирование, которое заканчивается в тот момент, когда все тесты проходят, и программисты не могут придумать новых тестов. Дизайн делается теми же людьми, которые пишут код. (только последняя ступень — соединение дизайна и кода является общим для всех гибких процессов). Незаконченная, но функционирующая система показывается узкому кругу пользователей (чаще всего это сами разработчики). В этот момент начинают писать тесты для следующей наиболее важной части системы.

Другие модели

ISO/IEC 15504 — один из американских стандартов

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

Test Driven Development — разработка через тестирование — техника программирования, при которой модульные тесты для программы или ее фрагмента пишутся до самой программы и, по существу, управляют ее разработкой. Является одной из основных практик экстремального программирования.

6 RUP создана в виде страниц формата HTML, имеющих обширную систему гиперссылок, графическую навигацию, подробное оглавление и встроенный поисковый механизм. Основными понятиями RUP являются артефакт (artifact) и прецедент (precedent). Артефакты — это некоторые продукты проекта, порождаемые или используемые в нем при работе над окончательным продуктом. Прецеденты — это последовательности действий, выполняемых системой для получения наблюдаемого результата.

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

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

Основной упор в RUP делается не на подготовку документов как таковых, а на моделирование разрабатываемой системы. Модели помогают очерчивать как проблему, так и пути ее решения, и создаются они при помощи унифицированного языка Unified Modeling Language (UML), предложенного компанией Rational и впоследствии утвержденного OMG как стандарт, но еще до это UML стал стандартом де-факто для описания сложных систем и позволяет разработчикам определять, визуализировать, конструировать и документировать артефакты программных систем.

Все задачи, описанные в RUP, поддерживаются средствами разработки от Rational Software. В RUP включен раздел Tool Mentors, в котором подробно описывается использование Rational Rose для создания UML-моделей, Rational RequisitePro, Rational Clear Quest, Rational Clear Case для анализа требований, запросов на измерения и исправления дефектов и для поддержки процесса унифицированного управления изменениями (UCM). В этом же разделе описываются методы применения Rational Purify, Rational PureCoverage, Rational Quantify, Rational Robot для автоматизации процесса тестирования и поиска дефектов программного обеспечения, а Rational SoDa — для автоматизации процесса документирования. Кроме того, Tool Mentors содержит подробные рекомендации по использованию этих и других средств компании Rational для создания конкретных артефактов разрабатываемой системы.

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

Каждый такой процесс представляется при помощи диаграмм, состоящих из пиктограмм, связанных гиперссылками с другими документами. При активизации гиперссылок происходит детализация процесса.

Это дает возможность пройти через всю последовательность необходимых работ — от общего взгляда на них “с высоты птичьего полета” до создания конкретных артефактов.

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