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

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

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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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

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

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

 

Специальность: «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. Управление выпуском и поставкой включает в себя изготовление эталонных копий программ и документации, их хранение и поставку пользователям в соответствии с порядком, принятом в организации.

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

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

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

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

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