Разработка информационной системы ОВД г. Донецка

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

Рис 2.10 - Общая структура данных учёта платежей

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

1. Таблица «Группы аппаратуры» (Рис 2.11);

Рисунок 2.11 - таблица «Группы аппаратуры»

Поля таблицы (рис. 2.12):

Рисунок 2.12 - поля таблицы «Группы аппаратуры»

В данной таблице ключевым является поле «ID тех средства», которое служит для обеспечения целостности данных. «Наименование аппаратуры» берется из таблицы «Материалы», «Спецификация» из таблицы «Спецификация».

2. Таблица «Возврат материала» (рис.2.13);

Рисунок 2.13 - Таблица «Возврат материала»

Поля таблицы (рис. 2.14):

Рисунок 2.14 - поля таблицы «Возврат материала»

В данной таблице ключевым является поле «ID». «Материал принял» и «Материал сдал» берется из таблицы «Персонал», «Наименование тех средств» из таблицы «Материалы».

3. Таблица «Должность» (рис. 2.15);

Рисунок 2.15 - таблица «Должность»

Поля таблицы (рис. 2.16):

Рисунок 2.16 - поля таблицы «Должность»

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

4. Таблица «Заявки на материал» (рис. 2.17);

Рисунок 2.17 - таблица «Заявки на материал»

Поля таблицы (рис. 2.18):

Рисунок 2.18 - поля таблицы «Заявки на материал»

В данной таблице ключевым является поле «ID заявки». «Наименование» берется из таблицы «Материалы».

5. Таблица «Изменения в конструкции во время эксплуатации» (рис. 2.19);

Рисунок 2.19 - таблица «Изменения в конструкции во время эксплуатации»

Поля таблицы (рис. 2.20):

Рисунок 2.20 - поля таблицы «Изменения в конструкции во время эксплуатации»

В данной таблице ключевым является поле «ID». «Наименование» берется из таблицы «Материалы», «Должность ответственного лица» из таблицы «Должность», «ФИО ответственного» из таблицы «Персонал».

6. Таблица «Инвентаризация средств связи» (рис. 2.21);

Рисунок 2.21 - таблица «Инвентаризация средств связи»

Поля таблицы (рис. 2.22):

Рисунок 2.22 - поля таблицы «Инвентаризация средств связи»

В данной таблице ключевым является поле «ID инвентаризации». «Наименование» берется из таблицы «Материалы».

7. Таблица «Материалы» (рис. 2.23);

Рисунок 2.23 - таблица «Материалы»

Поля таблицы (рис. 2.24):

Рисунок 2.24 - поля таблицы «Материалы»

Представленная таблица содержит поле «Наименование», она необходима для связки практически всех таблиц по полю «ID тех средства».

8. Таблица «Персонал» (рис. 2.25);

Рисунок 2.25 - таблица «Персонал»

Поля таблицы (рис. 2.26):

Рисунок 2.26 - поля таблицы «Персонал»

Представленная таблица содержит поле «Фамилия ИО», она необходима для связки таких таблиц, как «Возврат материала», «Изменения в конструкции во время эксплуатации и ремонта», «Результаты проверки инспектирующими лицами», «Сведения о движении изделия при эксплуатации», «Учет технического обслуживания» по полю «ID» «Должность» берется из таблицы «Должность».

9. Таблица «Спецификация» (рис. 2.27);

Рисунок 2.27 - таблица «Спецификация»

Поля таблицы (рис. 2.28):

Рисунок 2.28 - поля таблицы «Спецификация»

Представленная таблица содержит поле «Спецификация», она необходима для связки таблицы «Группы аппаратуры».

10. Таблица «Учет технического обслуживания» (рис. 2.29);

Рисунок 2.29 - таблица «Учет технического обслуживания»

Поля таблицы (рис. 2.30):

Рисунок 2.30 - поля таблицы «Учет технического обслуживания»

В данной таблице ключевым является поле «ID». «Должность ответственного» берется из таблицы «Должность», «ФИО ответственного» берется из таблицы «Персонал».

Схема данных. Схема данных необходима для отражения таблиц, их атрибутов, а также связей между ними по ключевым полям. Далее представлена схема данных на основании построенных таблиц (рис. 2.31):

Рисунок 2.31 - Схема данных

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

Физическая модель данных представлена на рисунке 2.32.

Рисунок 2.32 - Физическая модель данных

Для реализации программы «Информационная система МРССиСт» были выбраны такие программные средства разработки как Microsoft Access 2002 и язык программирования Microsoft Visual С# .Net.

Microsoft Access - это интерактивная реляционная СУБД для WINDOWS . Это программа, которую используют для хранения и извлечения данных в зависимости от отношений, которые установлены. Работа с ней упрощена посредством манипулятора мыши. Графические возможности оболочки производят большое впечатление при изготовлении высококачественных отчетов и распечаток. Все это благодаря поддержки True-type шрифтов и встраивания OLE-объектов в рамках среды WINDOWS. OLE - объект представляет собой ссылку на определенную информацию, которая остается в своей первоначальной форме. [6]

Access также предоставляет в распоряжение пользователя механизмы работы с базами данных различных форматов.

Поскольку в инженерном отделе находится всего 3 компьютера была потребность в небольшой и гибкой СУБД. В итоге можно сделать вывод, что Microsoft Access 2003 идеальная среда разработки БД для данной организации, отвечающая всем представленным требованиям.

Специально для платформы Microsoft Visual Studio .Net был разработан новый язык программирования - C#. Он впитал в себя многое из того лучшего, что есть в самых разных языках программирования. [11]

Язык C# обезоруживает своей простотой - в нем насчитывается около 80 ключевых слов и десяток встроенных типов данных. Тем не менее, он оказывается исключительно выразительным, когда дело доходит до реализации современных концепций программирования. Язык C# включает в себя самую полную поддержку структурного, компонентно-ориентированного и объектно-ориентированного программирования, которую только можно ожидать от современного языка. [25]

В C# предусмотрены встроенные синтаксические конструкции для работы с перечислениями, структурами и свойствами классов.

C# позволяет интерактивно конструировать внешний вид приложений. Можно располагать разные элементы управления (кнопки, полосы прокрутки и т.п.) на поверхности окна программы, а C# генерирует соответствующий код. [44]

Таким образом, гармонично сочетающиеся между собой компоненты разработки информационной системы МРССиСТ СУБД MS Access и язык высокого уровня C#, идеально подходят не только для взаимодействия между собой, но и для нужд инженерного отдела милиции.

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

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

- выбор объектов;

- ввод информации о технике;

- просмотр, редактирование и печать отчетов.

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

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

Для начала работы с программой необходимо запустить файл Mrssst.exe. Работа с системой начинается с главного меню. Структура меню представлена на рисунке 2.33. Меню включает в себя следующие пункты: Файл, Правка, Вид, Таблица, Окно.

Рисунок 2.33 - Главное меню

Далее «Открыть», а потом выбрать нужное: «Справочники», «Карточки учета», «Резервное копирование» или «Формы» (Рисунок 2.34)

Рисунок 2.34 - Меню «Открыть»

При выборе подпункта «Материалы» подменю «Справочники» появляется окно «Материалы» (рисунок 2.35).

Рисунок 2.35 - Окно «Материалы»

При выборе подпункта «Группы аппаратуры» подменю «Справочники» появляется окно «Группы аппаратуры» (рисунок 2.36).

Рисунок 2.36 - Окно «Справочник группы аппаратуры»

При выборе подпункта «Карточки учета материалов» подменю «Карточки учета» появляется окно «Карточки учета материалов» (рисунок 2.37).

Рисунок 2.37 - окно «Карточки учета материалов»

Форма «Создание новой записи» (рисунок 2.38) позволяет создавать и добавлять новые записи в таблицу.

Рисунок 2.38 - форма «Создание новой записи»

Подменю «Установка даты» позволяет установить текущую дату (рисунок 2.39).

Рисунок 2.39 - форма «Установка текущей даты»

Если нужно распечатать полученный документ, нужно выбрать в меню «Файл» - «Печать» (рисунок 2.40). Здесь же можно выбрать вид печати: предварительный просмотр или стандартная печать.

Рисунок 2.40 - окно «Печать документов»

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

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

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

Используются стандартные библиотеки (рисунок 3.1)

using System;

using System.Data.OleDb;

using System.Drawing;

using System.Collections;

using System.ComponentModel;

using System.Windows.Forms;

using System.Data;

using System.Xml;

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

Весь активный процесс C#-программы происходит в пределах класса. Класс является основой, для создания объектов. В классе определяются данные и код, который работает с этими данными. [45]

Типы членов классов C#:

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

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

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

- константы. Это поле, значение которого изменить нельзя.

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

- события. Событие вызывает исполнение некоторого фрагмента кода. События - неотъемлемая часть для программирования Microsoft Windows. [33]

Поскольку в предыдущем разделе 2.4 Обоснование выбора платформы создания информационной системы было принято решение о разработке приложения программы с помощью объектно - ориентированного языка высокого уровня C# на платформа .NET то на ее основе, определено множество типов (организованных в соответствующие пространства имен) для взаимодействия с локальными и удаленными хранилищами данных. Общее название пространств имен с этими типами -- ADO.NET.

Модель объектов ADO.NET очень обширна, но в ее основе лежит довольно простой набор классов. Наиболее важным из них является DataSet. DataSet представляет собой отображение используемой базы данных, перенесенной на машину пользователя. При этом нет необходимости постоянно подключаться к серверу базы данных для модификации данных.

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

DataSet состоит из объектов типа DataTable и объектов DataRelation. К ним можно обращаться как к свойствам объекта DataSet. Свойство Tables возвращает объект типа DateTableCollection, который содержит все объекты DataTable используемой базы. [25]

Таблица - 3.1 - Пространство имен ADO.NET

Создание DataSet осуществляется при помощи управляемого провайдера (managed provider). Управляемый провайдер -- это набор классов, реализующих интерфейсы, определенные в пространстве имен System.Data.

Второй возможностью доступа к данным является использование OLE DB Provider. Такой способ позволяет осуществлять доступ к любому OLE DB провайдеру, включая Access.

В реализованном приложении ADO.NET мы использовали одно пространство имен -- System.Data. Кроме того, нам практически во всех ситуациях потребуется использовать еще либо пространство имен System.Data.OleDb-- для установления соединения с источником данных.

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

§ открыть соединение (connection) с базой данных;

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

§ закрыть соединение с базой данных.

Связь с базой данных остается активной только на достаточно короткий срок -- на период выполнения запроса. [45]

После записи информации из таблиц в приложение связи с БД закрывается.

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

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

В данном дипломном проекте в качестве тестирования был использован метод тестирования «черного ящика».

План тестирования ПО представлен в ПРИЛОЖЕНИИ Г.

Тестовый пример можно разделить на следующие категории:

1. Нет данных;

2. Повторное выполнение;

3. Верные данные.

Пример теста когда «нет данных» показан на рисунке 3.3.1:

Рисунок 3.3.1 - тестовый пример «нет данных»

Пример теста когда «повторное выполнение», т.е. введение одних и тех же значений, показан на рисунке 3.3.2:

Рисунок 3.3.2 - тестовый пример «Повторное выполнение»

Пример теста когда «верные данные» показан на рисунке 3.3.3.

Рисунок 3.3.2 - тестовый пример «Повторное выполнение»

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

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

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

Разработка разбивается на четыре этапа:

- планирование;

- анализ риска;

- оценка заказчика;

- конструирование.

Одним из возможных подходов к разработке ПО в рамках спиральной модели ЖЦ является получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки ПО, содержащий 3 элемента:

- небольшую команду программистов (от 2 до 10 человек);

- короткий, но тщательно проработанный производственный график (от 2 до 6 мес.);

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

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

Жизненный цикл ПО по методологии RAD состоит из четырех фаз:

- фаза анализа и планирования требований;

- фаза проектирования;

- фаза построения;

- фаза внедрения.

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

На фазе проектирования часть пользователей принимает участие в техническом проектировании системы под руководством специалистов-разработчиков. CASE-средства используются для быстрого получения работающих прототипов приложений. Пользователи, непосредственно взаимодействуя с ними, уточняют и дополняют требования к системе, которые не были выявлены на предыдущей фазе. Более подробно рассматриваются процессы системы. Анализируется и, при необходимости, корректируется функциональная модель. Каждый процесс рассматривается детально. При необходимости для каждого элементарного процесса создается частичный прототип: экран, диалог, отчет, устраняющий неясности или неоднозначности. Определяются требования разграничения доступа к данным. На этой же фазе происходит определение набора необходимой документации. [37]

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

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

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

- точно определенные с помощью CASE-средства интерфейсы между автономно разрабатываемыми подсистемами;

- построенные прототипы экранов, отчетов, диалогов.

Все модели и прототипы должны быть получены с применением тех CASE-средств, которые будут использоваться в дальнейшем при построении системы. Данное требование вызвано тем, что в традиционном подходе при передаче информации о проекте с этапа на этап может произойти фактически неконтролируемое искажение данных. Применение единой среды хранения информации о проекте позволяет избежать этой опасности. [14]

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

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

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

- определяется необходимость распределения данных;

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

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

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

- определяются способы увеличения производительности;

- завершается разработка документации проекта.

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

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

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

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

Таблица 4.1 - Размер приложения

В качестве итога перечислим основные принципы методологии RAD:

- разработка приложений итерациями;

- необязательность полного завершения работ на каждом из этапов жизненного цикла;

- обязательное вовлечение пользователей в процесс разработки ИС;

- необходимое применение CASE-средств, обеспечивающих целостность проекта;

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

- необходимое использование генераторов кода;

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

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

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

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

RAD - технология не применима для построения:

- сложных расчетов программ;

- операционных систем;

- а также приложений, от которых зависит безопасность людей. [39]

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

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

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

Структура пооперационного перечня работ разрабатывалась в приложении Microsoft Office Project 2003, как и весь проект.

Эта структура включает следующие задачи и подзадачи:

Анализ и планирование требований к программному продукту:

- анализ требований;

- создание черновой версии спецификации проекта;

- разработка графика сдачи;

- получение разрешений на продолжение (концепция, расписание).

Проектирование:

- разработка общей информационной модели системы;

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

- точное определение интерфейсов;

- построение прототипов экранных форм, диалогов, отчетов.

Разработка:

- Определение параметров модульной и уровневой архитектуры;

- Назначение персонала для разработки;

- Разработка кода.

Реализация:

- Разработка планов тестирования модулей с использованием спецификации продукта;

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

Тестирование модулей:

- Ревизия кода модулей;

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

- Выявление ошибок в спецификациях продукта;

- Изменение кода;

- Повторное тестирование измененного кода.

Тестирование интеграции:

- Тестирование интеграции модулей;

- Выявление ошибок и недоработок;

- Изменение кода;

- Повторное тестирование измененного кода.

Разработка документации:

- Разработка справки;

- Разработка руководства пользователя;

- Ревизия всей документации для пользователей;

- Доработка документации для пользователей с учетом замечаний. [36]

Более наглядное представление структуры пооперационного перечня работ приводится в ПРИЛОЖЕНИИ Е - Перечень работ.

Для того чтобы идентифицировать задачи и действия необходимо в Microsoft Office Project 2003 выбрать команду меню Вид ¦ Использование задач. Все работы можно классифицировать по своим характеристикам: длительности, трудозатратам и количеству людских ресурсов. Данные параметры связаны друг с другом: трудозатраты задачи равны произведению длительности на количество людских ресурсов. Задачи в плане проекта могут быть трех типов: с фиксированными длительностью, трудозатратами и количеством ресурсов.

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

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

Основные проектные документы, подготавливаемые на данном этапе, -- это:

- концептуальный проект системы;

- настроенные в системе прототипы бизнес-процессов;

- уточненный объем проекта;

- уточненный план проекта.

Для того чтобы реализовать ту или иную задачу необходимы ресурсы (человек или оборудование). В нашем случае ресурсами будут:

- руководитель проекта;

- группа аналитиков;

- разработчики;

- тестеры;

- специалисты по распространению технической информации;

- инструкторы; [38]

Каждой задаче соответствует тот или иной вид ресурсов, что наглядно показано на рисунке 4.1.

Рис4.1 - Идентификация задач

Страницы: 1, 2, 3