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

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

Рис. 6 Сетевая диаграмма этапов

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

Рис.7 Временная диаграмма распределения работников по этапам

Раздел 2 Описание предметной области и постановка задачи на проектирование

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

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

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

§ описание его структуры с выделением основных составляющих и определением их роли в достижении поставленных целей;

§ четкое определение места анализируемого объекта в системе более круп­ного масштаба;

Желательно также проанализировать финансовые показатели: доходы, рас­ходы и результаты деятельности.

Характеристика и анализ объекта исследования проводится от общего к частному с последующим углублением и расширением.

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

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

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

Объем этой части не должен превышать 3 страницы.

Раздел 3. Концептуальная модель данных

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

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

· наличие в модели не менее трёх уровней;

· не менее двух уровней декомпозиции в стандарте IDEF0 (контекстная диаграмма + диаграммы A0);

· на диаграмме 1-го уровня (A0) не менее 4-х функциональных блоков;

· на диаграмме 2-го и далее уровнях должна быть декомпозиция в стандарте IDEF3, на каждой диаграмме не менее 2-х функциональных блоков

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

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

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

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

Раздел 4 «Разработка требований к информационной системе»

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

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

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

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

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

Дата добавления: 2014-10-15