Общие сведения о технологии проектирования ИС

I. Общие положения

ТЗ должно соответствовать современному уровню развития науки и техники, максимально точно отражать цели, замысел и требования к создаваемой системе и при этом не ограничивать разработчика в поиске и реализации наиболее эффективных технических, технико-экономических и других решений. В соответствии с ГОСТ 34.601-90,после согласования с Заказчиком, выполняется разработка, оформление, согласование и утверждение Технического задания на АИС (при необходимости – на части АИС). Данный стандарт также определяет состав участников проектирования и реализации проектных решений, которые участвуют в составлении и (или) согласовании ТЗ. В самом общем случае к ним относятся:

1. Организация-заказчик (пользователь), для которой создаётся АИС и которая обеспечивает финансирование, приёмку работ и эксплуатацию как по всей АИС, так и по отдельным её компонентам;

2. Организация-разработчик (генпроектировщик), осуществляющая работы по созданию АИС, представляя Заказчику совокупность научно-технических услуг на разных стадиях и этапах создания, а также разрабатывая и поставляя различные программные и технические средства АС. Данная (головная) организация может пользоваться услугами других организаций, работающих у неё на субподряде;

3. Организация-поставщик, изготавливающая и (или) поставляющая программные и технические средства по заказу Разработчика или Заказчика;

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

ГОСТ 34.602-89 устанавливает порядок разработки, согласования и утверждения ТЗ на создание (развитие или модернизацию) автоматизированных систем различного назначения, а также состав и содержание указанного документа независимо от того, будет ли она работать самостоятельно или в составе другой системы. В зависимости от условий создания системы возможны различные совмещения функций заказчика, разработчика, поставщика и других организаций, участвующих в работах по созданию АИПС.

ТЗ на АИС разрабатываются на основании исходных данных.

Любые изменения к ТЗ оформляются дополнительными протоколами, подписанными заказчиком и разработчиком. Оформленные таким образом дополнения являются неотъемлемой частью ТЗ на АИС. На титульном листе ТЗ должна быть запись “Действует с …”.

СОСТАВ И СОДЕРЖАНИЕ ТЕХНИЧЕСКОГО ЗАДАНИЯ

Рассмотрим состав ТЗ с учётом требований ГОСТ 34.602-89.

ТЗ на АИС содержит следующие разделы:

1. Общие сведения.

2. Назначение и цели создания (развития) системы.

3. Характеристика объектов автоматизации.

4. Требования к системе.

5. Состав и содержание работ по созданию системы.

6. Порядок контроля и приемки системы.

7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу АИС в действие.

8. Требования к документированию.

9. Источники разработки.

10. Приложения.

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

Рассмотрим содержание основных разделов ТЗ с учётом требований ГОСТ 34.602-89.

Раздел“Общие сведения”:

1. Полное наименование системы и её условное обозначение.

2. Наименование и реквизиты предприятий (объединений) разработчика и заказчика системы.

3. Перечень документов, явившихся основанием создания системы, кем и когда они утверждены.

4. Возможные сроки начала и окончания работ по созданию системы.

5. Сведения об источниках и порядке финансирования работ.

6. Порядок оформления и предъявления заказчику результатов работ по созданию системы или её частей, по изготовлению и наладке отдельных средств (технических, программных, информационных) и программно-технических комплексов системы.

Раздел “Назначение и цели создания (развития) системы”:

1. Под “Назначением системы” понимается вид автоматизируемых процессов (деятельности) и перечень предполагаемых к использованию объектов.

2. В пункте “Цели создания системы” приводятся наименования и требуемые значения технических, технологических, производственно-экономических и других показателей объекта автоматизации, достигаемые в результате создания АИС, указываются критерии оценки достижения целей создания системы.

Раздел “Характеристики объекта автоматизации”:

1. Краткие сведения об объекте автоматизации или ссылки на документы, содержащие эти данные.

2. Сведения об условиях эксплуатации объекта автоматизации.

3. Характеристики внешней среды, в которой функционирует объект автоматизации.

Раздел “Требования к системе” содержит подразделы с требованиями к системе в целом, функциям (задачам), выполняемым системой, видам обеспечения.

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

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

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

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

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

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

В дополнительные требования могут быть включены:

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

· требования к сервисным средствам, стендам для проверки элементов системы;

· требования к системе, связанные с особыми условиями эксплуатации;

· специальные требования по усмотрению разработчика или заказчика системы.

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

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

В части требований к информационному обеспечению системы приводят требования:

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

· к информационному обмену между компонентами системы;

· к информационной совместимости со смежными системами;

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

· к внутрисистемным форматам данных;

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

· к структуре процесса сбора, обработки, передачи данных в системе и представлению данных;

· к защите данных от разрушений при авариях и сбоях в электропитании системы;

· к контролю, хранению, обновлению и восстановлению данных;

В части требований к лингвистическому обеспечению системы приводятся требования к применению в системе:

· классификаторов и тезаурусов,

· языков взаимодействия пользователей и технических средств системы,

· средств кодирования и декодирования данных,

· конверторов,

· языков ввода-вывода данных,

· языков манипулирования данными,

· способов организации диалога.

В части требований к программному обеспечению АИС приводятся общие функциональные и общесистемные требования к приобретаемым и вновь разрабатываемым программным продуктам. При этом следует предусмотреть:

· решение средствами ПО системы полного комплекса служебных и пользовательских задач;

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

· поддержку возможности настройки на заданные входные и выходные формы документов;

· поддержку необходимых форматов данных и средств лингвистического обеспечения;

· поддержку требований протоколов телекоммуникационного обмена данными, действующими в области функционирования АИС,

· обеспечение необходимой для создаваемой АИС скорости обработки и поиска данных,

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

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

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

В требования по обеспечению управления и контроля включают:

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

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

· требования к видам статистической обработки контролируемых данных, а также их выходным формам,

· требования к средствам формально-логического контроля.

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

В разделе “Порядок контроля и приемки системы”указывают:

1. Виды, состав, объём и методы испытаний системы и её составных частей (виды испытаний в соответствии с действующими нормами, распространяющимися на разрабатываемую систему);
2. Общие требования к приемке работ по стадиям (перечень участвующих организаций, и/или юридических и физических лиц, место и сроки проведения), порядок согласования и утверждения приёмочной документации;
3. Статус приёмочной комиссии (государственная, межведомственная, ведомственная и т.п.).

В разделе “Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие” необходимо привести перечень основных мероприятий, которые следует выполнить при подготовке объекта автоматизации к вводу АИС в действие, и их исполнителей.

В разделе “Требования к документированию” приводят:

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

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

В разделе “Источники разработки” должны быть перечислены документы и информационные материалы (технико-экономическое обоснование, отчеты о законченных научно-исследовательских работах, информационные материалы на отечественные, зарубежные системы-аналоги и др.), на основании которых разрабатывалось ТЗ и которые должны быть использованы при создании системы.

В состав ТЗ на АИСвключают приложения, содержащие расчёт ожидаемой эффективности системы; оценку научно-технического уровня системы; использованные при разработке ТЗ методические и наиболее важные информационные материалы из состава документов указанных в разделе “Источники разработки”.

Дополнительные рекомендации по составу и содержанию ТЗ на автоматизированные системы различного назначения и приложений к ним содержатся также в РД 50-640-87 и ГОСТ 24.602-86.

ПРАВИЛА ОФОРМЛЕНИЯ ТЗ НА АИС

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

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

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

Разделы и подразделы ТЗ должны быть размещены в порядке, установленном ГОСТ 34.602-89.

Если конкретные значения показателей, норм и требований не могут быть установлены в процессе разработки ТЗ на АИС, в нём делают запись о порядке установления и согласования этих показателей, норм и требований “Окончательное требование (значение) уточняется в процессе ... и согласовывается протоколом с ... на стадии ...”. При этом в текст ТЗ на АИС изменений не вносят.

Титульный лист дополнения к ТЗ на АИС оформляют аналогично титульному листу Технического задания. Вместо наименования “Техническое задание” пишут “Дополнение 1... к ТЗ на АИС...”.

На следующих листах дополнения к ТЗ на АИС помешают основание для изменения, содержание изменения и ссылки на документы, в соответствии с которыми вносятся эти изменения.

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

Реально сложившаяся практика проектирования АИС предусматривает следующие этапы (стадии) проектирования:

1. Предпроектное обследование, включающее:

· краткую характеристику исходного состояния объекта автоматизации и среды, в которой он функционирует;

· указание основных целей и перечень задач автоматизации;

· описание укрупнённой организационно-функциональной структуры выбранного варианта (вариантов) построения создаваемой системы;

· технико-экономическое обоснование системы;

· укрупнённое описание и основные требования к средствам информационного и лингвистического обеспечения;

· перечень и общие требования к средствам программно-аппаратного обеспечения;

· перечень и укрупнённую характеристику этапов создания системы, сроки их выполнения;

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

2. Техническое задание на систему в целом и (или) её основные составные части (подсистемы, программно-технические комплексы и средства, отдельные задачи и т.д.), выполненное в соответствии с ГОСТ 34.601-90.
3. Эскизное проектирование.При проектировании программного обеспечения системы Эскизный проект должен содержать полную спецификацию разрабатываемых программ.

4. Опытная и промышленная эксплуатация разработанной АИС.

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

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

Поиск по каталогу

Список стандартов

Обновление баз, загрузка модулей

Очистка стоков

ГОСТ 34.601-90

ГОСТ 34.601-90

Общие сведения о технологии проектирования ИС

Поделиться…

Поиск по материалам:

Технологии и инструментальные средства проектирования (CASE-средства) составляют основу проекта любой информационной системы (ИС). Каждая технология поддерживается конкретными стандартами, методиками и инструментальными средствами, которые обеспечивают выполнение процессов жизненного цикла (ЖЦ).

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

Технология проектирования, разработки и сопровождения ИС должна удовлетворять следующим требованиям:

• поддерживать полный ЖЦ ИС;
• обеспечивать гарантированное достижение целей разработки ИС с заданным качеством и в установленное время;
• обеспечивать возможность выполнения крупных проектов в виде подсистем;
• предусматривать возможность управления конфигурацией проекта, ведение версий проекта, возможность автоматического выпуска проектной документации;
• обеспечивать независимость выполняемых проектных решений от средств реализации ИС (СУБД, ОС, языков программирования);
• поддерживаться комплексом согласованных CASE-средств, обеспечивающих автоматизацию процессов, выполняющихся на всех стадиях ЖЦ.

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

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

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

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

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

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

Существует несколько моделей ЖЦ ИС, которые отличаются различным количеством этапов и их содержанием: каскадная, спиралевидная, непрерывной разработки, быстрого прототипирования fast track и др. Выбор модели определяется сложностью ИС, ее масштабом, желанием заказчика и т.д. Каждая из ведущих фирм разработчиков CASE-средств и СУБД име-ют свой набор моделей ЖЦ, этапы которых обеспечиваются программным инструментарием.

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

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

Основной недостаток этой модели ЖЦ в том, что реальный процесс создания ИС никогда полностью не укладывается в такую жесткую схему:«Все работы должны выполняться на каждом этапе сразу и за один раз».

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

Для преодоления этих проблем была предложена спиральная (спиралевидная) модель ЖЦ (рис. 1), которая делает основной упор на начальные этапы ЖЦ: анализ и проектирование.

Рис. 1. Спиральная модель ЖЦ ИС

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

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

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

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