Переход на физический уровень

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

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

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

Описание MS Project

Одним из наиболее распространенных программных продуктов, предназначенных для управления проектами, является Microsoft Project. На сегодняшний день - MS Project представляет собой оптимальный набор программных инструментов для управления проектами со стандартным офисным интерфейсом, что является немаловажным фактором для большинства пользователей, работающих с пакетом MS Office.

Основные особенности пакета:

- иерархические коды структур для задач и ресурсов;

- расходуемые материалы как вид ресурсов;

- месяц как единица длительности работ;

- индивидуальные календари для задач;

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

- поля с формулами вычислений, определяемыми пользователями;

- две шкалы времени (основная и вспомогательная);

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

- создание шаблонов проектов.

Описание WBS

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

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

WBS обеспечивает выявление работ, необходимых для достижения целей проекта. При таком подходе проект определяется в терминах иерархически взаимосвязанных ориентированных на результат элементов (пакетов работ – комплексов работ, сгруппированных по заданным основаниям/критериям). Каждый следующий уровень декомпозиции обеспечивает последовательную детализацию содержания проекта, что позволяет производить оценку выполненных объемов работ, освоенных денег и выполнения по срокам. На нижних уровнях пакетам работ соответствуют сравнительно меньшие объемы работ. Это упрощает оценку процента выполнения и дает возможность более четко определять действия, необходимые для достижения целей проекта.

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

Правила разработки WBS

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

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

2. Каждый элемент WBS должен являться агрегатом всех подчиненных элементов, перечисленных непосредственно под ним.

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

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

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

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

7. Все результаты в явном виде должны быть включены в WBS.

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

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

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

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

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

Иерархия работ

В этом разделе описывается иерархия работ, необходимых мне для выполнения и защиты ВКР бакалавра.

Сначала я выделил основные блоки (пакеты) работ над проектом, которые отражают процесс подготовки и создания ВКР. Затем декомпозировал эти блоки на более мелкие, чтобы иметь представление о том, что конкретно нужно выполнить в каждом пакете. Каждая задача имеет сроки выполнения, в которые нужно уложиться. Они отражены в диаграмме Ганта в Приложении 3. В итоге получилась следующая иерархия работ:

Организационные работы по проекту

Выбор руководителя

Выбор темы

Утверждение темы у зав. Кафедрой

Подготовительные работы

Сбор информации

Анализ информации

Постановка задачи и целей работы

Выполнение первой части работы

Оформление введения

Описание предметной области

Согласование работы с преподавателем

Внесение исправлений и дополнений

Выполнение второй части работы

Описание CASE-средства

Построение моделей и диаграмм

Выполнение поставленных задач

Подготовка выводов

Согласование работы с преподавателем

Внесение изменений и дополнений

Выполнение презентации

Заключительные работы

Утверждение работы у руководителя

Рецензирование

Подача зав. Кафедрой на утверждение

Подготовка речи

Защита ВКР

Заключение

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

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

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

Также я составил расписание работ, необходимых для написания ВКР бакалавра, и которому я следую.

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

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