36) Ограничения методологии rad///

Следует, однако, отметить, что методология RAD, как и любая другая, не может претендовать на универсальность, она хороша в первую очередь для относительно небольших проектов, разрабатываемых для конкретного заказчика. Если же разрабатывается типовая система, которая не является законченным продуктом, а представляет собой комплекс типовых компонент, централизованно сопровождаемых, адаптируемых к программно-техническим платформам, СУБД, средствам телекоммуникации, организационно-экономическим особенностям объектов внедрения и интегрируемых с существующими разработками, на первый план выступают такие показатели проекта, как управляемость и качество, которые могут войти в противоречие с простотой и скоростью разработки. Для таких проектов необходимы высокий уровень планирования и жесткая дисциплина проектирования, строгое следование заранее разработанным протоколам и интерфейсам, что снижает скорость разработки.

Методология RAD неприменима для построения сложных расчетных программ, операционных систем или программ управления космическими кораблями, т.е. программ, требующих написания большого объема (сотни тысяч строк) уникального кода.

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

37) Корпоративные стандарты – соглашения о единых правилах организации технологии управления. При этом на основе корпоративных применяются отраслевые национальные стандарты (международные и т.д.) Высокая динамика развития приводит к устарению стандартов т.к. меняются требования к функции , в этих условиях применение классических способов разработки малоэффектны. Полезные стандарты открытых систем на пример стандарты взаимодействий . Разработка требует новых методов включая ПО требуется адаптивное проектирование , одним из способов является разработка профилей ТУ .Корпоративные стандарты :

1. стандарты на продукты и услуги

2. на процессы и технологии

3. на формы коллективной деятельности

38) Классификация стандартов для ИТ:

1.по предмету стандартизации

-функциональные стандарты

-стандарты на организацию жизненного цикла

-на создание и использование ИС

2.по утверждающей организации

-национальные

-международные

ведомственные

Госты,ANSI

-стандарты «дефакто» SQL, C

-фирменные стандарты (Майкрософт)

3.По методическому источнику

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

Методика Oracle CDM – разработка ИС под заказ

-ISO/IEC 12207 организация жизненного цикла

-ГОСТ 34 гост ЕСПД

39.Методика Oracle CDM

1.Основу технологии case в инструментальной среде составляет методология структурного нисходящего проектирования.

2. поддержка всех этапов жизненного цикла ИС прикладных систем (с общим описание предметной области)

3. ориентация на организацию приложений в архитектуре клиент-сервер

4.наличие централизованных БД, по управление СУБД ORACLE

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

6.автоматизация последовательных переходов от одного этапа к следующему, для этого предусматриваются специальные утилиты

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

40. Фазы ЖЦ и методика оракл

1.Стратегия (определение требований)

2.анализ (формирование детальных требований к прикладной системе)

3. проектирование – преобразование требований к детальному классу

4. реализация (написание и тестирование прикладной программы)

5.внедрение (установка новой системы ,подготовка специалистов)

6. эксплуатация

7. утилизация

1й этап не являет обязательным (он автоматический)

На втором этапе разрабатываются концептуальные модели

-информационная (отражает структуру и общие закономерности предметной области)

-описывают возможности использования генераторов идей

Процессы методики ОРАКЛ

1.определение производственных потребностей

2.использование существующих систем

3.определение технической архитектуры

4.проектирование и построение БД

5.Конвертирование данных

6.документирование

7.тестирование

8.обучение

9.переход к новой системе

10.поддержка и сопровождение

41) Особенности и ограничения методики Oracle CDM

Отметим основные особенности методики Oracle CDM, определяющие область ее применения и присущие ей ограничения.

-Степень адаптивности CDM ограничивается тремя моделями жизненного цикла:

--классическая - предусматривает все этапы;

--быстрая разработка - ориентированна на использование инструментов моделирования и программирования Oracle;

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

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

-Все модели жизненного цикла являются по сути каскадными.

-Методика не является обязательной, но может считаться фирменным стандартом.

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

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

-Методика Oracle CDM представляет собой вполне конкретный материал, детализированный до уровня заготовок проектных документов, рассчитанных на прямое использование в проектах информационных систем с опорой на инструментальные средства и СУБД фирмы Oracle.

42) Общая структура стандарта ISO 12207

  В стандарте ISO 12207 не предусмотрено каких-либо этапов (фаз или стадий) жизненного цикла информационной системы. Данный стандарт определяет лишь ряд процессов, причем по сравнению с Oracle CDM стандарт ISO 12207 состоит из гораздо более крупных обобщенных процессов: приобретение, поставка, разработка и т. п. Несколько утрируя, можно сказать, что один процесс ISO 12207 сопоставим со всеми процессами Oracle CDM вместе взятыми.      Согласно ISO 12207, каждый процесс подразделяется на ряд действий, а каждое действие - на ряд задач.      Очень важной особенностью ISO 12207 по сравнению с CDM является то, что каждый процесс, действие или задача инициируются и выполняются другим процессом по мере необходимости, причем нет заранее определенных последовательностей (естественно, при сохранении логики связей по исходным сведениям задач и т. п.).

43) Основные и вспомогательные процессы жизненного цикла стандарта ISO 12207

 В стандарте ISO 12207 описаны пять основных процессов жизненного цикла программного обеспечения:

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

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

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

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

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

 Кроме основных, стандарт ISO 12207 оговаривает 8 вспомогательных процессов:

-процесс решения проблем;

-процесс документирования;

-процесс управления конфигурацией;

-процесс обеспечения качества;

-процесс верификации;

-процесс аттестации;

-процесс совместной оценки;

-процесс аудита.