Файл: Основы программирования на языке Pascal (Основные понятия, классификация и структура информационных систем).pdf

• 1. Жизненный цикл и модели жизненного цикла информационных систем

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

Основными стадиями в процессе являются [10]:

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

Рисунок 2 – Основные стадии создания ИС

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

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

Рисунок 3 - Каскадная модель ЖЦ ИС

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

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

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

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

Рисунок 5 - Спиральная модель ЖЦ ИС

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

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

Сама каскадная модель имеет множество преимуществ, но только при условии использования ее в проекте, приемлемом для нее. Ниже представлены ее преимущества:

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

• лучше справляется с трудностями и отлично срабатывает в тех проектах, где все достаточно понятно, но трудноразрешимо;

• легко доступна для понимания, так как нацелена на выполнение необходимых действий;

• проста и удобно в использовании, т.к. процесс разработки идет поэтапно.

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

• Основа модели – линейная последовательная структура, и в результате попытки вернуться назад на одну-две фазы для исправления проблемы или недостатка теряется много времени, увеличиваются затраты и срывается график работы;

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

• не показывает главное свойство разработки ПО, которое направлено на решение задачи. Отдельные фазы связаны определенными действиями, что часто отличается от привычной работы коллектива или персонала;

• создает ошибочное впечатление о работе с проектом. Указание, что «45% выполнено» обычно не имеет какого-то смысла и не служит показателем для менеджера проектов.

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

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

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

Реализация жизненного цикла системы, как и многие процессы эволюционировали. Самые известные модели жизненного цикла и время их появления:

• каскадная модель, 70-е года двадцатого века;

• итерационная модель, 70-80 года двадцатого века;

• спиральная модель, начало 80-х годов двадцатого века.[1]

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

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

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

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

Внедрение разработанной информационной системы может производится в соответствии с четырьмя стратегиями:

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

3) Пилотный проект – такая стратегия, при которой разработанная информационная система вначале оценивается на одном узком секторе деятельности компании, а затем, по итогам такого использования, проводится внедрение остальной ее части;

4) Узкое место – при внедрении «узкого места», план выполняется только для него самого, а также для сотрудников, которые там работают.

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

• 1. Проектирование и основные технологии разработки информационных систем

К базовым технологиям проектирования АИС можно отнести:

• объектно-ориентированный подход;

• функционально-модульный или структурный подход.

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

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

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

В процессе функционального подхода объектные модели данных в виде ER-диаграмм "объект — свойство — связь" создаются отдельно. Чтобы проверить правильность проектирования предметной области между объектными и функциональными моделями выделяются взаимно однозначные связи.

Основной недостаток такого подхода объясняется движением данных в одном направлении. При наличии какой-либо сложности в ходе разработки в соответствии с таким стандартом она может решиться только на данной стадии и никак не может быть связана с другими стадиями разработки [20].

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

В объектно-ориентированном подходе (ООП) главной категорией объектной модели является класс, который включает в себя на элементарном уровне, как данные, так и операции, которые над ними реализуются (методы). Именно с такой позиции все изменения, относящиеся к переходу от структурного к ООП, становятся максимально заметными. Разделение процессов и данных устранено, но существует еще вопрос по минимизации сложности системы, который решается методом применения механизма компонентов[22].

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

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

1) Объектная декомпозиция позволяет разрабатывать программные системы более компактного размера при помощи общих механизмов, которые дают необходимую экономию выразительных средств. Применение объектного подхода значительно увеличивает уровень оптимизации разработки и пригодность для последующих применений не только программ, но и проектов, что позволяет создать среду разработки и перейти к сборочному созданию ПО. Системы практически всегда получаются более компактными, чем их структурные эквиваленты, что показывает не только уменьшение объема кода программы, но и уменьшение затрат на проект за счет применения итогов предыдущих разработок[23];

2) Объектная декомпозиция минимизирует риск разработки сложных систем ПО, основывается на эволюционном пути развития системы на базе небольших внутренних подсистем. Процесс объединения системы проходит на протяжении всего времени разработки и не становится единовременным событием;

3) Объектная модель очень естественна, поскольку изначально ориентирована на человеческое восприятие мира, а не IT-реализацию;

4) Объектная модель дает возможность максимально использовать выразительные способности объектных и объектно-ориентированных средств программирования.

К недостаткам ООП относят небольшое снижение эффективности функционирования ПО и повышенные начальные затраты.

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

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

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