Жизненный цикл разработки программ

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

Алексей Ярцев

Введение

В программных проектах, больших и малых, методология разработки программы используется для проектирования, разработки и сопровождения приложения. Эта методология может полностью отсутствовать при реализации малых проектов. В таких проектах главная идея программы обсуждается одним программистом и конечным пользователем, некоторые детали заносятся на бумагу, и проект реализуется в течение нескольких дней или недель. Совершенно иначе выглядят проекты, в которых задействованы команды разработчиков и группы конечных пользователей, а сроки исполнения проектов исчисляются месяцами и годами совместной работы обеих сторон. В данном случае необходима строгая методология создания и реализации проектов, называемая Жизненным Циклом Разработки Программ или ЖЦРП.

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

В данной статье я попытаюсь обсудить стандартные компоненты Жизненного Цикла Разработки Программ и причины необходимости следования им. Я объясню, почему методология ЖЦРП так важна, и почему использование отдельных компонент данной методологии сможет сделать решение задачи более простым. Наконец, я расскажу, как обойти некоторые типичные ошибки, возникающие в процессе реализации проекта.

Подбор команды

Каждая разработка собирает вокруг себя команду проекта. Эта команда проекта состоит из личностей нескольких типов:

Конечные пользователи

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

Разработчики

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

Начальник отдела

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

Начальник отдела информационных систем

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

Ответственный за гарантию качества

Эта роль в каждом проекте состоит в том, чтобы убедиться, что:

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

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

Ответственные за бета-тестирование

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

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

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

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

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

Стадии жизненного цикла разработки программ

ЖЦРП может сильно отличаться от проекта к проекту и от руководителя проекта к руководителю проекта. Однако, обычно он состоит из следующих стадий:

  • Анализ пожеланий и требований заказчика
  • Уточнение функциональных характеристик
  • Создание технического проекта (технического задания)
  • Реализация
  • Системное тестирование
  • Послереализационный обзор
  • Сопровождение

Какие проблемы?

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

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

Software Engineering Institute (SEI) в Университете Карнеги- Меллон в Питсбурге установил некоторые градационные рамки, которые позволяют каждому пользователю и производителю отнести себя к одной из пяти категорий по отношению к проектированию и разработке программного обеспечения. При обследовании ряда частных фирм и государственных учреждений получены следующие результаты.

  • УРОВЕНЬ 1 Хаотичный: Плохое управление порядком. Отсутствие управления операциями. Высокая себестоимость проектов и проблемы с планированием. Отсутствие управления технической стороной реализации проектов, неиспользование новых средств и технологий. От 74% до 86% всех разработчиков программного обеспечения подпадают под данную категорию
  • УРОВЕНЬ 2 Повторяющийся: Переоценка стоимости, планирование, изменение требований, обзор состояния дел и прочее повторяются от проекта к проекту. Используются стандартные методы. Стоимость проектов и планирование под контролем. От 22% до 23% всех разработчиков в данной категории.
  • УРОВЕНЬ 3 Определенный: Процесс разработки определен в терминах технического стандарта разработки программного обеспечения, включая проектирование, рецензирование кода и обучение. Только от 1% до 4% разработчиков достигли данного уровня.
  • УРОВЕНЬ 4 Управляемый: Процесс определен, оценен и хорошо управляем. Используются специальные средства для контроля и управления процессом разработки и для поддержки сбора и анализа данных. Ведется обширный анализ данных о проекте, собранных при помощи обзоров и тестирования. Практически 0% разработчиков достигли данного уровня компетенции.
  • УРОВЕНЬ 5 Оптимизированный: Достигнута высокая степень управления процессом, организация концентрирует усилия на оптимизации отдельных операций. Исчерпывающий анализ допущенных и предотвращение возможных ошибок постоянно ведет к совершенствованию процесса. 0% достигли данного уровня.

Определенная методология разработки программного обеспечения обеспечивает следующие улучшения в типичном цикле разработки программ:

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

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

Предварительный анализ

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

Что система должна делать?

Была ли четко сформулирована цель создания системы. Знает ли конечный пользователь, что система действительно должна делать?

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

Модели данных и словари

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

Выходные формы

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

Безопасность и управление

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

Платформа и окружение

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

  • Сетевых аппаратных и программных ресурсах
  • Типах компьютеров
  • Операционной системе
  • Типах принтеров, мониторов, дисководов
  • Других периферийных устройствах

Behavior Issues

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

  • Скорости
  • Безопасности
  • Внешней привлекательности
  • Простоты использования
  • Размера данных и способа их организации

Кто будет использовать данную систему?

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

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

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

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

Что ожидают от Вас конечные пользователи?

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

  • Начальное обследование и составление технического задания
  • Инсталляция
  • Обучение
  • Поддержка
  • Помощь в эксплуатации

Резюме

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

Анализ пожеланий и требований заказчика

Стандартная техника разработки и программирования - собрать весь код в небольшие, хорошо управляемые модули. Цикл разработки программ работает по аналогичной схеме для больших проектов. Огромная работа должна быть выполнена до того, как хотя бы одна строка кода будет написана.

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

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

Наиболее важная цель, которой необходимо достигнуть на этом первом этапе - это найти и понять, что же НА САМОМ ДЕЛЕ ХОЧЕТ ПОЛЬЗОВАТЕЛЬ. Иной раз это не так просто сделать, поскольку пользователь не всегда представляет, ЧТО он действительно хочет получить. Банальным примером могут служить пользователи, заказывающие, например, одновременно несколько больших задач типа "Учет заработной платы", "Ведение складского учета", "Составление табеля" и т.п., называя все это "Бухгалтерией". Если проигнорировать данный этап, то проект может, в конце концов, быть осужден на большое количество доработок, достраивание кода "на коленке" и непременное сидение программистов по выходным, чтобы сделать клиенту действительно то, что он хочет и что не было оговорено заранее. Можно сравнить цикл разработки программы со строительством дома. Когда дом спроектирован, фундамент заложен и строительство подходит к концу, нет возможности передвигать стены или изменять общую планировку дома.

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

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

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

Пользователь - кто он?

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

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

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

Чтобы избежать вышеописанных ситуаций, необходимо предпринять следующее:

  • Убедитесь, что люди, участвующие в обсуждении проекта, являются людьми, детально разбирающимися в тонкостях решаемой задачи.
  • Убедитесь, что люди, принимающие участие в обсуждении проекта, заинтересованы в конечном результате.
  • Дайте пользователям возможность обсудить все вопросы, которые только возможно. Даже если их объяснения несвязны и неорганизованны, постарайтесь выяснить, что для пользователей является более важным в создаваемой программе, а что менее важным (что бы они хотели получить сначала, а что потом).
  • Постарайтесь подключить к обсуждению людей, которые действительно будут использовать создаваемый продукт.

Кто будет вести шоу?

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

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

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

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

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

Программисты, работающие на уровне битов и байтов

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

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

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

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

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

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

Анализ требований заказчика

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

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

Простейший способ начать обследование - сверху вниз. Что является главной целью системы? Каковы основные требования к системе? Определение основных компонент системы может быть полезным для введения пользователя в нужное русло обсуждения проблемы. Почти все системы требуют ввод некоей информации и вывод каких-то отчетных форм (в виде отчетов и запросов), некоторый вид конфигурации, возможности импорта и экспорта данных, архивирования, и, возможно, сервисный раздел. Иногда процесс импорта - единственный способ ввода данных в систему. Если же пользователь требует многотабличную систему, тогда конфигурация может стать главной частью системы. Также, какой тип интерфейса требуется? Выпадающие окна? Графический интерфейс? Исходя из этих данных, вы можете получить информацию о том, что должно находиться в главном меню программы, и прикинуть некоторые детали разработки еще до полного определения проекта. Also, what tурe of user interface is required?

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

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

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

Функциональная спецификация

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

Начальный обзор требований выделяет то, ЧТО система должна делать, а техническая спецификация - это детализированное проектирование каждого элемента системы. Это последняя стадия перед непосредственным кодированием. Следовательно, функциональная спецификация может рассматриваться как транспорт, переносящий нас из точки A в точку B.

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

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

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

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

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

Формат документа.

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

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

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

Требования пользователя

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

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

Отвечает ли документ на все вопросы?

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

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

Чего нужно избегать?

Предположим, функциональная спецификация разработана, подписана и положена на полку. Она может оказаться полностью бесполезна по ряду причин.

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

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

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

Новая техника

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

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

Сomрuter Aided Software Engineering (СASE) средства также играют огромную роль в сегодняшних инструментальных средствах разработки приложений. С мощными СASE-средствами процесс разработки приложений заметно упрощается. Проектировщик использует программные средства для создания и компоновки словарей данных, потоков данных и диаграмм объекта, а в некоторых случаях прототипов процессов обработки данных и функционального кода.

Однако, использование СASE-средств разработки приложений не очень распространено в сфере разработки промышленных приложений. Это происходит по двум причинам. Во-первых, это ограниченность возможностей СASE-систем. Любая система автоматизированного проектирования обладает своей спецификой и никогда не отражает всех требований того или иного пользователя на 100 %. Во-вторых, если СASE-система достаточно мощна и многофункциональна, то она требует больших временных затрат на ее освоение. А поскольку большинство проектов имеют тенденцию быть «завершенными вчера», то необходимое время не может быть выделено.

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

Техническая спецификация или техническое проектирование

Техническое проектирование - это мост между функциональной спецификацией и фактической стадией кодирования. Часто команда разработчиков пытается сократить и объединить стадию разработки функциональной спецификации и техническое проектирование и разработать один документ. Это ошибка.

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

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

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

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

Формат документа

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

  • Диаграмма зависимости объектов. Данная диаграмма - уникальный способ для неинформированного программиста получить быстрый краткий обзор того, что система делает. Эта диаграмма показывает все объекты системы и связи между ними (один-к-одному, один-ко-многим и т.д.). Она может также показывать спецификации ключевых полей и другие связи по мере необходимости.
  • Структурная диаграмма. Это высокоуровневое проектирование программных модулей и связи между ними, начиная с главного модуля и основных модулей, определенных ранее в функциональной спецификации (например, главное меню). Детализированная структурная диаграмма может также включать информацию о передаваемых между модулями параметрах. Эта диаграмма - хороший способ отдельным членам команды программистов быстро выяснить общую структуру программы и решить все проблемы по интеграции отдельных модулей в систему. Это «моментальный снимок» разрабатываемой системы.

Детализация модулей и псевдокод

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

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

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

Глобальные переменные и структуры

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

Среда разработки системы

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

Создание временной диаграммы проекта

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

Библиотека функций

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

Обзор проекта

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

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

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

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

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

Реализация

Обычно на стадии кодирования всплывают все неприятные проблемы, которые только можно себе представить. Чем больше проект - тем больше проблем. Вот почему первые три шага так важны.

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

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

Обзор кода

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

Системные тесты

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

  • Системный тест или лабораторные испытания.
  • Опытная эксплуатация.
  • Приемочный тест

Альфа тест (лабораторные испытания)

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

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

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

Бета тестирование (опытная эксплуатация)

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

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

Приемочный тест

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

Послереализационный обзор

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

  • Что мы делали правильно?
  • Что мы делали неправильно?
  • Какие стадии были наиболее полезными, а какие ненужными?
  • Отсутствовало ли что-нибудь на какой-либо стадии разработки, что помогло бы нам усовершенствовать программный продукт?

Сопровождение

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

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

Революционизирование процесса Рrocess

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

Одна из наиболее выдающихся моделей, появившихся в течении нескольких последних лет - Raрid Aррlications Develoрment (RAD) или жизненный цикл быстрой разработки программ.

Жизненный цикл RAD основан на значительных усовершенствованиях в четырех областях.:

  • Инструментальные средства- генераторы исходного кода, СASE-средства, инструментальные средства макетирования и языки четвертого поколения;
  • Методология - жизненный цикл оптимизируется для ускорения цикла разработки;
  • Персонал - выбор высококвалифицированного и заинтересованного персонала;
  • Управление - выбор инновационной стратегии управления, которая разрушает бюрократические и политические препятствия к ускорению процесса разработки.

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