Проектирование системы. Проектирование систем. Проектирование информационных систем ( на примере методов структурного системного анализа)
 Скачать 1.64 Mb.
|
|
2.2. Стандарты на процессы ЖЦ ИС ISO/IEC 12207 (по определению) – базовый стандарт на процессы ЖЦ ИС, ориентированный на различные типы проектов ИС. В стандарте не преду- смотрено каких-либо этапов ЖЦ ИС, а определен лишь ряд процессов. Стан- дарт позволяет реализовать любую модель ЖЦ. ГОСТ 34.601-90 – распространяется на АИС и устанавливает стадии и этапы их создания, содержит описание содержания работ на каждом этапе. Стандарт ориентирован на использование каскадной модели ЖЦ. ISO/IEC 12207:1995-08- 01 и сопутствующие стандарты Первая редакция ISO 12207 была подготовлена в 1995 г. объединенным техническим комитетом ISO/IEC JTC1 «Информационные технологии, подко- митет SC7, проектирование программного обеспечения». Международный стандарт ISO/IEC 12207 является основным норматив- ным документом, регламентирующим ЖЦ ПО. Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО. Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки ПО. Способы выполнения действий задач, включенных в перечисленные процессы, могут быть любыми. В соответствии с базовым международным стандартом ISO/IEC 12207 все процессы ЖЦ ПО делятся на три группы. 87 I. Основные процессы: 1) процесс приобретения – определяет действия предприятия-покупателя; 2) процесс поставки – определяет действия предприятия-поставщика; 3) процесс разработки – определяет действия предприятия-разработчика; 4) процесс функционирования – определяет действия предприятия- оператора, которое обеспечивает обслуживание системы в целом (а не только ПО) в процессе ее функционирования в интересах пользовате- ля; 5) процесс сопровождения – определяет действия персонала, обеспечи- вающего сопровождение программного продукта, т.е. управление мо- дификациями, поддержку текущего состояния и функциональной при- годности. Сюда же относится установка программного изделия на вы- числительной системе и его удаление. II. Вспомогательные процессы – предназначены для поддержки выпол- нения основных процессов, обеспечения качества проекта, организации вери- фикации, проверки и тестирования ПО: 1) процесс документирования; 2) процесс управления конфигурацией; 3) процесс обеспечения качества; 4) процесс верификации; 5) процесс аттестации; 6) процесс аудита; 7) процесс совместной оценки; 8) процесс решения проблем. 88 III. Организационные процессы – определяют действия и задачи, вы- полняемые как заказчиком, так и разработчиком проекта для управления свои- ми процессами: 1) процесс управления; 2) процесс создания инфраструктуры проекта; 3) процесс усовершенствования; 4) процесс обучения. Характеристики стандарта ISO/IEC 12207: • динамичность: обеспечивается способом определения последовательно- сти выполнения процессов, при котором один процесс при необходимо- сти вызывает другой или его часть. Это позволяет реализовать любую модель ЖЦ; • адаптивность:стандарт ISO 12207 предусматривает исключение процес- сов, видов деятельности и задач, неприменимых в конкретном проекте. Ниже приведены ориентировочные описания основных процессов ЖЦ (табл. 2.1. – 2.3.). Таблица 2.1. Ориентировочное описание процесса приобретения. Исполнитель – Заказчик Вход Действия Выход 1. Решение о начале работ по внедрению ИС. 2. Результаты обследования деятельности заказчика. 3. Результаты анализа рынка ИС/ тендера. 4. План поставки/ разработки. 5. Комплексный тест ИС. 1. Инициирование. 2. Подготовка заявочных предложений. 3. Подготовка договора. 4. Контроль деятельности поставщика. 5. Приемка ИС. 1. Технико-экономическое обоснование внедрения ИС. 2. Техническое задание на ИС. 3. Договор на поставку/ разра- ботку. 4. Акты приемки этапов работы. 5. Акт приемно-сдаточных ис- пытаний. 89 Таблица 2.2. Ориентировочное описание процесса поставки. Исполнитель – Разработчик ИС Вход Действия Выход 1. Техническое задание на ИС. 2. Решение руководства об участии в разработке. 3. Результаты тендера. 4. Техническое задание на ИС. 5. Разработанная ИС и доку- ментация. 1. Инициирование. 2. Ответ на заявочные предложения. 3. Подготовка договора. 4. Планирование ис- полнения. 5. Поставка ИС. 1. Решение об участии в разработке. 2. Коммерческие предложения/ кон- курсная заявка. 3. Договор на поставку/ разработку. 4. План управления проектом. 5. Акт приемно-сдаточных испыта- ний. Таблица 2.3. Ориентировочное описание процесса разработки. Исполнитель – разработчик ИС Вход Действия Выход 1. Техническое задание на ИС. 2. Техническое задание на ИС, модель ЖЦ. 3. Техническое задание на ИС. 4. Подсистемы ИС. 5. Спецификации требо- вания к компонентам ПО. 6. Архитектура ПО. 7. Материалы детально- го проектирования ПО. 8. План интеграции ПО, тесты. 9. Архитектура ИС, ПО, документация на ИС, тесты. 1. Подготовка. 2. Анализ требований к ИС. 3. Проектирование архи- тектуры ИС. 4. Разработка требований к ПО. 5. Проектирование архи- тектуры ПО. 6. Детальное проектиро- вание ПО. 7. Кодирование и тести- рование ПО. 8. Интеграция ПО и ква- лификационное тести- рование ПО. 9. Интеграция ИС и ква- лификационное тести- рование ИС. 1. Используемая модель ЖЦ, стандарты разработки. 2. План работ. 3. Состав подсистем, компоненты обо- рудования. 4. Спецификации требования к компо- нентам ПО. 5. Состав компонентов ПО, интерфейсы с БД, план интеграции ПО. 6. Проект БД, спецификации интерфей- сов между компонентами ПО, требо- вания к тестам. 7. Тексты модулей ПО, акты автоном- ного тестирования. 8. Оценка соответствия комплекса ПО требованиям ТЗ. 9. Оценка соответствия ПО, БД, техни- ческого комплекса и комплекта до- кументации требованиям ТЗ. Для поддержки практического применения стандарта ISO/IEC 12207 раз- работан ряд технологических документов: • руководство для ISO/IEC 12207 (ISO/IEC TR 15271:1998 Information tech- nology – Guide for ISO/IEC 12207); • руководство по применению ISO/IEC 12207 к управлению проектами (ISO/IEC TR 16326:1999 Software engineering – Guide for the application of ISO/IEC 12207 to project management). 90 Позднее был разработан и в 2002 г. опубликован стандарт на процессы ЖЦ систем ISO/IEC 15288 (System life cycle processes). При создании стандар- та был учтен практический опыт создания систем в правительственных, ком- мерческих, военных и академических организациях. К разработке стандарта были привлечены специалисты различных областей: системной инженерии, программирования, управления качеством, человеческими ресурсами, безопас- ностью и пр. Стандарт применим для широкого класса систем, но его основное предназначение – поддержка создания компьютеризированных систем. Согласно стандарту ISO/IEC серии 15288 в структуру ЖЦ следует вклю- чать следующие группы процессов: договорные процессы: • приобретение (внутренние решения или решения внешнего по- ставщика); • поставка (внутренние решения или решения внешнего поставщика). процессы предприятия: • управление окружающей средой предприятия; • инвестиционное управление; • управление ЖЦ ИС; • управление ресурсами; • управление качеством. проектные процессы: • планирование проекта; • оценка проекта; • контроль проекта; • управление рисками; • управление конфигурацией; • управление информационными потоками; • принятие решений. технические процессы: 91 • определение требований; • анализ требований; • разработка архитектуры; • внедрение; • интеграция; • верификация; • переход; • аттестация; • эксплуатация; • сопровождение; • утилизация. специальные процессы: определение и установка взаимосвязей исходя из задач и целей. Стадии создания системы, предусмотренные ISO/IEC 15288: 1) формирование концепции – анализ потребностей, выбор концепции и проектных решений; 2) разработка – проектирование системы; 3) реализация – изготовление системы; 4) эксплуатация – ввод в эксплуатацию и использование системы; 5) поддержка – обеспечение функционирования системы; 6) снятие с эксплуатации – прекращение использования, демонтаж, архивирование системы. ГОСТ 34.601-90 (каноническое проектирование) Комплекс стандартов ГОСТ 34 задумывался в конце 80-х годов как всеобъ- емлющий комплекс взаимоувязанных межотраслевых документов. Основной целью комплекса было разрешение противоречий, возникающих при интеграции систем вследствие несогласованности нормативно-технической документации. 92 В 80-х годах действовали следующие комплексы и системы стандартов, устанавливающие требования к различным видам АС: • единая система стандартов АСУ (24-я система) для АСУ, ОАСУ (отрас- левая АСУ), АСУП, АСУТП и других организационно-экономических систем; • комплекс стандартов системы 23501, распространявшихся на системы ав- томатизированного проектирования (САПР); • четвертая группа 1-й системы стандартов, распространявшихся на авто- матизированные системы технологической подготовки производства (АСТПП). Несмотря на общие понятия, требования стандартов не были согласованы между собой, имелись различия по составу и содержанию работ, обозначениям и оформлению документов. В этих условиях было решено выработать одну обобщенную понятийную и терминологическую систему, общую схему разра- ботки, общий набор документов и их содержания и определить их как обяза- тельные для всех АИС. В этом смысле комплекс стандартов ГОСТ 34 более близок к схемам кон- кретных методик, чем к стандартам типа ISO 12207. Объектами стандартиза- ции являются автоматизированные системы различных видов и все виды их компонентов, а не только ПО и БД. Комплекс рассчитан на взаимодействие заказчика и разработчика. При этом, аналогично ISO 12207 в нем предусмотрено, что заказчик может разраба- тывать АС сам для себя, например, создав для этого специализированное под- разделение. ГОСТ 34 уделяет основное внимание содержанию проектных до- кументов, а распределение действий между сторонами обычно производятся исходя из этого содержания. Наиболее популярными в группе ГОСТ 34 можно считать следующие стандарты: • ГОСТ 34.601-90 (стадии и этапы создания автоматизированной системы); 93 • ГОСТ 34.602-89 (техническое задание на создание автоматизированной системы); • методические указания РД 50-34.698-90 (требования к содержанию доку- ментов). Согласно ГОСТ 34.601-90 разработка ИС разбивается на следующие ста- дии: 1) формирование требований к ИС: 1.1) обследование объекта и обоснование необходимости создания ИС; 1.2) формирование требований пользователя к ИС; 1.3) оформление отчёта о выполненной работе и заявки на разработку ИС (тактико-технического задания); 2) разработка концепции ИС: 2.1) изучение объекта; 2.2) проведение необходимых научно-исследовательских работ; 2.3) разработка вариантов концепции ИС, удовлетворяющего требовани- ям пользователя; 2.4) оформление отчёта о выполненной работе; 3) техническое задание – разработка и утверждение технического задания на создание ИС; 4) эскизный проект: 4.1) разработка предварительных проектных решений по системе и её ча- стям, а именно: • по функционально-алгоритмической структуре системы; • по функциям персонала и организационной структуре; • по структуре технических средств; • по алгоритмам решения задач и применяемым языкам; • по организации и ведению информационной базы; • по системе классификации и кодирования информации; • по программному обеспечению; 94 4.2) разработка документации на ИС и её части. 5) технический проект: 5.1) разработка проектных решений по системе и её частям; 5.2) разработка документации на ИС и её части; 5.3) разработка и оформление документации на поставку изделий для комплектования ИС и (или) технических требований (технических зада- ний) на их разработку; 5.4) разработка заданий на проектирование в смежных частях проекта объекта автоматизации. 6) рабочая документация: 6.1) разработка рабочей документации на систему и её части; 6.2) разработка или адаптация программ. 7) ввод в действие: 7.1) подготовка объекта автоматизации к вводу ИС в действие; 7.2) подготовка персонала; 7.3) комплектация ИС поставляемыми изделиями (программными и тех- ническими средствами, программно-техническими комплексами, инфор- мационными изделиями); 7.4) строительно-монтажные работы; 7.5) пусконаладочные работы; 7.6) проведение предварительных испытаний; 7.7) проведение опытной эксплуатации; 7.8) проведение приёмочных испытаний; 8) сопровождение ИС: 8.1) выполнение работ в соответствии с гарантийными обязательствами; 8.2) послегарантийное обслуживание. Виды документов, разрабатываемых на стадиях «Эскизный проект», «Технический проект», «Рабочая документация»: • «ведомость» – перечисление в систематизированном виде объектов, предметов и т.д.; 95 • «схема» – графическое изображение форм документов, частей, элементов системы и связей между ними в виде условных обозначений; • «инструкция» – изложение состава действий и правил их выполнения персоналом; • «обоснование» – изложение сведений, подтверждающих целесообраз- ность принимаемых решений; • «описание» – пояснение назначения системы, ее частей, принципов их действия и условий применения; • «конструкторский документ» – по ГОСТ 2.102; • «программный документ» – по ГОСТ 19.101. В зависимости от сложности объекта автоматизации и набора задач, тре- бующих решения при создании конкретной ИС, стадии и этапы работ могут иметь различную трудоемкость. ГОСТ 34 допускает объединение последовательных этапов и даже ис- ключение некоторых из них на любой стадии проекта. Допускается исключить стадию «Эскизный проект» и отдельные этапы работ на всех стадиях, объеди- нять стадии «Технический проект» и «Рабочая документация» в одну стадию «Технорабочий проект». В зависимости от специфики создаваемых АС и условий их создания до- пускается выполнять отдельные этапы работ до завершения предшествующих стадий, параллельное во времени выполнение этапов работ, включение новых этапов работ. Стадии и этапы, выполняемые организациями-участниками, прописыва- ются в договорах и технических заданиях на выполнение работ. 96 2.3. Документирование проекта Назначение документации Документация входит в состав проекта по созданию, внедрению, сопро- вождению, модернизации и ликвидации ИС на протяжении полного жизненно- го цикла этой ИС. Документация необходима: • для обеспечения эффективных и экономичных процедур разработки, со- провождения и использования программных средств и всей ИС; • для организации обмена информацией между управляющим персоналом, разработчиками, администратором, пользователями ИС, а также другими, не предусмотренными проектом лицами и группами (инспектирующими структурами и т.п.) на всех стадиях жизненного цикла (ЖЦ) ИС. Документация выполняет следующие функции: • дает описание возможностей системы, то есть позволяет пользователю определить соответствие программного продукта требованиям, предъяв- ляемым к ИС в целом; • обеспечивает фиксацию принятых и реализованных проектных решений, давая возможность для дальнейшей модификации и совершенствования программного обеспечения ИС; • предоставляет технические материалы для анализа информационной си- стемы на этапах её приобретения и разработки; • предоставляет информацию о процедурах эксплуатации и технического обслуживания ИС; • регламентирует средства и процедуры защиты информации, регулирует права и обязанности различных групп пользователей ИС, условия функ- ционирования ИС, включая вопросы ее модернизации, масштабирования, переносимости и ликвидации. 97 Требования к документации К документации предъявляют следующие требования: 1. документы должны быть ясными, краткими, точными и полными; 2. для повышения эффективности работы с документами должны использо- ваться стандарты, регламентирующие форму, содержание и, иногда, стиль документов; 3. документация должна создаваться параллельно с разработкой ПО; 4. обязанности по документированию системы лежат на ее разработчике, создающем, модернизирующем и привлекающем в проект ИС те или иные программные средства. Особенно важна внешняя документация; 5. документация должна высокий уровень абстракции при возможности четкого и однозначного толкования и достаточности информации об опи- сываемых объектах; 6. перед составлением документации необходимо иметь ответ на следую- щие вопросы: • что и зачем должно быть документировано; • для кого предназначен тот или иной документ; • возможные способы решения тех или иных задач, стоящих перед поль- зователем; • какие ошибки может допустить пользователь, и что нужно сделать для их устранения; • как и в каких условиях будет использоваться документ; • сколько выделено средств, и каковы сроки разработки документа; • кто будет оценивать документ и как он соотносится к отраслевым или ведомственным требованиям на сертификацию разработки; • как будет обновляться и поддерживаться документация и каковы ме- ханизмы и сроки внесения изменений и пересмотра документа; кто от- ветственен за реализацию этих действий, а также за хранение, неиз- 98 менность и контроль за исполнением. Ответы на эти вопросы должны быть получены на ранних стадиях разра- ботки ИС (на стадии разработки технико-экономического обоснования к ТЗ) и входить в состав разрабатываемой в рамках проекта документации. Для повышения эффективности разработки программных изделий (ПИ), а также повышения их качества необходима стандартизация и унификация доку- ментов, описывающих как процедуры работ, так и результаты выполнения ра- бот по созданию программного продукта. С этой целью было разработано не- сколько десятков отечественных государственных стандартов, из которых больше половины были стандартами в рамках Совета экономической взаимо- помощи (СЭВ) бывшего содружества стран социалистического лагеря (СССР и др.), остальные – международными (ISO). Состав программных документов по фазам ЖЦ ИС |