Программные документы по фазам жизненного цикла. Лекция 3 презентация

Методологические основы проектирования ИC

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

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

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

Проектирование ИС охватывает три основные области:
1. проектирование объектов данных, которые будут реализованы в базе данных (БД);
2. проектирование программ, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным;
3. учет конкретной среды или технологии, а именно: топологии сети, конфигурации аппаратных средств, используемой архитектуры (файл- сервер или клиент-сервер), параллельной обработки, распределенной обработки данных и т.п.

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

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

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

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

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

Жизненный цикл
информационной системы

Жизненный цикл ИС в общем случае начинается в момент принятия ре­шения о ее создании и заканчивается в момент выведения ее из эксплуатации.
Существует несколько вариантов жизненного цикла ИС, подразделяе­мого на различные стадии, например:
ГОСТ 34.601-90
ISO/IEC 12207:1995
Rational Unified Process (RUP)
Microsoft Solution Framework (MSF)
и др.).

Жизненный цикл ИС в общем случае начинается в момент принятия ре­шения о ее создании и заканчивается в момент выведения ее из эксплуатации.
Существует несколько вариантов жизненного цикла ИС, подразделяе­мого на различные стадии (например, ГОСТ 34.601-90, ISO/IEC 12207:1995. Rational Unified Process (RUP), Microsoft Solution Framework (MSF) и др.).

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

Предпроектная стадия
Обследование объ­екта и обоснование необходимости создания ИС
Формирование требований поль­зователя к ИС
Стадия проектирования
Разработка эскизного проекта
Разработка рабоче­го проекта
Стадия разработки
Разработка приложений
Тестирование
Подготовка рабочей документации
Стадия внедрения
Опытная эксплуа­тация
Обучение пользователей
Стадия
промышленной эксплуатации
Эксплуатация и сопровождение
Стадия модернизации (утилизации)
Внесение измене­ний или выведение из эксплуатации и утилизация

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

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

Один из возможных вариантов этапов жизненного цикла ИС

Жизненный цикл ИС позволяет выделить четыре основные стадии.
1. Анализ системы и объекта управления. Выполняется обследование и изучение системы управления, анализируется существующая организационная структура, система документооборота, связи с внешними организациями и системами. На основе которой выделяются и анализируются недостатки существующей системы управления. Моделируется деятельность предприятия, при необходимости осуществляется реорганизация функций, формируются требования к созданию ИС. Разрабатывается план создания ИС.

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

Модели жизненного цикла ИС

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

Каскадная модель
Каскадная модель демонстрирует классический подход к разработке раз­личных систем в любых прикладных областях (широко использовалась в 70-х – первой половине 80-х годов). В изначально существовавших однородных ИС каждое приложение представляло собой единое целое.
Его основной характеристикой является разбие­ние всей разработки на этапы, причем переход с одного этапа на следующий происходит только после того, как будет полностью завершена работа на теку­щем.
Каждый этап завершается выпуском полного комплекта до­кументации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.

Waterfall (каскадный)

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

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

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

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

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

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

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

6. связан с конфликтом (не всегда явным) между разработчиками, участвующими в выполнении проекта. Конфликт обусловлен тем, что возврат части проекта на предыдущую стадию обычно сопровождается поиском причин и виновных. А так как однозначно персонифицировать ответственного за ошибки можно далеко не всегда, попытки поиска виноватых могут сильно усложнить отношения в коллективе. Чем строже дисциплина, тем менее творческой становится атмосфера в коллективе.
Такое положение вещей может привести к тому, что наиболее одаренные кадры со временем покинут коллектив.

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

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

3. Incremental (итеративный/инкрементальный)

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

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

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

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

Spiral (спиральный)

Автор: Барри Боэм (Barry Boehm) модифицировал каскадную модель: разделил практики деятельности и стадии жизни системы.
Есть фазы:
одна фаза концептуального проектирования
фаза разработки системы
фаза совершенствования системы
фаза расширения
фазы эксплуатации.
На всех этих фазах применяются одни и те же практики (общение с заказчиками, планирование, анализ рисков и т. д).

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

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

Основные работы, выполняемыми на стадиях и этапах разработки и внедрения АИС:
I стадия — предпроектное обследование:
1-й этап — Изучение экономического объекта. Дается полная характеристика предприятия: основная деятельность, основные фонды, контрагенты, материально-техническая база, т.д.
2-й этап — сбор материалов для проектирования — формирование требований, изучение объекта проектирования, разработка и выбор варианта концепции системы;
3-й этап — анализ материалов и формирование документации — создание и утверждение технико-экономического обоснования и технического задания на проектирование системы на основе анализа материалов обследования, собранных на первом этапе.

II стадия — проектирование:
1-й этап — техническое проектирование, где ведется поиск наиболее рациональных проектных решений по всем аспектам разработки, создаются и описываются все компоненты системы, а результаты работы отражаются в техническом проекте;
2-й этап — рабочее проектирование, в процессе которого осуществляется разработка и доводка программ, корректировка структур баз данных, создание документации на поставку, установку технических средств и инструкций по их эксплуатации, подготовка для каждого пользователя системы обширного инструкционного материла, оформленного в виде должностных инструкций исполнителям-специалистам, реализующим свои профессиональные функции с использованием технических средств управления. Технический и рабочий проекты могут объединяться в единый документ — технорабочий проект.

III стадия — ввод системы в действие:
1-й этап — подготовка к внедрению — установка и ввод в эксплуатацию технических средств, загрузка баз данных и опытная эксплуатация программ, обучение персонала;
2-й этап — проведение опытных испытаний всех компонентов системы перед передачей в промышленную эксплуатацию, обучение персонала;
3-й этап (завершающая стадия создания АИС и АИТ) — сдача в промышленную эксплуатацию; оформляется актами приема-сдачи работ.
IV стадия — промышленная эксплуатация — кроме повседневного функционирования включает сопровождение программных средств и всего проекта, оперативное обслуживание и администрирование баз данных.

Состав программных документов по фазам жизненного цикла

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

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