Проектирование системы. Проектирование систем. Проектирование информационных систем ( на примере методов структурного системного анализа)
 Скачать 1.64 Mb.
|
|
Системная документация (классификация документов, существовавшая с 1970 по 1980 годы и не отмененная в настоящее время) по стадиям ЖЦ ИС: постановка задачи: 1) техническое задание (ТЗ), включает в свой состав: технико- экономическое описание проекта (ТЭО); календарный план проек- тирования; сметную калькуляцию проекта; каталожное описание разработки (КО), технические требования (ТТ) и технические усло- вия (ТУ), относящиеся к проектируемому изделию и т.п.; разработка: 2) проектная документация, в составе: проект системы; подготовка данных; разработка программы; реализация испытаний: 3) пособия руководства: руководство пользователя; руководство по 99 обслуживанию; руководство оператора; руководство администра- торов (данных, баз данных, серверного обеспечения, сетевого обес- печения, сервера защиты и т.п.) эксплуатация: 4) реализация: программный код; информация, вызываемая системой; тесты и тестовые прогоны программы; требования, процедуры и условия сертификации продукта. Альтернативный состав документации, предусмотренный действующими стандартами (по стадиям ЖЦ ИС): выработка требований: 1) требования к функциональной структуре; 2) требования к информационной структуре; проектирование: 3) системная спецификация и описание подсистем; 4) программная спецификация; 5) спецификация БД; 6) руководство системных специалистов, администраторов; 7) руководство пользователя, план испытаний; программирование, испытание, сертификация: 8) руководство по эксплуатации; 9) руководство по сопровождению; Единая система программной документации (ЕСПД) ЕСПД – комплекс государственных стандартов Российской Федерации, устанавливающих взаимосвязанные правила разработки, оформления и обра- щения программ и программной документации. В стандартах ЕСПД устанавли- вают требования, регламентирующие разработку, сопровождение, изготовление и эксплуатацию программ. Сопровождение программы включает анализ функ- ционирования, развитие и совершенствование программы, а также внесение 100 изменений в нее с целью устранения ошибок. Различают следующие классифи- кационные группы стандартов ЕСПД: 1) общие положения; 2) основополагающие стандарты; 3) правила выполнения документации при разработке; 4) правила выполнения документации при изготовлении; 5) правила выполнения документации при сопровождении; 6) правила выполнения документации при эксплуатации; 7) правила обращения к программной документации; 8) резервные группы; 9) прочие стандарты. Подразумевается, что за счет единых средств формирования документов, унификации их структуры, последовательности выполнения операций, исполь- зование указанных групп стандартовобеспечиваетвзаимный обмен програм- мами, применение ранее разработанных программ в новых разработках и сни- жение затрат на разработку, оформление и использование программ. Согласно ЕСПД предусмотрен следующий перечень обязательных доку- ментов, входящих в состав ИС: спецификация; ведомость держателей подлин- ников; текст программы – сведения о логической структуре и функции про- грамм. Программа и методика испытаний в составе этого пакета документов отображает требования, подлежащие проверке, а также методы контроля. В техническом задании (ТЗ) обосновываются назначение и области приме- нения программы, технические, технико-экономические и специальные требова- ния, необходимые стадии и сроки разработки, виды испытаний. Каждая созданная или привлеченная в проект программа сопровождается пояснительной запиской, в которой наряду с ее обобщенным описанием приводятся схема алгоритма и общее описание алгоритма и функция программы, а также обоснование принятых реше- ний. Эта записка входит в состав расчетно-пояснительной записки к проекту ИС. Эксплуатационные документы содержат сведения необходимые для обеспечения функционирования и эксплуатации системы и включают в состав: 101 ведомость эксплуатационных документов на программу; • формуляр (основные характеристики, комплектность, сведения об экс- плуатации); • описание применения (сведения о назначении, класс задач, область при- менения, используемые методы, организация, минимальная конфигура- ция технических средств, в том числе по вопросам организации АРМ пользователей, серверного хозяйства, маршрутизации, сетевого обеспе- чения, организации бесперебойного энергопитания, средств защиты, пе- риферийных устройств и ТСО); • руководство системного программиста (сведения для проверки, обеспе- чения функционирования и настройки программы); • руководство программиста (сведения для эксплуатации программ); • руководство оператора (сведения для осуществления действий по выпол- нению программой / системой требований); • руководство по техническому обеспечению; • журнал документов; • руководство (инструкции) по сертификации, модернизациям, масштаби- рованию и ликвидации ИС (АСУ) по истечении действия предусмотрен- ного проектом полного жизненного цикла системы; • обучающие и учебно-методические материалы по системе, ознакоми- тельные с ней материалы (демоверсии и их описание); • другие эксплуатационные документы (специального назначения), огово- ренные в ТЗ. Стандарты в составе ЕСПД: • ГОСТ 19.001-77. ЕСПД. Общие положения; • ГОСТ 19.003-80. ЕСПД. Схемы алгоритмов и программ. Обозначения условные графические. Заменен на ГОСТ 19.701-90; • ГОСТ 19.005-85. ЕСПД. Р-схемы алгоритмов и программ. Обозначения условные графические и правила выполнения; 102 • ГОСТ 19.101-77. ЕСПД. Виды программ и программных документов; • ГОСТ 19.102-77. ЕСПД. Стадии разработки; • ГОСТ 19.103-77. ЕСПД. Обозначение программ и программных документов; • ГОСТ 19.104-78. ЕСПД. Основные надписи; • ГОСТ 19.105-78. ЕСПД. Общие требования к программным документам; • ГОСТ 19.106-78. ЕСПД. Требования к программным документам, выпол- ненным печатным способом; • ГОСТ 19.201-78. ЕСПД. Техническое задание. Требования к содержанию и оформлению; • ГОСТ 19.202-78. ЕСПД. Спецификация. Требования к содержанию и оформлению; • ГОСТ 19.301-79. ЕСПД. Программа и методика испытаний. Требования к содержанию и оформлению; • ГОСТ 19.401-78. ЕСПД. Текст программы. Требования к содержанию и оформлению; • ГОСТ 19.402-78. ЕСПД. Описание программы; • ГОСТ 19.403-79. ЕСПД. Ведомость держателей подлинников; • ГОСТ 19.404-79. ЕСПД. Пояснительная записка. Требования к содержа- нию и оформлению; • ГОСТ 19.501-78. ЕСПД. Формуляр. Требования к содержанию и оформ- лению; • ГОСТ 19.502-78. ЕСПД. Описание применения. Требования к содержа- нию и оформлению; • ГОСТ 19.503-79. ЕСПД. Руководство системного программиста. Требо- вания к содержанию и оформлению; • ГОСТ 19.504-79. ЕСПД. Руководство программиста. Требования к содер- жанию и оформлению; • ГОСТ 19.505-79. ЕСПД. Руководство оператора. Требования к содержа- нию и оформлению; 103 • ГОСТ 19.506-79. ЕСПД. Описание языка. Требования к содержанию и оформлению; • ГОСТ 19.507-79. ЕСПД. Ведомость эксплуатационных документов; • ГОСТ 19.508-79. ЕСПД. Руководство по техническому обслуживанию. Требования к содержанию и оформлению; • ГОСТ 19.601-78. ЕСПД. Общие правила дублирования, учета и хранения; • ГОСТ 19.602-78. ЕСПД. Правила дублирования, учета и хранения про- граммных документов, выполненных печатным способом; • ГОСТ 19.603-78. ЕСПД. Общие правила внесения изменений; • ГОСТ 19.604-78. ЕСПД. Правила внесения изменений в программные до- кументы, выполненные печатным способом; • ГОСТ 19.701-90 (ИСО 5807-85). ЕСПД. Схемы алгоритмов, программ, данных и систем. Условные обозначения и правила выполнения. Техническое задание на создание ИС Определение и назначение технического задания На стадии «Техническое задание» разрабатывают Техническое задание (ТЗ) на создание автоматизированной системы в соответствии с требованиями ГОСТ 34.602-89. Техниическое задание (ТЗ, техзадание) – исходный документ для про- ектирования сооружения или промышленного комплекса, конструирования технического устройства (прибора, машины, системы управления и т. д.), раз- работки информационных систем, стандартов либо проведения научно- исследовательских работ (НИР). ТЗ содержит основные технические требова- ния, предъявляемые к сооружению или изделию и исходные данные для разра- ботки. ТЗ на ИС является основным документом, определяющим требования и 104 порядок создания (развития или модернизации – далее создания) ИС, в соответ- ствии с которым проводится разработка ИС и ее приемка при вводе в действие. ТЗ на ИС разрабатывают на систему в целом, предназначенную для рабо- ты самостоятельно или в составе другой системы. Дополнительно могут быть разработаны ТЗ на части ИС: • на подсистемы ИС, комплексы задач ИС и т. п. в соответствии с требова- ниями настоящего стандарта; • на комплектующие средства технического обеспечения и программно- технические комплексы в соответствии со стандартами ЕСКД и СРПП; • на программные средства в соответствии со стандартами ЕСПД; • на информационные изделия в соответствии с ГОСТ 19.201 и научно- технической документацией, действующей в ведомстве заказчика ИС. В ТЗ указываются назначение объекта, область его применения, стадии разработки конструкторской (проектной, технологической, программной и т.п.) документации, её состав, сроки исполнения и т. д., а также особые требования, обусловленные спецификой самого объекта либо условиями его эксплуатации. Как правило, ТЗ составляют на основе анализа результатов предварительных исследований, расчётов и моделирования. Как инструмент коммуникации в связке общения заказчик-исполнитель, техническое задание позволяет обеим сторонам: • представить готовый продукт; • выполнить попунктную проверку готового продукта (приёмочное тести- рование – проведение испытаний); • уменьшить число ошибок, связанных с изменением требований в резуль- тате их неполноты или ошибочности (на всех стадиях и этапах создания, за исключением испытаний); заказчику: • осознать, что именно ему нужно; • требовать от исполнителя соответствия продукта всем условиям, огово- рённым в ТЗ; 105 исполнителю: • понять суть задачи, показать заказчику «технический облик» будущего изделия, программного изделия или автоматизированной системы; • спланировать выполнение проекта и работать по намеченному плану; • отказаться от выполнения работ, не указанных в ТЗ. Разделы технического задания ТЗ на ИС содержит нижеследующие разделы, которые могут быть разделены на подразделы. 1. Общие сведения. 1.1. Полное наименование системы и её условные обозначения. 1.2. Шифр темы или номер договора. 1.3. Наименование организации разработчика и заказчика системы. 1.4. Перечень документов, на основании которых создается система. 1.5. Плановые сроки начала и окончания работы по созданию системы. Начало: __.__.____ Окончание: __.__.____ 1.6.Порядок оформления и предъявления заказчику результатов. 2. Назначение и цели создания (развития) системы. Раздел «Назначение и цели создания (развития) системы» состоит из подразделов. 2.1. Назначение системы – указывают вид автоматизируемой деятельно- сти (управление, проектирование и т. п.) и перечень объектов автома- тизации (объектов), на которых предполагается ее использовать. 2.2. Цели создания системы – приводят наименования и требуемые значе- ния технических, технологических, производственно-экономических или других показателей объекта автоматизации, которые должны быть достигнуты в результате создания АС, и указывают критерии оценки достижения целей создания системы. Цель в технике преду- сматривает положительную динамику, изменение текущего состояния 106 чего-либо в сторону улучшения, удовлетворения определенных по- требностей или требований. Измеримость цели предполагает, что по описанию цели можно легко определить, насколько ее достижение улучшит текущее состояние. Цель в технике часто ошибочно иденти- фицируют с задачей. Например, «цель – строительство нового много- этажного жилого дома». На самом деле, «строительство многоэтажно- го жилого дома» – задача, цель – прибыль, а миссия – «повышение благосостояния граждан». Пример целей и задач создания автомати- зированной системы учета: «Целями создания автоматизированной системы учета являются: 1) повышение точности учета…; 2) снижение затрат, связанных с…; 3) повышение эффективности…; Задачи создания автоматизированной системы учета: 1) замена устаревших приборов учета на приборы, отвечающие со- временным требованиям; 2) автоматизация процесса измерения учитываемых физических величин; 3) автоматизация процесса консолидации данных об измеренных величинах». 3. Характеристика объектов автоматизации. 4. Требования к системе. 4.1. Требования к системе в целом. 4.1.1. Требования к структуре и функционированию системы – пере- чень подсистем, их назначение и основные характеристики, требо- вания к числу уровней иерархии и степени централизации систе- мы. 4.1.2. Требования к численности и квалификации персонала системы и режиму его работы: • требования к численности персонала (пользователей) АС; 107 • требования к квалификации персонала, порядку его подготовки и контроля знаний и навыков; • требуемый режим работы персонала АС. 4.1.3. Показатели назначения: • степень приспособляемости системы к изменению процессов и методов управления, к отклонениям параметров объекта управ- ления; • допустимые пределы модернизации и развития системы; • вероятностно-временные характеристики, при которых сохраня- ется целевое назначение системы. 4.1.4. Требования к надежности – требования к надежности техниче- ских средств и программного обеспечения. 4.1.5. Требования по безопасности – требования по обеспечению без- опасности при эксплуатации (защита от воздействий электромаг- нитных полей, акустических шумов и т. п.), по допустимым уров- ням освещенности, вибрационных и шумовых нагрузок. 4.1.6. Требования к эргономике и технической эстетике – показатели АС, задающие необходимое качество взаимодействия человека с машиной и комфортность условий работы персонала. 4.1.7. Требования к эксплуатации, техническому обслуживанию, ре- монту и хранению компонентов системы: • виды и периодичность обслуживания ТС системы или допусти- мость работы без обслуживания; • предварительные требования к допустимым площадям для раз- мещения персонала и ТС системы, к параметрам сетей энерго- снабжения и т.п.; • требования по количеству, квалификации обслуживающего пер- сонала и режимам его работы; • требования к составу, размещению и условиям хранения ком- плекта запасных изделий и приборов; 108 4.1.8. Требования к защите информации от несанкционированного до- ступа. 4.1.9. Требования по сохранности информации при авариях – приводят перечень событий: аварий, отказов технических средств (в том числе – потеря питания) и т. п., при которых должна быть обеспе- чена сохранность информации в системе. 4.1.10. Дополнительные требования. 4.2. Требования к функциям (задачам), выполняемым системой. 4.2.1. Перечень функций и задач по каждой подсистеме. 4.2.2. Требования к форме представления выходной информации. 4.2.3. Перечень и критерии отказов для каждой функции, по которой задаются требования по надежности. 4.3. Требования к видам обеспечения. 5. Состав и содержание работ по созданию системы. 6. Порядок контроля и приемки системы. 7. Требования к составу и содержанию работ по подготовке объекта автома- тизации к вводу системы в действие. 8. Требования к документированию. 9. Источники разработки. В подразделе 4.3. «Требования к видам обеспечения» в зависимости от вида системы приводят требования к математическому, информационному, лингвистическому, программному, техническому, метрологическому, органи- зационному, методическому и другие видам обеспечения системы. Для программного обеспечения системы приводят перечень покупных программных средств и требования, предъявляемые к ним. Описание информационного обеспечения содержит следующие разде- лы: • принципы организации ИО; 109 • организация сбора и передачи информации; • построение системы классификации и кодирования; • организация внутримашинной информационной базы; • организация внемашинной информационной базы. Для организационного обеспечения приводят требования: • к структуре и функциям подразделений, участвующих в функционирова- нии системы или обеспечивающих эксплуатацию; • к организации функционирования системы и порядку взаимодействия персонала АС и персонала объекта автоматизации; • к защите от ошибочных действий персонала системы. Для математического обеспечения системы приводят требования к со- ставу, области применения (ограничения) и способам использования в системе математических методов и моделей, типовых алгоритмов и алгоритмов, подле- жащих разработке. В ТЗ на АИС могут включаться приложения. В зависимости от вида, назначения, специфических особенностей объекта автоматизации и условий функционирования системы допускается оформлять разделы ТЗ в виде прило- жений, вводить дополнительные, исключать или объединять подразделы ТЗ. 110 2.4. Технологии поддержки ЖЦ ИС Определение и требования к технологии поддержки ЖЦ ИС Технология проектирования определяется как совокупность трех состав- ляющих: 1) пошаговой процедуры, определяющей последовательность технологиче- ских операций проектирования (рис.); 2) критериев и правил, используемых для оценки результатов выполнения технологических операций; 3) нотаций (графических и текстовых средств), используемых для описания проектируемой системы. Технологические инструкции, составляющие основное содержание тех- нологии, должны состоять из описания последовательности технологических операций, условий, в зависимости от которых выполняется та или иная опера- ция, и описаний самих операций. Технология проектирования, разработки и сопровождения ИС должна удовлетворять следующим общим требованиям: • поддерживать полный ЖЦ ПО; • обеспечивать гарантированное достижение целей разработки ИС с задан- ным качеством и в установленное время; • обеспечивать возможность выполнения крупных проектов в виде подси- стем (т.е. возможность декомпозиции проекта на составные части, разра- батываемые группами исполнителей ограниченной численности с после- дующей интеграцией составных частей). Опыт разработки крупных ИС показывает, что для повышения эффективности работ необходимо раз- бить проект на отдельные слабо связанные по данным и функциям подси- стемы. Реализация подсистем должна выполняться отдельными группами специалистов. При этом необходимо обеспечить координацию ведения общего проекта и исключить дублирование результатов работ каждой 111 проектной группы, которое может возникнуть в силу наличия общих дан- ных и функций; • обеспечивать возможность ведения работ по проектированию отдельных подсистем небольшими группами (3-7 человек). Это обусловлено прин- ципами управляемости коллектива и повышения производительности за счет минимизации числа внешних связей; • обеспечивать минимальное время получения работоспособной ИС. Речь идет не о сроках готовности всей ИС, а о сроках реализации отдельных подсистем. Реализация ИС в целом в короткие сроки может потребовать привлечения большого числа разработчиков, при этом эффект может ока- заться ниже, чем при реализации в более короткие сроки отдельных под- систем меньшим числом разработчиков. Практика показывает, что даже при наличии полностью завершенного проекта, внедрение идет последо- вательно по отдельным подсистемам; • предусматривать возможность управления конфигурацией проекта, веде- ния версий проекта и его составляющих, возможность автоматического выпуска проектной документации и синхронизацию ее версий с версиями проекта; • обеспечивать независимость выполняемых проектных решений от средств реализации ИС (систем управления базами данных (СУБД), опе- рационных систем, языков и систем программирования); • иметь поддержку со стороны согласованных CASE-средств, обеспечива- ющих автоматизацию процессов, выполняемых на всех стадиях ЖЦ. Понятие CASE Первоначально (1980-е) значение термина CASE (Computer Aided Soft- ware/System Engineering ) ограничивалось вопросами автоматизации черчения диаграмм. 112 Современные CASE-средства охватывают обширную область поддержки различных технологий проектирования, покрывающих весь жизненный цикл ПО. В настоящее время к CASE-средствам относят любое программное сред- ство, автоматизирующее ту или иную совокупность процессов ЖЦ ИС, вклю- чая анализ и формулировку требований, проектирование прикладного ПО и баз данных, генерацию кода, тестирование, документирование, обеспечение каче- ства, конфигурационное управление, управление проектом и др. и обладающее следующими основными характерными особенностями: • графические средства для описания и документирования ИС; • удобный интерфейс с разработчиками; • интеграция отдельных компонент, поддерживающих ЖЦ ПО; • использование специальным образом организованного хранилища про- ектных метаданных (репозитория). При этом большую роль играют методы визуального представления ин- формации. Это предполагает построение структурных или иных диаграмм в реальном масштабе времени, использование многообразной цветовой палитры, сквозную проверку синтаксических правил. Классификация CASE-средств Современный рынок программных средств насчитывает около 300 раз- личных CASE-средств, включая как относительно дешевые и ограниченные по возможностям системы для ПК, так и дорогостоящие системы для неоднород- ных вычислительных платформ и операционных сред. Все современные CASE-средства могут быть классифицированы в основ- ном по типам и категориям. |