История каскадной модели в проектировании информационных систем

Министерство образования и науки РФ

ФГБОУ ВПО «Шадринский  государственный педагогический институт»

Кафедра прикладной информатики и экономики

 

 

 

 

 

 

 

 

 

 

 

 

 

 

ИСТОРИЯ КАСКАДНОЙ  МОДЕЛИ В ПРОЕКТИРОВАНИИ ИНФОРМАЦИОННЫХ СИСТЕМ

Курсовая работа по дисциплине

«Проектирование информационных систем»

 

Специальность: «080801.65 Прикладная информатика (в экономике)»

 

 

Выполнил:

студент 842 группы

факультета  информатики, математики и физики,

Камолов М.С.

Руководитель:

канд. физ.-мат. наук, доцент

Пирогов В.Ю.

 

Оценка:

_________________________

Подпись руководителя

_________________________

Нормоконтролер:__________

 

 

Шадринск, 2012

 

 

Оглавление

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Введение

 

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

Одним из наиболее распространенных классов систем обработки данных являются информационные системы.

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

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

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

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

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

В данной курсовой работе будет рассмотрена каскадная  модель (англ. waterfall model) — модель процесса разработки программного обеспечения, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки [3].

Объект: проектирование информационных систем.

Предмет: каскадная модель в проектировании.

Цель курсовой работы: рассмотреть историю каскадной модели в проектировании информационных систем.

Задачи:

1. Определить понятие «информационная система», рассмотреть структуру;
2. Охарактеризовать основные процессы жизненного цикла;
3. Рассмотреть сущность понятия «каскадная модель» и этапы работы;
4. Выявить достоинства и недостатки использования каскадной модели.

Курсовая работа состоит из введения, заключения, 2 глав, 4 параграфов, списка использованных источников.

Глава I. ИНФОРМАЦИОННАЯ СИСТЕМА

1. Жизненный цикл информационных систем. Понятие и структура

 

 

Это непрерывный  процесс, который начинается с момента  принятия решения о необходимости  создания информационных систем (далее – ИС) и заканчивается в момент ее полного изъятия из эксплуатации (рис. 1).

 

 

 

 

 

 

 

 

 

 

Рис. 1. Структурная схема терминов

Основным нормативным  документом, регламентирующим жизненный  цикл, является международный стандарт ISO/IEC 12207 (ISO – International Organization of Standardization – Международная организация  по стандартизации, IEC – International Electrotechnical Commission – Международная комиссия по электротехнике). Он определяет структуру жизненного цикла, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания информационной системы. Структура жизненного цикла по стандарту ISO/IEC 12207 базируется на трех группах процессов: основные, вспомогательные, организационные [1, с. 125].

2. Основные процессы жизненного цикла

 

 

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

К основным относятся  процессы приобретения, поставки, разработки, эксплуатации и сопровождения.

Процесс приобретения охватывает действия заказчика по приобретению ПП. К этим действиям относятся:

1. Инициирование приобретения включает в себя много задач, в том числе определение заказчиком своих потребностей в приобретении, разработки или усовершенствование системы ПП.
2. Подготовка заявочных предложений подразумевает разработку и составление предложений, которые должны содержать: требования к разрабатываемой или покупаемой системе; перечень необходимых ПП; условия и соглашения; технические ограничения.
3. Подготовка и корректировка договора включает в себя следующие задачи: выбор поставщиком критерия оценки предложений; выбор конкретного поставщика на основе анализа предложений; подготовка и заключение договора с поставщиком; внесение изменений (при необходимости) в договор в процессе его выполнения.
4. Надзор за деятельностью поставщика осуществляется в соответствии с действиями, предусмотренными в процессе совместной оценки аудита.
5. Приемка и завершение работ

В процессе приемки  подготавливаются и выполняются  необходимые тесты. Завершение работ  по договору осуществляется в случае удовлетворения всем условиям приемки.

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

К этим действиям  относятся [2, с. 82]:

1. Инициирование поставки заключается в рассмотрении поставщиком заявочных предложений и принятия решения;
2. Подготовка ответа на заявочные предложения выполняются в соответствии с принятыми решениями;
3. Подготовка договора осуществляется после выбора заказчиком конкретного поставщика;
4. Планирование выполняется после заключения договора и включает в селя следующие задачи: принятие решения поставщиком относительно выполнения работ своими силами или с подключением субподрядчика; разработку поставщиком плана управления проектом, содержащего организационную структуру проекта, разграничение ответственности, технические требования к среде разработки, управление субподрядчиками.

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

5. Выполнение и контроль
6. Проверка и оценка
7. Поставка и завершение работ выполняется в соответствии с оговоренными в процессе инициирования действиями по приемки и завершении работ.

Процесс разработки охватывает действия и задачи разработчика и предусматривает следующие основные направления работ:

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

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

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

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

Процесс документирования предусматривает формализованное  описание информации, созданной в  течении жизненного цикла (далее – ЖЦ) ПП.

Этот процесс  включает в себя:

1. Подготовительную работу, которая требуется для определения и согласования необходимого перечня документов и документируемых процедур;
2. Проектирование и разработку документации, которые выполняются в процессе работы над ПП и завершается одновременно с завершением его ЖЦ;
3. Выпуск документации, который осуществляется по мере ее готовности;
4. Сопровождение включает в себя действия по корректировки и обновлению документации в процессе ЖЦ ПП.

Процесс управления конфигурацией предполагает применение административных и технических процедур на всем протяжении ЖЦ ПП.

Согласно стандарту IEEE-90 под конфигурацией ПП понимается совокупность его функциональных и физических характеристик, установленных в технической документации и реализованных в ПП.

Этот процесс включает в себя:

1. Подготовительную работу, которая заключается в планировании управления конфигурацией;
2. Идентификацию конфигурации – устанавливает правила, с помощью которых можно однозначно идентифицировать и различать компоненты ПП и их версии. Кроме того каждому компоненту и его версиям соответствует однозначно обозначаемый комплект документации;
3. Контроль конфигурации – предназначен для систематической оценки предполагаемых модификаций ПП и координированной их реализации с учетом эффективности каждой модификации и затрат на ее выполнение;
4. Учет состояния конфигурации – представляет собой регистрацию состояния компонентов ПП, подготовку отчетов обо всех реализованных и отвергнутых модификациях версий компонентов ПП;
5. Оценку конфигурации – заключается в оценки функциональной полноты компонентов ПП;
6. Управление выпуском и поставкой включает в себя изготовление эталонных копий программ и документации, их хранение и поставку пользователям в соответствии с порядком, принятом в организации.

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

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

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

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

Процесс аттестации предусматривает определение полноты  соответствия заданных требований к  создаваемой системе или ПП.

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

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

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

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

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

Разрешение проблем проводится на всем протяжении ЖЦ ПП.

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

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

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

Процесс усовершенствования предусматривает оценку, измерение, контроль, усовершенствование процессов  ЖЦ ПП.

Усовершенствование процессов  ЖЦ ПП направлено на повышение производительности труда всех участвующих в них специалистов за счет совершенствования используемой технологии, методов управления, выбора инструментальных средств и обучения персонала.

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

 

 

 

 

 

 

 

Вывод по главе I

 

Жизненный цикл информационных систем - это непрерывный  процесс, который начинается с момента  принятия решения о необходимости  создания информационных систем (далее  – ИС) и заканчивается в момент ее полного изъятия из эксплуатации.

Структура жизненного цикла, содержит процессы, действия и задачи, которые должны быть выполнены во время создания информационной системы. Структура жизненного цикла по стандарту ISO/IEC 12207 базируется на трех группах процессов: основные, вспомогательные, организационные.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Глава II. КАСКАДНАЯ МОДЕЛЬ ЖИЗНЕННОГО ЦИКЛА ИНФОРМАЦИОННОЙ СИСТЕМЫ

1. Сущность понятия «каскадная модель», этапы работы

 

 

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

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

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

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

 

 

 

 

 

 

 

 

Рис. 2. Каскадная модель разработки

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

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

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

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

Последний этап — сдача готового проекта.

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

2. Достоинства и недостатки использования каскадной модели

 

 

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

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

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

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

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

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

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

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

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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Рис. 3 Реальный процесс создания ИС на базе каскадной модели

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

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