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

Лекция 2

Анализ требований является первой фазой разработки ИС, на которой требования заказчика уточняются, формализуются и документируются. Фактически на этом этапе дается ответ на воп­рос: «Что должна делать будущая система?». Именно здесь лежит ключ к успеху всего проекта. В практике создания больших систем известно немало примеров неудачной реализации проекта именно из-за неполноты и нечеткости определения системных требований.

Список требований к АСУП должен включать:

• совокупность условий, при которых предполагается эксплуа­тировать будущую систему (аппаратные и программные ре­сурсы, предоставляемые системе; внешние условия ее функ­ционирования; состав людей и работ, имеющих к ней отно­шение);

• описание выполняемых системой функций;

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

Целью анализа является преобразование общих, неясных знаний о требованиях к будущей системе в точные (по возможности) опре­деления. Результатом этапа должна являться модель требований к системе (по другому — системный проект), определяющая:

• архитектуру системы, ее функции, внешние условия, распре­деление функций между аппаратной и программной частями (ПЧ);

• интерфейсы и распределение функций между человеком и системой;

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

• полную функциональную модель требований к будущей сис­теме с глубиной проработки до уровня каждой операции каж­дого должностного лица;

• спецификации операций нижнего уровня;

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

• концептуальную информационную модель требований;

• пакет отчетов и документов по информационной модели;

• архитектуру системы с привязкой к концептуальной инфор­мационной модели;

• предложения по оргштатной структуре для поддержки сис­темы.

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

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

• описать, «увидеть» и скорректировать будущую систему до того,

как она будет реализована физически;

• уменьшить затраты на разработку и внедрение системы;

• оценить разработку по времени и результатам;

• достичь взаимопонимания между всеми участниками работы (заказчиками, пользователями, разработчиками, програм­мистами и т. д.);

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

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

3. Модель требований может быть использована для самостоя­тельной разработки или корректировки уже реализованных на ее основе программных средств силами программистов отдела автома­тизации предприятия.

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

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

Разработка технического задания

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

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

• разработку требований к техническим средствам;

• разработку требований к программным средствам;

• разработку топологии, состава и структуры локальной вычис­лительной сети;

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

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

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

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

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

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

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

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

На основании выявленных требований разрабатывается тех­
ническое задание (ТЗ) на КИУС и, по необходимости, частные
ТЗ на ее компоненты (подсистемы). ТЗ создается на основе
i ГОСТ 34.602—89. Техническое задание на создание автоматизи-

рованной системы и включает в себя следующие основные раз­делы:

• общие сведения;

• назначение и цели создания системы;

• характеристика объекта автоматизации;

• требования к системе;

• состав и содержание работ по созданию системы;

• порядок контроля и приемки системы;

• требования по подготовке и вводу в действие;

• требования к документированию;

• источники разработки;

• глоссарий.

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

В разделе Характеристика объекта автоматизации приво­дятся общие сведения о предприятии согласно его уставу, пере­чень основных видов деятельности и бизнес-процессов, пере­чень бизнес-процессов, подлежащих автоматизации в рамках КИУС, характеристики видов обеспечения - организационного (организационные документы, организационная структура, нор­мативное обеспечение, квалификация персонала), методическо­го, программного (в сфере управления, в сфере производства,

общесистемное), технического, лингвистического, математиче­ского, правового и информационного.

Раздел Требования к системе включает следующие три под­раздела: требования к системе в целом, требования к функциям, требования к видам обеспечения. В подразделе Требования к системе в целом содержатся:

• перечень компонентов (подсистем), их назначение и основ­ные характеристики, требования к структуре системы;

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

• требования к характеристикам взаимосвязей создаваемой системы со смежными системами, требования к ее совмести­мости, способы информационного обмена;

• требования к режимам функционирования системы;

• требования к диагностированию системы;

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

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

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

• требования к стандартизации и унификации.

Г. Н. Калянов. Консалтинг

Глава 5. Создание КИУС

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

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

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

Раздел Требования к документированию содержит состав комплекта документации и структуру документов по системе. По типовым компонентам, используемым в системе, предостав­ляется документация, входящая в комплект поставки. Эксплуа­тационная документация по разрабатываемым компонентам представляется в соответствии с требованиями ГОСТ 34.201-89. Информационная технология. Комплекс стандартов на авто­матизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем,

а также РД 50-34.698-90. Методические указания. Информаци­онная технология. Требования к содержанию документов. Воз­можный перечень этих документов приведен ниже.

• Частное техническое задание - в соответствии с ГОСТ 34.602-89.

• Описание информационного обеспечения - в соответствии с РД 50-34.698-90, п. 5.3. (при необходимости).

• Описание программного обеспечения - в соответствии с РД 50-34.698-90, п. 6.1.

• Инструкция по обозначениям и кодированию (при необхо­димости).

• Альбом выходных форм.

• Руководство администратора подсистемы.

• Руководство пользователя - в соответствии с РД 50-34.698-90, п. 3.4.

• Программа и методика испытаний - в соответствии с РД 50-34.698-90, п. 2.14.

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

• План разработки (детализированный календарный план ра­бот, содержащий виды работ, даты начала и завершения ра­бот, отметки о выполнении работ);

• План управления конфигурацией, содержащий описание сле­дующих процессов управления проектной документацией: порядка разработки и хранения, порядка внесения измене­ний, ведения версионности, рассылки, порядка внутреннего согласования;

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