Методология организации проектирования информационных систем

Содержание

 

Введение

 

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

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

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

Цель работы: систематизировать знания в области организации и проектирования информационных систем, получить навыки моделирования автоматизированных информационных систем и ознакомиться с основными частями унифицированного языка моделирования UML.

Задача курсовой работы: получить навыки при моделировании информационной системы «Ресторан», используя средства языка моделирования UML.

 

1. Теоретическая часть.  Методология организации проектирования информационных систем

1.1. Жизненный цикл информационных систем

 

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

Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207 (ISO - International Organization of Standardization - Международная организация по стандартизации, IEC - International Electrotechnical Commission - Международная комиссия по электротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.

Структура ЖЦ ПО по стандарту ISO/IEC 12207 базируется на трех группах процессов:

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

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

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

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

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

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

 

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

 

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

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

Модель предполагает следующие свойства взаимодействия этапов:

- модель состоит из  последовательно расположенных  этапов;

- каждый этап полностью  заканчивается до того, как начнется  следующий;

- этапы не перекрываются  во времени: следующий этап не  начинается до тех пор, пока не завершится предыдущий;

- возврат к предыдущим  этапам не предусмотрен либо  всячески ограничен;

- исправление ошибок происходит  лишь на стадии тестирования;

- результат появляется  только в конце разработки.

Рисунок 1 - Каскадная модель жизненного цикла.

Критерием появления результата при каскадной модели ЖЦ является отсутствие ошибок и точное соответствие продукта первоначальной спецификации.

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

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

• этапы работ выполняются в логичной последовательности;

• возможно жестко планирование сроков завершения работ и соответствующих затрат.

Недостатки каскадной схемы:

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

2. Несоответствие разработанной  системы ожиданиям заказчика.

3. Превышение сроков и  сметы разработки или искажение  требований к системе.

4. Примитивная автоматизация  существующих производственных процессов.

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

 

1.3. Поэтапная модель с промежуточным контролем

 

Поэтапная модель с промежуточным контролем  еще известна как итерационная модель или «водоворот».

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

Модель характеризуется следующими свойствами взаимодействия этапов:

- модель состоит из  последовательно расположенных  этапов (точно так же, как и  «водопад»);

- каждый этап имеет  обратную связь с предыдущими  этапами;

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

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

- результат появляется  только в конце разработки, как  и в модели «водопад».

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

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

1.4. Спиральная модель жизненного цикла

 

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

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

Модель предполагает также свойства взаимодействия этапов: