47889 (608403), страница 9

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 9)

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

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

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

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

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

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

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

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

Жизненный цикл при использовании RAD-технологии предполагает активное участие конечных пользователей будущей системы на всех этапах разработки и включает четыре основные стадии информационного инжиниринга:

• анализ и планирование информационной стратегии. Пользователи вместе со специалистами-разработчиками участвуют в идентификации проблемной области;

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

• конструирование. Специалисты-разработчики проектируют рабочую версию ИС с использованием языков четвертого поколения;

• внедрение. Специалисты-разработчики обучают пользователей работе в среде новой ИС.

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

Спиральная модель чаще изменяется при разработке ИС силами собственного отдела ИТ предприятия.

Стандарты ЖЦ ИС

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

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

Значительный вклад в теорию проектирования и разработки инфор­мационных систем внесла компания IBM, предложив еще в середине 1970-х годов методологию BSP (Business System Planning - методология организационного планирования). Метод структурирования информации с использованием матриц пересечения бизнес-процессов, функциональных подразделений, функций систем обработки данных (информа­ционных систем), информационных объектов, документов и баз данных, предложенный в BSP, используется сегодня не только в ИТ-проектах, но и проектах по реинжинирингу бизнес-процессов, изменению организа­ционной структуры. Важнейшие шаги процесса BSP, их последователь­ность (получить поддержку высшего руководства, определить процессы предприятия, определить классы данных, провести интервью, обработать и организовать данные интервью) можно встретить практически во всех формальных методиках, а также в проектах, реализуемых на практике.

Среди наиболее известных стандартов можно выделить следующие:

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

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

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

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

• Microsoft Solution Framework (MSF) сходна с RUP так же включает четыре фазы: анализ, проектирование, разработка, стабилизация, является итерационной, предполагает использование объектно-ориентированного моделирования. MSF в сравнении с RUP в большей степени ориентирована на разработку бизнес-приложений.

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

Позднее был разработан и в 2002 г. опубликован стандарт на процессы жизненного цикла систем (ISO/IEC 15288 System life cycle processes). К разработке стандарта были привлечены специалисты различных облас­тей: системной инженерии, программирования, управления качеством. Человеческими ресурсами, безопасностью и пр. Был учтен практический опыт создания систем в правительственных, коммерческих, военных и академических организациях. Стандарт применим для широкого класса систем, но его основное предназначение - поддержка создания компью­теризированных систем.

Согласно стандарту ISO/IEC серии 15288 в структуру ЖЦ сле­дует включать следующие группы процессов:

1. Договорные процессы:

* приобретение (внутренние решения или решения внешнего поставщика);

* поставка (внутренние решения или решения внешнего поставщика).

2. Процессы предприятия:

* управление окружающей средой предприятия;

* инвестиционное управление;

* управление ЖЦ ИС;

* управление ресурсами;

* управление качеством.

3. Проектные процессы:

* планирование проекта;

* оценка проекта;

* контроль проекта;

* управление рисками;

* управление конфигурацией;

* управление информационными потоками;

* принятие решений.

4. Технические процессы:

* определение требований;

* анализ требований;

* разработка архитектуры;

* внедрение;

* интеграция;

* верификация;

* переход;

* аттестации;

* эксплуатации;

* сопровождение;

* утилизация.

5. Специальные процессы:

* определение и установка взаимосвязей исходя из задач и целей.

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

Таблица 4. Стадии создания систем(ISO/IEC 15288)

1.3.2 Основы современной технологии проектирования АИС

Классификация методов проектирования систем

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

Так, по степени автоматизации методы проектирования разде­ляются на:

Характеристики

Список файлов курсовой работы