Лекции по "Информационные системы"

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

Вспомогательные процессы

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

Организационные процессы

Управление проектом связано  с вопросами планирования и организации  работ, создания коллективов разработчиков  и контроля за сроками и качеством выполняемых работ. Техническое и организационное обеспечение проекта включает:

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

Обеспечение качества проекта  связано с проблемами верификации, проверки и тестирования компонентов  информационной системы.

Верификация — это процесс определения соответствия текущего состояния разработки, достигнутого на данном этапе, требованиям этого этапа.

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

Структура жизненного цикла информационной системы

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

Начальная стадия

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

Деловое применение включает:

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

Стадия  уточнения

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

Стадия  конструирования

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

Стадия  перехода

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

Основные этапы  разработки по каскадной модели

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

разработки, практически  не зависящих от предметной области:

• анализ требований заказчика;
• проектирование;
• разработка;
• тестирование и опытная эксплуатация;
• сдача готового продукта

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

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

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

На четвертом  этапе проводится проверка полученного программного обеспечения на предмет соответствия требованиям, заявленным в техническом задании. Опытная эксплуатация позволяет выявить различного рода скрытые недостатки, проявляющиеся в реальных условиях работы информационной системы. Последний этап - сдача го нового проекта. Главная задача этого этапа — убедить заказчика, что все его требования реализованы в полной мере. Этапы работ в рамках каскадной модели часто также называют частями «проектного цикла» системы. Такое название возникло потому, что этапы состоят из многих итерационных процедур уточнения требований к системе и вариантов проектных решении. Жизненный цикл самой системы существенно сложнее ее и больше. Он может включать в себя произвольное число циклов уточнения, изменения и дополнения уже принятых и реализованных проектных решений. В этих циклах происходит развитие информационной системы и модернизация отдельных ее компонентов.

Лекция 10

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

Каскадная модель имеет ряд  положительных сторон, благодаря  которым она хорошо зарекомендовала себя при выполнении различного рода инженерных разработок и получила широкое распространение. Рассмотрим основные достоинства модели «водопад»:

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

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

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

Перечень недостатков  каскадной модели при ее использовании  для разработки информационных систем достаточно обширен. Вначале просто перечислим их, а затем рассмотрим основные из них более подробно:

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

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

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

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

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

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

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