Построение сетевой и временной диаграмм
Временные и сетевые диаграммы полезны для представления графика работ. Временная диаграмма показывает время начала и окончания каждого этапа и его длительность. Сетевая диаграмма отображает зависимости между различными этапами проекта. Эти диаграммы можно создать автоматически с помощью программных средств поддержки управления на основе информации, заложенной в базе данных проекта.Если для создания сетевой диаграммы используются программные средства поддержки управления проектом, каждый этап должен заканчиваться контрольной отметкой. Очередной этап может начаться только тогда, когда будет получена контрольная отметка (которая может зависеть от нескольких предшествующих этапов). Поэтому в третьем столбце табл. 2 приведены контрольные отметки; они будут достигнуты только тогда, когда будет завершен этап, в строке которого помещена соответствующая контрольная отметка.Любой этап не может начаться, пока не выполнены все этапы на всех путях, ведущих от начала проекта к данному этапу. Минимальное время выполнения всего проекта можно рассчитать, просуммировав в сетевой диаграмме длительности этапов на самом длинном пути (длина пути здесь измеряется не количеством этапов на пути, а суммарной длительностью этих этапов) от начала проекта до его окончания (это так называемый критический путь).
Рис. 6 Сетевая диаграмма этапов
Временная диаграмма (иногда называемая по имени ее изобретателя диаграммой Гантта) может быть построена программными средствами поддержки процесса управления. Она показывает длительность выполнения каждого этапа и возможные их задержки (показаны затененными прямоугольниками), а также даты начала и окончания каждого этапа. Этапы критического пути не имеют затененных прямоугольников; это означает, что задержка с завершением данных этапов приведет к увеличению длительности всего проекта.
Рис.7 Временная диаграмма распределения работников по этапам
Раздел 2 Описание предметной области и постановка задачи на проектирование
В разделе используются фактические материалы, характеризующие объект исследования, его техническую, социальную, экономическую и организационную стороны. Причем более подробная характеристика дается по тем аспектам деятельности объекта, которые непосредственно связаны с решением задач, поставленных в курсовом проекте.
Характеристика объекта исследования независимо от специфики темы курсового проекта должна содержать:
§ перечень целей, необходимость реализации которых обусловила создание и функционирование исследуемого объекта;
§ описание его структуры с выделением основных составляющих и определением их роли в достижении поставленных целей;
§ четкое определение места анализируемого объекта в системе более крупного масштаба;
Желательно также проанализировать финансовые показатели: доходы, расходы и результаты деятельности.
Характеристика и анализ объекта исследования проводится от общего к частному с последующим углублением и расширением.
Источниками информации по вышеназванным вопросам могут служить: паспорт территории, устав предприятия, история создания и развития предприятия, положения о структурных подразделениях, материалы годовых отчетов деятельности объекта исследования и другие.
При изложении фактического материала основное внимание сосредотачивается не столько на характеристике объекта (большинство фактических данных и общих иллюстраций может быть представлено в приложениях), сколько на выявлении и анализе положительных сторон и недостатков его функционирования.
При оформлении этого раздела имеются большие возможности по использованию графических способов представления данных: схем, диаграмм, графиков и т.п.
Объем этой части не должен превышать 3 страницы.
Раздел 3. Концептуальная модель данных
Задачей этапа концептуального проектирования БД является создание формализованного описания данных на основе описания предметной области – концептуальной модели данных (КМД). Создание КМД позволит автоматизировать процесс проектирования, давая возможность использовать различные CASE – средства
Построение функциональных моделей на основании требований к информационной системе. Модель должна отражать весь указанный в описании функционал, а также чётко отражать существующие потоки данных и описывать правила их движения;
· наличие в модели не менее трёх уровней;
· не менее двух уровней декомпозиции в стандарте IDEF0 (контекстная диаграмма + диаграммы A0);
· на диаграмме 1-го уровня (A0) не менее 4-х функциональных блоков;
· на диаграмме 2-го и далее уровнях должна быть декомпозиция в стандарте IDEF3, на каждой диаграмме не менее 2-х функциональных блоков
Концептуальная модель абстрактно – в терминах задач, нажатий на клавиши, манипуляций мышью или экранной графики – описывает, что именно пользователь должен делать с системой, и какие концепты ему необходимо знать. Основная идея заключается в том, что тщательная разработка подробной концептуальной модели, на основе которой потом проектируется пользовательский интерфейс, делает приложение более простым и понятным для понимания. При этом необходимо, во-первых, сделать концептуальную модель максимально простой с использованием минимального количества концептов для обеспечения необходимой функциональности; и во-вторых, максимально ориентировать концептуальную модель на конкретные задачи, то есть исключить или ограничить работу пользователя с концептами, не фигурирующими в данной области задач.
Важным компонентом концептуальной модели является анализ объектов и действий – список всех видимых пользователю объектов приложения и действий, которые пользователь может совершать над каждым объектом. В реализации системы могут присутствовать и другие объекты, но предполагается, что они будут невидимыми для пользователя.
Объекты концептуальной модели приложения могут образовывать структурную иерархию, в которой дочерние блоки будут перенимать действия родительских. В зависимости от приложения объекты могут также образовывать иерархию включения, в которой некоторые объекты включают в себя другие. Использование двух этих типов иерархии в концептуальной модели значительно облегчает проектирование и разработку связного и понятного пользовательского интерфейса.
Подобный анализ объектов и действий помогает управлять реализацией системы, поскольку он указывает наиболее удобный вид иерархии объектов, а также методы работы, которые предусматривает каждый вид. Он также облегчает структуру команд приложения, т.к. позволяет разработчику увидеть, какие действия применимы к разным объектам и могут быть спроектированы как обобщенные.
Раздел 4 «Разработка требований к информационной системе»
на основе анализа определяются требования к создаваемой системе, и дается обоснование актуальности разработки.
· наличие пользовательских требований, четко описывающих будущий функционал системы;
· наличие системных требований, включающих требования к структуре, программному интерфейсу, технологиям разработки, общие требования к системе (надежность, масштабируемость, распределённость, модульность, безопасность, открытость, удобство пользования и т.д.);
Проблемы, которые приходится решать специалистам в процессе создания программного обеспечения, очень сложны. Природа этих проблем не всегда ясна, особенно если разрабатываемая программная система инновационная. В частности, трудно чётко описать те действия, которые должна выполнять система. Описание функциональных возможностей и ограничений, накладываемых на систему, называется требованиями к этой системе, а сам процесс формирования, анализа, документирования и проверки этих функциональных возможностей и ограничений – разработкой требований.
Требования подразделяются на пользовательские и системные. Пользовательские требования – это описание на естественном языке функций, выполняемых системой, и ограничений, накладываемых на неё. Системные требования – это описание особенностей системы (архитектура системы, требования к параметрам оборудования и т.д.), необходимых для эффективной реализации требований пользователя.