Успешное руководство бизнесом невозможно сегодня без постоянной, объективной и всесторонней информации. Для повышения эффективности и минимизации издержек управления (временных, ресурсных и финансовых), разрабатываются и применяются КИС, помогающие осуществлять контроль бюджетных процессов, рабочего времени сотрудников, выполненных ими работ, хода реализации проектов, документооборота, и других управленческих функций. С помощью эффективной КИС можно значительно упростить процессы контроля и управления на предприятии любого уровня.
Проектирование и внедрение КИС проходит следующие этапы:
1) проведение предпроектного обследования;
2) формулирование целей и ограничений проекта, разработка стратегии реализации проекта;
3) инжиниринг и реинжиниринг бизнес-процессов Заказчика, консалтинг в различных областях;
4) выбор платформы, разработка системы, интеграция с используемым программным обеспечением;
5) поставку оборудования и программного обеспечения;
6) пусконаладочные работы по вводу системы в эксплуатацию;
7) сопровождение созданной системы в процессе эксплуатации, работы по ее дальнейшему развитию.
Основная задача проектирования и внедрения КИС как результата системной интеграции – комплексная деятельность по решению бизнес-задач средствами современных информационных технологий.
Концепция построения КИС в экономике предусматривает наличие типовых компонентов:
1) ядра системы, обеспечивающего комплексную автоматизацию совокупности бизнес-приложений, которое содержит полный набор функциональных модулей для автоматизации задач управления;
2) системы автоматизации документооборота в рамках корпорации;
3) вспомогательных инструментальных систем обработки информации (экспертных систем, систем подготовки и принятия решений и др.) на базе хранилищ данных КИС;
4) программно-технических средств системы безопасности КИС;
5) сервисных коммуникационных приложений (электронной почты, программного обеспечения удаленного доступа);
6) компонентов интернет/интранет для доступа к разнородным базам данных и информационным ресурсам, сервисным услугам;
7) офисных программ – текстового редактора, электронных таблиц, СУБД настольного класса и др.
8) систем специального назначения – систем автоматизированного проектирования (САПР), автоматизированных систем управления технологическими процессами (АСУТП), банковских систем и др.
Ядром каждой производственной системы являются воплощенные в ней рекомендации по управлению производством. Существует несколько сводов таких рекомендаций. Они представляют собой описание общих правил, по которым должны производиться планирование и контроль различных стадий деятельности корпорации.
К основным принципам построения КИС относятся:
1) принцип интеграции, заключающийся в том, что обрабатываемые данные вводятся в систему только один раз и затем многократно используются для решения возможно большего числа задач;
2) принцип однократного хранения информации;
3) принцип системности, заключающийся в обработке данных в различных разрезах, чтобы получить информацию, необходимую для принятия решений на всех уровнях и во всех функциональных подсистемах и подразделениях корпорации;
4) 
принцип комплексности, подразумевающий автоматизацию процедур преобразования данных на всех стадиях продвижения продуктов корпорации.
Рассмотрим различные классификации моделей жизненного цикла КИС.
Одной из старейших последовательностей шагов разработки программного обеспечения (ПО) является классический жизненный цикл (рис. 8.1). Чаще классический жизненный цикл называют каскадной или водопадной моделью, подчеркивая, что разработка рассматривается как последовательность этапов, причем переход на следующий иерархически нижний этап происходит только после полного завершения работ на текущем этапе, и возврата к пройденным этапам не предусматривается.
Рис. 8.1. Классический жизненный цикл разработки ПО
Приведем краткое описание основных этапов. Разработка программного обеспечения начинается на системном уровне и проходит через:
1) анализ;
2) проектирование;
3) кодирование (реализацию);
4) тестирование;
5) сопровождение.
При этом моделируются действия стандартного инженерного цикла.
Системный анализ определяет роль каждого элемента в компьютерной системе, взаимодействие элементов друг с другом. Анализ начинается с определения требований и назначения подмножества этих требований программному элементу. На этом этапе начинается решение задачи планирования проекта ПО.
В ходе планирования проекта осуществляется следующее:
· определяется объем проектных работ;
· определяется риск проектных работ;
· определяются необходимые трудозатраты;
· формируются рабочие задачи;
· формируется план-график работ.
При анализе требований, относящемся к программному элементу, т.е. к ПО, уточняются и детализируются:
· функции ПО;
· характеристики ПО;
· интерфейс ПО.
Все определения документируются в спецификации анализа.
При проектировании создаётся представление:
· архитектуры ПО;
· модульной структуры ПО;
· алгоритмической структуры ПО;
· структуры данных;
· входного и выходного интерфейса (входных и выходных форм данных).
Кодирование (реализация) состоит в переводе результатов проектирования в текст на языке программирования.
Тестирование – это выполнение программы для выявления дефектов в функциях, логике и форме реализации программного продукта.
Сопровождение – это внесение изменений в эксплуатируемое ПО. Цели изменений:
· исправление ошибок;
· адаптация к изменениям внешней для ПО среды;
· усовершенствование ПО по требованию заказчика.
Сопровождение ПО состоит в повторном применении каждого из предшествующих шагов (этапов) жизненного цикла, т.е. системного анализа, анализа требований, проектирования и т. д., к существующей программе, но не разработке новой программы.
Каждая стадия (этап) завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.
Достоинствами классического жизненного цикла являются:
· получение плана и временного графика по всем этапам проекта;
· упорядочение хода разработки.
К недостаткам классического жизненного цикла относятся:
· при реализации реальных проектов происходит частое отклонение от стандартной последовательности шагов;
· цикл должен быть основан на точной формулировке исходных требований к ПО, тогда как реально в начале проекта требования заказчика определены лишь частично;
· результаты проекта доступны заказчику лишь в конце работы.
Следующая модель разработки программного обеспечения имеет название – макетирование. На начальной стадии проекта полностью и точно сформулировать все требования к будущей модели невозможно, поскольку пользователи, как правило, не в состоянии изложить все свои требования и не могут предвидеть, как они изменятся в ходе разработки, и, кроме того, за время разработки могут произойти изменения во внешней среде, которые могут повлиять на требования к системе. Поэтому процесс создания ПО носит скорее итерационный характер, когда результаты очередной стадии разработки могут вызвать необходимость возврата к предыдущим разработкам.
Поэтому ПО создается не сразу, как в случае каскадного подхода, а постепенно с использованием макетирования (прототипирования), когда создается модель требуемого программного продукта. Под прототипом понимается действующий программный компонент, реализующий отдельные функции.
Модель может принимать одну из трех форм:
1) бумажного макета или макета, полученных на персональном компьютере (который изображает или рисует человеко-машинный диалог);
2) работающего макета (выполняет некоторую часть требуемых функций);
3) программы (характеристики которой затем должны быть улучшены).
Макетирование основывается на многократном повторении итераций, в которых участвуют заказчик и разработчик. Поскольку часто заказчик не может определиться в своих требованиях по разрабатываемому продукту, а проектировщик сомневается в полноте и целесообразности требований заказчика, то макетирование начинается со сбора и уточнения требований к создаваемому ПО.
Совместными усилиями разработчик и заказчик определяют все цели ПО, устанавливают, какие требования известны, а какие предстоит доопределить. Следующим шагом является быстрое проектирование, внимание в котором сосредотачивается на тех характеристиках ПО, которые должны быть видимы пользователю. Макет (прототип), построенный на этапе быстрого проектирования, оценивается заказчиком и используется для уточнения требований к ПО. Итерации повторяются до тех пор, пока макет не выявит все требования заказчика и не даст возможности разработчику понять, что должно быть сделано.
Достоинством макетирования является обеспечение определения полных требований к ПО.
К недостаткам макетирования относятся:
1) возможность принятия заказчиком макета за продукт;
2) возможность принятия разработчиком макета за продукт
Заказчик, получивший предварительную версию (макет) и удостоверившийся в ее работоспособности, может перестать видеть недостатки и нерешенные вопросы ПО и перестать соглашаться на дальнейшее усовершенствование, требуя скорейшего преобразования макета в рабочий продукт. В тоже время для экономии времени разработки макета, а также возможности показать работающий вариант, разработчик может использовать неэффективные средства. Забывая о причинах, побудивших использовать эти средства, разработчик может интегрировать неэффективный вариант в систему.
Существующие стратегии разработки ПО, которые можно подразделить на три группы:
1) линейная последовательность этапов разработки – однократный проход (водопадная стратегия);
2) инкрементная стратегия, когда сначала определяются все требования (пользовательские и системные), а затем оставшаяся часть разработки выполняется в виде последовательности версий, первая из которых реализует часть запланированных возможностей, а все последующие версии реализуют дополнительные возможности до тех пор, пока не будет получена полная система;
3) эволюционная стратегия.
При линейной стратегии начальный этап не содержит полного объема требований, они уточняются в ходе разработки новых последовательных версий.
Инкрементная модель является классическим примером инкрементной стратегии разработки ПО, объединяющей элементы последовательной водопадной модели с итерационной философией макетирования. Она содержит несколько поставок (инкрементов), представляющих собой последовательность анализа, проектирования, кодирования и тестирования.
Разработка первого инкремента позволяет получить базовый продукт, реализующий базовые требования, при этом многие вспомогательные требования остаются нереализованными. План следующих инкрементов предусматривает последовательную модификацию базового продукта, которые обеспечивают дополнительные характеристики и функциональность. По своей природе инкрементный процесс итеративен, но в отличие от макетирования инкрементная модель обеспечивает в конце инкрементной итерации работающий продукт.
Эволюционную стратегию рассмотрим на примерах спиральной модели, компонентно-ориентированной модели и тяжеловесных и облегченных процессов проектирования.
Спиральная модель опирается на лучшие свойства классического жизненного цикла и макетирования, к которым добавляется новый элемент – анализ риска, отсутствующий в моделях классического жизненного цикла и макетирования. Спиральная модель определяет планирование (определение целей, вариантов, ограничений), анализ риска (анализ вариантов и распознавание/выбор риска), конструирование (разработку продукта следующего уровня), оценивание (оценку заказчиком текущих результатов разработки).
С каждой итерацией по спирали (продвижением от центра к периферии) строятся все более полные версии ПО. В первом витке спирали:
1) определяются начальные цели, варианты и ограничения;
2) выполняется распознавание и анализ риска;
3) определяется необходимость использования макетирования;
4) осуществляется оценка заказчиком конструктивной работы и внесение предложения по модификации;
5) выполняется следующая фаза планирования и анализа риска, базируемая на предложениях заказчика.
В каждом цикле по спирали результаты анализа риска формируются в виде «продолжать, не продолжать». Если риск слишком велик, проект может быть остановлен. В большинстве случаев движение по спирали продолжается, с каждым шагом разработчики продвигаются к более общей модели системы. В каждом цикле по спирали требуется конструирование, которое может быть реализовано классическим жизненным циклом или макетированием.
К достоинствам спиральной модели относится:
1) наиболее реальное (в виде эволюции) отображение разработки программного обеспечения;
2) возможность явно учитывать риск на каждом витке эволюционной разработки;
3) включение шага системного подхода в итерационную структуру разработки;
4) использование моделирования для уменьшения риска и совершенствования программного изделия.
Недостатками спиральной модели являются:
1) повышенные требования к заказчику;
2) трудности контроля и управления временем разработки.
Компонентно-ориентированная модель является развитием спиральной модели и основывается на эволюционной стратегии разработки ПО. В этой модели конкретизируется содержание конструирования – оно отображает тот факт, что в современных условиях новая разработка должна основываться на повторном использовании существующих программных компонентов.
К достоинствам компонентно-ориентированной модели относится:
1) уменьшение времени разработки ПО;
2) снижение стоимости программной разработки;
3) повышение производительности разработки.
Традиционно для упорядочения и ускорения программных разработок использовались строго упорядочивающие так называемые тяжеловесные процессы. В этих процессах прогнозируется весь объем предстоящих работ, поэтому они называются прогнозирующимися процессами. Порядок действий, который должен выполнять при этом человек-разработчик, чрезвычайно строг.
В последние годы появилась группа новых облегченных процессов разработки ПО. Их также называют подвижными процессами. Эти процессы привлекательны отсутствием бюрократизма, характерного для тяжеловесных (прогнозирующих) процессов. Облегченные процессы разработки ПО воплощают разумный компромисс между строгой дисциплиной и отсутствием ее. Подвижные процессы требуют меньшего объема документации и ориентированы на человека. Подвижные процессы учитывают особенности современного заказчика, а именно, частые изменения его требований к ПО.