Файл: Лекция Введение. Основные понятия. Корпоративные информационные системы. Структура кис.docx

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

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

Вспомогательные процессы ЖЦ ИС

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

 Организационные процессы ЖЦ ИС

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

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

 Структура жизненного цикла ИС

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

      Согласно методологии, предлагаемой Rational Software, ЖЦ ИС подразделяется на четыре стадии: начало, уточнение, конструирование, сдача в эксплуатацию. Границы каждой стадии определены некоторыми моментами времени, в которые должны быть достигнуты определенные ключевые цели.

---

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

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

      Стадия конструирования: разрабатывается законченное изделие, готовое к передаче пользователю.

      Сдача в эксплуатацию: готовая ИС передается пользователю. 

---

Лекция 6. Основные модели ЖЦ ИС. Каскадная модель: характеристика, достоинства, недостатки. Спиральная модель: характеристика, достоинства, проблемы.

Модели жизненного цикла ИС

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

     К настоящему времени наибольшее распространение получили следующие две основные модели ЖЦ ИС: каскадная модель (модель «водопад» – waterfall ) и спиральная модель.

 Каскадная модель жизненного цикла ИС

     Каскадная модель (КМ) характерна для классического подхода к разработке различных систем в любых прикладных областях. Для разработки ИС данная модель широко использовалась в 70-80-х годах. Каскадные методы проектирования хорошо описаны в отечественной и зарубежной литературе. Организация работ по каскадной схеме официально рекомендовалась и широко применялась в различных областях

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

Основные этапы разработки по КМ

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

· анализ требований заказчика ;

· проектирование ;

· разработка ;

· тестирование и опытная эксплуатация ;

· сдача готового проекта

     На первом этапе проводится исследование проблемы, четко формулируются требования заказчика. Результат этапа – техническое задание (ТЗ), согласованное со всеми сторонами.

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

     Третий этап – реализация проекта. Здесь разрабатывается программное обеспечение (кодирование) в соответствии с проектными решениями, полученными на предыдущем этапе. Методы, используемые для реализации, принципиального значения не имеют. Результат этапа – готовый программный продукт.

---

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

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

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

Основные достоинства каскадной модели

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

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

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

Недостатки каскадной модели

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

Основные недостатки каскадной модели следующие:

1. существенная задержка получения результатов;

2. необходимость возврата на предыдущие этапы;

3. сложность распараллеливания работ по проекту;

4. информационная перенасыщенность каждого этапа;

5. сложность управления проектом ;

6. высокий уровень риска и ненадежности инвестиций.

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

---

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

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

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

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

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

      Сложность управления проектом обусловлена строгой последовательностью стадий разработки и наличием сложных взаимосвязей между частями проекта. Последовательная разработка  одни группы разработчиков должны ждать результатов работы других.  Требуется административное вмешательство для согласования сроков работы и состава передаваемой документации. А если обнаружена ошибка и необходим возврат к предыдущим стадиям?  поиск виновных  сложные отношения в коллективе  проблемы у руководства; несовместимость строгой дисциплины и творчества  самые талантливые разработчики уйдут.

---