Жанр: Учеба
Жизненный цикл программы
Жизненный цикл разработки программ
Алексей Ярцев
Введение
В программных проектах, больших и малых, методология
разработки программы используется для проектирования,
разработки и сопровождения приложения. Эта методология может
полностью отсутствовать при реализации малых проектов. В
таких проектах главная идея программы обсуждается одним
программистом и конечным пользователем, некоторые детали
заносятся на бумагу, и проект реализуется в течение
нескольких дней или недель. Совершенно иначе выглядят
проекты, в которых задействованы команды разработчиков и
группы конечных пользователей, а сроки исполнения проектов
исчисляются месяцами и годами совместной работы обеих сторон.
В данном случае необходима строгая методология создания и
реализации проектов, называемая Жизненным Циклом Разработки
Программ или ЖЦРП.
Хотя описываемая методология обычно применяется в больших
программных проектах, где привлечены три или более
программиста, принципы данной методологии будут очень полезны
при реализации проектов любой сложности.
В данной статье я попытаюсь обсудить стандартные компоненты
Жизненного цикла Разработки Программ и причины необходимости
следования им. Я объясню, почему методология ЖЦРП так важна,
и почему использование отдельных компонент данной методологии
сможет сделать решение задачи более простым. Наконец, я
раскажу, как обойти некоторые типичные ошибки, возникающие в
процессе реализации проекта.
Подбор команды
Каждая разработка собирает вокруг себя команду проекта. Эта команда
проекта состоит из личностей нескольких типов:
Конечные пользователи
Осуществляют ввод в систему, которую мы разрабатываем, обеспечивают
обратную связь в нашем проекте интерфейса, проводят бетатестирование
и помогают управлять определением достижения
конечной цели.
Разработчики
Один из разработчиков является pуководителем команды проекта,
регулирующий поток информации между членами команды.
Разработчики отвечают за исследования, проект и создание
программного обеспечения, включая альфа-тестирование своей
работы.
Начальник отдела
Это лицо, возглавляющее отдел, для которого мы пишем
приложение.На начальника отдела возлагается ответственность
за достоверность данных, выдаваемых этим отделом,
информационной системе. Кроме того, начальник отдела отвечает
за то, соответствует ли законченное приложение поставленным в
проекте задачам.
Начальник отдела информационных систем
Роль начальника информационных систем состоит в том, чтобы
определить цели (планы) для разработчиков, основанные на
информации, которую он получает от менеджеров других отделов
и главного управления. Кроме того, он устанавливает
приоритеты между проектами и работает в качестве источника
информации между отделами и между разработчиками. Он также
распределяет объемы ресурсов, требуемых для выполнения
каждого проекта.
Ответственный за гарантию качества
Эта роль в каждом проекте состоит в том, чтобы убедиться, что:
' Проект приложения достигнет намеченных целей.
' Проект приложения отвечает описанию системы.
' План тестирования отвечает требованиям.
' План преобразования данных отвечает требованиям.
' Стандарты разработки информационных систем соблюдаются.
За качество проекта обычно отвечает один человек, но следят за
качеством все члены команды проекта.
Ответственные за бета-тестирование
В группу нашей команды бета-тестирования входят возможные
конечные пользователи. Существует два типа тестирования. Один
использует планы специального тестирования, разработанные
ответственным за гарантию качества. Другой использует
тесты, которые разработали сами ответственные за бетатестирование,
применяя критерии ответственного за гарантию
качества.
Три составляющих нашего стиля достаточно важны, чтобы
упомянуть о них.
Первое, ответственность за проект несет разработчик, а не
начальник отдела. Не говорите, что я не прав, начальники
являются членами команды - последнее слово в некоторых
важных вопросах принадлежит им. Однако, на самом деле
проектом управляет разработчик. Почему я сделал так? Я
обнаружил, что когда y разработчиков есть "собственный"
проект, их интерес в успехе или неудаче этого проекта
и, следовательно, вероятность успеха увеличивается в
геометрической прогрессии.
Второе, когда разработчики полностью изучат типы связей между
всеми частями проекта(в отличие от одной его части), их
квалификация повышается. Это обеспечивает тип перекрестного
обучения в двух очень важных факторах успешной разработки
программного обеспечения. Означает ли это, что разработчик
выполняет меньше собственно программистской работы? Конечно.
Когда разработчику нужна помощь в программировании для
конкретного проекта, мы привлекаем отдел информационных
систем и сторонних разработчиков (несколько таких
разработчиков сотрудничают с нами по контракту).
Третье, все члены команды точно знают свои обязанности. Это
достигается с помощью встреч, на которых обсуждаются
отдельные части проекта. В каждый момент времени на
определенной стадии проекта все члены команды знают точно,
что они должны делать. Как конкретно это достигается? С
помощью постановки задач и определения локальных заданий.
Стадии жизненного цикла разработки программ
ЖЦРП может сильно отличаться от проекта к проекту и от
pуководителя проекта к pуководителю проекта. Однако, обычно
он состоит из следующих стадий:
¦ Анализ пожеланий и требований заказчика
¦ Уточнение функциональных характеристик
¦ Создание технического проекта (технического задания)
¦ Реализация
¦ Системное тестирование
¦ Послереализационный обзор
¦ Сопровождение
Какие проблемы?
Существует большое количество преимуществ использования структурного
подхода к проектированию и разработке, многие из которых
основываются на следующих высказываниях: перегрузка проекта,
задержки реализации, проблемы сопровождения и повторное
изобретение колеса.
Независимые консультанты обычно концентрируют внимание на стоимости
проекта. Часто они не принимают в расчет затраты на
проведение системного анализа и разработку проекта и дают
неправильную оценку времени реализации данного проекта. Хотя
известно, что необходимо выполнить детальный анализ задачи
перед тем, как проект будет утвержден, пользователи не
склонны затрачивать дополнительные средства на исследование.
К сожалению, это часто приводит к большому количеству
затруднений в процессе разработки, а иногда к разваливанию
всего проекта.
Software Engineering Institute (SEI) в Университете КарнегиМеллон
в Питсбурге установил некоторые градационные рамки,
которые позволяют каждому пользователю и производителю
отнести себя к одной из пяти категорий по отношению к
проектированию и разработке программного обеспечения. При
обследовании ряда частных фирм и государственных учреждений
получены следующие результаты.
' УРОВЕНЬ 1 Хаотичный: Плохое управление порядком.
Отсутствие управления операциями. Высокая себестоимость
проектов и проблемы с планированием. Отсутствие управления
технической стороной реализации проектов, неиспользование
новых средств и технологий. От 74% до 86% всех разработчиков
программного обеспечения подпадают под данную категорию.
' УРОВЕНЬ 2 Повторяющийся: Переоценка стоимости,
планирование, изменение требований, обзор состояния дел и
прочее повторяются от проекта к проекту. Используются
стандартные методы. Стоимость проектов и планирование под
контролем. От 22% до 23% всех разработчиков в данной
категории.
' УРОВЕНЬ 3 Определенный: Процесс разработки определен в
терминах технического стандарта разработки программного
обеспечения, включая проектирование, рецензирование кода и
обучение. Только от 1% до 4% разработчиков достигли данного
yровня.
' УРОВЕНЬ 4 Управляемый: Процесс определен, оценен и
хорошо управляем. Используются специальные средства для
контроля и управления процессом разработки и для поддержки
сбора и анализа данных. Ведется обширный анализ данных о
проекте, собранных при помощи обзоров и тестирования.
Практически 0% разработчиков достигли данного yровня
компетенции.
' УРОВЕНЬ 5 Оптимизированный: Достигнута высокая степень
управления процессом, организация концентрирует усилия на
оптимизации отдельных операций. Исчерпывающий анализ
допущеных и предотвращение возможных ошибок постоянно ведет к
совершенствованию процесса. 0% достигли данного yровня.
Определенная методология разработки программного обеспечения обеспечивает
следующие улучшения в типичном цикле разработки программ:
' Разногласия и отсутствие связи между членами команды
разработчиков и между программистами и конечными
пользователями быстро обнаруживаются и устраняются в процессе
разработки.
' Новые люди "безболезненно" подключаются к проекту на
любой стадии разработки.
' Конечное приложение базируется на фундаментальном
анализе задачи, что позволяет свести к минимуму затраты на
дальнейшую доработку, модификацию и сопровождение продукта.
' В процессе разработки создается мощный пакет
документации, позволяющий в дальнейшем упростить неизбежное
сопровождение и дополнения программного продукта.
' Один раз хорошо отработанный цикл разработки приложения
позволяет сэкономить много времени при реализации последующих
проектов.
' Он позволяет лучше использовать сушествующий
инструментарий и не "изобретать велосипед".
Получив некоторое представление о необходимости рассмотрения
методологии управления проектом, давайте рассмотрим отдельные
его составляющие.
Предварительный анализ
Очень важным этапом является предварительный анализ. Вы должны
быть уверены, что имеете всю необходимую информацию о
клиенте, прежде чем возьметесь за реализацию проекта.
Что система должна делать?
Была ли четко сформулирована цель создания системы. Знает ли
конечный пользователь, что система действительно должна
делать?
Действительно очень важно найти истинную цель приложения, чтобы иметь
возможность определить границы проекта. Это необходимо
сделать настолько скорее, насколько это возможно.
Модели данных и словари
Важно, чтобы данные, обрабатываемые в приложении, были
выделены и определены в понятиях, доступных как конечным
пользователям, так и команде разработчиков. Часто случается,
что заранее не существует какой-либо сформировавшейся модели
данных, и проектировщик должен создать словарь и модель
данных, а затем вернуться к пользователю и оговорить с ним
разработанную схему, чтобы пользователь понимал ее.
Выходные формы
При предварительном опросе пользователя необходимо сделать
наброски всех выходных форм, поскольку может потребоваться
дополнительное наращивание словаря баз данных для обеспечения
реализации того или иного.
Безопастность и управление
Прежде чем начать разработку, конечный пользователь должен
определить необходимость обеспечения безопасности системы и
данных. Включение системы обеспечения безопасности должно
рассматриваться на самой ранней стадии проектирования.
Платформа и окружение
На какой платформе или платформах будет функционировать
создаваемое программное обеспечение? Важно оценить окружение,
в котором будет работать система. Клиенты тратят большие
средства на приобретение аппаратных средств еще до того, как
обращаются к Вам. Вы должны выяснить все детали о:
' Сетевых аппаратных и программных ресурсах
' Типах компьютеров
' Операционной системе
' Типах принтеров, мониторов, дисководов
' Других периферийных устройствах
Behavior Issues
В зависимости от системы и ее целей, отдельные детали должны
быть обсуждены более подробно, нежели остальные. Вы должны
знать, что является более приоритетным для конечного
пользователя. Одни системы требуют максимального внимания к
внешнему оформлению и особенностям эксплуатации, другие -
максимальной скорости и удобства ввода данных при максимально
упрощенном внешнем виде системы. Скорость часто снижается при
использовании средств ограничения доступа и защиты
информации. Удостоверьтесь, что пользователи понимают
значение:
' Скорости
' Безопасности
' Внешней привлекательности
' Простоты использования
' Размера данных и способа их организации
Кто будет использовать данную систему?
Часто понятие "кто" значительно важнее понятия "что". Хорошее
понимание категорий конечных пользователей может дать Вам
важную стартовую информацию для начала создания проекта. Вы
должны постоянно изучать, что Ваши конечные пользователи
хотят. Различные типы пользовательских групп имеют различные
требования. Эти требования должны быть учтены при
проектировании программного обеспечения.
Приложения для общего рынка
Если Вы делаете приложения для общего рынка, Вы можете создать
только очень грубое представление о конечном пользователе.
Если я пишу какую-либо общую программу учета, я могу лишь
предположить, что мой клиент имеет общее представление о
компьютере и y него есть необходимость что-либо учитывать.
Приложения для вертикального рынка
Если я пишу программу поддержки офиса агенства путешествий и
экскурсий, я знаю, что мои конечные пользователи будут
использовать данное приложение именно в этой области. Таким
образом я могу оптимизировать систему учета и расчетов,
учитывая специфику конкретного бизнеса. Однако я не знаю ни
опыта работы конечных пользователей с вычислительной
техникой, ни yровня их профессионализма в их собственном
бизнесе.
Пользовательские приложения
Если я пишу офисную систему для офиса "Иванов и сыновья", я могу
непосредственно общаться с конечными пользователями и
выяснять их yровень познания вычислительной техники и опыт
работы в собственном бизнесе, что даст мне возможность
заранее предусмотреть большинство конфликтных ситуаций между
моим приложением и конечными пользователями.
Что ожидают от Вас конечные пользователи?
Каждая группа конечных пользователей имеет различные требования и
ожидания от вашей системы. Перед началом проектирования
системы необходимо выяснить, на что расчитывает конечный
пользователь. Необходимо обратить внимание на следующие
аспекты:
' Начальное обследование и составление технического
задания
' Инсталляция
' Обучение
' Поддержка
' Помощь в эксплуатации
Резюме
Как проектировщик системы, Вы должны вернуться на yровень
предварительного анализа задачи и удостовериться, что вся
необходимая информация вами получена. При несоблюдении
данного требования вы можете значительно замедлить реализацию
проекта вследствие многократного повторного обращения к
пользователю за уточнением неверно трактованых деталей и
необговоренных условий.
Анализ пожеланий и требований заказчика
Стандартная техника разработки и программирования - собрать весь код в
небольшие, хорошо управляемые модули. Цикл разработки
программ работает по аналогичной схеме для больших проектов.
Огромная работа должна быть выполнена до того, как хотя бы
одна строка кода будет написана.
Существует огромная пропасть между идеями пользователей и
представлением о возможных способах реализации этих идей
конкретными разработчиками. Мостом между этими двумя
понятиями должен быть первичный цикл обследования проекта и
составление технического задания на данный проект. Эта задача
делится на три стадии - изучение требований заказчика,
уточнение функциональной специфики задачи и техническое
проектирование задачи.
Анализ требований и пожеланий заказчика начинается с получения
заказа на новую разработку (или на модификацию существующей)
и заканчивается составлением документа, в деталях
описывающего данную разработку. Это может быть интерактивный
процесс, в результате которого появляется документ, полностью
описывающий задачу и удовлетворяющий обе стороны.
Результирующий документ описывает то, что конечные
пользователи хотели бы получить в результате успешного
завершения проекта. Этот документ должен включать
рассмотрение всех проблем и решаемых задач, множество листов
с требованиями и пожеланиями заказчика и прочую необходимую
информацию.
Наиболее важная цель, которой необходимо достигнуть на этом пеpвом
этапе - это найти и понять, что же НА САМОМ ДЕЛЕ ХОЧЕТ
ПОЛЬЗОВАТЕЛЬ. Иной раз это не так просто сделать, поскольку
пользователь не всегда представляет, ЧТО он действительно
хочет получить. Банальным примером могут служить
пользователи, заказывающие, например, одновременно несколько
больших задач типа "Учет заработной платы", "Ведение
складского учета", "Составление табеля" и т.п., называя все
это "Бухгалтерией". Если проигнорировать данный этап, то
проект может в конце концов быть осужден на большое
количество доработок, достраивание кода "на коленке" и
непременное сидение программистов по выходным, чтобы сделать
клиенту действительно то, что он хочет и что не было
оговорено заранее. Можно сравнить цикл разработки программы
со строительством дома. Когда дом спроектирован, фундамент
заложен и строительство подходит к концу, нет возможности
передвигать стены или изменять общую планировку дома.
Очевидно, что любой проект начинается с идеи. Как только
появляется идея, один или несколько чесловек начинают
развивать данную идею. Эти люди - пользователи. Они
определяют начальные требования и принимают решение о
создании того или иного пограммного продукта. Без них не было
бы и продукта. Таким образом, необходимо выяснить, что же эти
люди хотят получить от программного продукта.
Перед началом обсуждения будущего проекта очень важно убениться,
что с обеих сторон стола переговоров сидят именно те люди,
которые требуются для совместного обсуждения проекта. Три
наиболее распространенные ошибки допускаются на данной
стадии:
1. Пользователи, начинающие обсуждение проекта, не являются
людьми, которые будут принимать окончательное решение о
требованиях к обсуждаемой системе (т.е. они не являются
людьми, имеющими полное представление об описываемой ими
задаче).
2. Участники обсуждения со стороны разработчиков не
являются людьми, имеющими отношение к технической разработке
проекта.
3. Технические специалисты не понимают пользователей. Либо
разработчики плохо разбираются в делопроизводстве и бизнесе,
либо они последнюю часть жизни провели не отходя от монитора,
и могут разговаривать только на языке битов и байтов.
Пользователь - кто он?
В первом случае, пользователи, участвующие в обсуждении
проекта, описывают все, с их точки зрения, детали предстоящей
задачи и остаются удовлетворенными мыслью, что они точно
изложили все требования и пожелания к задаче. К сожалению,
если пользователи, участвовавшие в обсуждении не являются
конечными пользователями данной системы, то после составления
конечного документа, который в деталях описывает решаемую
задачу, y людей, подписывающих данный документ, возникают
вопросы и какие-либо новые предложения по усовершенствованию
отдельных деталей или их изменению. Эта ситуация возникает в
большинстве подобных случаев. Как вы понимаете, такая
ситуация отбрасывает процесс разработки приложения на стадию
анализа предстоящего проекта. Налицо потеря времент и
средств.
Аналогичная проблема возникает при участии в составлении проекта людей,
которые никогда не будут использовать создаваемую программу.
Это общая проблема проектирования программного обеспечения.
Когда весь проект разработан, реализован, оттестирован и
представлен заказчику, конечные пользователи, те кто
действительно будет использовать созданное приложение,
выясняют, что оно скорее помеха, нежели помощь в их работе.
Третья из описанных выше проблем заключается в том, что
пользователи, предъявившие минимальные требования к системе
на стадии системного проектирования и оставившие разработку
проекта на рассмотрение производителя, начинают возмущаться,
что продукт не удовлетворяет тем или иным требованиям, а
поэтому работает некорректно и требует переделки.
Чтобы избежать вышеописанных ситуаций, необходимо предпринять
следующее:
' Убедитесь, что люди, участвующие в обсуждении проекта,
являются людьми, детально разбирающимися в тонкостях решаемой
задачи.
' Убедитесь, что люди, принимающие участие в обсуждении
проекта, заинтересованы в конечном результате.
' Дайте пользователям возможность обсудить все вопросы,
которые только возможно. Даже если их объяснения несвязны и
неорганизованы, посторайтесь выяснить, что для пользователей
является более важным в создаваемой программе, а что менее
важным (что бы они хотели получить сначала, а что потом).
' Постарайтесь подключить к обсуждению людей, которые
действительно будут использовать создаваемый продукт.
Кто будет вести шоу?
Второй распространенной ошибкой является выбор pуководителя
проекта, не обладающего соответствующими техническими
знаниями для реализации данного проекта. Эта проблема обычно
встречается на больших проектах, где необходима большая
команда программистов. Часто существует технический лидер,
который может управлять проектом также хорошо, как и решать
технические вопросы. Использование его в качестве менеджера
проекта более предпочтительно, нежели использование простого
администратора.
В процессе анализа требований заказчика важно, чтобы в
переговорах участвовал один из членов команды разработчиков,
а в лучшем случае, ведущий технический специалист или
технический pуководитель проекта. К сожалению, достаточно
тяжело собрать в одной комнате и в одно время всех людей,
которым необходимо принимать участие в обсуждении проекта.
Если в процессе обсуждения участвует только административное
лицо, либо pуководитель проекта, далекий от проблем
непосредственного кодирования, то возникает множество проблем
и вопросов, связанных с возможной оптимизацией отдельных
операций, созданием словаря баз данных, системными
требованиями к создаваемому программному обеспечению и т.д. В
данном случае отдельным членам приходится повторно общаться с
конечными пользователями для выяснения неучтенных или плохо
продуманных вопросов, что в конце концов может испортить
отношения между командой разработчиков и конечными
пользователями. С другой стороны, участие в обсуждении
проекта технических специалистов может привести к заметному
упрощению проекта за счет приведения отдельных требований
пользователя к уже существующим и ранее разработанным
технологиям удовлетворения данных требований.
Когда необходимый технический персонал просто не может
присутствовать на всех заседаниях обсуждения проекта, или
технический специалист должен временно переключиться на
другие действия в процессе обсуждения, может помочь так
называемый протокол заседаний. Данный протокол содержит
заметки о всех обсуждаемых на данном заседании вопросах, а
также имена, должности и телефоны участников обсуждения как с
одной, так и с другой стороны. Данный протокол также должен
содержать информацию о принятых решениях, оговоренных нюансах
и любых деталях, обсуждение которых уже производилось. В
конце концом данные заметки должны перерасти в конечный
документ, описывающий результат, полученный в процессе
обсуждения всех частей и деталей проекта.
Если указанные рекомендации будут соблюдены, то техническая
сторона разработки будет рассмотрена более полно, что даст
возможность впоследствии избежать многих ошибок, связанных с
непониманием той или иной стороной технических особенностей
проекта.
Программисты, работающие на yровне битов и байтов
Оберегайтесь программистов, которые могут просидеть несколько суток над
созданием функции, которая фактически не нужна конечному
пользователю. Программисты, которые не умеют работать с
пользователями, не понимают вопросов, связанных со спецификой
работы конечного пользователя, или не умеющие изложить более
или менее сложные технические вопросы на простом pусском
языке не должны участвовать в процессе обсуждения проекта.
Они могут создать дополнительные трудности технического и
временного характера, начиная детально выяснять
несущественные вопросы.
К сожалению, многие программисты не очень хорошо разбираются в
окружающем их деловом мире. Их специализация - компьютеры и
программы, а не создание кинофильмов или управление
госпитальным хозяйством. Возникает вопрос:"Действительно ли
необходимо команде разработчиков детально разбираться в
делопроизводстве и специфике бизнеса конечных пользователей?"
Неопытный программист подумает, "Пользователи профессионалы в
своей области, я профессионал в своей: если мы начнем обучать
друг друга нашим профессиям, понадобимся ли мы друг другу в
конце концов?"
Неверно. Профессиональные знания в той или иной области не
приобретаются в процессе совместного обсуждения какого-либо
проекта. Не приобретаются они и в процессе написания
программы по заданной тематике. Профессиональные знания часто
приобретаются в процессе многих лет обучения, следующих за не
менее длительным периодом проб и ошибок.
Когда пользователи пытаются описать, что они хотят от отдельных
частей программы, не надо сразу переводить их пожелания в
код. Необходимо понять, что хочет пользователь, а затем
постараться сделать это наиболее оптимальным способом.
Оптимальный вариант, когда пользователь имеет представление о
технической стороне обсуждаемой задачи, а команда
программистов имеет опыт в сфере деятельности пользователя.
Когда сочетаются такие качества пользователя и разработчика,
примерно половина вопросов сразу снимается с обсуждения за
ненадобностью. Я однажды имел дело с заказчиком, который не
только самостоятельно разработал входные и выходные формы
документов и подробно описал все этапы выполнения требуемой
задачи, но и предложил схему словаря данных, которая
наилучшим образом подходила для обеспечения управлением
данных, представленых в задаче.
В худшем случае пользователь является технофобом, а
технический специалист ничего не знает о бизнесе. В данном
слу
...Поділитися у соцмережах
