- обследование объекта и обоснование необходимости создания ИС;

- формирование отчета о выполненной работе и заявки на разработку тактико-технического задания.

2. Разработка концепции АС:

- изучение объекта (модель «AS IS» (как есть));

- разработка вариантов концепции ИС и выбор варианта (модели «TO BE» (как должно быть));

- оформление отчета о выполненных работах.

3. Техническое задание:

- разработка и утверждение ТЗ.

4. Эскизный проект:

- разработка предварительных проектных решений по системе и ее ча-стям (определяются функции ИС, функции подсистем; состав комплексов задач и интерфейсов; концепция БД, ее укрупненная структура; функции СУБД; состав вычислительной системы; функции и параметры основных аппаратных средств);

- разработка документации на ИС.

5. Технический проект:

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

граммному обеспечению);

- разработка документации на АС (полное описание совокупности принятых проектных решений и достаточного для дальнейшего выполнения работ по созданию ИС (ГОСТ 34.201)).

6. Рабочая документация:

- разработка рабочей документации на систему и ее части (для обеспе-чения работы по вводу ИС в эксплуатацию, а также для поддержания уров-ня эксплуатационных характеристик системы (ГОСТ 34.201));

- разработка или адаптация (покупных) программ.

7. Ввод в действие:

- подготовка объекта автоматизации к вводу ИС в действие (организационная подготовка);

- подготовка персонала;

- строительно-монтажные работы;

- пуско-наладочные работы (автономная наладка технических и программных средств, загрузка информации в БД; комплексная наладка всех средств системы);

- проведение предварительных испытаний;

- проведение опытной эксплуатации;

- проведение приемочных испытаний.

8. Сопровождение АС:

- выполнение гарантийных обязательств;

- анализ функционирования ИС, ее модификация и выпуск новых вер-сий.

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

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

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

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

Проектирование и разработка сложных ИС может быть выполнена с применением программных инструментариев СУБД Oracle: функциональ-ная модель может быть построена с помощью Process Modeller, Function Hierarchy Diagrammer; база данных логического уровня – с помощью Entity Relationship Diagrammer; пользовательский интерфейс – на основе языка 4-го поколения Oracle Forms и программные модули на языке 3-го поколения PL/SQL.

Для проектирования и разработки простых ИС, в том числе и для учебных целей, удобно использовать более простые программные инструментарии. Обычно в этих случаях применяют пакет BPwin для построения всего комплекта диаграмм для описания функционального наполнения предметной области: организационная диаграмма, диаграммы плавательных дорожек и интегрированная иерархическая функциональная модель на основе методологий IDEF0, IDEF3, DFD.

Информационная модель логического и физического уровней строится с помощью пакета ERwin в виде ER-диаграммы.

Пользовательский интерфейс и программные модули реализуются в среде СУБД Access или с помощью средства быстрого разработки программного обеспечения Delphi.

3. Построение функциональной модели ИС

3.1. Методология IDEF0

Для построения функциональных моделей обычно используется методология IDEF0, которая хорошо представлена в пакетах Design/IDEF и BPwin (All Fusion Process Modeler 4.1) [3].

Методология IDEF0, более известная как методология SADT (Structure Analysis and Design Technique) предназначена для представления функ-ций системы и анализа требований к системам. Она является одной из самых известных и широко используемых методологий проектирования ИС.

Построение IDEF0-моделей в среде этих двух пакетов практически не отличается, но в BPwin возможно построение интегрированных функциональных моделей, объединяющих три вида методологий: IDEF0, IDEF3 и Data Flow Diagramm (диаграмм потоков данных, DFD).

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

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

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

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

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

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

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

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

Диаграммы являются главными компонентами модели.

Основными элементами диаграмм являются функциональные блоки и дуги, которые представляются соответственно прямоугольниками и стрел-

ками.

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

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

В IDEF0 используется четыре типа дуг: входные (INPUT), управления (CONTROL), выходные (OUTPUT) и механизма (MECHANIZM), представ-ляющие собой ICOM-объекты (аббревиатура из первых букв английских названий дуг). В качестве иллюстрации приведем контекстную диаграмму функциональной модели кардиологического терапевтического отделения (рис. 3).

Рис. 3. Контекстная диаграмма методологии IDEF0

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

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

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

Дуги механизмов или управления могут быть входами других блоков.

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

Контекстная диаграмма является верхним уровнем иерархии функци-ональной модели и представляет собой наиболее обобщенную схему функционирования предметной области.

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

Рис. 4. Окно выбора методологий и количества блоков декомпозиции.

Щелкнув по клавише ОК, получают диаграмму декомпозиции первого уровня, которая содержит: выбранное выше количество блоков и ICOM-коды, то есть названия всех дуг контекстной модели. Необходимо дать названия блокам, подсоединить к ним по смыслу ICOM-объекты и построить требуемые соединительные (внутренние) дуги, присвоив им названия (рис. 5).

Если ICOM-объекты не используются на каком-либо уровне иерархии, то дуги, соединяющие эти объекты, можно поместить в туннель. Причем если в туннель помещен конец дуги (конец дуги помещается в квадратные скобки), то дуга и соответствующий ей ICOM-объект отсутствует на диаграмме-родителе. Если в туннель помещено начало дуги, то дуга и соответствующий ей ICOM-объект отсутствуют на диаграмме-потомке (дуга ВРАЧ на рис. 3).

Рис. 5. IDEF0-диаграмма второго уровня иерархии

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

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

При удалении объекта его необходимо выделить, а затем нажать на клавишу <Delete>.

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

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

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

Для редактирования имен объектов необходимо с ним совместить курсор, с помощью ПКМ вызвать контекстное меню и воспользоваться командой Name.

Для удаления какой-либо из диаграмм, ее необходимо открыть, выполнить команду Edit/Delete diagram и щелкнуть по кнопке Delete. Другой вариант удаления – выполнить команду Diagram / Diagram manager.

Для сохранения модели требуется выполнить команду File/Save. Если модель сохраняется впервые, то при выполнении этой команды откроется окно диалога Save Diagram As. В разделе “Имя файла” надо набрать на клавиатуре имя файла (рекомендуется давать имя файла латинскими буквами) и нажать <OK>.

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

Рис. 6. Дерево узлов

Иерархия IDEF0-модели может быть представлена в виде дерева узлов. Для этого необходимо воспользоваться командой Node Tree diagrams в навигаторе, запускающей Мастер построения диаграммы (Node Tree Wizard), который позволяет задать необходимые опции для выбора нужного типа диаграммы.

3.2. Стоимостный анализ (Activity Based Costing, ABC)

BPwin предоставляет аналитику инструмент для оценки модели – сто-имостный анализ, основанный на работах (Activity Based Costing, ABC),с целью определить общую стоимость процесса. Стоимостный анализ основан на модели работ, потому что количественная оценка невозможна без детального понимания функциональности предприятия. Обычно ABC при-меняется для того, чтобы понять происхождение выходных затрат и облегчить выбор нужной модели работ при реорганизации деятельности пред-

приятия (Business Process Reengineering, BPR).

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

Рис. 7. Настройка единиц измерения валюты и времени

При проведении стоимостного анализа в BPwin сначала задаются единицы измерения времени и денег. Для задания единиц измерения следует вызвать диалог Model Properties (меню Model/Model Properties), вкладка ABC Units (рис. 7).

Затем описываются центры затрат (cost centers). Для внесения центров затрат необходимо вызвать диалог Cost Center Dictionary (меню Dictionary / Cost Center (рис. 8). Каждому центру затрат следует дать подробное описание в окне Definition. Для отдельной модели задается один набор функциональных центров.

Для задания стоимости работы (для каждой работы на диаграмме декомпозиции нижнего уровня) следует щелкнуть ПКМ по работе и на всплывающем меню выбрать Costs (рис. 9). Во вкладке Costs диалога Activity Properties указывается частота проведения данной работы в рамках общего процесса (окно Frequency) и продолжительность (Duration). Затем следует выбрать в списке один из центров затрат и в окне Cost задать его стоимость. Аналогично назначаются суммы по каждому центру затрат, т.е. задается стоимость каждой работы по каждой статье расхода.

Рис. 8. Диалог Cost Center Dictionary

Общие затраты по работе рассчитываются как сумма по всем центрам затрат. При вычислении затрат вышестоящей (родительской) работы сначала вычисляется произведение затрат дочерней работы на частоту работы (число раз, которое работа выполняется в рамках проведения родительской работы), затем результаты складываются. Если во всех работах модели включен режим Compute from Decompositions (в окне Activity Properties), подобные вычисления автоматически проводятся по всей иерархии работ снизу вверх.

Рис. 9. Задание стоимости работ в диалоге Activity Cost

4. Построение ER-диаграммы

4.1. Общие сведения о методологии IDEF 1 X

Методология IDEF1X представляет собой семантическое моделирование данных и применяется для построения информационной модели в виде ER-диаграммы (рис. 10), которая представляет структуру информации, необходимой для поддержания функции производственной системы или среды.

Основными конструкциями ER-диаграммы являются:

1. Предметы (сущности), к которым относятся данные. Они изобража-ются блоками.

2. Отношения между этими предметами, которые изображаются с по-мощью линий, соединяющих эти блоки.

3. Характеристики этих предметов, изображаемые именами атрибутов внутри блоков.

Рис. 10. ER-диаграмма

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

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

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

Независимая сущность рисуется прямоугольником. Зависимая сущность рисуется прямоугольником с закругленными углами.

Каждой сущности присваиваются уникальное имя, которое помещается над блоком.

Имя является грамматическим оборотом существительного в единственном числе (у существительного могут быть прилагательные и предлоги).

Сущность может иметь список синонимов и псевдонимов, и все они должны быть приведены в глоссарии модели.

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

Правила, связанные с сущностями:

1. Каждая сущность должна иметь уникальное имя.

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

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

4. Каждая сущность может обладать любым количеством отношений с другими сущностями модели.

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

Отношениe родитель-потомок – это связь между сущностями, при которой одна сущность, называемая родительской, и может быть связана с произвольным (в том числе и нулевым) количеством экземпляров второй сущности, называемой сущностью-потомком. Каждый экземпляр сущности-потомка связан в точности с одним экземпляром сущности-родителя. Таким образом, экземпляр сущности потомка может существовать только при наличии сущности-родителя.

Отношение связи может дополнительно определяться с помощью указания мощности отношения. Мощность отношения определяет, какое количество экземпляров сущности-потомков может существовать для каждого экземпляра сущности-родителя.

Существует четыре типа мощности отношения:

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

- каждый экземпляр сущности-родителя может иметь не менее одного связанного с ним экземпляра сущности-потомка (P);

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

- каждый экземпляр сущности-родителя связан с некоторым фиксированным числом экземпляров сущности-потомка (N).

Отношения связи отображаются линией с точкой на конце у сущности-потомка. Рядом с этой линией указывается мощность отношения (P, Z или N).

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

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

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

Правила отношений:

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

2. Экземпляр сущности-родителя может быть связан с любым числом (0 и более) экземпляров сущности-потомка, в зависимости от указанной мощности отношения.

3. В идентифицирующем отношении сущность-потомок всегда является зависимой от идентификатора сущностью.

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

4.2. Отношения категоризации

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

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

Рис. 11. Фрагмент ER-диаграммы с отношением полной категоризации

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

Допускается существование неполного множества категорий. Например, если существует экземпляр общей сущности, не связанный ни с одним экземпляром сущности-категории, то такое отношение называется отношением неполной категоризации.

При наличии между сущностями отношений категоризации в экземп-

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

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

Отношение категоризации не именуется, но может звучать как “может быть”.

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

Правила отношений категоризации

1. Сущность-категория может иметь только одну общую сущность.

2. Сущность-категория может быть общей сущностью.

3. Атрибуты первичного ключа общей сущности и сущности-катего-рии должны совпадать.

4. Все экземпляры сущности-категории имеют одно и то же значение дискриминатора.

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

Рис.12. Пример неспецифического отношения

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

Рис. 13. Пример введения сущности-пересечения

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

4.3. Синтаксис атрибутов и ключей

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

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

Правила атрибутов:

1. Сущность может обладать любым количеством атрибутов.

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

сущности-родителя или общей сущности.

3. Каждый экземпляр сущности должен иметь значение для каждого атрибута.

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

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

Правило первичных и альтернативных ключей

1. Каждая сущность должна обладать первичным ключом.

2. Каждая сущность может обладать любым числом альтернативных ключей.

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

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

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

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

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

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

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

В некоторых случаях сущность-потомок может иметь несколько отно-шений с одной и той же сущностью-родителем.

Первичные ключи сущности-родителя в этом случае появляются в сущности-потомке в качестве наследуемых атрибутов для каждого отноше

ния.

Внешний ключ помещается внутри блока сущности как наследуемый атрибут с буквами (FK) - Foreign Key (рис. 10).

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

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

Имена атрибутов являются грамматическими оборотами существительного.

Правила внешних ключей

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

2. Первичный ключ общей сущности должен наследоваться в качестве внешнего ключа для каждой сущности-категории.

3. Каждое присвоенное наследуемому атрибуту имя роли должно быть уникальное.

4.4. Процедуры моделирования ER-диаграммы

Сам процесс моделирования разбивается на пять стадий.

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

Стадия 2 – идентифицируются и определяются сущности.

Стадия 3 – идентифицируются и определяются соотношения между сущностями.

Стадия 4 – идентифицируются и определяются ключи.

Стадия 5 – идентифицируются и определяются неключевые атрибуты.

Стадия 1 – начало работы над проектом

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

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

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

Стадия 2 - определение сущностей

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

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

1. Может ли она быть описана, т.е. обладает какими-либо характерными особенностями?

2. Существует ли более одного экземпляра этой сущности?

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

4. Называет или описывает это что-либо? Если этот ответ положительный, то это скорее атрибут, чем сущность.

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

В качестве примера можно привести существительные, используемые для описания модели на рис. 38: комитет, МУП, заявка, сводная заявка , наименование товара, цена, адрес, руководитель, поставщик , сотрудник , образование, должность, дата заявки, реквизиты банка и др. Выделенные жирным шрифтом слова соответствуют требованиям, указанным в пп.1-4. Оставшиеся слова можно использовать в качестве атрибутов.

На четвертом этапе некоторые сущности из этого списка могут быть исключены и добавлены новые.

.

Стадия 3 - определение отношений

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

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

Рис. 14. Матрица “сущность-отношение”

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

Не следует устанавливать чрезмерное количество отношений между сущностями. Следует иметь в виду, что с помощью этой матрицы вы описываете модель в терминах отношений “родитель-потомок”.

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

1. Указание зависимостей.

2. Имя отношения.

3. Комментарии к отношениям.

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

Стадия 4 - определение ключей

Цели стадии:

1. Детализация неспецифических отношений.

2. Определение ключевых атрибутов для каждой сущности.

3. Перемещение первичных ключей на установление внешних ключей.

На стадии 4 требуется избавиться от всех неспецифических отношений и включать появляющиеся при этом новые сущности и отношения в матрицу "сущность/отношение" (стадия 3).

Если на этапе 4 объем сущностей увеличится настолько, что трудно охватить в целом смысл модели, то ER-модель разбивается на отдельные функциональные сегменты моделируемой системы.

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

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

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

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

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

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

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

Проверка правильности ключей и отношений

Идентификация и миграция ключей подчиняются следующим правилам:

1. Миграция ключей от родительских (или общих) сущностей к сущности-потомку (или категории) является обязательной.

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

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

4. Сущности с составными ключами не могут быть разбиты на несколько сущностей с более простыми ключами.

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

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

Стадия 5 - определение атрибутов

Стадия 5 завершается стадией разработки модели и включает в себя:

1. Установление принадлежности атрибутов к сущности.

2. Определение не ключевых атрибутов.

3. Проверку правильности и детализацию структур данных.

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

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

Затем необходимо произвести определение атрибутов, которое включают в себя имя атрибута, определение атрибута, синонимы атрибута.

Имя атрибута должно быть уникальным.

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

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

5. IDEF1X-методология в пакете ERwin

Модель данных обычно начинают создавать с логического уровня, который представляется сущностями и атрибутами. Логический уровень модели данных является универсальным и не связан с какой-либо конкретной СУБД.

После построения логического уровня можно выбрать необходимую СУБД и создать физический уровень модели, в которой содержится информация обо всех объектах базы данных (таблицах, колонках, индексах, процедурах и т.п.). Для одного логического уровня можно построить несколько разных физических уровней для различных СУБД (Oracle, Informix, Sybase, Ingress и т.д.).

ERwin позволяет создавать модели трех типов: логическую (Logical ),

физическую (Phisical ) и модель, имеющую как логический, так и физический уровни (Logical / Phisical ), пакет Design/IDEF- модель логического уровня. При создании новой модели в диалоге Create Model можно выбрать тип новой модели. Рекомендуется выбирать тип модели (Logical / Phisical ), так как при генерации базы данных физического уровня потребуется физический тип модели.

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

Диаграмма сущность-связь (Entity Relationship Diagram (ERD)) включает сущности и взаимосвязи, она не слишком детализирована и в нее включаются основные сущности и связи между ними. ER-диаграмма может включать связи «многие ко многим» и не включать описание ключей. Обычно этот тип диаграммы используется для презентаций и обсуждения структуры данных с заказчиком.

Модель данных, основанная на ключах, включает описание всех сущностей и первичных ключей и обеспечивает более полное представление структуры данных.

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

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

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

5.1. Создание сущностей и связей ER -диаграммы в ERwin

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

Построение модели данных предполагает определение сущностей и атрибутов, т.е. необходимо определить, какая информация будет храниться в конкретной сущности и в конкретном атрибуте. Сущность можно определить как объект, событие или концепцию, информация о которых должна сохраняться. Для внесения сущности в модель необходимо (убедившись предварительно, что вы находитесь на уровне логической модели) щелкнуть на кнопке сущности Ей на панели инструментов, затем щелкнуть на том месте диаграммы, где необходимо расположить новую сущность. Щелкнув правой кнопкой мыши по сущности и выбрав из всплывающего меню пункт Entity Properties , можно вызвать диалог Entities , в котором определяются имя, описание и комментарии сущности (рис. 15).

Рис. 15. Диалог Entities

Для описания атрибутов следует, щелкнув правой кнопкой по сущности, выбрать в появившемся меню пункт Attributes . Появляется диалог Attributes (рис. 16).

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

Для атрибутов первичного ключа во вкладке General диалога Attributes необходимо сделать пометку в окне выбора Primary Key .

Вкладка Definition позволяет записывать определения отдельных атрибутов.

Для большей наглядности диаграммы каждый атрибут можно связать с иконкой. При помощи списка выбора Icon во вкладке General можно связать иконку с атрибутом.

Домен атрибута будет использоваться при определении типа колонки на уровне физической модели.

Рис. 16. Диалог Attributes

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

Домен может быть создан на основе другого домена и наследовать все свойства домена-прародителя. По умолчанию ERwin имеет четыре предопределенных домена: String , Number , Blob , Datetime . Создать домен мож-но во вкладке Domains окна Model Explorer .

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

Рис. 17. Диалоговое окно для построения связей

Для создания новой связи следует:

· установить курсор на нужной кнопке (идентифицирующая или неидентифицирующая связь) в палитре инструментов и нажать левую кнопку мыши;

· щелкнуть сначала по родительской, а затем по дочерней сущности.

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

В палитре инструментов кнопка соответствует идентифицирующей связи, кнопка - связи "многие ко многим" и кнопка соответствуют неидентифицирующей связи.

Для редактирования свойств связи следует щелкнуть правой кнопкой мыши по связи и выбрать в контекстном меню пункт Relationship Properties .

Во вкладке General появившегося диалога можно задать мощность, имя и тип связи (рис. 17).

5.2. Интеграция IDEF0- и IDEF1 X-моделей и связывание объектов модели данных со стрелками и работами

BPwin позволяет связывать модели данных (ER-диаграммы) с

Рис. 18. Модель данных, открытая в ERwin

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

Первым шагом связывания модели данных и функциональной модели является экспорт данных из ERwin в BPwin. Для этого используем способ импорта через файлы формата .ЕАХ - .ВРХ .

Для экспорта модели данных из ERwin в BPwin необходимо в ERwin открыть модель (рис. 18) и выбрать пункт меню File/Export/BPwin. В появившемся диалоге Select BPwin Export File необходимо выбрать каталог, вставить имя создаваемого файла экспорта с расширением *.еах и нажать “Сохранить”. Затем в BPwin нужно открыть модель процессов (рис. 19) и выбрать в меню пункт File/Import/ERwin (EAX). Затем в диалоге Open выбрать имя файла с расширением *.еах и нажать “Открыть”.

Рис. 19. Функциональная IDEF0-модель

Появится диалог Import Differences Preview, в котором показывается протокол импорта (рис. 20). Для внесения данных в модель процессов следует щелкнуть по кнопке Accept. Кнопка Cancel отменяет импорт.

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

Появляется вкладка Arrow Data диалога Arrow Properties (рис. 21).

Рис. 20. Диалог Import Differences Preview

Рис. 21. Вкладка Arrow Data диалога Arrow Property для стрелки ценники

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

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

В появившемся диалоге Data Usage Editor (рис. 22) в виде иерархического списка показываются все функциональные блоки модели (учет продаж, учет товара), стрелки (ценники, накладная в торговый зал, накладная поставщика и др.), которые касаются блоков, сущности ( prodavec , tovar , zakaz ) и атрибуты (fio , cena , nazv и др.), которые были связаны со стрелками. Для задания ассоциации достаточно щелкнуть по окну в иерархическом списке.

Рис. 22. Диалог BPwin Data Usage Editor

Для сущностей задается ассоциация CRUD (Create, Read, Update, Delete), для атрибутов - IRUN (Insert, Read, Update, Nullify). Ассоциации CRUD и IRUN - это правила использования сущностей и атрибутов работами, т. е. то, что могут делать работы с входящими или исходящими данными. Данные не могут использоваться работами произвольно. Стрелки входа представляют данные, которые работа преобразует в выход или потребляет. Такие данные могут быть обновлены (Update) или прочитаны (Read), но не могут быть созданы (Create, Insert) или удалены (Delete, Nullify). Данные, связанные со стрелками выхода, могут быть обновлены (если им соответствуют данные стрелок входа), удалены (Delete, Nullify) или созданы (Create, Insert). Для стрелок управления и механизма ассоциации не устанавливаются.

Результат связывания объектов модели процессов можно отобразить в отчете Data Usage Report (Tools / Reports / Data Usage Report ) (рис. 23).

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

В окне Standarts Reports можно установить пять видов отчетов, указать их формат (в группе Report Format ) и задать состав полей и их порядок следования в отчете.

На рисунке 23 установлены опции отчета, показанного на рис. 26 (вид отчета – Activity Entity Attribute Association ). Этот вариант отчета позволяет определить, какие атрибуты сущностей задействованы в стрелках.

На рисунках 24, 25 приведены другие установки опций в окне Data Usage Report .

Рис. 24. Отчет о связях функциональных блоков с сущностями и атрибутами.

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

Рис. 26. Отчет о связях стрелок с сущностями и атрибутами.

Анализов отчетов (рис. 26) и диалоговых окон (рис. 21) позволяет определить те атрибуты, которые не используются во входных и выходных документах, а, следовательно, являются лишними, если в них не планируется хранение каких либо вычисляемых при эксплуатации данных.

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

Если в процессе связывания стрелок с объектами модели данных окажется, что каких-либо сущностей или атрибутов не хватает, их можно добавить прямо в BPwin с помощью команды Model / Entity / Attribute Editor ( рис. 27), а затем экспортировать в ERwin.

Рис. 27. Пример добавления атрибута data_izgot в сущность tovar

Если в модель данных были внесены изменения, то для ее экспорта из BPwin следует выбрать команду File / Export / ERwin (ВРХ) и указать имя нового файл, в который будет "выгружена" информация об измененной информационной модели.

В ERwin следует выбрать меню File / Import / BPwin и в диалоге ERwin Open File указать файл ВРХ, в который была "выгружена" информация о модели. Возникает диалог ERwin / BPwin Import , в котором отображаются сущности и атрибуты, имеющиеся в ВРХ-файле, но отсутствующие в модели ERwin

После щелчка по кнопке Import запускается процесс импорта ВРХ-файла и получаем сущность tovar с новым атрибутом data _ izgot (рис. 28).

Если будет импортироваться вновь созданная сущность, то она не бу-

дет иметь первичного ключа и не будет связана с другими сущностями. Назначение атрибутов первичным ключом и связывание сущностей можно провести только средствами ERwin.

Рис. 28. Модифицированная в BPwin ER-диаграмма

5.3. Генерация базы данных физического уровня в среде СУБД Access

Подготовка к генерации базы данных физического уровня начинается с создания пустой БД в среде той СУБД, куда планируется генерировать ER-диаграмму. Для этого надо запустить СУБД Access, выполнить команду на создание новой БД, присвоить ей имя и сохранить (рис. 29).

Рис. 29. Пустая БД с именем test _ db в СУБД Access

Рис. 30. Физическая модель БД в ERwin

Затем открываем ER-диаграмму в среде ERwin и с помощью списка выбора в стандартной панели инструментов производим переключение между логической и физической моделью (рис.30). При переключении, если физической модели еще не существует, она будет создана автоматически. Теперь надо выбрать СУБД, в которой будем производить генерацию БД физического уровня. Для этого следует выполнить команду DATABASE / Choose database , в появившемся диалоговом окне (рис. 31) выбрать интересующую СУБД Access и щелкнуть по кнопке <ОК>.

Рис. 31. Диалог выбора СУБД (сервера)

Рис. 32. Диалог присоединения к СУБД Access

Для у становления соединения БД из ERwin c целевой СУБД Access необходимо выполнить команду DATABASE / Database connection . В появившемся диалоговом окне (рис.32) необходимо указать путь к БД в СУБД Access, вписать имя admin и нажать кнопку Connect . Для генерации БД физического уровня в среде СУБД Access необходимо выполнить команду TOOLS / Forward Engineering / Schema Generation . В результате получаем диалог генерации схемы БД (рис. 33), который имеет 3 закладки:

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

Во вкладке Summary отображаются все опции, заданные во вкладке Options . Список опций в Summary можно редактировать так же, как и в Options .

Comment . Позволяет внести комментарий для каждого набора опций.

Каждый набор опций может быть именован (окно Option Set, кнопки New, Rename и Delete) и использован многократно.

Кнопка Preview вызывает диалог Schema Generation Preview , в котором отображается SQL-скрипт, создаваемый ERwin для генерации системного каталога СУБД (рис. 34).

Рис. 33. Диалог генерации схемы БД

' CREATE TABLE " prodavec"

Set ERwinTableDef = ERwinDatabase.CreateTableDef("prodavec")

Set ERwinField = ERwinTableDef.CreateField("IDprod", DB_LONG)

ERwinTableDef.Fields.Append ERwinField

Set ERwinField = ERwinTableDef.CreateField("fio", DB_TEXT, 20)

ERwinTableDef.Fields.Append ERwinField

Set ERwinField = ERwinTableDef.CreateField("vozrast", DB_TEXT, 20)

ERwinTableDef.Fields.Append ERwinField

Set ERwinField = ERwinTableDef.CreateField("adress", DB_TEXT, 20)

ERwinTableDef.Fields.Append ERwinField

Set ERwinField = ERwinTableDef.CreateField("dolghnost", DB_TEXT, 20)

ERwinTableDef.Fields.Append ERwinField

Set ERwinField = ERwinTableDef.CreateField("oklad", DB_LONG)

ERwinTableDef.Fields.Append ERwinField

ERwinDatabase.TableDefs.Append ERwinTableDef

' CREATE TABLE "tovar"

Set ERwinTableDef = ERwinDatabase.CreateTableDef("tovar")

Set ERwinField = ERwinTableDef.CreateField("IDtov", DB_LONG)

ERwinTableDef.Fields.Append ERwinField

Set ERwinField = ERwinTableDef.CreateField("naimenovanie", DB_LONG)

ERwinTableDef.Fields.Append ERwinField

Set ERwinField = ERwinTableDef.CreateField("cena", DB_LONG)

ERwinTableDef.Fields.Append ERwinField

Set ERwinField = ERwinTableDef.CreateField("proizvoditel", DB_TEXT, 20)

ERwinTableDef.Fields.Append ERwinField

Set ERwinField = ERwinTableDef.CreateField("postavshik", DB_TEXT, 20)

ERwinTableDef.Fields.Append ERwinField

Set ERwinField = ERwinTableDef.CreateField("kolichestvo", DB_LONG)

ERwinTableDef.Fields.Append ERwinField

ERwinDatabase.TableDefs.Append ERwinTableDef

Рис. 34. Программа генерации таблиц БД (SQL-скрипты)

Кнопка Print диалога предназначена для вывода на печать создаваемого ERwin SQL-скрипта.

Кнопка Report сохраняет тот же скрипт в ERS- или SQL-текстовом файле. Эти команды можно в дальнейшем редактировать любым текстовым редактором и выполнять при помощи соответствующей утилиты сервера

Нажатие на кнопку Generate приведет к запуску процесса генерации схемы. Возникает диалог связи с базой данных, устанавливается сеанс связи с сервером-базы данных (СУБД Access), и начинает выполняться SQL-скрипт. При этом возникает диалог Generate Database Schema (рис. 35).

Рис. 35. Диалог Generate Database Schema

По умолчанию в диалоге Generate Database Schema включена опция Stop If Failure . Это означает, что при первой же ошибке выполнение скрипта прекращается. Щелкнув по кнопке Continue , можно продолжить выполнение. Кнопка Abort прерывает выполнение. При выключенной опции Stop If Failure скрипт будет выполняться, несмотря на встречающиеся ошибки.

Для выполнения обратного проектирования следует выбрать пункт меню Tools / Reverse Engineer .

После выполнения скриптов (рис. 34) в среде СУБД Access создается БД физического уровня (рис. 36).

Рис. 36. Структура БД физического уровня в СУБД Access

Таким образом, на основе физической модели ERwin можно сгенерировать системный каталог СУБД или соответствующий SQL-скрипт. Этот процесс называется прямым проектированием ( Forward Engineering ). Тем самым достигается масштабируемость - создав одну логическую модель данных, можно сгенерировать физические модели под любую поддерживаемую ERwin СУБД. С другой стороны, ERwin способен по содержимому системного каталога или SQL-скрипту воссоздать физическую и логическую модель данных ( Reverse Engineering ).

На основе полученной логической модели данных можно сгенерировать физическую модель для другой СУБД и затем сгенерировать ее системный каталог. Следовательно, ERwin позволяет решить задачу по переносу структуры данных с одного сервера на другой. Например, можно перенести структуру данных с Oracle на Informix (или наоборот).

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

Порядок выполнения работ определяется этапами каскадной модели жизненного цикла (рис. 2). Пример выполнения курсового проекта приведен в Приложении №4.

6.1. Формирование требований к ИС

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

Квалифицированное построение организационной диаграммы и модели “AS IS” как в виде IDEF0-модели, так в виде диаграмм Swim Lane позволяет в удобной форме использовать принципы системного подхода при анализе структуры и процесса функционирования организации. Организационная диаграмма и плавательные дорожки в качестве модели “AS IS” приведены в Приложении №1.

Результирующим документов этапа формирования требований являет-ся технико-экономическое обоснование (ТЭО) (ГОСТ 24.202-80, РД 50-34.698-90).

Документ ТЭО ИС должен состоять из введения и следующих разделов:

· введение;

· характеристика объекта и существующей системы управления;

· цели, критерии и ограничения создания ИС;

· функции и задачи создаваемой ИС;

· ожидаемые технико-экономические результаты создания ИС;

· выводы и предложения.

«Введение» должно содержать следующие сведения по технико-эко-номическому обоснованию создания ИС:

· основание для проведения работ;

· наименование организации-заказчика;

· сроки начала и окончания работ.

Раздел «Характеристика объекта и существующей системы уп-равления» должен содержать:

· общую характеристику объекта;

· характеристику производственно-хозяйственной деятельности, организационной и производственной структуры объекта;

· характеристику функций управления, используемых методов и средств управления;

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

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

Раздел «Цели, критерии и ограничения создания ИС» Должен содержать:

· формулировку производственно-хозяйственных, научно-техничес-ких и экономических целей и критериев создания ИС;

· характеристику ограничений по созданию ИС.

Раздел «Функции и задачи создаваемой ИС» должен содержать обоснование выбора перечня автоматизированных функций и комплексов задач (задач) управления с указанием очередности внедрения;

Раздел «Ожидаемые технико-экономические результаты создания ИС» должен содержать:

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

· оценку ожидаемых затрат на создание ИС с распределением их по очередям создания ИС и по годам;

· ожидаемые обобщающие показатели экономической эффективности ИС.

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

6.2. Разработка концепции ИС.

На этом этапе системный аналитик должен выполнить тщательное обследование предметной области с позиций системного подхода:

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

2. Уточнить перечень выходных документов организации.

3. Уточнить перечень входных документов организации.

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

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

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

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

При построении модели « TO BE » следует также максимально удовлетворять требованиям процессного подхода к управлению: правильно определять состав функций каждого бизнес-процесса на нижних уровнях иерархии. Выходом каждого бизнес-процесса должен воспользоваться хотя бы один клиент, необходимо максимально сократить количество подразделений, поскольку большинство проблем возникает на границах между под-разделениями организации. Для этого надо либо заранее описать действия на всех этапах бизнес-процесса, либо изменить структуру подразделений, либо изменить поток работ.

Однако основным инструментом при построении модели «TO BE» является Business process reengineering ( BPR ) - это радикальный способ реконструкции управления деятельностью предприятия. Цель BPR - добиться более гибкой реакции предприятия на изменения требований потребителей или на прогноз таких изменений при снижении затрат всех видов.

Реинжиниринг изменяет реконструируемые бизнес-процессы следую-щим образом.

1. Несколько рабочих процедур объединяются в одну. Для перепроектированных процессов характерно отсутствие технологии «конвейера», в рамках которой на каждом рабочем месте выполняются простые задания или рабочие процедуры. Теперь они интегрируются в одну – происходит горизонтальное сжатие процесса . Если не удается привести все шаги процесса к одной работе, то создается команда, отвечающая за данный процесс. Горизонтальное сжатие ускоряет выполнение процесса примерно в десять раз.

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

3. Шаги процесса выполняются в естественном порядке. Реинжиниринг

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

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

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

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

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

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

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

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

На основе этих положений BPR создается модель «TO BE». Рассмотрим построение модели «ТО ВЕ» на примере управления городом, используя для этого стилизованные диаграммы потоков данных «объектного» типа. На рис. 37 представлена модель управления городом «AS IS» (функциональная IDEF0-модель приведена в Приложении №2), при которой весь груз проблем по обеспечению своей жизнедеятельности (поиск поставщиков, закупка оборудования и материалов, оплата коммунальных услуг, выплата зарплаты и пр.) несут на себе бюджетные учреждения: школы, больницы, детские сады и т.п. При этом все эти действия выполняются неквалифицированными специалистами, которые не всегда правильно ориентируются в выборе поставщиков, качественного оборудования и товаров, а также возможны всевозможные финансовые нарушения и махинации.

Рис. 37. Модель управления городом «AS IS»

Модель управления «ТО ВЕ» финансовыми и материальными потока-ми муниципального образования построена по принципу корпорации, в ко-торой централизован ряд финансово-хозяйственных процедур (рис. 38). Функциональная иерархическая IDEF0-модель приведена в Приложении №3.

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

Переход на единую схему муниципальных закупок дает экономию в 15-20%, автоматизация учета расходов местного бюджета может принести до 20% экономии.

Рис. 38. Модель управления городом «TO BE»

Данный пример является типичной задачей бизнес-анализа, для которой широко применяются методологии IDEF0, IDEF3 и DFD.

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

6.3. Техническое задание

Полученные на предыдущем этапе функциональная модель, база данных логического уровня и пользовательский интерфейс разрабатываемой системы позволяют разработчику и заказчику определить сложность и тру-доемкость разработки ИС, ее функциональный состав, структуру информации, условия эксплуатации. Этой информации достаточно для разработки технического задания (ТЗ) на ИС (ГОСТ 34.602-89). ТЗ является основным юридическим документом во взаимоотношениях между разработчиком и заказчиком и определяет цели создания ИС, требования к системе и основные исходные данные, необходимые для ее разработки, а также план-график создания ИС. Обычно ТЗ разрабатывает разработчик, а выдает его разработчику заказчик.

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

При разработке технического задания необходимо решить следующие задачи:

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

ТЗ на ИС содержит следующие разделы , которые могут быть разделены на подразделы:

1) общие сведения;

2) назначение и цели создания (развития) системы;

3) характеристика объектов автоматизации;

4) требования к системе;

5) состав и содержание работ по созданию системы;

6) порядок контроля и приемки системы;

7) требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;

8) требования к документированию;

9) источники разработки.

Эти разделы подробно описаны в ГОСТе, но особенно следует обратить внимание на следующие моменты.

В разделе «Требования к системе» в подразделе требования к функциям (задачам), выполняемым системой, следует перечислить все блоки нижнего уровня иерархии дерева узлов модели “TO BE” (Приложение №3).

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

Раздел «Состав и содержание работ по созданию (развитию) системы» должен содержать перечень стадий и этапов работ по созданию си-стемы в соответствии с ГОСТ 24.601, сроки их выполнения. В данном разделе также приводят:

1) перечень документов по ГОСТ 34.201, предъявляемых по окончании соответствующих стадий и этапов работ;

2) вид и порядок проведения экспертизы технической документации (стадия, этап, объем проверяемой документации, организация-эксперт).

В разделе « Порядок контроля и приемки системы» указывают виды (приемочные испытания, опытная эксплуатация и приемочные испытания), состав, объем и методы испытаний системы на основе стандарта ГОСТ 34.603-92. Рекомендуется указать кто (разработчик или заказчик) разрабатывает программу и методики испытаний .

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

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

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

В разделе «Требования к документированию» приводят согласованный разработчиком и заказчиком системы перечень подлежащих разработке комплектов и видов документов, соответствующих требованиям ГОСТ 34.201 и ЕСКД.

В последнее время рекомендуется разрабатывать профиль стандартов [1, 2] на разрабатываемую ИС и утверждать его в составе ТЗ.

После утверждения ТЗ разработчик и заказчик заключают контракт на разработку ИС, с указанием этапов выполнения работ, сроков их выпол-нения и стоимости.

6.4. Технический проект

Этап технического проекта является самым ответственным и решающим в успешном завершении разработки ИС. Этап выполняется на основе стандарта РД 50-34.698-90.

Технический проект ИС содержит основные проектные решения по системе в целом, ее функциям и всем видам обеспечения ИС, которых должно быть достаточно для разработки программных кодов и рабочей документации. В стандарте ГОСТ 34.201-89 приведены более 20 документов, которые следует разработать на этом этапе: пояснительная записка к техническому проекту, ведомость технического проекта, перечень входных сигналов и данных, перечень выходных сигналов (документов), описание автоматизируемых функций, описание информационного обеспечения системы, описание организации информационной базы, описание комплекса технических средств и др. Содержание этих документов приведены в стандарте РД 50-34.698-90.

Для упрощения оформления документации для этапа технический проект предлагаются так называемые “Утвержденные спецификации требований и алгоритмы на функциональные группы программ, программные и информационные компоненты” [2]. Эти спецификации тре-бований являются основой для детального планирования процесса разработки программных средств и их компонентов. Под спецификациями требований понимается формальное описание свойств всех объектов будущего программного продукта: программных модулей, таблиц БД и элементов пользовательского интерфейса.

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

·пояснительная записка к техническому проекту;

· спецификации требований и алгоритмы на функциональные группы программ, программные и информационные компоненты;

· описание организации информационной базы.

Содержание пояснительной записки к техническому проекту подробно описано в стандарте РД 50-34.698-90 и не требует дополнительных объяснений. Она оформляется в виде отдельного документа с титульным листом, содержащим утверждающие и согласующие подписи.

Спецификации требований и алгоритмы на функциональные группы программ, программные и информационные компоненты содержат описание свойств трех основных компонент ИС: программные модули, таблицы БД и пользовательский интерфейс.

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

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

Спецификации для таблиц БД содержат описание каждого поля таблиц (тип и размер поля, его смысловое значение).

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

Документ «Описание организации информационной базы» содержит разделы:

· входная информация;

· выходная информация;

· логическая структура базы;

· физическая структура базы.

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

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

В разделе «Логическая структура» приводят описание состава данных, их форматов и взаимосвязей между данными (ER-диаграмма).

В разделе «Физическая структура» приводят описание избранного варианта расположения данных на базе конкретного СУБД.

На этапе технического проекта завершается проектирование и начинается разра6отка ИС с помощью программных инструментариев, предназначенных для этих целей, например с помощью Delphi, Oracle Developer / 2000 и др.

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

На этапе "Ввод в действие" выделяются три группы работ: подготов-ка персонала, пусконаладочные работы и испытания.

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

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

Испытания системы в полном объеме содержат три стадии, подробно описанные в ГОСТ 34.603-92: предварительные испытания, опытная эксплуатация и приемочные испытания. Общим для них является созда-ние комиссий для проведения испытаний, программы, методик и протоколов испытаний, а также акта об их результатах.

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

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

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

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

Литература

1. Коваленко В.В. Проектирование информационных систем. РГРТУ, Рязань, 2006. 184 с.

2. Липаев В.В., Филинов Е.Н. Мобильность программ и данных в открытых информационных системах. М.: Научная книга, 1997. 368 с.

3. Маклаков В.С. Создание информационных систем с All Fusion Modeling Suite. М.: ДИАЛОГ-МИФИ, 2003. 432 с.

Приложение №1

Организационная диаграмма и Swim Lane diagram

Приложение №2

Функциональная модель “AS IS” управления городом

Приложение №3

Функциональная модель “ТО ВЕ ” управления городом

Приложение №4

Пример курсового проекта “ИС продуктового магазина самообслуживания”

Задание на курсовой проект

по дисциплине “Проектирование ИС”

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

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

1. Выбор, анализ и описание предметной области.

2. Анализ существующих систем

3. Проектирование бизнес-процессов выбранной предметной области по методологии IDEF0:

· построение организационной диаграммы Organization Chart ;

· построение диаграмм плавательных дорожек Swim Lane ;

· создание контекстной диаграммы;

· определение уровней декомпозиции с применением IDEF 0, IDEF 3 и DFD методологий;

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

· построение моделей TO BE ;

· выбор оптимальной функциональной IDEF 0- модели TO BE .

4. Разработка ER -модели предметной области по методологии IDEF 1 X

· определение сущностей (задание первичных и внешних ключей);

· определение атрибутов с указанием типов выбранного СУБД;

· определение связей между сущностями.

5. Построение сценария диалога (дерева меню) и разработка на его основе

пользовательского интерфейса средствами DELPHI или СУБД ACCESS.

6. Проектирование информационной системы выполнить в соответствии

с этапами жизненного цикла каскадной модели по ГОСТ 34.601-90 .

Каждый этап завершать разработкой документации на основе того же ГОСТа и РД 50-34.698-90 :

· технико-экономическое обоснование;

· техническое задание;

· пояснительная записка к техническому проекту;

· спецификации требований и алгоритмы на функциональные группы программ, программные и информационные компоненты;

· описание организации информационной базы.

Список рекомендуемой литературы

В.В. Коваленко. Проектирование ИС. РГРТУ, Рязань, 2006.

А.М. Вендоров. Сase- технологии. Современные методы и средства проектирования информационных систем. – М.; Финансы и статистика, 1998.

С.В. Маклаков. Создание информационных систем с ALLFusion Modeling Suite. М.,2003.

Проектирование экономических информационных систем: Учебник. Г.Н. Смирнова, А.А. Сорокин, Ю.Ф. Тельнов–М.: Финансы и статистика, 2002.

Содержание

Введение ...........................................................................................68

1. Анализ существующих систем ...................................................70

2. Формирование требований к ИС.................................................75

3. Разработка концепций ИС............................................................83

4. Техническое задание.....................................................................85

5. Технический проект......................................................................99

Заключение.......................................................................................110

Список литературы..........................................................................111

Приложение № 1. Swim Lane Diagram ...........................................112

Приложение № 2. Функциональная модель ..................................113

Приложение № 3. Логическая модель БД ......................................120

Приложение № 4. Пользовательский интерфейс .......................... 121

Приложение № 5. Входные и выходные документы .................... 128

Введение

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

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

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

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

¾ управление закупками и продажами товаров (учет остатков и движения запасов, ведение прайс-листов, формирование товарных отчетов)

¾ формирование платежных ведомостей (аванс, зарплата)

¾ регистрацию документов в книгах покупок и продаж.

¾ учет имущества предприятия (учет специального оборудования и инструментов, учет наличия и движения каждого объекта учета, начисление амортизации объектов)

Все стадии проектирования были выполнены согласно соответствующим стандартам ГОСТ-34 на разработку информационных систем.

В процессе выполнения проекта были использованы такие программные продукты, как AllFusion BPWIN (4.1), AllFusion ERWIN (4.1), СУБД ACCESS 2002, Borland Delphi 7.0

1.Анализ существующих систем.

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

В рамках курсового проекта были рассмотрены несколько внедренных систем автоматизации магазинов.

1С-Papyc:Магазин.

Компании "1С-Рарус" и "1С-Рарус-НН" (нижегородский филиал компании 1С-Рарус) осуществили разработку и установку системы автоматизации магазина на платформе "1С:Предприятие 7.7 SQL" с использованием типового решения "1С-Рарус:Магазин" [10]. Полученная система, работая в комплексе с терминалами сбора данных, принтерами этикеток, фискальными регистраторами, электронными весами обеспечивает управление торговым процессом магазина самообслуживания - прием товаров на складе, формирование заказов поставщикам, перемещение товаров в торговый зал, продажи и возвраты товаров, инвентаризацию товаров и другие, характерные для розничной торговли операции. Кроме того, автоматизирована продажа по кредитным и дисконтным картам (Union Cards и пластиковые карты СаровБизнесБанка). В торговой системе реализован ряд нестандартных функций, например, продажа товаров в кредит по пропускам сотрудников предприятия.

Структура автоматизированного магазина включает рабочие места кладовщика, товароведа, менеджера магазина, три кассовых места.

При приемке товаров проводится сквозное штриховое кодирование товаров с помощью принтера этикеток Godex EZ-4TT, работающего под управлением конфигурации "1С-Рарус: Печать этикеток и ценников". Автоматизирован процесс поступления и инвентаризации товаров при помощи терминалов сбора данных фирмы "CIPHER Lab".

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

БЭСТ-Магазин

Система "БЭСТ-Магазин" [9] предназначена для комплексной автоматизации оперативного и бухгалтерского учета и анализа хозяйственной деятельности на предприятиях розничной торговли. Она может работать в магазинах, реализующих номенклатуру различного вида - от продуктов до бытовой техники и ведущих учет в розничных ценах.

Основное достоинство программного комплекса "БЭСТ-Магазин" заключается в том, что он обеспечивает оперативный количественно-суммовой учет на протяжении всего цикла товародвижения в магазине (оприходование - подготовка к продаже - реализация в розницу). При этом оперативный учет тесно переплетается с учетом бухгалтерским.

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

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

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

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

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

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

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

1С:Управление Торговлей 8.0

С целью автоматизации оперативного учета специалистами ВЦ "1С:Бухучет и Торговля" (БиТ) была автоматизирована сеть магазинов с помощью типовой конфигурации "1С:Управление Торговлей 8" [7]. Решение позволяет вести оперативный учет и управление не только торговыми, но и складскими и финансовыми операциями.
Конфигурация решает следующие задачи:
- составление и анализ плана реализаций в разрезе различных характеристик учета на основе анализа данных о продажах за предыдущие периоды;
- сравнение запланированных продаж продукции с фактическими;
- планирование входящих и исходящих платежей;
- учет заказов покупателей и отслеживание этапов выполнения заказа поставщику;
- оформление заказов поставщиков и контроль их исполнения;
- формирование платежного календаря расходов денежных средств;
- управление продажами (включает оптовую, розничную и комиссионную торговлю);
- управление поставками;
- управление складскими запасами;
- управление отношениями с клиентами;
- анализ товарооборота предприятия;
- анализ цен и управление ценовой политикой.

Специалистами компании "1С:Бухучет и Торговля" (БиТ) проведены демонстрация новых возможностей системы, установка; в настоящий момент ведутся настройки по требованию клиента.

Анализируя внедренные системы автоматизации управления продуктовым магазином, невольно напрашивается вывод, что в настоящее время не существует таких ИС, которые бы отвечали требованиям всех торговых предприятий. Любая система требует дополнительных доработок, чтобы учитывать все индивидуальные особенности того или иного магазина. К примеру, рассматривая систему «БЭСТ - Магазин», можно выделить, что она ориентирована в большей степени на учетную информацию, а не на управление магазином.

2. Формирование требований в ИС

2.1. Организационная диаграмма магазина

Организационная диаграмма автоматизированного магазина имеет следующий вид:

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

Каждый сотрудник магазина выполняет свои функции.

Директор принимает решения по оперативному управлению магазином: заключает договора, издает приказы и распоряжения.

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

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

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

Кладовщик осуществляет выгрузку, перенос, перевозку внутрискладского груза и др. ТМЦ, ведет их учет, составляет документацию по движению товара в складском помещении.

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

2.2 Swim Lane Diagram,s

Диаграммы «Прием товара» и «Возврат товара покупателем» находятся в Приложении 1.

Диаграмма «Прием товара».

В этом процессе участвует двое сотрудников предприятия: кладовщик и администратор.

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

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

Диаграмма «Возврат товара покупателем».

В процессе возврата товара покупателем участвуют два сотрудника магазина: администратор и кассир.

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

2.3.Технико-экономическое обоснование

на создание ИС «Продуктовый магазин»

1. Введение

1.1.Основанием для проведения работ является приказ директора магазина.

1.2. Заказчик: Продуктовый магазин

1.3. Разработчик: СИЭИТ

1.4. Сроки начала и окончания работ

Дата начала работы 18 января 2008 года

Дата окончания работы 25 мая 2008 года

2 Характеристика объекта автоматизации

2.1.Общая характеристика

Объектом автоматизации проектирования является деятельность продуктового магазина самообслуживания. Работой магазин руководит директор, у которого в непосредственном подчинении находятся бухгалтер и администратор (см. организационную диаграмму). В свою очередь администратор руководит деятельностью кладовщика, мерчендайзера, 2-х кассиров.

2.2.Характеристика существующей системы управления

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

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

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

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

2.3. Перечень и характеристика недостатков в организации и управлении

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

-выполнение документооборота вручную может привести к потере документов или неправильному составлению документации;

-учет всех дневных продаж по каждому товару вручную физически невозможен;

- проведение инвентаризации без средств автоматизации при огромном ассортименте товаров является долговременной операцией, что приводит к потере денежных средств из-за вынужденного "простоя";

- при анализе ассортимента товаров могут возникнуть ошибки, что повлияет на формирование заявок на поставку товаров;

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

3. Цели, критерии и ограничения внедрения ИС

3.1. Характеристика целей создания ИС.

Информационная система «Продуктовый магазин» разработана для автоматизации ведения товароучетных и административных операций торгового предприятия. ИС позволит:

¾ ввести автоматизированное управление закупками и продажами товаров (учет остатков и движения запасов, ведение прайс-листов, формирование товарных отчетов)

¾ автоматизировать регистрацию документов в книгах покупок и продаж

¾ сократить время на учет имущества предприятия (учет наличия специального оборудования и инструментов и движения каждого объекта учета, начисление амортизации объектов)

3.2. Характеристика ограничений по созданию ИС

Проектируемая ИС не обеспечивает учет рабочего времени сотрудников, больничных листов, отпусков и назначение зарплаты.

4. Функции и задачи создаваемой ИС

ИС включает в себя следующие автоматизированные функции (на основании модели “AS IS”):

- учет закупки и движения товаров (анализ ассортимента, формирование заявок на поставку товаров, учет принятых товаров, учет списания и возврата товаров, инвентаризацию)

- учет денежных средств

- формирование документации магазина (отчеты, ордера, ведомости).

- учет имущества предприятия (учет наличия и движения оборудования предприятия, начисление амортизации)

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

5. Ожидаемые технико-экономические результаты создания ИС

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

- сокращение объема бумажной документации;

- увеличение скорости поиска информации и подготовки отчетов;

- возможность анализа деятельности магазина на основе накопленных в БД сведений;

- повышение производительности труда;

- сокращение запасов товара на складе;

- улучшения качества обслуживания покупателей.

Ожидаемые затраты на создание и внедрение ИС:

· разработка ИС;

· компьютерная техника (компьютеры, принтеры, кассовый аппарат, сетевое оборудование);

· лицензии на ОС Windows и текстовый редактор Word.

6. Выводы и предложения

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

Внедрение ИС потребует обучение сотрудников магазина работе на компьютере в пределах знания ОС Windows, текстового редактора Word и создаваемой ИС.

3. Разработка концепции ИС

3.1 Функциональная модель

Функциональная модель системы создавалась с использованием IDEF0, IDEF3 и DFD диаграмм. Диаграмма верхнего уровня называется «Управление магазином». Данная диаграмма имеет следующие стрелки:

- входящие: Заявление покупателя о возврате товара;

-выходящие: Ведомость начисления заработной платы, Акт возврата товаров поставщику, Бухгалтерский баланс;

-управляющие: Нормативные документы (Закон "О защите прав потребителей", ДИ, Устав предприятия, Приказы директора и др.);

-ресурсы: Директор, Администратор, Кассир, Кладовщик, Мерчендайзер, Бухгалтер.

Изображение контекстной диаграммы, реализованной в BPWin, представлено на рис.1 в Приложении 2.

Следующий уровень декомпозиции состоит из 3-х диаграмм (рис. 2 Приложение 2).

- Управление складом;

- Управление торговым залом;

- Оперативный учет.

Декомпозиция этих диаграмм представлена на рис. 3 – 10 Приложение 2.

Полное представление о функциональной модели системы дает диаграмма дерева узлов (рис. 11 Приложение 2)

3.2 Логическая модель

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

В логической модели выделено семь сущностей: Counteragent, Sotrudnik, Document, Oborudovanie, Nomenklatura, Tovar_skl, Tovar_mag.

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

Сущность Counteragent содержит всю информацию о контрагентах, необходимую для составления накладной.

Сущность Sotrudnik содержит информацию обо всех сотрудниках магазина.

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

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

Сущность Nomenklatura содержит атрибуты, которые дают общую информацию о товарах. Номенклатура составляется для отображения информации о товарах, находящихся на складе, или о товарах в торговом зале.

Сущность Tovar_skl содержит информацию о количестве и ценах товаров на складе.

Сущность Tovar_mag содержит информацию о количестве и отпускных ценах товаров в торговом зале.

4. Техническое задание

СИЭИТ

наименование организации – разработчика ТЗ на АС

наименование вида ИС

наименование объекта автоматизации

сокращенное наименование АС

ТЕХНИЧЕСКОЕ ЗАДАНИЕ

На 12 листах

Действует с________________________

1. Общие сведения о проекте

1.1. Полное наименование системы и ее условное обозначение

Информационная система «Продуктовый магазин».

1.2. Наименование предприятий разработчика и заказчика (пользователя) системы и их реквизиты:

Заказчик: магазин самообслуживания ИНН 478732567829

Разработчик: СИЭИТ ИНН 478732567829

1.3. Перечень документов, на основании которых создается система, кем и когда утверждены эти документы:

- ISO/IES 12207:1995-08-01 «Информационная технология. Процессы ЖЦ программного обеспечения»

- ГОСТ 34.601-90 «Стадии создания АС»

- ГОСТ 34.602-89 «Техническое задание на создание АС»

- ГОСТ 34.603-92 «Виды испытаний АС»

- РД 50-34.698-90 «Требование к содержанию документов»

- ГОСТ 24.202-80 «Технико-экономическое обоснование»

- ГОСТ 34.20-89 «Виды, комплектность и обозначение документов при создании АС»

1.4. Плановые сроки начала и окончания работы по созданию системы:

Дата начала работ 18 января 2008 года

Дата окончания работ 30 мая 2008 года

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

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

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

2. Назначения и цели создания системы

2.1. Назначение системы

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

2.2. Цели создания системы:

¾ управление закупками товаров, а также управление продажами товаров (учет остатков и движения запасов, ведение прайс-листов, формирование товарных отчетов)

¾ формирование платежных ведомостей (аванс, зарплата)

¾ регистрацию накладных в книгах покупок и продаж

¾ учет имущества предприятия (учет специального оборудования и инструментов, учет наличия и движения каждого объекта учета, начисление амортизации объектов)

3. Характеристики объекта автоматизации

3.1. Краткие сведения об объекте автоматизации

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

3.2. Сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды.

При проектировании ИС продуктового магазина должны быть автоматизированы рабочие места большей части сотрудников магазина: директора; администратора; кассира; кладовщика; мерчендайзера; бухгалтера.

4. Требования к системе

4.1 Требования к системе в целом

4.1.1. Требования к структуре и функционированию системы :

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

- Пользователь «Директор» имеет право доступа ко всей БД.

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

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

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

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

- Пользователь «Бухгалтер» имеет доступ только к оперативному учету.

4.1.2. Требования к численности, квалификации персонала и режиму его работы

Данная область предполагает работу за компьютером всего персонала. Поэтому необходимо провести обучение для пользования АИС и основам работы на компьютере.

Режим работы: без выходных, с 8.0 час. до 22.00 час.

4.1.3. Требования к надежности:

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

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

4.1.4. Требования по эргономике и технической эстетике

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

- ГОСТ Р 50948-96 «Средства отображения информации индивидуального пользования. Общие эргономические требования и требования безопасности»

Комфортность условий работы персонала должна обеспечиваться в соответствии со стандартами:

- ГОСТ 12.2.032-78 «Рабочее место при выполнении работ сидя. Общие эргономические требования»;

- ГОСТ Р 50923-96 «Дисплеи. Рабочее место оператора. Общие эргономические требования к производственной среде. Методы измерения».

Оценка эргономических параметров и параметров безопасности должна проводиться в соответствии со стандартом:

- ГОСТ Р 50949-96 «Средства отображения информации индивидуального пользования. Методы измерений и оценки эргономических параметров и параметров безопасности».

4.1.5. Требования по стандартизации и унификации:

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

4.2 Требования к функциям (задачам), выполняемым системой (функциональные блоки нижнего уровня иерархии дерева узлов):

· анализ ассортимента товаров;

· формирование списка требуемых товаров;

· формирование списка наиболее перспективных товаров;

· выбор поставщиков;

· формирование заявки;

· поиск несоответствия товаров накладной;

· составление акта разногласий;

· составление отчета о принятом товаре;

· переоценка товара;

· списание товара;

· учет инвентаризации товаров на складе;

· оформление возврата поставщику;

· маркировка товара;

· формирование документации о движении товара;

· учет продажи товаров;

· оформлении возврата товара покупателем;

· составление расходно-кассового ордера;

· оформление возврата в кассовой книге;

· учет материальных ценностей.

4.3 Требования к видам обеспечения

4.3.1. Требования к информационному и программному обеспечению

Данные в системе должны быть реализованы в виде реляционной БД на основе СУБД SQL Server 2000. БД располагается на сервере под управлением операционной системы Microsoft Windows Server 2000 или Windows XP Professional. На клиентских местах установлена операционная система Windows XP Professional.

4.3.2. Требования к техническому обеспечению

Сервер базы данных должен быть оснащен процессором не ниже Intel Xeon 2500 МГц, оперативной памятью 512 MB и RAID массивом для обеспечения целостности базы данных. Клиентские места должны быть оснащены процессором не ниже Pentium-800 МГц. Для распечатки документов и отчетов необходимо установить принтеры.

5. Состав и содержание работ по созданию (развитию) системы

Работы по созданию системы выполняются последовательно и включают следующие этапы:

5.1. Формирование требований к АИС

Характеристика объекта и результатов его функционирования :

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

Могу быть разработаны организационная диаграмма и диаграммы Swim Lane в качестве модели “AS IS’.

Отчет о выполненной работе : разработчик составляеттехнико-экономическое обоснование (ТЭО) (РД 50-34.698-90, ГОСТ 24.202-80).

Все работы должны быть выполнены в течение 10 дней.

5.2. Разработка концепций АИС

Изучение объекта :

Разработчик – проводит детальное изучение работы персонала. Результатом на данном этапе является построение функциональной модели «TO BE». Заказчик – предоставляет разработчику все необходимую для этого информацию.

Концепции АИС, удовлетворяющие требованиям пользователя : разработчик – проектирует оптимальную модель «TO BЕ» на основе ранее созданной модели «AS IS». Результатом работы является построение функциональной модели «TO BЕ».

Все работы должны быть выполнены в течение 10 дней.

5.3. Разработка технического задания (ТЗ)

Проводится разработка, оформление, согласование и утверждение ТЗ в соответствии с ГОСТ 34.602-83).

На этом этапе разработчик может сам создать первоначальный профиль стандартов на основании стандартов: ISO/IES 1220761995-08-01; ГОСТ 34.602-83; ГОСТ 34.601-90; ГОСТ 34.20-89; РД 50-34.689-90; ГОСТ 34.603-92

Все работы должны быть выполнены в течение 7 дней.

5.4. Эскизный проект

Эскизный проект разрабатывается только для сложных систем. В курсовых проектах не требуется.

5.5. Технический проект

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

Разработка документации на ИС : разработчик - по итогам работ составляет (РД 50-34.698-90):

·пояснительная записка к техническому проекту;

· спецификации требований и алгоритмы на функциональные группы программ, программные и информационные компоненты;

· описание организации информационной базы.

Все работы должны быть выполнены в течение 20 дней.

5.6. Рабочая документация

Разработка рабочей документации на ИС : разработчик – создает руководства операторов, программистов и администраторов на основании стандартов РД 50-34.698-90 и ЕСПД.

Разработка или адаптация покупных программ : разработчик – создает на основе спецификаций требований для программных модулей, БД и пользовательских интерфейсов системы. В случае приобретения готовых программных средств, производит их адаптацию и привязку к системе. На всех стадиях создания программных средств осуществляет их тестирование (стандарт ISO/IES 12207: 1995-08-01).

Все работы должны быть выполнены в течение 7 дней.

5.7. Ввод в действие

Организационная подготовка объекта информатизации к вводу АИС: разработчик и заказчик - проводят организационную подготовку объекта к вводу АИС.

Подготовка персонала : разработчик - обучает персонал, проверяет их способность обеспечить функционирование АИС.

Строительно-монтажные работы : производится установка и наладка технических средств.

Пуско-наладочные работы : проводятся автономная наладка аппаратных и программных средств, загрузка информации в БД, комплексная наладка всех средств системы.

Испытания системы : проводятся предварительные испытания, опытная эксплуатация и приемочные испытания. Более подробно испытания системы представлены в пункте "Порядок контроля и приемки системы" настоящего документа.

Все работы должны быть выполнены в течение 30 дней.

5.8. Сопровождение ИС

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

Все работы должны быть выполнены в течение 95 дней.

6. Порядок контроля и приемки системы

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

Автоматизированная информационная система проходит обычно три этапа испытаний:

- предварительные испытания : по усмотрению разработчика создается программа и методика автономных или комплексных испытаний (ГОСТ 34.603-92, РД 50-34.689-90, ЕСПД). Результаты испытаний отражаются в протоколе. Работу завершают оформлением акта приемки и рекомендацией в опытную эксплуатацию. Работы проводятся разработчиком и заказчиком на протяжении 4 дней;

- опытная эксплуатация : разработчик – создает программу и методики испытаний (ГОСТ 34.603-92, РД 50-34.689-90, ЕСПД). В соответствии с этой программой проводят опытную эксплуатацию. Во время ее проведения ведет рабочий журнал, в который заносит сведения о продолжительности функционирования ИС, отказах, сбоях, аварийных ситуациях, изменениях параметров объекта информатизации, проводимых корректировках документации и программных средств, наладке технических средств. Работы завершаются оформлением акта о завершении опытной эксплуатации и допуске системы к приемочным испытаниям. Работы проводятся разработчиком и заказчиком на протяжении 30 дней.

- приемочные испытания : разработчик - создает программу и методики испытаний (в соответствии со стандартом ГОСТ 34.603-92, РД 50-34.689-90, ЕСПД). В соответствии с этой программой проводят приемочные испытания. Результаты испытаний фиксируют в протоколах испытаний. Протоколы испытаний по всей программе обобщают в едином протоколе, на основании которого делают заключение о соответствии системы требованиям технического задания на ИС. Испытания завершаются оформлением акта о приемке ИС в постоянную эксплуатацию. Работы проводятся разработчиком и заказчиком на протяжении 3 дней;

.

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

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

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

7.2. Изменения, которые необходимо осуществить в объекте автоматизации

Проведение подобных работ оговаривается отдельно.

7.3. Создание условий функционирования объекта автоматизации, при которых гарантируется соответствие создаваемой системы требованиям, содержащимся в ТЗ

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

7.4. Сроки и порядок комплектования штатов и обучения персонала

Перед началом работы с АИС сотрудники магазина должны пройти начальный курс работы с ПК и курс обучения работы с данной АИС.

8. Требования к документированию

Перечень подлежащих разработке документов:

· технико-экономическое обоснование;

· технический проект;

· руководство программиста,

· руководство пользователя,

· руководство администратора,

· программа и методики испытаний;

· текст программ;

· описание программ..

____

код ТЗ

СОСТАВИЛИ

СОГЛАСОВАНО

5. Технический проект

5. 1.Пояснительная записка

5.1.1 Общие положения.

Наименование проектируемой ИС «Продуктовый магазин».

Основанием для проведения работ является приказ директора магазина.

Разработчик - СИЭИТ

Нормативные документы, на основании которых разрабатывается ИС:

ГОСТ 34.601-90 – «Стадии создания АС»

ГОСТ 34.602-89 – «ТЗ на создание АС»

ГОСТ 34.603-92- «Виды испытаний АС»

РД 50-34.698-90- «Требования к содержанию документов»

ISO/IEC 12207:1995-08-01 – «Информационная технология. Процессы ЖЦ программного обеспечения».

5.1.2. Цели, назначение и области использования АИС.

Информационная система «Продуктовый магазин» разработана для автоматизации ведения товароучетных и административных операций торгового предприятия. ИС позволяет:

¾ ввести автоматизированное управление закупками и продажами товаров (учет остатков и движения запасов, ведение прайс-листов, формирование товарных отчетов)

¾ автоматизировать регистрацию накладных в книгах покупок и продаж

¾ сократить время на учет имущества предприятия (учет наличия специального оборудования и инструментов и движения каждого объекта учета, начисление амортизации объектов)

5.1.3 Основные технические решения

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

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

¾ Количество работников системы – 6 человек (1директор, 1 бухгалтер, 1 мерчендайзер, 1 кладовщик, 2 кассира). Персонал должен иметь навыки работы на ПК, а именно: уметь вводить данные в систему и получать из системы информацию (по своему модулю). Заведующий должен иметь навыки работы с ПК, но в

Для пользователя «Директор» - просмотр, анализ и корректировка выполнения всех операций в магазине.

Для пользователя «Администратор» - ввод, изменение сведений о поставках товаров, анализе ассортимента магазина, товародвижении, проведении инвентаризаций.

Для пользователя «Кладовщик» - ввод и изменение сведений о поставленных поставщиком товарах и товародвижении на складе.

Для пользователя «Кассир» - ввод и изменение сведений о продажах товаров и возвратах товаров от покупателей.

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

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

5.1.4. Мероприятия по подготовке объекта автоматизации к вводу системы в действие

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

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

Мероприятия по созданию необходимых подразделений и рабочих мествыполняются заказчиком по согласованию с разработчиком.

5.2. Утвержденные спецификации требований и алгоритмы на функциональные группы программ, программные и информационные компоненты

5.2.1 Программные модули

Модуль “Analiz_assortimenta_magazina”

Входные данные = (Nomenklatura.id_tovar, Nomenklatura.name_tovar, Nomenklatura.ed_izm, Nomenklatura.producer, Склад: Tovar_skl.kolvo_skl, Tovar_skl.cena; Торговый зал: Tovar_mag.kolvo_mag, Tovar_mag.price)

Выходные данные = см. Приложение 4, рис.3

Модуль “Formirovanie_zayavki_na_postavku”

По нажатию кнопки «Поиск» на форме (Приложение 4, рис.2)

Входные данные = (Counteragent.id_counterag, Counteragent.name_counterag, Counteragent.address_counterag, Counteragent.tel_counterag, Counteragent.main_person); (Список товаров: Nomenklatura.name_tovar, Nomenklatura.ed_izm, Nomenklatura.producer, Kolvo)

Выходные данные = см. Приложение 4, рис.2

Модуль “Sostavlenie akta”

Входные данные = (Document.id_doc, Document.id_counterag, Document.date_sostav, Document.art_doc, Document.sum, Document.id_sotrudnik)

Выходные данные = см. Приложение 4, рис.4

Модуль “Oformlenie tovara”

Входные данные = (Nomenklatura.id_tovar, Nomenklatura.name_tovar, Nomenklatura.ed_izm, Nomenklatura.producer, Kolvo, Cena)

Выходные данные = см. Приложение 4, рис. 13

Модуль “Inventarizatsiya_torgovogo_zala”

Входные данные = (Nomenklatura.id_tovar, Nomenklatura.name_tovar, Nomenklatura.ed_izm, Tovar_mag.id_doc, Fakt_nal, Tovar_mag.kolvo_mag)

Выходные данные = см. Приложение 4, рис.5

Модуль “Markirovka_tovara”

Входные данные = (Nomenklatura.id_tovar, Nomenklatura.name_tovar, Nomenklatura.ed_izm, Nomenklatura.producer, Tovar_mag.price)

Выходные данные = см. Приложение 4, рис. 13

Модуль “Formirovanie_dokumentatsii_o_dvijenii_tovara”

Входные данные = (Document.id_doc, Document.id_counterag, Document.date_sostav, Document.art_doc, Document.sum, Document.id_sotrudnik)

Выходные данные = см. Приложение 4, рис. 4

Модуль “Oformlenie_vozvrata_tovara_ot_pokupatelya”

Входные данные = (Nomenklatura.id_tovar, Nomenklatura.name_tovar, Nomenklatura.ed_izm, Nomenklatura.producer, Tovar_mag.kolvo_mag, Tovar_mag.price, Dokument)

Выходные данные = см. Приложение 4, рис. 6

Модуль “Uchet prodaj”

Входные данные = (Nomenklatura.id_tovar, Nomenklatura.name_tovar, Nomenklatura.ed_izm, Nomenklatura.producer, Tovar_mag.kolvo_mag, Tovar_mag.price)

Выходные данные = см. Приложение 4, рис. 8

Модуль “Otchet_kassira”

Входные данные = (Document.id_doc, Document.date_sostav, Document.art_doc, Document.sum, Document.id_sotrudnik)

Выходные данные = см. Приложение 4, рис. 7

Модуль “Uchet_material_tsennocteyi”

Входные данные = (Oborudovanie.id_oborud, Oborudovanie.name_oborud, Oborudovanie.god_produc, Oborudovanie.god_postavki, Oborudovanie.cost, Oborudovanie.cap_remont, Oborudovanie.id_sotrudnik)

Выходные данные = см. Приложение 4, рис. 12

Модуль “Uchet_denejn_credstv”

Входные данные = (Document.id_doc, Document.id_counterag, Document.date_sostav, Document.art_doc, Document.sum, Document.id_sotrudnik)

Выходные данные = см. Приложение 4, рис. 10

Модуль «Poisk_postavchika»

Входные данные = (Counteragent.id_counterag, Counteragent.name_counterag, Counteragent.address_counterag,Counteragent.tel_counterag,Counteragent.main_person)

Выходные данные = см. Приложение 4, рис. 2

5.2.2.Описание структуры БД

Counteragent

Document

Sotrudnik

Oborudovanie

Nomenklatura

Tovar_skl

Tovar_mag

5.2.3. Пользовательский интерфейс

Примерные формы пользовательского интерфейса расположены в Приложении 4.

1. Стартовая форма (рис.1)

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

2. Форма «Работа директора» (рис.2)

Данная форма имеет 2 вкладки: для формирования заявки на поставку товаров и контроля работы сотрудников.

На первой вкладке расположена таблица для ввода данных о фирме-поставщике товаров. С помощью кнопки «Поиск» (см. модуль «Poisk_postavchika»), расположенной на форме, можно автоматически заполнить данные в таблицу «Поставщики». В таблицу «Товар» заносится список товаров, которые можно заказать у данного поставщика. Нажатие кнопки «Сформировать заявку» формирует документ «Заявка на поставку» (см. модуль “Formirovanie_zayavki_na_postavku”)

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

3. Форма «Работа администратора» (рис. 3 – 5)

На форме имеется 3 вкладки: Склад, Торговый зал, Контроль сотрудников.

Вкладка «Склад» включает номенклатуру склада, которая содержит информацию обо всех товарах склада (можно осуществить поиск товара по его наименованию). Также данная вкладка позволяет осуществить следующие операции: анализ ассортимента товара (см. модуль “Analiz_assortimenta_magazina”), учет актов (см. модуль “Formirovanie_dokumentatsii_o_dvijenii_tovara”), составляемых на складе (возврат, недовоз, списания и т.д.), инвентаризацию (см. модуль “Inventarizatsiya_sklada”). Результатом выполнения этих операций является формирование отчета о проделанной работе при нажатии кнопки «Сформировать отчет».

Вкладка «Торговый зал» включает в себя номенклатуру товаров, находящихся в торговом зале и позволяет выполнять такие операции, как учет всех актов, имеющих отношение к движению товаров в торговом зале, и инвентаризация торгового зала. По нажатию кнопки «Сформировать отчет» (см. модуль “Inventarizatsiya_torgovogo_zala”) можно вывести на экран отчет об выполненных работах.

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

4. Форма «Работа кассира» (рис. 6-8)

Форма содержит номенклатуру торгового зала, которая дает представление обо всех товарах магазина, находящихся в торговом зале. Пользователь также имеет возможность найти необходимый товар по его наименованию или по номеру накладной, по которой он был доставлен в торговый зал. Также на форме расположены 3 вкладки, с помощью которых можно выполнить следующие операции: продажу товаров (см. модуль “Uchet prodaj”), их возврат от покупателя (см. модуль “Oformlenie_vozvrata_tovara_ot_pokupatelya”) и учет документации (см. модуль “Formirovanie_dokumentatsii_o_dvijenii_tovara”).

В любой момент времени можно вывести отчет о выполненной работе, нажав кнопку «Сформировать отчет».

5. Форма «Работа мерчендайзера» (рис.9)

Для упрощения работы мерчендайзера на форме расположены следующие таблицы: «Номенклатура торгового зала» и «Накладные». В этих таблицах можно изменять, добавлять или удалять информацию о товарах и накладных соответственно. Также возможны поиск товара по наименованию и сортировка накладных по дате их составления. В любой момент времени можно сформировать отчет о накладных (см. модуль “Formirovanie_dokumentatsii_o_dvijenii_tovara”), по которым можно проследить движение товара в торговом зале.

6. Форма «Работа бухгалтера» (рис.10 - 12)

Данная форма предназначена для упрощения работы бухгалтера. На ней расположены 3 вкладки, позволяющие вести учет материальных ценностей магазина (см. модуль “Uchet_material_tsennocteyi”), учет оплаты труда сотрудникам (см. модуль “Uchet_oplati_truda”) и учет денежных средств и кредитных операций (Модуль “Uchet_denejn_credstv”). По этим вкладкам впоследствии можно составить бухгалтерский баланс и вывести его на экран в виде документа.

7. Форма «Работа кладовщика» (рис.13)

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

5.3. Описание информационной базы.

5.3.1. Входная информация

1. Накладная от поставщика - на бумажном носителе стандартной формы, при поставке товара, еженедельно, от поставщика (Приложение №5).

2. Заявление покупателя о возврате товара – бланк установленного образца на бумажном носителе от покупателя по мере возникновения проблемы (Приложение №5).

5.3.1. Выходная информация

1. Накладная со склада – на бумажном носителе стандартной формы при передаче товара со склада в торговый зал примерно один раз в неделю от кладовщика (Приложение №5).

2. Акт возврата товара поставщику - на бумажном носителе стандартной формы при передаче товара на склад при получении товара от поставщика (Приложение №5).

3.Отчет о принятом товаре - на бумажном носителе стандартной формы, при поставке товара, еженедельно, от кладовщика (Приложение №5).

4. Заявка на поставку товара - на бумажном носителе стандартной формы, при запросе на поставку товара, еженедельно, от менчендайзера (Приложение №5).

5.3.2. Логическая структура БД.

Логическая структура БД разработана на основе функциональной модели ИС и представлена в Приложении №3.

5.3.2. Физическая структура БД.

Физическая структура БД разработана для СУБД Access на основе логической структуры БД и представлена в Приложении №3.

Заключение.

В ходе выполнения курсового проекта была спроектирована ИС продуктового магазина.

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

¾ управление закупками товаров, а также управление продажами товаров (учет остатков и движения запасов, ведение прайс-листов, формирование товарных отчетов)

¾ формирование платежных ведомостей (аванс, зарплата)

¾ регистрацию накладных в книгах покупок и продаж

¾ учет имущества предприятия (учет специального оборудования и инструментов, учет наличия и движения каждого объекта учета, начисление амортизации объектов)

Вся документация, сопутствующая проектированию, оформлена в соответствии с государственными стандартами ГОСТ-34.

Дальнейшая доработка ИС планируется в будущем.

Список литературы.

1. А.М. Вендоров. Сase- технологии. Современные методы и средства проектирования информационных систем. – М.; Финансы и статистика, 1998.

2. В.В. Коваленко. Проектирование ИС. РГРТУ, Рязань, 2006.

3. Волков Ю.Г. Как написать диплом, курсовую, реферат? Ростов-на-Дону, 2001

4. Проектирование экономических информационных систем: Учебник. Г.Н. Смирнова, А.А. Сорокин, Ю.Ф. Тельнов; Под ред. Ю.Ф. Тельнова. –М.: Финансы и статистика, 2002.

5. С.В. Маклаков. ERwin и Bpwin. CASE-средства разработки информационных систем.М.,1999.

6. С.В. Маклаков. Создание информационных систем с ALLFusion Modeling Suite. М.,2003.

7. http://1cbit.ru – сайт программы 1С: Бухучет и торговля.

8. http://victoria-yug.by.ru/public_best_analiz_2.htm - сайт программы БЭСТ-Анализ

9. http://www.bestnet.ru/prog_14.html - сайт программы БЭСТ-4 Магазин

10. http://www.sovmestimo1c.ru/rarus_shop2.html - сайт программы 1С-Рарус: Магазин 2.0

Приложение 1. Swim Lane Diagram

рис.1. Возврат товара от покупателя

рис.2. Прием товара от поставщика
Приложение 2. Функциональная модель

Рис.1.

Рис.2

Рис.3

Рис.4

Рис.5

Рис.6

Рис. 7

Рис.8

Рис.9

Рис.10

д

Приложение 3. Логическая модель

Приложение 4. Пользовательский интерфейс

рис. 1. Стартовая форма 3

рис.2. Управление закупками (Директор)

рис.3. Анализ ассортимента магазина (Администратор)

рис.4. Учет актов (Администратор)

рис. 5. Инвентаризация торгового зала (Администратор)

рис.6. Возврат товаров от покупателей (Кассир)

рис.7. Журнал регистрации документов (Кассир)

рис. 8. Продажа товаров (Кассир)

рис.9. Пользовательский интерфейс для мерчендайзера

рис.10. Учет денежных средств и кредитных операций (Бухгалтер)

рис.11. Учет оплаты труда (Бухгалтер)

рис. 12. Учет материальных ценностей (Бухгалтер)

рис.13. Пользовательский интерфейс для кладовщика

Приложение 5. Входные и выходные документы

РАСЧЕТНАЯ ВЕДОМОСТЬ №___

________200_г.

ВЕДОМОСТЬ ОБОРУДОВАНИЯ на месяц

ИНВЕНТАРИЗАЦИОННАЯ ОПИСЬ

ТОВАРНО-МАТЕРИАЛЬНЫХ ЦЕННОСТЕЙ Nо. _________

Дата начала инвентаризации

Дата окончания инвентаризации

Итого по описи:

количество порядковых номеров _________________________________

общее количество единиц фактически_______________

на сумму, руб. фактически ________________________

ЖУРНАЛ РЕГИСТРАЦИИ ПРИХОДНЫХ И РАСХОДНЫХ КАССОВЫХ ДОКУМЕНТОВ 20___ Г.

Итого

Акт №______ от____________20___г.
о возврате бракованного товара.

Итого Сумма, руб.(прописью)_______________в том числе НДС, руб.(прописью)____________________________ Должность_____________ подпись_________ Ф.И.О.

ЗАЯВЛЕНИЕ

на обмен непродовольственного товара надлежащего качества

«__»__200_г. в Вашем магазине «______», расположенном по адресу:____

^{дата название адрес}

я приобрел(а) ________________по цене ______(_________) рублей.

^{наименование товара цифрами прописью}

Прошу обменять указанный товар ___________________________________

^{указать причину обмена}

на аналогичный товар без какого-либо перерасчета покупной цены.

___________ /____________/

^{подпись расшифровка}

^{«__»__________200_г.}

Баланс

Предприятие, организация

Адрес -----------------------------------------------------------