IDEF0 - стандарт и методология функционального моделирования

 

стратегическое планирование;

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

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

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

аттестационное тестирование на соответствие требованиям и отладка;

внедрение - установка и  ввод системы в действие;

эксплуатация (использование) - - работы по подготовке к внедрению  компонентов ИС в эксплуатацию К  основным направлениям деятельности следует  отнести :

конфигурирование базы данных;

конфигурирование рабочих  мест пользователей;

обеспечение эксплуатационной документацией;

проведение обучения персонала;

локализация проблем и  устранение причин их возникновения;

модификация ИС в рамках установленного регламента;

подготовка предложений  по совершенствованию, развитию и модернизации системы.

сопровождение ИС - обеспечение  штатного процесса эксплуатации системы  на предприятии заказчика

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

 

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

 

 

 

 

 

 

 

 

 

 

 

Жизненный цикл программного обеспечения (ПО) — период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации^[1]. Этот цикл — процесс построения и развития ПО.

Содержание   [убрать]  1 Стандарты жизненного цикла ПО 2 Стандарт ГОСТ 34.601-90 3 Стандарт ISO/IEC 12207/ и его применение 4 Процессы жизненного цикла ПО 5 Стадии жизненного цикла ПО, взаимосвязь между процессами и стадиями 6 Модели жизненного цикла ПО 6.1 Водопадная (каскадная, последовательная) модель 6.2 Итерационная модель 6.3 Спиральная модель 7 Методологии разработки ПО 8 Литература 9 Примечания

[править]Стандарты жизненного цикла ПО

• ГОСТ 34.601-90
• ISO/IEC 12207:1995 (российский аналог — ГОСТ Р ИСО/МЭК 12207-99)

[править]Стандарт ГОСТ 34.601-90

Стандарт ГОСТ 34.601-90 предусматривает следующие стадии и этапы создания автоматизированной системы:

1. Формирование требований к АС
1. Обследование объекта и обоснование необходимости создания АС
2. Формирование требований пользователя к АС
3. Оформление отчета о выполнении работ и заявки на разработку АС
2. Разработка концепции АС
1. Изучение объекта
2. Проведение необходимых научно-исследовательских работ
3. Разработка вариантов концепции АС и выбор варианта концепции АС, удовлетворяющего требованиям пользователей
4. Оформление отчета о проделанной работе
3. Техническое задание
1. Разработка и утверждение технического задания на создание АС
4. Эскизный проект
1. Разработка предварительных проектных решений по системе и ее частям
2. Разработка документации на АС и ее части
5. Технический проект
1. Разработка проектных решений по системе и ее частям
2. Разработка документации на АС и ее части
3. Разработка и оформление документации на поставку комплектующих изделий
4. Разработка заданий на проектирование в смежных частях проекта
6. Рабочая документация
1. Разработка рабочей документации на АС и ее части
2. Разработка и адаптация программ
7. Ввод в действие
1. Подготовка объекта автоматизации
2. Подготовка персонала
3. Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями)
4. Строительно-монтажные работы
5. Пусконаладочные работы
6. Проведение предварительных испытаний
7. Проведение опытной эксплуатации
8. Проведение приемочных испытаний
8. Сопровождение АС.
1. Выполнение работ в соответствии с гарантийными обязательствами
2. Послегарантийное обслуживание

Эскизный, технический проекты  и рабочая документация — это  последовательное построение все более  точных проектных решений. Допускается  исключать стадию «Эскизный проект»  и отдельные этапы работ на всех стадиях, объединять стадии «Технический проект» и «Рабочая документация»  в «Технорабочий проект», параллельно выполнять различные этапы и работы, включать дополнительные.

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

[править]Стандарт ISO/IEC 12207/ и его применение

Стандарт ISO/IEC 12207:1995 «Information Technology — Software Life Cycle Processes» является основным нормативным документом, регламентирующим состав процессов жизненного цикла ПО. Он определяет структуру жизненного цикла, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.

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

[править]Процессы жизненного цикла ПО

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

Каждый процесс включает ряд действий. Например, процесс приобретения охватывает следующие действия:

1. Инициирование приобретения
2. Подготовка заявочных предложений
3. Подготовка и корректировка договора
4. Надзор за деятельностью поставщика
5. Приемка и завершение работ

Каждое действие включает ряд задач. Например, подготовка заявочных  предложений должна предусматривать:

1. Формирование требований к системе
2. Формирование списка программных продуктов
3. Установление условий и соглашений
4. Описание технических ограничений (среда функционирования системы и т. д.)

[править]Стадии жизненного цикла ПО, взаимосвязь между процессами и стадиями

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

Стандарт ГОСТ Р ИСО/МЭК 12207-99 не предлагает конкретную модель жизненного цикла. Его положения являются общими для любых моделей жизненного цикла, методов и технологий создания ИС. Он описывает структуру процессов жизненного цикла, не конкретизируя, как реализовать или выполнить действия и задачи, включенные в эти процессы.

Модель ЖЦ ПО включает в себя:

1. Стадии;
2. Результаты выполнения работ на каждой стадии;
3. Ключевые события — точки завершения работ и принятия решений.

Стадия — часть процесса создания ПО, ограниченная определенными временными рамками и заканчивающаяся выпуском конкретного продукта (моделей, программных компонентов, документации), определяемого заданными для данной стадии требованиями.

На каждой стадии могут  выполняться несколько процессов, определенных в стандарте ГОСТ Р ИСО/МЭК 12207-99, и наоборот, один и тот же процесс может выполняться на различных стадиях. Соотношение между процессами и стадиями также определяется используемой моделью жизненного цикла ПО.

[править]Модели жизненного цикла ПО

[править]Водопадная (каскадная, последовательная) модель

Основная статья: Модель водопада

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

Этапы проекта в соответствии с каскадной моделью:

1. Формирование требований;
2. Проектирование;
3. Реализация;
4. Тестирование;
5. Внедрение;
6. Эксплуатация и сопровождение.

Преимущества:

• Полная и согласованная документация на каждом этапе;
• Легко определить сроки и затраты на проект.

Недостатки:

В водопадной модели переход  от одной фазы проекта к другой предполагает полную корректность результата (выхода) предыдущей фазы. Однако неточность какого-либо требования или некорректная его интерпретация в результате приводит к тому, что приходится «откатываться» к ранней фазе проекта и требуемая переработка не просто выбивает проектную команду из графика, но приводит часто к качественному росту затрат и, не исключено, к прекращению проекта в той форме, в которой он изначально задумывался. По мнению современных специалистов, основное заблуждение авторов водопадной модели состоит в предположениях, что проект проходит через весь процесс один раз, спроектированная архитектура хороша и проста в использовании, проект осуществления разумен, а ошибки в реализации легко устраняются по мере тестирования. Эта модель исходит из того, что все ошибки будут сосредоточены в реализации, а потому их устранение происходит равномерно во время тестирования компонентов и системы^[2]. Таким образом, водопадная модель для крупных проектов мало реалистична и может быть эффективно использована только для создания небольших систем^[3].