Технология разработки программного обеспечения

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

1. Определение проблемы.

2. Альтернативные решения и ожидаемые от них преимущества.

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

2.3.2. Выявление, понимание и спецификация требований

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

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

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

Основная цель деятельности по определению требований — точное понимание взаимодействия между разрабатываемым приложением и его внешним окружением. Таким окружением может быть, скажем, физический завод, работу которого программное приложение призвано автоматизировать и контролировать, либо это может быть библиотека, где библиотекари используют систему для регистрации в каталогах новых поступлений, выдачи книг читателям и где читатели могут просматривать каталоги в поиске нужных книг. Для понимания требований разработчик должен разбираться в предметной области приложения и четко определять, кто есть главные "заинтересованные лица", т. е. те, кто заинтересован в системе, и кто в конечном итоге несет ответственность за ее приемку. Например, в случае с библиотекой разработчики должны отдавать себе отчет в том, кто будет потенциальным пользователем системы (библиотекари и читатели) и чем будут различаться их права доступа к системе. Разработчикам необходимо понимать механизмы поступления книг, их получения, возврата и т. д. В число основных участников здесь входят библиотекари и читатели. Поскольку библиотека часто является компонентом некой более крупной структуры, лица, ответственные за библиотеку в этой крупной системе, также являются важными участниками. Например, если библиотека относится к факультету университета, то декан последнего также является заинтересованным лицом, цели и требования которого необходимо учитывать. Целью декана сможет быть поощрение студентов к пользованию библиотечными книгами и журналами, дабы стимулировать их интерес к ознакомлению с научными работами. Либо декан может требовать, чтобы студенты брали только книги, тогда как журналы будут предназначены исключительно для преподавателей. Декан может потребовать, чтобы преподаватели были способны получить доступ к каталогам и заказывать копии книг и журналов через web-ориентированный интерфейс со своих персональных компьютеров и т. д. Важным заинтересованным лицом является человек или организация, распределяющие бюджет для оплаты разработки (возможно, это будет тот же декан или ректор университета). Следует обратить внимание на то, что разные участники имеют различные точки зрения на то, какой должна быть система. Каждая точка зрения представляет собой отдельный взгляд на ожидаемые от системы свойства. Иногда точки зрения могут быть противоречивыми, тогда целью разработчика является их объединение и нахождение компромисса для составления общей концепции системы.

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

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

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

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

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

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

Ниже приведен возможный перечень пунктов документа спецификации требований, который может быть руководством специалиста по программному обеспечению:

1. Предметная область. Краткое описание предметной области приложения и целей, которых необходимо достичь при разработке конечного продукта. Сюда входит точное документирование сведений о предметной области, необходимых для получения спецификаций. Кто является заинтересованными сторонами, и каковы их цели и ожидания? Каковы основные логические объекты (категории), характеризующие предметную область? Каковы их основные взаимосвязи? Как на них повлияет разрабатываемая система?
2. Функциональные требования. Описывают действия программного продукта, используя неформальные, полуформальные, формальные представления либо их комбинацию. В настоящее время язык UML все более используется как практический стандарт, потому что содержит разные нотации для выражения разных точек зрения о системе.
3. Нефункциональные требования. Их можно классифицировать по следующим категориям: надежность (работоспособность, целостность, безопасность, защищенность и т. д.); точность результатов; производительность; вопросы взаимодействия человека с компьютером; эксплуатационные ограничения; физические ограничения; переносимость и др.
4. Требования к процессу разработки и сопровождения. Сюда входят процедуры управления качеством (в частности процедуры тестирования системы), приоритеты необходимых функций, возможные изменения процедур обслуживания системы и прочие требования.

2.3.3. Определение архитектуры программного обеспечения и рабочий проект

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

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

2.3.4. Кодирование и тестирование модулей

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

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

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

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

2.3.5. Сборка и системное тестирование

Интегрирование (сборка) заключается в компоновке программного приложения из набора отдельно разработанных и протестированных компонентов. Сборка не всегда рассматривается как операция, отдельная от кодирования. Фактически пошаговые разработки могут постепенно интегрировать и тестировать компоненты по мере их разработки. Несмотря на то, что два этих этапа можно объединить, они принципиально различаются по масштабу проблем, которые призваны решать: первая относится к локальному программированию, тогда как вторая — к программированию системы в целом.

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

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

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

2.3.6. Поставка, развертывание и сопровождение ПО

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

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

Наконец, техническое обслуживание (сопровождение) можно определить как набор действий, направленных на внесение изменений в систему после ее поставки заказчику. Стандарт IEEE (IEEE [1999]) определяет техническую поддержку как "модификацию программного продукта после его поставки заказчику с целью исправления ошибок, повышения производительности или других атрибутов либо с целью адаптации продукта к изменившимся внешним условиям". Техническое обслуживание заключается в исправлении ошибок, оставшихся в системе (корректирующее сопровождение), в адаптации приложения к изменениям внешней среды (настраивающее сопровождение), а также в совершенствовании, изменении или добавлении в программу новых функций и качеств (усовершенствующее сопровождение). Не стоит забывать, что цена сопровождения часто превышает 60 % от общей цены продукта и что до 20 % затрат на сопровождение составляет доля корректирующего и настраивающего сопровождения, а 50 % приходится на долю усовершенствующего сопровождения. На основании этой статистики можно сделать вывод о том, что развитие здесь, возможно, — более уместный термин, нежели сопровождение (хотя последний используется чаще).