Глава 3. Сравнительный анализ стандартов на организацию
Жизненного цикла создания и использования ИС.
Профили стандартов
Все существующие стандарты в области информационных технологий можно сгруппировать по трем следующим критериям: по предмету стандартизации, по утверждающей организации и по методическому источнику [9]. В свою очередь стандарты сгруппированные по предмету стандартизации, можно разделить на две группы: функциональные стандарты (стандарты на языки программирования, интерфейсы и протоколы) и стандарты на организацию жизненного цикла создания и использования ИС и ПО.
В стандартах жизненного цикла обобщен опыт и результаты исследований нескольких поколений специалистов и рекомендуются современные методы и процессы создания и развития прикладных систем. Стандарты ЖЦ могут использоваться как непосредственные директивные, руководящие или рекомендательные документы, а также как организационная база при автоматизации технологических этапов или процессов. Стандартизация процессов ЖЦ ИС отражается не только на их технико-экономических показателях, но и в первую очередь на качестве и надежности создаваемых ИС [17].
ЖЦ в стандартах отражается набором этапов, частных работ и операций, выполняемых в определенной последовательности и взаимосвязи на всех стадиях от подготовки технического задания до завершения испытаний версий и окончания эксплуатации ИС.
Стандарты включают описания исходной информации, способов и методов выполнения операций и работ, устанавливают требования к результатам и правилам их контроля, а также регламентируют содержание технологических и эксплуатационных документов на ИС. Кроме этого, они определяют организационную структуру, обеспечивают распределение и планирование работ, а также контроль за ходом разработки.
Например, в первом стандарте жизненного цикла DOD - STD -2167А, который был разработан в 1985 году для проектирования программных средств систем военного назначения по заказам Министерства обороны США, регламентировано 8 этапов ЖЦ и около 250 типов обязательных требований к процессам и объектам проектирования на всех этапах разработки.
В общих требованиях представлены планирование и управление разработкой ИС, правила взаимодействия с субподрядчиками и испытателями, а также документирование результатов. Изложены общие требования к технологии и средствам автоматизации разработки программ, к структуре и организации комплекса программ и поддерживающей его базы данных.
Специальный раздел посвящен требованиям к квалификационным испытаниям, к средствам и организации тестирования программ на всех этапах разработки. Изложены требования к организации, выполнению и документированию оценок качества программной продукции.
В России создание и испытание ИС регламентированы стандартами серии 34: ГОСТ 34.601-90 (Стадии создания АС), ГОСТ 34.602-89 (ТЗ на создание АС), ГОСТ 34.603-92 (Виды испытаний АС), РД 50-34.698-90 (Требования к содержанию документов). Однако создание, сопровождение и развитие ИС в этих стандартах отражено слабо, отдельные их положения устарели с точки зрения построения и обработки данных.
Проектирование и информационная поддержка организации разработки ИС, включая программное обеспечение и базы данных, традиционно поддерживается многими стандартами и фирменными методиками. Поэтому для каждого серьезного проекта требуется тщательный подбор и правильное применение базовых стандартов и нормативных документов.
Правильно выбрать базовые стандарты из нескольких сотен стандартов, действующих в сфере информационных технологий, достаточно сложно и ответственно, поскольку степень адаптации стандартов к создаваемым ИС обычно недостаточна и не покрывает полностью потребности в стандартизации объектов и процессов создания систем и их компонентов. Кроме этого, надо иметь ввиду предпочтение в этом вопросе заказчика, самих разработчиков и реальное состояние проекта (новая разработка, адаптация типового проекта или модификация действующей ИС).
Для сокращения стоимости и обеспечения качества создаваемой ИС выбранный стандарт ЖЦ следует адаптировать к индивидуальному проекту ИС. Должны быть определены характеристики окружения проекта, которые могут воздействовать на адаптацию. Этими характеристиками могут быть: функции ЖЦ ИС; требования к системе и программному обеспечению; организационные основы коллективов специалистов, процедуры и стратегии их работы; размер, критичность и типы систем; число задействованного персонала и сторон-участников [17].
В процессе адаптации стандарта ЖЦ должны быть включены особенности пользователей, поддерживающего персонала, потенциальных покупателей. Все решения по адаптации стандарта должны быть задокументированы вместе с обоснованием их целесообразности и поддержаны комплексом наиболее эффективных инструментальных средств.
Одним из наиболее распространенных способов адаптации стандартов является разработка и применение профилей стандартов ЖЦ, под которыми понимают совокупность нескольких базовых стандартов и других нормативных документов с четко определенными и гармонизированными подмножествами обязательных и факультативных возможностей, или группы функций ISO/IECTR 10000.
Поэтому представляется полезным провести сравнение по основным характеристикам трех наиболее популярных стандартов, которые при этом максимально отличаются друг от друга назначением применения, содержанием и степенью адаптивности к создаваемым проектам. Первый – это современный, модный стандарт ISO / IEC 12207:1995-08-01 на организацию ЖЦ продуктов программного обеспечения, который имеет максимальную степень адаптивности и характеризуется как инструкция участникам разработки, содержащая всю информацию только о том, «что надо сделать». Второй стандарт, выбранный для сравнения – комплекс российских стандартов ГОСТ 34, который считается достаточно устаревшим, но полезным с тех позиций, что в нем детально прописано «как надо делать», и он имеет высокую степень адаптивности. И наконец, в качестве третьего стандарта выбрана методология Oracle CDM, которая подробнейшим образом описывает действия участников разработки на уровне этапов, процессов и задач, но степень адаптивности минимальна: используется только для программного инструментария фирмы Oracle и не допускает никаких изменений в содержании и составе этапов, процессов и задач. Предназначается для разработки информационных систем под заказ и представляет собой конкретный материал, детализированный до уровня заготовок проектных документов, рассчитанных на прямое использование в проектах ИС с опорой на инструментарий Oracle.
Методология Oracle CDM
Методика Oracle CDM возникла как развитие давно разработанной версии Oracle CASE-Method (ныне Designer/2000). CDM самым тесным образом опирается на использование инструментария Oracle, хотя имеются утверждения о возможности приспособления CDM к проектам, в которых используется другой инструментальный комплекс.
Общая структура ЖЦ формируется из определенных этапов проекта и процессов, каждый из которых выполняется в течение нескольких этапов, то есть модель ЖЦ имеет двумерную структуру.
Этапы модели ЖЦ CDM :
- «Определение требования (или стратегия)»;
- «Анализ» (формулирование детальных требований к системе);
- «Проектирование» (преобразование требований в детальные спецификации системы);
- «Реализация» (написание и тестирование приложений);
- «Внедрение» (установка новой ИС, подготовка к началу эксплуатации);
- «Эксплуатация» (поддержка и слежение за приложением, планирование будущих функциональных решений).
Процессы модели ЖЦ CDM: Определение производственных требований, Исследование существующих систем, Определение технической архитектуры, Проектирование и построение БД, Проектирование и реализация модулей, Конвертирование данных, Документирование, Тестирование, Обучение, Переход к новой системе, Поддержка и сопровождение.
Каждый процесс декомпозируется на последовательность задач, которые размещаются на диаграммах в хронологическом порядке их выполнения. При этом задачи различных процессов взаимосвязаны с помощью явно указанных ссылок.
CDM наиболее сильно связана с методикой Oracle PJM по организации управления проектом.
Степень адаптивности CDM ограничивается тремя моделями ЖЦ: Классическая (Classic) – предусмотрены все работы/задачи и этапы; Быстрая разработка (Fast Track) – присутствует три этапа, еще в большей степени ориентирована на использование инструментов моделирования и программирования Oracle; Облегченный подход (Lite) – содержит только два этапа, отсутствуют два процесса (исследование существующих систем и конвертирование данных), рекомендуется в случае малых проектов и возможности быстрого прототипирования приложения.
Классическая модель ЖЦ относится к каскадной, а Fast Track и Lite – к моделям ЖЦ быстрого прототипирования.
Методика CDM не предусматривает удаление задач или включение дополнительных задач, а также и изменение последовательности выполнения задач особенно по ходу процесса проектирования.
Дата добавления: 2019-07-17; просмотров: 225; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!