Период разработки ПО

Рассмотрим классический период разработки ПО.

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

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

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

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

2. Начинается предпроектное обследование объекта автоматизации. С помощью CASЕ-средств составляется формальная модель его работы, модель базы данных, объектов и потоков информации. На этом этапе привлекаются специалисты заказчика и эксперты, хорошо знакомые с предметной областью, для которой составляется задача.

Примерный объем работ второго этапа — 10 % от общего.

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

Примерный объем работ третьего этапа — 10 % от общего.

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

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

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

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

В процессе разработки необходимо:

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

• непрерывно контролировать ход работ в соответствии с планом и при отклонениях от него принимать экстренные меры.

Примерный объем этих работ — 10 % от общего объема проекта.

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

Примерный объем этих работ — 10 % от общего объема проекта.

6.После того как заказчик удовлетворен качеством продукта, начинается его внедрение — подготовка к окончательному запуску в эксплуатацию. Если приложение многопользовательское, нередко требуется сформировать и настроить локальную сеть, установить серверы, инсталлировать вспомогательные программы. Очень много проблем возникает при переходе со старых программ (например, бухгалтерского учета, расчета зарплаты, работы с персоналом), которые создавались разными сотрудниками и покупались в разных фирмах (так называемая лоскутная автоматизация), к новой интегрированной системе. Необходимо выверить, ввести или перенести множество жизненно важной информации: всю бухгалтерскую и финансовую отчетность, данные о хранимом оборудовании и множество других сведений. Этот этап самый трудоемкий и «нудный» и занимает порой до 90 % времени всего проекта. Для систем автоматизации больших предприятий он растягивается на годы.

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

Примерный объем трудозатрат на обучение — 5 % от общего объема проекта.

8. После того как заказчик подписывает акт приемки, проект считается завершенным, но связь с исполнителем не теряется. Особенно в первое время у пользователей системы постоянно будет возникать множество вопросов по работе с ней. Неизбежно и возникновение ошибок, которые требуется устранять. Кроме того, исполнитель может выпускать новые версии системы, и старая система потребует обновления. Сотрудничество с заказчиком по обслуживанию системы называется сопровождением. Оно бесплатно на определенный гарантийный срок (например, год).

Реально объем непосредственного программирования и отладки (тестирования) в цикле разработки невелик. Он составляет 10-20 % от общего объема работ.

Контроль качества

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

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

Системы не очень сложного конфигурационного управления, охватывающие контроль версий исходных текстов и ряд других аспектов работы группы программистов, встроены, в частности, в такие системы, как Delphi 5 и Visual C++ 6.0.