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

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

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

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

3)Спиральная модель опирается на начальные этапы жизненного цикла: анализ, предварительное и детальное проектирование.

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

Заключение

Проблемы  и эффекты от внедрения  автоматизированных информационных систем

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

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

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

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

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

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

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

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

Нынешних огрехов  проектирования можно избежать, используя  принцип, который называется синархическим  проектированием. Этот новый принцип  является проявлением "закона синархии", который описал в начале ХХ века российский философ Владимир Шмаков. Если кратко, то это органичное сочетание  определенной иерархии и аналогии в  построении мироздания.

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

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

Список  использованной литературы

1. Барановская Т.П., Лойко В.И. и другие Информационные системы и технологии в экономике: Учебник - М.: Финансы и статистика, 2008. - 416 с.

2. Джонатан Генник, SQL. Карманный справочник, - СПб.:Питер, 2007.

3. Зобнин Б.Б., Задания и методические указания к выполнению курсовой работы по дисциплине «Моделирование систем» для студентов профилизации «Автоматизированные системы обработки информации и управления»направления 552800 - «Информатика и вычислительная техника», Екатеринбург, 2006.

4. Зобнин Б.Б., Моделирование систем, Конспект лекций, Екатеринбург, 2007

5. Информационные  технологии управления: Учебное  пособие / Под ред. Ю.М. Черкасова. -- М.: ИНФРА-М, 2007. -- 216 с. -- (Серия «Высшее образование»)

6. Информационные  технологии управления: Учебное  пособие для ВУЗов под ред.  Г.А. Титоренко - М.:ЮНИТИ-ДАНА, 2005. - 439 с.

7. Меняев М.Ф. Информационные технологии управления: Учебное пособие в 3-х кн. Кн. 3. Системы управления организацией - М.: Омега - Л, 2003. - 464 с.

8. Павловская Т.А. Программирование на языке высокого уровня. [Текст] / Т.А. Павловская. - М.: Питер, 2007. С. 461.

9. Петров В.Н. Информационные  системы - СПб: Питер, 2007. - 688 с.

10. Саак А.Э., Пахомов Е.В., Тюшняков В.Н. Информационные технологии управления: Учебник для вузов. - СПб.: Питер, 2005. - 320 с. - (Серия "Учебник для вузов")

11. Семакин И.Г.  Основы программирования. [Текст] / И.Г.  Семакин, А.П. Шестаков. - М.: Мир, 2006. C. 346.

12. Семенов М.И.  и другие Автоматизированные  информационные технологии в  экономике: Учебник - М.: Финансы  и статистика, 2006. - 416 с.

13. Советов Б.Я., Цехановский В.В. Информационные технологии: Учебник для ВУЗов - М.: Высшая школа, 2006. - 263 с.

14. Уткин В.Б. Информационные  системы и технологии в экономике:  Учебник - М.: ЮНИТИ-ДАНА, 2003. - 355 с.

15. Хотинская Г.И. Информационные технологии управления: Учебное пособие. - М.: Дело и Сервис, 2006. - 128 с.

16. Эккель Б. Введение в стандартный С++. [Электронный ресурс] / Б. Эккель. - М.: Питер, 2004. С. 572.