Этапы и стратегии разработки корпоративной информационной системы

Размещено на http://www.allbest.ru/

19

МИНИСТЕРСТВО ОБРАЗОВАНИЯ РОССИЙСКОЙ ФЕДЕРАЦИИ

ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

САМАРСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ

Кафедра Информационные технологии

Курсовая работа

на тему

ЭТАПЫ И СТРАТЕГИИ РАЗРАБОТКИ КИС

по дисциплине

Предметно-ориентированные экономические информационные системы

Выполнил:

студент 4-АИТ-7

Яруллин И.Т.

Проверила:

Тышковская Ю. В.

Самара 2010Содержание

1. Этапы разработки КИС

1.1 Формирование требований к системе

1.2 Проектирование

1.3 Реализация

1.4 Тестирование

1.5 Ввод в действие

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

2. Стратегии разработки КИС

3. Классический жизненный цикл

1. Этапы разработки КИС

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

Обычно выделяют следующие этапы создания ИС:

1. формирование требований к системе

2. проектирование

3. реализация

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

5. ввод в действие

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

Рассмотрим каждый этап более подробно.

1.1 Формирование требований к системе

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

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

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

Необходимо классифицировать планируемые функции системы по степени важности. Один из возможных форматов представления такой классификации- MoSCoW. Эта аббревиатура расшифровывается так: Must have- необходимые функции; Should have- желательные функции; Could have- возможные функции; Won't have- отсутствующие функции.

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

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

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

В документе обязательно должны быть описаны:

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

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

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

· описание выполняемых системой функций;

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

· интерфейсы и распределение функций между человеком и системой;

· требования к программным и информационным компонентам ПО, требования к СУБД;

· что не будет реализовано в рамках проекта.

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

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

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

Аналитики собирают и фиксируют информацию в двух взаимосвязанных формах:

· функции- информация о событиях и процессах, которые происходят в бизнесе;

· сущности- информация о вещах, имеющих значение для организации и о которых что-то известно.

Двумя классическими результатами анализа являются:

· иерархия функций, которая разбивает процесс обработки на составные части (что делается и из чего это состоит);

· модель "сущность-связь" (ER-модель), которая описывает сущности, их атрибуты и связи (отношения) между ними.

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

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

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

В качестве ресурсов рассматриваются:

1. время на разработку ИС

2. финансы

3. персонал

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

5. другие ресурсы

1.2 Проектирование

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

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

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

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

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

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

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

· и т. п.

Конечными продуктами этапа проектирования являются:

· схема базы данных (на основе ER-модели, разработанной на этапе анализа);

· набор спецификаций (описаний) модулей системы (строятся на базе моделей функций)

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

Этап проектирования завершается разработкой технического проекта информационной системы.

1.3 Реализация

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

1.4 Тестирование

Этап тестирования обычно оказывается распределенным во времени.

После завершения разработки отдельного модуля системы выполняют автономный тест, который преследует две основные цели:

1. обнаружение отказов модуля (жестких сбоев);

2. соответствие модуля спецификации (наличие всех необходимых функций, отсутствие лишних функций)

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

Далее группа модулей тестируется на надежность работы, проходя:

1. тесты имитации отказов системы показывают насколько хорошо система восстанавливается после сбоев ПО, отказов аппаратного обеспечения

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

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

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

1.5 Ввод в действие

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

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

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

Сопровождение предусматривает ликвидацию последствий сбоев в работе системы, исправление ошибок, которые не были выявлены, а так же модернизацию (доработку и усовершенствование) ИС.

2. Стратегии разработки КИС

корпоративный информационная система жизненный цикл

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

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

Такое формальное описание жизненного цикла ИС позволяет спланировать и организовать процесс коллективной разработки и обеспечить управление этим процессом.

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

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

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

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

1. Планирование и анализ требований (предпроектная стадия)

- Исследование и анализ существующей ИС

- формирование требований к новой ИС

- изучение объекта автоматизации

- выбор и разработка варианта концепции системы

- создание и утверждение технико-экономического обоснования

- разработка и утверждение технического задания на проектирование информационной системы

2. Проектирование (техническое проектирование, логическое проектирование)выбор проектных решений по всем аспектам разработки информационной системы

- описание всех компонентов информационной системы

- оформление и утверждение технического проекта

- выбор и разработка математических методов и алгоритмов программ

- корректировка структур баз данных

- создание документации на поставку и установку программных продуктов

- Выбор комплекса технических средств ИС

- разработка технорабочего проекта ИС

3. Реализация (рабочее проектирование, физическое проектирование, программирование)получение и установка технических средств

- разработка, тестирование и доводка программ

- получение и установка программных средств

- наполнение баз данных

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

- оформление рабочего проекта

4. Внедрение (тестирование, опытная эксплуатация)ввод в опытную эксплуатацию технических средств

- ввод в опытную эксплуатацию программных средств

- обучение персонала

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

- оформление акта о приемо-сдаточных испытаниях ИС

5. Эксплуатация ИС (сопровождение, модернизация)повседневная эксплуатация ИС

- сбор статистики о функционировании ИС

- исправление ошибок и недоработок

- оформление требований к модернизации ИС и ее выполнение.

Часто второй и третий этапы объединяют в одну стадию, называемую техно-рабочим проектированием или системным синтезом.

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

В настоящее время известны и используются следующие модели жизненного цикла:

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



Рисунок 1. Каскадная модель.

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

Рисунок 2. Поэтапная модель с промежуточным контролем.

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

Рисунок 3. Спиральная модель.

На практике наибольшее распространение получили две основные модели жизненного цикла:

· каскадная модель (характерна для периода 1970-1985 гг.);

· спиральная модель (характерна для периода после 1986.г.).

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

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

· ISO/IEC 12207:1995 - стандарт на процессы и организацию жизненного цикла. Распространяется на все виды заказного ПО. Стандарт не содержит описания фаз, стадий и этапов.

· Custom Development Method (методика Oracle) по разработке прикладных информационных систем - технологический материал, детализированный до уровня заготовок проектных документов, рассчитанных на использование в проектах с применением Oracle. Применяется CDM для классической модели ЖЦ (предусмотрены все работы/задачи и этапы), а также для технологий «быстрой разработки» (Fast Track), рекомендуемых в случае малых проектов.

· Rational Unified Process (RUP) предлагает итеративную модель разработки, включающую четыре фазы: начало, исследование, построение и внедрение. Каждая фаза может быть разбита на этапы (итерации), в результате которых выпускается версия для внутреннего или внешнего использования. Прохождение через четыре основные фазы - цикл разработки, каждый цикл завершается генерацией версии системы. Если работа над проектом не прекращается, то полученный продукт снова минует те же фазы. Суть работы в рамках RUP - это создание и сопровождение моделей на базе UML.

· Extreme Programming (XP). Экстремальное программирование (самая новая среди рассматриваемых методологий) сформировалось в 1996 году. В основе методологии командная работа, эффективная коммуникация между заказчиком и исполнителем в течение всего проекта по разработке ИС, а разработка ведется с использованием последовательно дорабатываемых прототипов.

3. Классический жизненный цикл

Классический жизненный цикл - каскадная модель жизненного цикла.

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

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

Можно выделить следующие положительные стороны применения каскадного подхода:

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

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

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

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

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

Основные причины, по которым каскадная модель сохраняет свою популярность, следующие:

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

Иллюзия снижения рисков участников проекта (заказчика и исполнителя). Каскадная модель предполагает разработку законченных продуктов на каждом этапе: технического задания, технического проекта, программного продукта и пользовательской документации. Разработанная документация позволяет не только определить требования к продукту следующего этапа, но и определить обязанности сторон, объем работ и сроки, при этом окончательная оценка сроков и стоимости проекта производится на начальных этапах, после завершения обследования. Очевидно, что если требования к информационной системе меняются в ходе реализации проекта, а качество документов оказывается невысоким (требования неполны и/или противоречивы), то в действительности использование каскадной модели создает лишь иллюзию определенности и на деле увеличивает риски, уменьшая лишь ответственность участников проекта. При формальном подходе менеджер проекта реализует только те требования, которые содержатся в спецификации, опирается на документ, а не на реальные потребности бизнеса. Есть два основных типа контрактов на разработку ПО. Первый тип предполагает выполнение определенного объема работ за определенную сумму в определенные сроки (fixed price). Второй тип предполагает повременную оплату работы (time work). Выбор того или иного типа контракта зависит от степени определенности задачи. Каскадная модель с определенными этапами и их результатами лучше приспособлена для заключения контракта с оплатой по результатам работы, а именно этот тип контрактов позволяет получить полную оценку стоимости проекта до его завершения. Более вероятно заключение контракта с повременной оплатой на небольшую систему, с относительно небольшим весом в структуре затрат предприятия. Разработка и внедрение интегрированной информационной системы требует существенных финансовых затрат, поэтому используются контракты с фиксированной ценой, и, следовательно, каскадная модель разработки и внедрения. Спиральная модель чаще применяется при разработке информационной системы силами собственного отдела ИТ предприятия.

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

Размещено на Allbest.ru