Структурный анализ потоков данных с помощью диаграмм DFD

 

Так же, как и диаграммы IDEF0, диаграммы потоков данных (DataFlowDiagrams – DFD) моделируют систему как набор действий, соединенных друг с другом стрелками. Диаграммы потоков данных могут содержать два новых типа объектов: объекты, собирающие и хранящие информацию, – хранилища данных и внешние сущности – объекты, моделирующие взаимодействие с теми частями системы (или другими системами), которые выходят за границы моделирования (рис. 4.4.35).

Рис. 4.4.35. Пример DFD диаграммы

 

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

Построение DFD-диаграмм в основном ассоциируется с разработкой программного обеспечения, поскольку нотация DFD изначально была разработана для этих целей. В отличие от IDEF0, рассматривающего систему как множество взаимопересекающихся действий, в названиях объектов DFD-диаграмм преобладают имена существительные; Контекстная DFD-диаграмма часто состоит из одного функционального блока и нескольких внешних сущностей. Функциональный блок на этой диаграмме обычно имеет имя, совпадающее с именем всей системы (рис. 4.4.36).

 

Рис. 4.4.36. Контекстная DFD-диаграмма

 

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

Функциональный блок DFD моделирует некоторую функцию, которая преобразует сырье в какую-либо продукцию (или, в терминах IDEF, вход в выход). Хотя функциональные блоки DFD и изображаются в виде прямоугольников с закругленными углами, они почти идентичны функциональным блокам IDEF0 и действиям IDEF3. Как и действия IDEF3, функциональные блоки DFD имеют входы и выходы, но не имеют управления и механизма исполнения, как IDEF0. В некоторых интерпретациях нотации DFD Гейна-Сарсона механизмы исполнения IDEF0 моделируются как ресурсы и изображаются в нижней части прямоугольника (рис. 4.4.37).

Рис. 4.4.37. Элемент DFD-диаграммы, построенной по нотации

Гейна - Сарсона

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

принимать выходы (функционируя как получатель).

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

Рис. 4.4.38. Обозначение внешней сущности

 

Стрелки описывают передвижение (поток) объектов от одной части системы к другой. Поскольку все стороны обозначающего функциональный блок DFD прямоугольника равнозначны (в отличие от IDEF0), стрелки могут начинаться и заканчиваться в любой части блока. В DFD также используются двунаправленные стрелки, которые нужны для отображения взаимодействия между блоками (например, диалога типа «приказ–результат выполнения»).

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

Рис. 4.4.39. Двунаправленный поток между блоком и внешней

сущностью

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

Рис. 4.4.40. Обозначение хранилища данных на DFD-диаграмме

 

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

Рис. 3.6.42. Разветвление стрелки, иллюстрирующее декомпозицию

данных

 

Стрелки могут соединяться между собой(объединяться) для формирования так называемых комплексных объектов. Пример такого объединения приведен на рис. 4.4.42.

Рис.4.4.42. Объединение потоков в один

 

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

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

 

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

 

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

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

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

Уникальные номера присваиваются также каждому хранилищу данных и каждой внешней сущности вне зависимости от расположения объекта на диаграмме. Каждый номер хранилища данных содержит префикс D (DataStore) и уникальный номер хранилища в модели (например, D3).

 

Рис. 4.4.43. Компоненты номера функционального блока DFD

 

Аналогично, номер каждой внешней сущности содержит префикс Е (Externalentity) и уникальный номер сущности в модели (например, Е5).

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

4.5. Особенности разработки требований к программному обеспечению АС

4.5.1. Участники разработки и структура требований к ПО

В разработке требований к программному обеспечению (ПО) заинтересованы различные лица, такие как:

1. заказчики, которые финансируют проект или приобретают продукт для решения каких-то своих задач;

2. пользователи, которые взаимодействуют напрямую или не напрямую с приложениями (подкласс заказчиков);

3. аналитики требований, которые пишут требования и передают их разработчикам;

4. разработчики, которые создают, разворачивают и поддерживают продукт;

5. тестеры, которые определяют соответствие поведения ПО желаемому;

6. технические писатели, которые отвечают за создание руководства пользователей, тренировочные материалы и справочную систему;

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

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

9. производственники, которые должны построить продукт, содержащий данное ПО;

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

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

Требование к ПО состоит из трех уровней:

 – бизнес – требования,

- требования пользователей,

- функциональные требования.

Вдобавок каждая система имеет свои нефункциональные требования.

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

Рис. 4.5.1. Взаимосвязи нескольких типов информации для требований

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

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

Требования пользователей описывают цели и задачи, которые пользователям позволит решить система. К отличным способам представления этого вида требований относятся варианты использования, сценарии и таблицы «событие - отклик». Таким образом в этом документе указано, что клиенты смогут сделать с помощью системы. Пример варианта использования – «Сделать заказ» для заказа билетов на самолет, аренды автомобиля, заказа гостиницы через Интернет.

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

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

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

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

- при разработке и тестировании ПО,

- при определении гарантии качества продукта,

- для управления проектом и связанных с проектом функций.

 

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

 

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

 

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

Чтобы лучше воспринять некоторые из различных видов требований, рассмотрим простую программу подготовки текстов. Бизнес-требование может выглядеть следующим образом: «Продукт позволит пользователю исправлять орфографические ошибки в тексте эффективно». На коробке CD-ROM указано, что проверка грамматики включена как характеристика, удовлетворяющая бизнес-требованиям. Соответствующие требования пользователей могут содержать задачи или варианты использования вроде такой: «Найдите орфографическую ошибку» или «Добавьте слово в общий словарь». Проверка грамматики имеет множество индивидуальных функциональных требований, которые связаны с такими операциями, как поиск и выделение слова с ошибкой, отображение диалогового окна с фрагментом текста, где это слово находится, и замена слова с ошибкой корректным вариантом по всему тексту. Атрибут качества легкость и простота использования как раз и определяет его значение посредством слова «эффективно» в бизнес-требованиях.

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

Хотя в модели на рис. 4.5.1 показан поток требований в направлении сверху вниз, следует ожидать и циклов, и итераций между бизнес-требованиями, требованиями пользователей и функциональными требованиями. Кто бы когда бы ни предложил новые характеристики, варианты использования или функциональные требования, аналитик должен спросить: «Они попадают в указанные границы? » Если ответ «да», то они соответствуют спецификации. На «нет», как известно, и суда нет. А вот если ответ «нет, но они должны там быть», то заказчик или тот, кто финансирует проект, должен решить, готов ли он раздвинуть границы проекта, чтобы принять новое требование.

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

 

4.5.2. Этапы разработки требований, риски возникновения ошибок

 

Понятие «требование к ПО» требует уточнения, для чего полезным является разделение этого понятия на собственно разработку требований к ПО и на управление требованиями. Это показано на рис. 4.5.2.

Рис. 4.5.2.

Лекция 9

3.3.2. Этапы разработки требований, риски возникновения ошибок

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

 Такими действиями являются следующие действия:

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

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

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

- установление относительной важности атрибутов качества, т.е. установление приоритетов реализации;

- документирование собранной информации и построение моделей;

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

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

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

- определение основной версии требований, т.е. моментальный срез требований для конкретной версии продукта;

- просмотр предлагаемых изменений требований и оценка вероятности воздействия каждого изменения до его принятия;

- включение одобренных изменений требований в проект установленным способом;

- согласование плана проекта с требованиями;

- обсуждение новых обязательств, основанных на оцененном влиянии изменения требований;

- отслеживание отдельных требований до их дизайна, исходного кода и вариантов тестирования;

- отслеживание статуса требований и действий по изменению на протяжении всего проекта.

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

В заключение отметим, что основное следствие проблемы с требованиями – переделка того, что как вы думаете, уже готово. На это расходуется от 30 до 50% общего бюджета разработки, а ошибки в требованиях стоят от 70 до 85% стоимости переделки. Следовательно, предотвращение ошибок в требованиях и обнаружение их на ранних стадиях сильно уменьшает объем переделки.

Рассмотрим наиболее общие риски возникновения ошибок в разработанных требованиях к ПО.

 

Рис. 4.5.3.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Полнота. Никакие требования или необходимые данные не должны быть пропущены.

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

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

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

 

4.5.3. Права и обязанности разработчиков и клиентов ПО

 

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

Совместная работа разработчиков и клиентов возможна только тогда, когда:

1) все участники процесса разработки ПО знают, что необходимо им для успеха;

       2) когда они понимают и уважают стремление их соратников к успеху.

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

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

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

 

Рассмотрим вначале «Билль о правах клиента ПО при формировании требований».

Клиент имеет право:

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

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

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

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

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

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

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

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

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

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

Рассмотрим теперь «Билль об обязанностях клиента ПО при формировании требований».

Клиент обязан:

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

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

3. Точно и конкретно описать требования к системе. Весьма заманчиво оставить требования неопределенными и нечеткими, ведь прояснять подробности утомительно и долго. Тем не менее, на каком-то этапе разработки участникам проекта необходимо устранить все неоднозначности и неточности. Это может сделать только клиент - пользователь. В противном случае угадывать, что же именно нужно клиенту будут аналитики и разработчики. В спецификации требований к программному обеспечению рекомендуется использовать пометки типа «TBD» (tobedetermined – необходимо определить). Эти пометки указывают на необходимость дополнительных исследований, анализа и информации. Иногда такие маркеры используют в случаях, когда конкретное требование трудно определить точно и никто не хочет с ним возиться. В таких случаях можно применять метод, когда пользователь и аналитик формулируют требования поэтапно и постепенно.

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

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

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

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

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

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

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

Результатом сотрудничества клиента и разработчика считается соглашение по требованиям к продукту. Однако, реальность такова, что на ранних этапах над проектом известна лишь часть требований, со временем они могут меняться. Тем не менее, необходимо подтвердить полученные результаты своими подписями. Под подписями рекомендуется сделать примерно следующий текст: «Настоящий документ является базовой (основной) версией и наилучшим образом представляет понимание требований к проекту на данный момент. В базовый документ в будущем могут вноситься изменения».

 

4.5.4. Обязанности аналитика требований

 

Рассмотрим теперь вопросы, касающиеся аналитика требований.

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

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

 

Рис. 4.5.4

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

Аналитик обязан:

 

1. Определить бизнес-требования, для чего надо поработать со спонсором, менеджером проекта или менеджером по маркетингу.

       2. Определить заинтересованных лиц и классы пользователей.

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

- интервью, опросы и семинары;

- анализ бизнес-процессов и посещение рабочих мест клиентов;

- анализ документооборота и решаемых задач;

- анализ конкурирующих продуктов и исследование существующих систем;

- ретроспективы развития предыдущего проекта.

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

5. Создавать спецификации с требованиями. В результате формулировки требований формируется коллективный взгляд на систему. Применение стандартных шаблонов ускоряет процесс составления спецификации. Пример такого шаблона приведен на рис. 4.4.5.

 

1. Введение 1.1. Назначение 1.2. Соглашения, принятые в документах 1.3. Предполагаемая аудитория и рекомендации по чтению 1.4. Границы проекта 1.5. Ссылки

2. Общее описание 2.1. Общий взгляд на продукт 2.2. Особенности продукта 2.3. Классы и характеристики пользователей 2.4. Операционная среда 2.5. Ограничения дизайна и реализации 2.6. Документация для пользователей 2.7. Предположения и зависимости

3. Функции системы 3.х. Функция системы 3.х.1. Описание и приоритеты 3.х.2. Последовательности «воздействие - реакция» 3.х.3. Функциональные требования

4. Требования к внешнему интерфейсу 4.1. Интерфейсы пользователя 4.2. Интерфейсы оборудования 4.3. Интерфейсы ПО 4.4. Интерфейсы передачи информации

5. Другие нефункциональные требования 5.1. Требования к производительности 5.2. Требования к охране труда 5.3. Требования к безопасности 5.4. Атрибуты качества

6. Остальные требования

Приложение А. Словарь терминов

Приложение Б. Модели анализа

Приложение В. Список вопросов

Рис. 4.4.5. Шаблон для спецификации требований к ПО

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

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

8. Обеспечить расстановку приоритетов требований.

9. Управлять требованиями. Управление требованиями подразумевает контроль над состоянием отдельных функциональных требований по мере степени готовности продукта. Расспрашивая коллег, аналитик собирает информацию о связях требований, сопоставляет их с прочими элементами системы. Аналитик – ключевая фигура в управлении изменениями базовых требований, для этого он применяет средства контроля изменений.

Лекция 10.

4.5.5. Управление требованиями ПО

Рассмотрим упрощенную схему процесса управления требованиями.

Все действия по выявлению, анализу, спецификации и проверке требований выполняются не последовательно и не за один проход. На практике они выполняются попеременно, поэтап­но и повторяются (Рисунок 1.4).

Этап «выявление требований» - работа с клиентами в качестве аналити­ка; клиентам задаются вопросы, выслушиваются ответы, ведутся наблюдения за действиями клиентов.

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

«Определение приоритетов реализации требований» – аналитики определяют на основе различных критериев степень важности каждого требования.

Последующие этапы – «учет изменений и контроль версий требований», «анализ рисков реализации требований», «анализ трудозатрат реализации требований», «анализ длительности и стоимости разработки».

 

Рис. 4.5.5. Обобщенная схема процесса управления требованиями.

 

Этот итерационный процесс и есть процедура управления требованиями.

Рассмотрим конкретную проектную организацию, занимающуюся разработкой ПО. Ее структура представлена на рис 4.5.6.

Рис.4.5.6.Структура проектной организации

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

Отдел разработки обеспечивает реализацию требований, а именно, разработку ПО.

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

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

- функционирование программно-технических средств;

- функционирование локальной вычислительной сети;

- функционирование средств телекоммуникаций и связи;

- функционирование систем пожарно-охранной сигнализации;

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

- формирование и ведение информационных массивов и баз данных;

- защиту информации от несанкционированного доступа;

- формирование и ведение архивов страховочных копий общесистемного и специального программного обеспечения и данных.

Также в обязанности отдела технической поддержки входит:

- обеспечение оперативного управления комплексом средств автоматизации,

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

- принятие информации о состоянии работоспособности комплекса средств автоматизации,

- анализ и, при необходимости, принятие мер по устранению выявленных недостатков;

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

Перейдем теперь к рассмотрению жизненного цикла требований в системе создания ПО применительно к этой конкретной организации (подразделении ИТ). Этот жизненный цикл представим в виде сетевого графика, представленного на рис. 4.5.7.

 

 

Рис. 4.5.7. Сетевой график жизненного цикла требований к ПО

 

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

- «Поступление требования заказчика».

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

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

 - «Запись требования в БД» - поставщик выполняет данную процедуру для хранения и обработки данных требования. 

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

- «Детальный анализ требования, определение подзадач» - на данном этапе аналитик разбивает требование на подзадачи, разрабатывает предварительные проектные решения по подзадачам. 

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

- «Составление плана тестирования». От этого этапа во многом зависит качество итогового программного продукта. Наличие подробно специфицированных требований позволяет проверить разработанный программный продукт на соответствие требованиям. Такая проверка осуществляется путем составления вариантов тестирования – вместе все варианты тестирования должны покрывать 100% требований.

- «Утверждение проекта решения и поступление заявки в очередь на выполнение» осуществляется при согласовании с заказчиком; на этом этапе должно быть подтверждено соответствие проекта решения потребностям заказчика.

- «Выбор и постановка на выполнение требования» производится руководителем на основании относительной важности требований.

- «Выполнение подзадач» включает в себя непосредственное программирование и отладку.

- «Комплексное тестирование программного продукта» - осуществляет оператор технической поддержки на основе плана тестирования, ранее составленного аналитиком.

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

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

В рассматриваемой конкретной организации основным средством автоматизации разработки ПО является система JIRA, представляющая собой средство управления изменениями и багтрэкер (bug tracker – программа регистрации ошибок и дефектов ПО и их состояния). То есть все заявки, поступающие в систему, есть ошибки и изменения в уже существующих программных продуктах.

При поступлении требования в систему оператор технической поддержки фиксирует это событие. Заявка заносится в базу данных, что вполне естественно и удобно – система JIRA интегрируема с такими базами, как MS SQL, Oracle, DB2, MySQL, Access. В базе хранятся все заявки, когда-либо поступившие в систему. С помощью запросов можно найти любую заявку, узнать ее статус, атрибуты (о них речь пойдет в следующих разделах) и т.д.

Когда заявка занесена в базу, ее может посмотреть и проанализировать руководитель отдела разработчиков на своем рабочем месте (АРМ), сделав запрос к БД. Тут же назначается аналитик для работы с данным требованием.

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

Результаты такого анализа – проект решения и предполагаемые подзадачи, поставленные для удовлетворения требования, тоже вносятся в БД.

 

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

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

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

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

 

⇐ Предыдущая9101112131415161718Следующая ⇒

Поделиться: