Что можно приготовить из кальмаров: быстро и вкусно

Описание презентации Этапы создания АИС Модели жизненного цикла АИС по слайдам

Жизненный цикл АИС -совокупность стадий и этапов, которые проходит АИС в своем развитии от момента принятия решения о создании системы до момента прекращения ее функционирования.

Этапы жизненного цикла 1 Планирование и анализ (предпроектная стадия) – определение того, что должна делать система. Оформление технико-экономического обоснования (ТЭО) и технического задания (ТЗ).

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

3. Реализация (рабочее проектирование, программирование) — Создание функциональных компонентов и отдельных подсистем, соединение подсистем в единое целое. Заполнение БД. Создание инструкций для персонала. Оформление рабочего проекта

4 Внедрение (тестирование, опытная эксплуатация) – установка и ввод системы в действие, отладка подсистем, обучение персонала. Оформление акта о приемо-сдаточных испытаниях.

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

3. Для каждого этапа исходными являются документы и решения принятые на предыдущем этапе. 4. Модели жизненного цикла определяют порядок исполнения этапов в процессе создания системы и критерии перехода от этапа к этапу.

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

Основные модели ЖЦ Каскадная – предполагает переход на следующий этап после полного завершения работ предыдущего. Эта модель используется при построении АИС для которых с самого начала точно и полно сформулированы все требования. Недостатки: жесткая схема – невозможность возврата к предыдущим этапам и использование для сложных систем.

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

Роль пользователя АИС создается для удовлетворения информационных потребностей конкретного пользователя. Он принимает непосредственное участие в ее работе. .

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

Участие пользователя в создании АИС обеспечивает оперативное и качественное решение задач, сокращает время на внедрение новых технологий

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

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

Выбор модели жизненного цикла зависит от специфики, масштаба, сложности проекта и набора условий, в которых АИС создается и функционирует.

Модель ЖЦ АИС включает:

Результаты выполнения работ на каждой стадии;

Ключевые события или точки завершения работ и принятия решений.

В соответствии с известными моделями ЖЦ ПО определяют модели ЖЦ АИС -каскадную, итерационную, спиральную.

I. Каскадная модель описывает классический подход к разработке систем в любых предметных областях; широко использовалась в 1970-80-х гг.

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

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

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

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

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

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

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

Рис.1.1 Каскадная модель ЖЦ АИС

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

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

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

2) последовательное выполнение этапов работ позволяет планировать сроки завершения и соответствующие затраты.

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

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

Существенная задержка в получении результатов;

Ошибки и недоработки на любом из этапов проявляются, как правило, на последующих этапах работ, что приводит к необходимости возврата;

Сложность параллельного ведения работ по проекту;

Чрезмерная информационная перенасыщенность каждого из этапов;

Сложность управления проектом;

Высокий уровень риска и ненадежность инвестиций.

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

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

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

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

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

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

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

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

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

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

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

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

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

Недостатки итерационной модели:

· время жизни каждого этапа растягивается на весь период работки;

· вследствие большого числа итераций возникают рассогласования выполнения проектных решений и документации;

· запутанность архитектуры;

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

III . Спиральная модель , в отличие от каскадной, но аналогично предыдущей предполагает итерационный процесс разработки АИС. При этом возрастает значение начальных этапов, таких как анализ и проектирование, на которых проверяется и обосновывается реализуемость технических решений путем создания прототипов.

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

Рис. 1.2. Спиральная модель ЖЦ АИС

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

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

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

Преимущества итерационного подхода:

Итерационная разработка существенно упрощает внесение изменений в проект при изменении требований заказчика;

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

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

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

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

Спиральная модель позволяет получить более надежную и устойчивую систему. Это связано с тем, что по мере развития системы ошибки и слабые места обнаруживаются и исправляются на каждой итерации. Одновременно корректируются критические параметры эффективности, что в случае каскадной модели доступно только перед внедрением системы;

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

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

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

Модель жизненного цикла и технология проектирования

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

· задачи, состав и последовательность выполняемых работ;

· получаемые результаты каждого выполняемого действия;

· методы и средства, необходимые для выполнения работ;

· роли и ответственность участников;

· иную информацию, необходимую для планирования, организации и управления коллективной разработкой ИС,

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

Этапы и стадии проектирования

Часто смешивают понятия «этап» и «стадия» проектирования. Иногда говорят об этапах или фазах жизненного цикла, шагах проектирования. Возникает вопрос: как правильно?

Следует помнить, что в разных международных стандартах используемая терминология может отличаться. Мы будем, по возможности, ориентироваться на терминологию отечественных ГОСТов. Этапом проектирования будем называть часть процесса создания ИС, ограниченную некоторыми временными рамками и заканчивающуюся выпуском конкретного продукта (модели, документации, текста программы и т. п.). По общности целей этапы проектирования могут объединяться в стадии . Например, стадия «Технический проект», стадия «Внедрение» и т.п.

По опубликованным данным каждый этап разработки АИС требует определенных затрат времени. В основном (45-50 %) время уходит на кодирование, комплексное и автономное тестирование. В среднем разработка АИС занимает одну треть всего ЖЦ системы.

Рис. Распределение времени при разработке АИС

Стадии создания АИС (ISO/IEC 15288)

Стандарт ISO/IEC 12207 определяет структуру жизненного цикла, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания информационной системы.

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

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

IDEF0 - первый информационный разрез -- функциональность системы. Основной из трех методологий, поддерживаемых BPwin, является IDEF0. IDEF0, относится к семейству IDEF, которое появилось в конце шестидесятых годов под названием SADT (Structured Analysis and Design Technique). IDEF0 может быть использована для моделирования широкого класса систем. Для новых систем применение IDEF0 имеет своей целью определение требований и указание функций для последующей разработки системы, отвечающей поставленным требованиям и реализующей выделенные функции. Применительно к уже существующим системам IDEF0 она может быть использована для анализа функций, выполняемых системой и отображения механизмов, посредством которых эти функции выполняются. Результатом применения IDEF0 к некоторой системе является модель этой системы, состоящая из иерархически упорядоченного набора диаграмм, текста документации и словарей, связанных друг с другом с помощью перекрестных ссылок.

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

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

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

В данной работе именем модели «Учет посещаемости в детском саду», имя проекта «Учет посещаемости в детском саду», имя автора и тип модели - Ощепков Максим и Time Frame: AS - IS (Как есть).

Цель работы (Purpose) - Моделировать текущие бизнес-процессы сотрудника IT-отдела, точку зрения (Viewpoint) - инженера-системотехника. Внесем определение модели: «Это модель, ведет учет посещаемости в детском саду» и цель: «Ведение учета посещаемости, регистрация выполненных работ, организация поиска и отчетности».

Первая диаграмма в иерархии диаграмм IDEF0 всегда изображает функционирование системы в целом. Такие диаграммы называются контекстными (рисунок 2).

Рисунок 2. Контекстная диаграмма «Учет посещаемости в детском саду»

В соответствии с методом IDEF0 определим входные данные, выходные данные, управление и механизм, которые изображаются на диаграмме стрелками:

• - Входные данные: Заявка сотрудника с указанием причины неработоспособности ПК и его номера.
• - Выходные данные: Различные виды отчетности, исправленные и неисправленные комплектующие.
• - Управление: Законодательство, правила и инструкций.
• - Механизм: Сотрудники IT-отдела и других отделов организаций.

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

Рисунок 3. Диаграмма декомпозиции «Учет посещаемости в детском саду»

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

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

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

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

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

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

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

1. Формирование требований;

2. Проектирование;

3. Разработка;

4. Тестирование;

5. Внедрение;

6. Эксплуатация и сопровождение.

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

-Полная и согласованная документация на каждом этапе;

-Определенный порядок последовательности работ;

-Позволяет четко спланировать сроки и затраты.

Недостатки:

-Существенная задержка получения готовых результатов;

-Ошибки на любом из этапов выявляются на последующих этапах, что приводит к необходимости возврата и переоформление проектной документации;

-Сложность управления проектом.

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

Каждая итерация – законченные циклы разработки в виде 1й версии АИС.

Этапы итерации:

1.Формирование требований

3.Проектирование

4.Разработка

5.Интеграция

На каждой итерации оцениваются:

Риск превышения сроков и стоимости проекта;

Необходимость выполнения ещё одной итерации;

Степень полноты и точности понимания требований к системе;

Целесообразность прекращения проекта.

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

-Упрощается процесс внесения изменений в проект;

-Обеспечивает большую гибкость в управлении проектом;

-Возможность получения надежной и устойчивой системы, т.к. ошибки и несоответствия обнаруживаются на каждой итерации;

-Влияние заказчика на работу в процессе проверки каждой итерации.

Недостатки:

-Сложность планирования;

-Напряженный режим работы для разработчиков;

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

Требования к технологии проектирования, разработки и сопровождения АИС

Технология проектирования - определяет совокупность трех составляющих:

-пошаговой процедуры, определяющей последовательность технологических операций проектирования;

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

-представление проектной разработки на экспертизу и утверждению.

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

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

Технология должна поддерживать полный ЖЦ ПО;

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

Технология должна обеспечивать возможность ведения работ по проектированию отдельных подсистем небольшими группами (3-7 человек). Это обусловлено принципами управляемости коллектива и повышения производительности за счет минимизации числа внешних связей;

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

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

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

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

-стандарт пользовательского интерфейса.

Требование разработки

- Выполнение работ по созданию программного обеспечения;

Подготовка к внедрению АИС;

Контроль, тестирование основных показателей проекта.

Требования к сопровождению

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

В процессе сопровождения КИС ставится задача поддержания ее жизнеспособности. Жизнеспособность КИС во многом определяется насколько она соответствует реальным задачам и потребностям ВУЗа, которые являются меняющимися в течение жизненного цикла КИС.

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

Существует три класса методологий проектирования АИС :
· концептуальное моделирование предметной области;
· выявление требований и спецификация информационной системы через ее макетирование;
· системная архитектура программных средств, поддерживаемая инструментальными средствами CASE-технологии (CASE -- Computer Aided Software Engineering -- технология создания и сопровождения ПО различных систем).

Стадия создания автоматизированной системы — часть процесса создания АС, установленная нормативными документами и заканчивающаяся выпуском документации наАС, которая должна содержать модель системы на уровне данной стадии, изготовление несерийных компонентов или приемку АС в эксплуатацию.
Каждая стадия выделена по соображениям рационального планирования и организации работ и обязательно должна заканчиваться определенным результатом. Содержание документации на каждой стадии определяется составом и спецификой работ.
В ГОСТ 34.601-90 определено восемь стадий создания автоматизированных систем:

1. Формирование требований к АС.
2. Разработка концепции АС.
3. Техническое задание.
4. Эскизный проект.
5. Технический проект.
6. Рабочая документация.
7. Ввод в действие.
8. Сопровождение АС.

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

• изучение объекта;
• проведение научно-исследовательских работ;
• выбор варианта концепции системы из нескольких разработанных;
• составление отчета о выполненной работе.

• проектных решений по системе и ее частям;
• документации наАС и ее части;
• документации на поставку изделий для комплектования АС и ТЗ на их разработку;
• заданий н# проектирование в смежных частях проекта объекта автоматизации.

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

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

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

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

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

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