Моделирование на uml с помощью doors/Analyst

DOORS/Analyst позволяет создавать UML модели и диаграммы непосредственно в формальных модулях DOORS, размещая их внутри объектов. Более того, такие объекты могут быть помечены как элементы UML, например актеры, классы, состояния. И тогда, если какие-либо диаграммы с помощью опций главного меню вызываются и вставляются в модуль DOORS, то объекты, помеченные таким образом синхронизируются с элементами, которые появляются в диаграммах. Немаловажный результат такого подхода – возможность иметь трассировку требований вплоть до элементов внутри диаграммы. DOORS/Analyst это результат интеграции DOORS с продуктом Telelogic TAU G2 (системой моделирования на UML).

Начало документа

7. Стандарты и проектирование ИС

1. Назначения стандартов

2. Стандарты CDM, ISO-12207, ГОСТ 34 и их характеристики

3. Назначения и содержание профилей

4. Сравнения стандартов проектироваие

7. 1.Назначения стандартов

Без стандартов невозможно осуществлять процесс проектирования Следования стандартов дает возможность всем разработчикам находиться в едином правом полем. В связи с сложностью разрабатываемых проектов длительностью их разработки возникает проблема применения соответствующих стандартов.

CDM позволяет разрабатывать прикладные, не сложные информационные системы на базе инструментариями Oracle

ISO/IEC 12207 который направлен на реализацию ЖЦ. Создание ПО.

ГОСТ 34 создание и развитие ИС по каскадной модели и проектной документации. Он применим для любых ИС.

Стандарты различаються :

- по детализации требований

- по открытости, по адаптируемой

- степень организации ЖЦ под предметную область

- прикладной областью, то есть ОУ

Начало документа

7.2. Стандарты cdm, iso-12207, гост 34 и их характеристики Методология Oracle cdm

• Стандарт, детализированный до уровня заготовок проектных документов, рассчитанных на прямое использование в проектах ИС с реализацией на инструментальных средствах Oracle;

• ориентирован на поддержку деятельности разработчика

RD - Определение производственных

требований,

• ES - Исследование существующих систем,

• TA - Определение технической архитектуры,

• DB - Проектирование и построение БД,

• MD - Проектирование и реализация модулей,

• CV - Конвертирование данных,

• DO - Документирование,

• TE - Тестирование,

• TR - Обучение,

• TS - Переход к новой системе,

• PS - Поддержка и сопровождение.

Доработка

AIM (Applications Implementation Method, Метод внедрения приложений) - представляет собой детальное описание задач, выполняемых в ходе проекта, с указанием последовательности выполнения и ответственных ролей проектной группы, разделяет доработку: •

при «нехватке» возможностей приложения, касающихся функциональности

• при «нехватке» возможностей приложения, касающихся отчетов

• при «нехватке» возможностей приложения по предоставлению/ограничению доступа к функциям и данным,

• при разработке программ автоматической конвертации (программ переноса бизнес-данных в новое приложение).

Доработка основного функционала BR.020 – BR.080 – MD.020

BR.020 – выявление «дыр» функциональности приложения, предварительное формулирование решения, как можно устранить «дыры»

• BR.080 – первоначальная оценка предложенного предварительного решения

• MD.020 – окончательное формулирование решения, как можно устранить «дыры», оценка трудозатрат

Последовательности задач Oracle CDM

RD.020 – RD.030 – RD.070 – BR.020 – BR.080 – MD.020 –MD.060 – DO.070 – TE.110 – PM.050 – CV.140 – PM.080,где

• RD.020 – изучение существующих бизнес-процессов

• RD.030 – моделирование будущих бизнес-процессов

• RD.070 – выявление детальных требований к будущим бизнес-процессам

• BR.020 – отображение бизнес-процессов в функциональность приложения

• BR.080 – тестирование принятых решений

MD.020 – оценка решений по доработке функциональности приложения

• MD.060 – дизайн расширений функциональности приложения

• DO.070 – разработка инструкций пользователя

• TE.110 – тестирование приложения

• PM.050 – установка приложения на систему периода эксплуатации

• CV.140 – ввод начальных данных

• PM.080 – запуск новой системы

Степень адаптивности Oracle CDM

ограничивается тремя разновидностями каскадной модели ЖЦ:"классическая" (предусмотрены все работы/задачи и этапы),"быстрая разработка" (Fast Track) (еще более сильно ориентированная на использование инструментов моделирования и программирования Oracle), "облегченный подход" (рекомендуемый в случае малых проектов и возможности быстро прототипировать приложения).

Методика не предусматривает:

• включение дополнительной задачи, которой нет в CDM, и ее привязку к остальным;

• удаление задачи (и порождаемых ею документов);

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

Степень обязательности Oracle CDM

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

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

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

Начало документа

ISO 12207

• определяет процессы ЖЦ. Состоит из крупных обобщенных процессов: "приобретение", "поставка", "разработка" и т. п.

• каждый процесс разделен на набор действий, каждое действие - на набор задач.

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

• заранее определенных последовательностей нет Равносильно ориентирован на организацию действий каждой из двух сторон: поставщик (разработчик) и покупатель (пользователь).

Содержание основных процессов ISO/IEC 12207

приобретение – определяет действия предприятия- покупателя, которое приобретает ИС, программный продукт или сервис ПО;

поставка – определяет действия предприятия-поставщика, которое снабжает покупателя системой, программным продуктом или сервисом ПО;

разработка – определяет действия предприятия- разработчика, которое разрабатывает принцип построения программного изделия и программный продукт;

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

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

Содержание основных процессов ЖЦ ИС (ISO/IEC 12207)

Процесс (исполнитель процесса)	Действия	Вход	Результат
Приобретение (заказчик)	•Инициирование	• Решение о начале	• Технико-
	•Подготовка	работ по внедрению ИС	экономическое
	заявочных	• Результаты	обоснование внедрения
	предложений	обследования	ИС
	• Подготовка	деятельности заказчика	• Техническое задание
	договора	• Результаты анализа	на ИС
	• Контроль	рынка ИС тендера	• Договор на
	деятельности	• План	поставку/разработку
	поставщика	поставки/разработки	• Акты приемки этапов
	• Приемка ИС	• Комплексный тест ИС	работы • Акт приемо-сдаточных испытаний

Процесс (исполнитель процесса)	Действия	Вход	Результат
Разработ- ка (разработ- чик ИС)	• Подготовка • Анализ требовании к ИС •Проектирование архитектуры ПС • Разработка требований к ПО •Проектирование архитектуры ПО • Детальное проектирование ПО · Кодирование и тестирование ПО · Интеграция ПО и квалификационное тестирование ПО · Интеграция ИС и квалификационное тестирование ИС	• Техническое задание на ПС • Техническое задание на ИС, модель ЖЦ • Техническое задание на ПС • Подсистемы ИС • Спецификации требования к компонентам ПО • Архитектура ПО · Материалы детального проектирования ПО · План интеграции ПО, тесты · Архитектура ИС, ПО, документация на ИС, тесты	• Используемая модель ЖЦ. стандарты разработки • План работ • Состав подсистем, компоненты оборудования • Спецификации требования к компонентам ПО • Состав компонентов ПО. интерфейсы с БД. план интеграции ПО • Проект БД, спецификации интерфейсов между компонентами ПО, требования к тестам · Тексты модулей ПО, акты автономного тестирования · Оценка соответствия комплекса ПО требованиям ТЗ · Оценка соответствия ПО, БД, технического комплекса и комплекта документации требованиям ТЗ

Степень адаптивности ISO 12207

• степень адаптивности: максимальная. Множество процессов и задач сконструировано так, что возможна их адаптация в соответствии с проектами ПО. Процесс адаптации является процессом исключения процессов, видов деятельности и задач, не применимых в конкретном проекте;

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

• позволяет реализовывать любую модель ЖЦ – один процесс при необходимости вызывает другой или его часть.

Степень обязательности ISO 12207

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

• стандарт не предписывает конкретную модель ЖЦ или метод разработки, но определяет, что стороны-участники использования стандарта ответственны за выбор модели ЖЦ для проекта, за адаптацию процессов и задач стандарта к этой модели, за выбор и применение методов разработки, за выполнение действий и задач, подходящих для проекта;

• стандарт ориентирован на различные виды ПО и типы проектов ИС, куда ПО входит как часть; содержит предельно мало описаний, направленных на проектирование БД.