12. Назначение стандартов проектирования и их виды.

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

Аналитики отмечают следующие назначения существующих стандартов:

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

- международный стандарт ISO/IEC 12207: 1995-08-01 направлен на организацию жизненного цикла создания продуктов программного обеспечения информационной системы;

- стандарты комплекса ГОСТ 34 на создание и развитие АС – обобщенные, но весьма жесткие по структуре жизненного цикла и проектной документации.

13. Необходимость формирования требований к ис

Быстрое и качественное выполнение проекта на ИС требует сокращения длительности разработки, ее стоимости, высокое качество проектирования.

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

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

Таким образом, без относительно стабильных базовых и согласованных требований проект не может быть реализован.

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

Следовательно, требования являются базой для:

- планирования проекта;

- управления рисками;

- приемочного тестирования;

- компромиссов и согласований;

- управления изменениями.

Причины провалов проекта:

- неполнота требований;

- недостаточное привлечение пользователей;

-недостаток в ресурсах;

- нереалистические ожидания;

- недостаток поддержки от руководства;

- изменение требований/спецификаций;

- недостаточное планирование;

- потеря необходимости реализации проекта;

Эти причины связаны с тем, что:

1. Требования плохо написаны, слабо связаны с запросами и потребностями пользователей, быстро изменяются;

2. Недостаточность ресурсов, плохое планирование и управление требованиями.

Факторы успехов проектов

1. Вовлечение пользователей;

2. Поддержка руководства;

3. Четкая и ясная постановка требований;

4. Хорошее планирование работ;

5. Частые контрольные точки;

6. Компетентная команда.

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