Файл: Рассматриваемая дипломная работа написана на базе Донецкой оао донецкая мануфактура для магазина Cleonelly.docx

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

Последним из понятий IDEF0 является глоссарий (Glossary). Для каждого из элементов IDEF0: диаграмм, функциональных блоков, интерфейсных дуг существующий стандарт подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображенный данным элементом. Этот набор называется глоссарием и является описанием сущности данного элемента. [24]

Рассмотрим диаграммы бизнес-процессов протекающие на складе магазина ОАО ДММ, «Cleonelly»:

Для общей видимости системы необходимо построить контекст «Деятельность склада предприятия» (смотри рисунок 1.1).


Рисунок 1.1 – Диаграмма «Деятельность склада предприятия»
После того как контекст установлен, проводится декомпозиция, т.е. построение следующих диаграмм в иерархии.

Каждая последующая диаграмма является более подробным описанием одной из работ на вышестоящей диаграмме. Пример декомпозиции контекстной работы показан на рисунке 1.2. Таким образом, вся система разбивается на подсистемы до нужного уровня детализации, данная система разбивается на три уровня.


Рисунок 1.2 – Диаграммы декомпозиции первого уровня
Далее каждый из блоков декомпозиции системы будет еще разбиваться, декомпозиция «Оформление товара» можно увидеть на рисунке 1.3, «Отпуск товара» – рисунок 1.4, «Оприходывание товара» – рисунок 1.5.


Рисунок 1.3 – Диаграмма «Оформление товара»


Рисунок 1.4 – Диаграмма «Отпуск товара»


Рисунок 1.5 – Диаграмма «Оприходывание товара»
DFD. В основе данной методологии лежит построение модели анализируемой ИС – проектируемой или реально существующей. В соответствии с методологией модель системы определяется как иерархия диаграмм потоков данных (DFD), описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи пользователю. Диаграммы DFD обычно строятся для наглядного изображения текущей работы системы документооборота организации. Чаще всего диаграммы DFD используют в качестве дополнения модели бизнес-процессов, выполненной в IDEF0.

---

Основными компонентами диаграммы потоков данных являются:

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

• 
  системы/подсистемы (графически выглядит как прямоугольник с округленными углами) – работы обозначающие функции или процессы, которые обрабатывают и изменяют информацию;
  

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

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

Рассмотрим диаграмму потоков данных (DFD) «Отпуск товара» рисунок 1.6. На этой диаграмме показано движение документов при поступлении в организацию «заявки на товар».


Рисунок 1.6 – Диаграмма DFD «Отпуск товара»
Рассмотрим следующую диаграмму потоков данных «Оформление товара» (смотри рисунок 1.7). Здесь показано процесс выполнения работ и движение документов при «отпуске товара».


Рисунок 1.7 – Диаграмма DFD «Оформление товара»
В диаграммах потоков данных все используемые символы складываются в общую картину, которая дает четкое представление о том, какие данные используются, и какие функции выполняются системой документооборота. При этом часто выясняется, что существующие потоки информации, важные для деятельности компании, реализованы ненадежно и нуждаются в реорганизации.*******

Организационная структура предприятия, занимающегося продажей махровых изделий, рассмотрена на примере компании ОАО “Донецкая Мануфактура М” магазина Cleonelly:

---

В направлении разработки систем контроля и учета материалов могут успешно решать проблемы:

1. 
   Это контроль за поставляемыми и хранящимися на складе товарами.
   
2. 
   Информацию о поставщиках и потребителях
   
3. 
   Также содержится информация информация и операции по товару
   
4. 
   Содержится журнал отчета отпущенного товара
   
5. 
   Содержится справочник товаров
   
6. 
   Автоматизация складских функций (приход, расход, списание, резервирование товара)
   
7. 
   Регистрация и хранение счетов на приобретаемый и продаваемый товар и за услуги, а также выписка счетов по предоплате, с отсрочкой платежа и с доставкой товара
   
8. 
   Создание накладных и учет выданного товара
   
9. 
   Проведение инвентаризации складов с созданием сличительной ведомости, акта недостачи и излишек
   
10. 
    Создание комплектов товаров
    

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

3. 1   2   3   4   5   6   7   8   9   10

---

Сбор требований

При проектировании информационной системы (ИС) «АРМ Оптового Магазина», было необходимо собрать требования, которые помогли бы создать интерфейс таким образом, что конечному пользователю (работнику магазина) было удобно работать с разработанной ИС.

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

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

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

Работа программы осуществляется в операционной системе Windows 2000/NT/XP.

Различают четыре основных этапа процесса разработки требований (рисунок 1.8):

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

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

4. Спецификация требований

Определение корректных требований — это, наверное, самый ответственный этап программного проекта. Очень важно, чтобы формат проекта соответствовал требованиям к ПО, собранным командой разработчиков, в противном случае эти требования не смогут быть поддержаны и представлены в программном продукте. Спецификация требований к ПО - Software Requirements Specification(SRS) имеет ключевое значение для всего жизненного цикла разработки программного продукта. Это не только производный документ, в котором

---

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

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

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

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

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

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

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

---