Менеджмент программных разработок

Что такое ГОСТ

ГОСТ - государственный стандарт

Государственные стандарты (ГОСТ) впервые были разработаны Комитетом по стандартизации при Совете труда и обороны, созданном в 1925 году. Тогда 80 лет назад были разработаны и утверждены стандарты, регламентирующие производство практически всего - начиная от продуктов питания и заканчивая автомобилями. Данные стандарты носили обязательный характер и действовали на всей территории СССР.

На сегодняшний день насчитывается порядка 25 тысяч ГОСТов, которые распространены не только на территории Российской Федерации, но и некоторых стран СНГ, таких как Азербайджан, Армения, Белоруссия, Грузия, Казахстан, Киргизия, Молдова, Таджикистан, Узбекистан, Украина.

С 27 декабря 2002 года, согласно Федеральному закону о техническом регулировании (№184-ФЗ) ГОСТ перестал носить обязательный характер и может применяться добровольно (за исключением случаев, касающихся обеспечения безопасности здоровья граждан или окружающей среды). В этом же году было введено понятие технического регламента, который в будущем должен заменить государственные стандарты.

Публикация текстов ГОСТов на территории Российской Федерации должна вестись на бесплатной основе. На официальном сайте Ростехрегулирования можно найти в открытом доступе большинство государственных стандартов.

Классификация ГОСТов

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

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

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

· ГОСТ 2 .ххх – Единая Система конструкторской документации (ЕСКД)

· ГОСТ 19 .ххх – Единая Система программной документации (ЕСПД)

· ГОСТ 24 ххх. - Единая система стандартов автоматизированных систем управления (позднее ГОСТ 34 – Комплекс стандартов на автоматизированные системы)

Так как ГОСТ носит частично международный характер для стандартов, действующих только на территории России, принято наименование ГОСТ Р.

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

ГОСТ 34 и ГОСТ 19

Наиболее частой проблемой при разработке технической документации является вопрос выбора правильного стандарта (ГОСТ 19 или ГОСТ 34). Ключ к пониманию разницы между данными стандартами заложен в наименовании их комплекса – Единая система программной документации (ГОСТ 19) и Комплекс стандартов на автоматизированные системы (ГОСТ 34).

Автоматизированная система является результатом целенаправленной деятельности ведущей к автоматизации одного или нескольких производственных процессов на предприятии. Таким образом, автоматизированная система (АС) должна иметь:

· цель (например: оптимизация процесса документооборота на предприятии);

· обслуживающий и эксплуатационный персонал (например: системный администратор, администратор баз данных и т.п.);

· программные средства, обеспечивающие корректную работу АС (например: операционная система);

· комплекс технических средств, на котором развернута АС (например: сервер, рабочее место пользователя).

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

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

1.3.Диаграммы деятельности

Диаграммы деятельности. Диаграммы деятельности (Activity diagram), называемые также диаграммами активности или диаграммами видов деятельности, были введены в язык UML сравнительно недавно. Диаграмма деятельности - это, по существу, блок-схема, которая показывает, как поток управления переходит от одной деятельности к другой, при этом внимание фиксируется на результате деятельности. Результат может привести к изменению состояния системы или возвращению некоторого значения. Диаграмма деятельности отличается от традиционной блок-схемы более высоким уровнем абстракции, возможностью представления с помощью диаграмм деятельности управления параллельными потоками наряду с последовательным управлением. Одно из основных направлений использования диаграмм деятельности - отображение внутрисистемной точки зрения на прецедент. Диаграммы деятельности применяют для описания шагов, которые должна предпринять система после того, как инициирован прецедент. Разработка диаграммы деятельности преследует цели: детализировать особенности алгоритмической и логической реализации прецедентов; выделить последовательные и параллельные потоки управления; подготовить детальную документацию для взаимодействия разработчиков системы с ее заказчиками и проектировщиками. Графически диаграмма деятельности представляется в форме графа деятельности, вершинами которого являются состояния действия или состояния деятельности, а дугами — переходы от одного состояния действия/деятельности к другому. Каждая диаграмма деятельности должна иметь единственное начальное и единственное конечное состояния (на практике иногда можно видеть несколько конечных состояний на одной диаграмме, но это одно и тоже состояние, изображенное несколько раз для лучшей читабельности диаграммы). Саму диаграмму деятельности принято располагать таким образом, чтобы действия следовали сверху вниз. В этом случае начальное состояние будет изображаться в верхней части диаграммы, а конечное — в ее нижней части. Рассмотрим основные элементы диаграммы деятельности. Состояние деятельности (Activity, Process) - это продолжающийся во времени неатомарный шаг вычислений в автомате. Состояния деятельности могут быть подвергнуты дальнейшей декомпозиции, вследствие чего выполняемую деятельность можно представить с помощью других диаграмм деятельности. Состояния деятельности не являются атомарными, то есть могут быть прерваны. Предполагается, что для их завершения требуется заметное время. Состояния действия (action state) - состояние, которое представляет вычисление атомарного действия, как правило - вызов операции. Состояния действия не могут быть подвергнуты декомпозиции. Они атомарны, то есть внутри них могут происходить различные события, но выполняемая в состоянии действия работа не может быть прервана. И наконец, обычно предполагается, что длительность одного состояния действия занимает неощутимо малое время. Действие может заключаться в вызове другой операции, посылке сигнала, создании или уничтожении объекта либо в простом вычислении - скажем, значения выражения. Состояния деятельности и состояния действия имеют одинаковое стандартное графическое обозначение - прямоугольник с закругленными краями. Внутри такого символа записывают произвольное выражение (action-expression), которое должно быть уникальным в пределах одной диаграммы деятельности.   Начальное и конечное состояния на диаграммах деятельности изображаются как закрашенный кружок и закрашенный кружок внутри окружности, соответственно.     Переход (Transitions) - отношение между двумя состояниями, показывающее, что объект, находящийся в первом состоянии, должен выполнить некоторые действия и перейти во второе состояние. Когда действие или деятельность в некотором состоянии завершается, поток управления сразу переходит в следующее состояние действия или деятельности. Для описания этого потока и используются переходы, показывающие путь из одного состояния действия или деятельности в другое. В UML переход представляется простой линией со стрелкой.   Ветвления. Простые последовательные переходы встречаются наиболее часто, но их одних недостаточно для моделирования любого потока управления. Как и в блок-схему, в диаграмму деятельности может быть включено ветвление или множественный переход со сторожевыми условиями. Ветвление описывает различные пути выполнения в зависимости от значения некоторого булевского выражения. Графически точка ветвления представляется ромбом. В точку ветвления может входить ровно один переход, а выходить - два или более. Для каждого исходящего перехода задается булевское выражение, которое вычисляется только один раз при входе в точку ветвления. Ни для каких двух исходящих переходов сторожевые условия не должны одновременно принимать значение "истина", иначе поток управления окажется неоднозначным. Но эти условия должны покрывать все возможные варианты, иначе поток остановится. Разделения и слияния. Простые и ветвящиеся последовательные переходы в диаграммах деятельности используются чаще всего. Однако часто возникает потребность изображения параллельных потоков, и это особенно характерно для моделирования бизнес-процессов. В UML для обозначения разделения и слияния таких параллельных потоков выполнения используется синхронизационная черта, которая рисуется в виде жирной вертикальной или горизонтальной линии. При этом разделение (concurrent fork) имеет один входящий переход и несколько выходящих, слияние (concurrent join), наоборот, имеет несколько входящих переходов и один выходящий (см. рис.2).

Следует помнить, что под параллельными потоками управления имеется в виду не только истинный параллелизм, то есть одновременное выполнение, но и последовательное выполнение с переключением между потоками, что дает лишь иллюзию истинного параллелизма, а также независимое прохождение потоков в произвольном порядке. Дорожки. При моделировании течения бизнес-процессов иногда бывает полезно разбить состояния деятельности на диаграммах деятельности на группы, каждая из которых представляет отдел компании, отвечающий за ту или иную работу. В UML такие группы называются дорожками (Swimlanes), поскольку визуально каждая группа отделяется от соседних вертикальной чертой, как плавательные дорожки в бассейне (см. рис. 3). Дорожки - это разновидность пакетов, описывающие связанную совокупность работ. Каждой присутствующей на диаграмме дорожке присваивается уникальное имя. Никакой глубокой семантики дорожка не несет, разве что может отражать некоторую сущность реального мира. Каждая дорожка представляет сферу ответственности за часть всей работы, изображенной на диаграмме. На диаграмме деятельности, разбитой на дорожки, каждая деятельность принадлежит ровно одной дорожке, но переходы могут пересекать границы дорожек. Имеется некоторая связь между дорожками и параллельными потоками выполнения. Концептуально деятельность внутри каждой дорожки обычно - но не всегда - рассматривается отдельно от деятельности в соседних дорожках. Это разумно, поскольку в реальном мире подразделения организации, представленные дорожками, как правило, независимы и функционируют параллельно.

Рекомендация. Диаграммы деятельности рекомендуется выполнять c использованием программного продукта Enterprise Architect как диаграмму UML Behavior с типом Activity На рис.4 приведена диаграмма деятельности прецедента «Прокат видео» для рассмотренного в разделе 1.2 примера «Магазин видеопродукции»

ПОДБОР КОМАНДЫ

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

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

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

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

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

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

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

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

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

АНАЛИЗ ПОЖЕЛАНИЙ И ТРЕБОВАНИЙ ЗАКАЗЧИКА

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

АНАЛИЗ ТРЕБОВАНИЙ К ПРОЕКТУ

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

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

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

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

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

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

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

ТРЕБОВАНИЯ ПОЛЬЗОВАТЕЛЯ

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

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

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

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

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

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

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

ТЕХНИЧЕСКОЕ ПРОЕКТИРОВАНИЕ

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

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

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

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

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

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

РЕАЛИЗАЦИЯ

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

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

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

СИСТЕМНОЕ ТЕСТИРОВАНИЕ

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

— системный тест, или лабораторные испытания;

— опытная эксплуатация;

— приемочный тест.

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

Лабораторное тестирование — последняя возможность разработчиков исправить все обнаруженные ошибки, прежде чем система будет передана конечным пол