Проектирование ИС

 

V – образная шарнирная модель.

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

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

1. большая роль придаётся  верификации ИС, начиная на ранних стадиях её разработки;

2. предполагается проверка  не только самой системы, но  и всех получаемых внешних  и внутренних данных;

3. ход выполнения работы  может с лёгкостью отслеживаться т.к. завершение прошлой фазы отмечается контрольной точкой.

Недостатки модели:

1. Отсутствует итерация между фазами
2. Нельзя вносить изменения на разных этапах ЖЦ ИС
3. тестирование системы происходит слишком полно, поэтому внесение изменения качественно влияет на выполнение графика работ.

Инкрементная модель

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

 

Спиральная модель

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

Преимущества спиральной модели:

1. уделяется специальное внимание раннему анализу возможностей повторного использования
2. предполагает возможность развитие ЖЦ и изменение программного продукта
3. достижение необходимых параметров качества выступает как процесс разработки программного продукта
4. уделяют специальное внимание предотвращению ошибок и отфильтровыванию необоснованных альтернатив на ранних этапах проекта по средствам создания прототипов.
5. позволяется контролировать источники проектных работ и соответствующие затраты
6. не разграничивает разработку новой ИС и расширение или сопровождение существующих
7. позволяет разрешать задачи разработки, охватывая как аппаратную, так и программную составляющую ИС

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

 

Модель фазы-функции

Модель должна служить основой  для организации взаимоотношений  между разработчиками и одной из её целей является поддержка функций менеджмента. Это приводит к необходимости наложения на модель контрольных точек, задающих временные рамки проекта и наложения организационно-технических функций, которые выполняются при разработке проекта. Наиболее наглядно это организовано в модели Гантера в виде матрицы фазы-функции. Модель Гантера имеет 2 измерения:

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

В данной модели ЖЦ распадается на следующие прикрывающие друг друга фазы:

1. этап исследования - начинается, когда необходимость разработки признана руководством, заключается в том, что для проекта обосновываются необходимые ресурсы, формулируются требования к разрабатываемому изделию.
2. анализ осуществимости - начинается на этапе исследования, когда определены исполнители объекта и утверждаются требования проекта. Цель этого этапа определить возможность конструирования изделия с технической точки зрения (достаточно ли ресурсов, квалификации и т.п.), будет ли изделие удобно для практического использования; решение вопросов экономической и коммерческой эффективности. Параллельно с этим решаются вопросы экономической и коммерческой эффективности готового продукта.
3. конструирование – начинается на этапе анализа осуществимости, как только заканчивают документироваться цели проекта и завершается утверждением проектных решений в виде специальных спецификаций на разработку.
4. Программирование – начинается на фазе конструирования, когда становятся доступны основные спецификации, но не ранее утверждения соглашения о требованиях. Целью этапа является реализация программ компонентов с последующей сборкой изделия. Он завершается когда разработчики заканчивают документирование, отладку и компоновку и передают готовое изделие специалистам, выполняющим независимую оценку результатов работы.
5. Оценка – является промежуточным звеном между началом испытаний и практическим использованием изделия. Этап начинается, как только произведены внутренние испытания изделия и заканчиваются, когда подтверждается готовность изделия к эксплуатации.
6. Этап использования – начинается ближе к концу этапа оценки, когда готовность изделия к эксплуатации проверена, и продукт можно распускать на распространение пользователя. Этап продолжается, пока изделие находится в эксплуатации действия. На этом этапе может производиться модернизация действия. Заканчивается он, когда разработчики прекращают сопровождение и поддержку данного программного продукта.

На протяжении фаз ЖЦ разработчики выполняют следующие технологические  и организационные функции:

1. планирование – функция, которая должна выполняться с самого начала и до конца развития проекта. Конкретные методы планирования выбираются в зависимости от специфики проекта.
2. разработка – выполняется на протяжении всей разработки проекта. В целом для каждого конкретного этапа её можно охарактеризовать как получение готового продукта в соответствии с задачами конкретной фазы.
3. обслуживание – функция которая обеспечит максимально удобную обстановку выполнения некоторой деятельности. Особенность любого обслуживания является то, что в нём должны участвовать как минимум 2 субъекта – обслуживающий и обслуживаемый.
4. документация – включает в себя не только техническое описание системы. Она должна сопровождать и другие рабочие продукты, такие как программы, диаграммы модели системы и т.д. Оформление документации начинается с утверждения требований, с этого момента интенсивность действий по выпуску документации растёт и достигает максимума на этапе программирования, перед этапом оценки.
5. испытание
6. поддержка – функция, выполнение которой необходимо в связи с передачей продукта в эксплуатацию и она связана с обучением и созданием необходимой инфраструктуры для нормального функционирования выпускаемого продукта.
7. сопровождение – отличается от поддержки тем, что оно организовано для внешнего использования проекта. Оно предполагает организацию поддержки и выполняет действия, нацеленные на обратную связь с пользователем, что бы можно было оперативно реагировать на их отклики, в том числе на изменения требований к с системе и её спецификации.

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

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

1. привычка – многие специалисты получали образование в то время, когда изучалась только каскадная модель, поэтому она используется ими в наши дни.
2. иллюзия снижения риска – каскадная модель предполагает разработку законченного продукта на каждом из этапов. К тому же разработанная документация позволяет определить не только требования к продукту последующего этапа, но и определить обязанности сторон, объём работ и сроки. При этом окончательная оценка срока и стоимости работ производится на начальных этапах после завершения проекта. Если требования к ИС изменяются в ходе реализации проекта, качество документов оказывается не на высоком уровне (требования к ИС оказались не полным или ТЗ разработано с ошибками), то в действительности использование каскадной модели создаёт лишь иллюзию определённости и на деле увеличивает риски, уменьшая лишь ответственность сторон.
3. проблема внедрения, в некоторых областях спиральная и итерационная модель не могут применяться, поскольку невозможно тестирование и использование продукта, обладающего не полной функциональностью (атомная разработка, военная промышленность). Поэтапное итерационное внедрение ИС. для бизнеса возможно, но сопряжено с организационными сложностями. Трудозатраты при таком итерационном внедрении оказываются значительно выше, чем у каскадной модели. Предвидя указанные сложности, заказчики выбирают каскадную модель, чтобы проводить внедрение только 1 раз.

Существует ряд стандартов регламентирующих ЖЦ ПО. Среди них можно выделить следующие:

1. ГОСТ 34601-90
2. ISO/IES 12207:1995
3. Custom Development Method (Oracle)
4. Rational Unified Process (RUP)
5. MS Solution Framework (MSF)
6. Extreme Programming (XP)

ISO 12207 – определяет модель ЖЦ процесса разработки ПО. Он не устанавливает какую-либо конкретную модель ЖЦ, управлением ПО, метод разработки или локально промышленную разработку. Он так же не предписывает, каким образом исполнять что-либо.

В соответствии со стандартом все  процессы ЖЦ ПО делятся на 3 группы:

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

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

В 2002 году опубликован стандарт на процессы ЖЦ систем ISO 15288. Стандарт применим для широкого класса систем, но его основное предназначение поддержка и создание компьютеризированных систем. Согласно этому стандарту ISO 15288 в структуру ЖЦ включают следующие группы процессов:

1. договорные процессы – приобретение  и поставка

2. процессы предприятия – управление окружающей средой предприятия, инвестиционное управление, управление ЖЦ ИС, управление ресурсами и управление качеством.

3. проектные процессы – планирование  проекта, оценка проекта, управление  рисками, контроль проекта, управление  конфигурацией и информационными потоками, принятие решений.

4. технические процессы – определение  требований и их анализ, разработка  архитектуры, внедрение, интеграция, верификация, аттестация, эксплуатация и утилизация.

5. специальные процессы – определение  и установка взаимосвязей исходя из задач и целей при построении ИС.

 

Стадии создания систем по ISO 15288

1. Формирование концепции – осуществляет действие по анализу потребностей, выбору концепции проектных решений.
2. Разработка – осуществляется проектирование системы
3. Реализация – изготовление системы
4. Эксплуатация - ввод в эксплуатацию и использование системы
5. Поддержка – обеспечивание функционирование системы
6. Снятие с эксплуатации – прекращение использования, демонтаж и архивирование системы.

 

Каноническое  проектирование ИС

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

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

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

Стадия 1. Формирование требований к ИС.

На начальной стадии проектирования выделяют следующие этапы работ:

• обследование объекта и обоснование необходимости создания ИС;
• формирование требований пользователей к ИС;
• оформление отчета о выполненной работе и ТЗ на разработку.

Стадия 2. Разработка концепции ИС.

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

Стадия 3. Техническое задание.

• разработка и утверждение технического задания на создание ИС.

Стадия 4. Эскизный проект.

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

Стадия 5. Технический проект.

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