Проектирование ИС

Содержание

Введение…………………………………………………………………………..3

Глава 1. Понятие  и классификация требований заказчика  в процессе проектирования информационной системы……………………………………5

1. Определение понятия требования………………………………………….5
2. Классификация требований………………………………………………...5
1. Требования к продукту и процессу………………………………………6

1.2.2.Уровни требований…………………………………………………………7

1.2.3. Системные  требования и требования к  программному обеспечению….9

1.2.4. Функциональные, нефункциональные требования и  характеристики продукта………………………………………………………………………….10

1.2.5. Классификация Rational Unified Process (RUP)…………………………12

1.3. Свойства  требований………………………………………………………..12

Глава 2. Анализ требований заказчика в процессе проектирования ИС…….21

2.1. Выявление  требований……………………………………………………..24

2.2. Формирование  видения…………………………………………………….26

2.3. Классификация  и специфицирование требований…………………….....30

2.4. Расширенный  анализ требований………………………………………….37

2.5. Документирование  требований……………………………………………40

2.6. Проверка  требований……………………………………………………….46

Глава 3. Моделирование  деятельности детского развлекательного центра…48

3.1. Краткая информация  о компании………………………………………….48

3.2. Формирование  бизнес-процессов………………………………………….50

3.3. Моделирование бизнес-процессов в программной среде AllFusion rocess Modeler (BPwin)………………………………………………………….57

Заключение………………………………………………………………………62

Список использованных источников…………………………………………..63 
 
 

Введение

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

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

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

• Понятие и классификация требований заказчика в процессе проектирования информационной системы;
• Свойства требований;
• Выявление требований;
• Формирование видения;
• Расширенный анализ требований;
• Документирование требований;

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

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

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

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

     Завершить практическую часть, и всю курсовую работу в целом, планируется их моделированием в программной среде AllFusion Process Modeler (BPwin).  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

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

1.1. Определение понятия требования

      Существует  множество определений понятия  «требование», например в одном из источников это понятие трактуется так, Требование - это:

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

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

1.2. Классификация требований

      Существует  значительное количество различных  методов классификации требований, наиболее существенные из которых будут рассмотрены далее. 

1.2.1. Требования к продукту и процессу

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

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

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

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

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

1. Разработчик представляет Заказчику согласованный детализированный план работ с точностью до конкретных исполнителей.
2. Разработчик осуществляет ежедневные сборки, регрессионное тестирование компонент разрабатываемого продукта и тестирование продукта в целом.
3. Все управленческие и проектные артефакты, исходные коды и тестовые примеры размещаются в режиме он-лайн в интегрированной среде разработки Rational ClearCase с возможностью для Заказчика осуществления он-лайн мониторинга на базе web-технологий.

1.2.2.Уровни требований

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

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

Обычно выделяют три уровня требований:

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

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

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

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

1.2.3.

Системные требования и требования к программному обеспечению