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

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

Рубрика Программирование, компьютеры и кибернетика
Вид дипломная работа
Язык русский
Дата добавления 12.01.2011
Размер файла 2,4 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

проверка типичных значений аргументов;

проверка обработки минимальных и максимальных значений аргументов;

использование заведомо недопустимых аргументов;

комбинированные примеры.

Существует так же еще несколько методов тестирования, рассмотрим два из них. Этот метод «черного ящика» и метод «белого ящика».

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

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

Имеющийся программный продукт тестировался по методу «белого ящика».

План тестирования:

система будет тестироваться методом «белого ящика»;

должно быть соблюдено соответствие между данными, хранящимися в БД, и данными появляющимися при тестировании программного модуля:

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

должна быть соблюдена проверка связи компонента с БД;

приложение отправляется на доработку, если найдено несоответствие. При исправлении ошибки приложение снова отправляется на тестирование.

Первым этапом тестирования программного модуля будет проверка связи с базой данной.

Входными параметрами являются:

информация о пользователях (ФИО, логин, пароль);

информация о повестке дня;

информация о пунктах повестки дня;

информация о месте проведения заседания;

Запуск программного модуля в режиме отладки при недоступном сервере баз данных, как и следовало ожидать, отладчик выдал ошибку - «Невозможно открыть базу данных, не удалось выполнить вход» (рисунок 3.5).

Рисунок 3.5 - Запуск программы в режиме отладки

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

Рисунок 3.6 - Ошибка в приложении

Последующий запуск приложения с доступной базой данных приводил к корректной работе приложения (рисунок 3.7).

Рисунок 3.6 - Корректная работа приложения

Методика развертывания приложения

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

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

секретарь;

члены руководящего аппарата ЧГП «Форсайт-центр».

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

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

Microsoft® Windows® XP/Vista/7;

Standard Resolution 640 x 480;

1024 MB RAM;

Windows® compatible mouse, keyboard;

Microsoft.NET Framework SDK v2.0.

Кроме этого на сервере должна быть установлена база данных Microsoft SQL Server 2005.

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

Установочный файл создавался при помощи инструментов Visual Studio.NET. Данный выбор был обусловлен возможностью избегания таких проблем как: при выборе других инструментов вероятен отказ приложения после установки в запуске, созданный конфликт DLL новой программой с другой программой, отказ деинсталлирующей программы, оставление файлов DLL в реестре и других файлов поддержки после удаления программы. В Visual Studio.NET процесс установки упрощен, так как приложения Visual Studio в основном используют функциональность библиотек классов.NET Framework, а не компоненты COM и вызовы функций Windows API. Кроме того, приложения Visual Studio компилируются как сборки - единицы развертывания, состоящие из одного или более файлов, необходимых для запуска программы.

Выводы

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

Продемонстрирована реализация взаимодействия компонента с СУБД и с клиентским приложением.

4. Управление информационным проектом

Выбор жизненного цикла разработки ПО

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

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

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

На основе этого результата будет определена наиболее приемлемая модель ЖЦ. На основе этого результата будет определена наиболее приемлемая модель модели жизненного цикла АИС учета и анализа деятельности управляющего аппарата ЧГП «Форсайт-центер».

Таблицы с вопросами, ответы на которые будут определять оптимальную модель жизненного цикла для информационной системы, приведено в ПРИЛОЖЕНИИ Г.

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

Таблица 4.1 -- Определение оптимальной модели жизненного цикла в баллах

Характеристика

Каскадная

V-образная

Прототипирование

Спиральная

RAD

Инкрементная

Требования

5

5

2

2

4

4

Участники команды разработчиков

4

5

5

2

8

5

Коллектив пользователей

3

6

5

8

7

6

Типы проектов и рисков

1

1

3

1

4

3

Итого

13

17

15

13

23

18

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

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

дефицит специалистов;

нереалистичные сроки и бюджет;

реализация несоответствующей функциональности;

разработка неправильного пользовательского интерфейса;

«золотая сервировка», перфекционизм, ненужная оптимизация и оттачивание деталей;

непрекращающийся поток изменений;

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

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

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

«разрыв» в квалификации специалистов разных областей знаний.

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

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

оценка и разрешение рисков;

определение целей;

разработка и тестирование;

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

На каждом витке спирали могут применяться разные модели процесса разработки ПО. В конечном итоге на выходе получается готовый продукт. Модель сочетает в себе возможности модели прототипирования и водопадной модели (процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований). Разработка итерациями отражает объективно существующий спиральный цикл создания системы. Неполное завершение работ на каждом этапе позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем этапе. При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации. Главная задача -- как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований. Основная проблема спирального цикла -- определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков. Одним из возможных подходов к разработке программного обеспечения в рамках спиральной модели жизненного цикла является получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки программного обеспечения, содержащий 3 элемента:

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

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

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

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

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

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

фаза реализации;

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

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

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

Таблица 4.2 -- Определение размера приложения по методологии RAD

< 1000 функциональных элементов

один человек

1000-4000 функциональных элементов

одна команда разработчиков

> 4000 функциональных элементов

4000 функциональных элементов на одну команду разработчиков

Определение цели и области действия программного проекта

Целью программного проекта является разработать и внедрить информационную систему учета и анализа деятельности управляющего аппарата ЧГП «Форсайт-центер». Разработанная информационная система будет представлена в виде взаимосвязанных модулей, которые обеспечивают эффективный ввод, обработку и передачу информации с сохранением в серверной базе данных.

Задачи проекта:

выполнить сбор, спецификацию и аттестацию требований

выполнить проектирование информационного и программного обеспечения системы;

разработать скрипты описания базы данных и программные коды приложения;

провести тестирование программного продукта;

Программный проект должен быть:

продуктом для внутреннего использования в ЧГП «Форсайт-центер»;

проектом для осуществления многопользовательского доступа;

Программный проект не должен быть:

проектом, доступным для посторонних лиц.

При определении области действия программного продукта эффективнее всего воспользоваться методикой «будет,/не будет». Ниже определены рамки проекта.

Проект будет:

сетевым;

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

применяться в операционных системах Windows.

Проект не будет:

локальным;

использоваться в системах отличных от Windows.

Создание структуры пооперационного перечня работ

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

Процесс создания Автоматизированной информационной системы анализа и учета деятельности руководящего аппарата ЧГП «Форсайт-центр» представляется в виде перечня работ, реализованном в прикладном пакете Microsoft Office Project 2007.

Рисунок 4.1 -- Пооперационный перечень работ АИС

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

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

планирование и активизация проекта;

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

фаза описания пользователя;

фаза «расчистки».

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

установку соответствия между действиями и планом;

распределение ресурсов проекта;

установку среды проекта;

планирование управлением проекта.

Данный жизненный цикл разработан для полноценно функционирующей АИС.

Идентификация задач и действий

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

анализ функций на уровне системы/продукта;

разработку системной архитектуры;

декомпозицию системных требований;

уточнение и разработку требований к ПО;

определение требований к интерфейсу;

изучение выполнимости - выполнение имитаций и сравнительных тестов;

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

создание БД - идентификация предварительных элементов БД;

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

- планирование следующей фазы.

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

планирование и активизация проекта;

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

фаза описания пользователя;

фаза «расчистки».

Фаза планирование и активизация проекта включает в себя:

установку соответствия между действиями и планом;

распределение ресурсов проекта;

установку среды проекта;

планирование управлением проекта.

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

процесс определения структуры системы:

анализ функций;

разработка архитектуры системы;

декомпозиция системных требований;

процесс определения требований:

определение и разработка требований к ПО;

определение требований к интерфейсу;

расстановка приоритетов и интеграция требований к ПО;

Фаза описания пользователя так же разделена на три основные задачи с подзадачами:

процесс разработки проекта:

разработка проекта архитектуры;

проектирование базы данных;

проектирование интерфейсов;

выбор либо разработка алгоритмов;

разработка модуля секретаря;

разработка модуля члена руководящего аппарата;

фаза конструирования.

Процесс внедрения:

генерирование тестовых данных;

создание исходного кода;

генерирование объектного кода;

создание оперативной документации;

планирование интеграции;

выполнение интеграции;

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

разработка тестовых требований;

выполнение тестов.

Фаза «расчистки» включает процесс установки, который делится на:

план установки;

распространение ПО;

инсталляция ПО;

установка ПО в операционной среде;

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

Оценка размера и возможности повторного использования ПО

Для оценки размера описываемого приложения был применен метод оценки количества строк кода SLOC (англ. Source Lines of Code -- SLOC). Данный метод заключается в подсчете созданных классов, а так же определенных методах в классах приложения. В данной разрабатываемой системе количество созданных классов будет равняться 15, а количество методов приходящихся на каждый класс будет рано в среднем 12. Так же необходимо определить какое количество строк кода(LOC) приходится на один метод. В зависимости от функций выполняемых определенным методом, количество строк кода будет колебаться от 10 - до 30. В общем же количество строк кода разрабатываемой системы равно 1700. Данные цифры являются усредненными, т.к. невозможно подсчитать точную цифру на этапе проектирования или разработки информационной системы.

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

Оценка длительности и стоимости разработки ПО

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

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

соблюдение директивных сроков завершения проекта;

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

своевременная коррекция исходного плана в соответствии с реальным положением дел.

Для автоматизации управление проекта использовался пакет Microsoft Project 2007. Автоматизированное средство Microsoft Project является широко распространённой системой управления проектами. К тому же данная система проста в применении. Проект состоит из серии взаимосвязанных задач, составляющих основу плана работ. Задача должна представлять определённую часть работы с ясной постановкой, но в тоже время должна быть достаточно короткой, чтобы иметь возможность регулярно отслеживать её исполнение и идентифицировать проблемы на ранних этапах.

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

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

В MS Project диаграмма Ганта является основным средством визуализации плана проекта. Эта диаграмма представляет собой график, на котором по горизонтали размещена шкала времени, а по вертикали расположен список задач. При этом длина отрезков, обозначающих задачи, пропорциональна длительности задач. Диаграмма Ганта данного проекта находится в ПРИЛОЖЕНИИ Д.

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

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

Одним из наиболее важных свойств любого ресурса является стоимость его использования в проекте. В MS Project выделяется два типа стоимости ресурсов: повременная ставка и стоимость за использование. Повременная ставка (Rate) выражается в стоимости использования ресурса в единицу времени, например 50 рублей в час или 500 рублей в день. Повременная ставка используется для людских, а также для каких-либо материальных ресурсов. В таком случае стоимость участия ресурса в проекте составит время, в течение которого он работает в проекте, умноженное на почасовую ставку. В разработанном мной проекте использовалась повременная ставка, а так же были назначены следующие ресурсы: руководитель, проектировщик, разработчик, аналитик и тестировщик (рисунок 4.3) Общие же затраты на использование ресурсов по всему проекту можно увидеть на рисунке 4.5.

Рисунок 4.3 -- Повременная ставка в использовании ресурса

Рисунок 4.4 -- Фрагмент сетевого графика

Рисунок 4.5 -- Общие затраты на использовании ресурсов проекта

Распределение ресурсов проекта

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

Распределение ресурсов проекта при создании системы учета и анализа деятельности руководящего аппарата можно представить в виде перечня представленного на рисунке 4.6.

Рисунок 4.6 -- Распределение ресурсов проекта

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

оценить потребность в ресурсах;

спланировать рациональное распределение потребности в ресурсах во времени;

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

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

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

Пример назначения ресурса задачи можно видеть из рисунка 4.7.

Из рисунка видно, что для реализации задачи «Проектирование базы данных» назначен ресурс Проектировщик.

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

На рисунке 4.8 Представлен пример таблицы использования ресурсов.

Рисунок 4.7 -- Ресурс для задачи «Проектирование базы данных»

Рисунок 4.8 -- Таблица использования ресурса «Руководитель»

MS Project 2003 предоставляет возможность просмотра календаря ресурса. Календарь ресурса - это распределение рабочего и нерабочего времени для конкретного ресурса. Используя диалоговое окно «Календарь ресурса», менеджер может задавать различные параметры, отражающие характеристики Рабочего времени ресурсов. Так для каждого ресурса определяется тип календаря, количество рабочих и выходных дней, ежедневный график работы. На рисунке 4.8 представлен пример календаря для ресурса «Руководитель».

Рисунок 4.8 -- Календарь ресурса «Руководитель»

Оценка эффективности проекта

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

АИС должна обеспечивать:

- работу с входными данными;

- получение выходных документов;

- формирование отчетов.

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

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

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

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

Для оценки эффективности данной системы используется метод экспертных оценок. Метод расчета в данном случае состоит из нескольких этапов:

выделение цели работы системы;

определение наборов показателей, характеризующих определенную цель;

определение уровня достижения показателя;

расчет степени достижения каждой цели по выдвинутым показателям;

определение весовых коэффициентов целей;

расчет общего показателя эффективности разрабатываемой информационной системы.

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

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

, (4.1)

где - степень достижения цели, баллы;

- значение показателя, баллы;

- количество показателей.

Общий показатель эффективности рассчитывается как:

, (4.2)

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

, (4.3)

где - оценка, баллы:

, (4.3)

где - минимальное значение ранга, баллы;

- сумма рангов, баллы:

, (4.4)

где - значение, выставленное экспертом, баллы;

- количество экспертов.

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

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

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

Все это сводится в таблицу (таблица 4.3)

Таблица 4.3 - Цели, показатели и уровень достижения работы ИС

Цель

Показатель

Уровень достижения, баллы

g1 - технический уровень

y11 - минимизация количества ошибок при автоматическом формировании повестки дня

0,9

y12 - автоматизированный процесс формирования повестки дня

0,81

y13 - автоматизация голосования

0,9

g2 - коммуникация

y21 - автоматизация документального оборота

0,9

y22 - автоматизация уведомлений

1,0

g3 - социальные цели

y31 - улучшение условий труда

0,99

y32 - удобство работы

0,8

y33 - уменьшение времени выполнения работ

0,95

g4 - получение отчетности

y41 - автоматизация формирования отчетов

1,0

y42 - уменьшение объема рутинной работы

0,75

g5 - простота использования

y51 - легко понимаемый интерфейс пользователя

0,91

y52 - возможность поиска

0,75

y53 - возможность сохранения, извлечения и редактирования документов

0,87

На основе формулы 4.1 рассчитаем степень достижения целей (таблица 4.4)

Таблица 4.4 - Расчет степени достижения показателей

0,87

0,95

0,91

0,88

0,84

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

Результаты опроса представлены в таблице 4.5.

Таблица 4.5 - Результаты опроса

Эксперты

Критерии оценки

g1

g2

g3

g4

g5

Э1

4

3

2

5

1

Э2

5

4

3

1

2

Э3

1

2

4

3

5

Э4

1

2

4

3

5

Э5

1

2

4

3

5

Э6

2

1

4

3

5

Э7

2

1

4

3

5

Э8

1

2

4

3

5

Э9

1

2

4

3

5

Э10

1

2

4

3

5

Эср

1

2

4

3

5

На основании полученных оценок рассчитаем весовые коэффициенты (формула 4.2, формула 4.3, формула 4.4).

Таблица 4.6 ? Расчет суммы рангов

Ранг

Расчет

Итог

1

2

3

4+5+1

10

3+4+2

9

2+3+4

9

5+1+3

9

1+2+5

8

8

Таблица 4.7 ? Расчет оценок

Оценка

Расчет

Итог

1

2

3

0,8

0,88

0,88

0,88

1

4,44

Таблица 4.8 ? Расчет весового коэффициента

Весовой коэффициент

Расчет

Итог

0,18

0,2

0,2

0,2

0,23

Представленные расчеты сведем в таблицу.

Таблица 4.9 - Сводная таблица расчетов

Показатели

Критерии

g1

g2

g3

g4

g5

10

9

9

9

8

0,8

0,88

0,88

0,88

1

0,18

0,2

0,2

0,2

0,23

0,87

0,95

0,91

0,88

0,84

Коэффициент конкордации мнений экспертов составил 0,87 баллов (q=0,87), что позволяет считать достоверными, поскольку, нормативное значение его должно составлять больше 0,7 баллов (q>0,7).

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

Таблица 4.10 ? Общий показатель эффективности

Общий показатель эффективности

Расчет

Итог

1

2

3

E

0,18*0,87+0,2*0,95+0,2*0,91+0,2*0,88+0,23*0,84

0,9

Таким образом, можно сказать, что эффективность работы разработанной нами информационной системы по отношению к заданным целям составляет 0,9 баллов, то есть на 90% система работает оптимально. Неэффективность работы ИС составляет 10%.

Выводы

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

Заключение

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

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

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

Проведен анализ бизнес-процессов деятельности руководящего аппарата, для которого разрабатывается АИС. Построены бизнес-варианты использования, описывающие основные направления деятельности сотрудников в целом и выявлены направления деятельности сотрудников руководящего аппарата ЧГП «Форсайт-центр».

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

Во втором разделе дипломного проекта выполнено проектирование информационной системы. На данном этапе были построены модели логического и физического представления системы.

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

Физическое представление системы заключалось в построении диаграммы компонентов системы и диаграммы развертывания. Программа была спроектирована как приложение, состоящее из: модулей Systems.Windows.Forms, сервера и сервера базы данных MS SQL Server 2005.

В ходе осуществления процесса проектирования выполнено моделирование структуры данных (логическая и физическая модели). Программное средство, используемое, для создания CASE-средства использовался программный продукт Rational Rose 2007 Enterprise Edition. Был рассмотрен использованный программный инструментарий. В качестве среды разработки программного обеспечения была использована Microsoft Visual Studio 2008 и язык программирования C#.

В третьем разделе дипломного проекта рассмотрена реализация программного продукта и вопросы, связанные с реализацией. Реализованы функции и классы взаимодействия с базой данных. Приведены методы и свойства классов. Продемонстрирован фрагментарно исходный код. Так же рассмотрена и продемонстрирована методика взаимодействия приложения с СУБД MS SQL Server 2005. Проведено тестирование программного кода с использованием стандартных средств предоставляемых Microsoft Visual Studio 2008.

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

В четвертом разделе дипломного проекта определялась цель и область действия программного продукта. Осуществлен выбор модели жизненного цикла процесса разработки по результатам, представленным в таблице 4.1 - «Определение оптимальной модели жизненного цикла в баллах». Составлена структура пооперационного перечня работ с использованием пакета управления проектами Microsoft Project 2007, на её основе построен график выполнения работ, приведена диаграмма Гантта.

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

Список сокращений

БД - база данных;

ЖЦ - жизненный цикл;

ИС - информационная система;

АИС - автоматизированная информационная система;

ЧГП - частно-государственное партнерство;

ПО - программное обеспечение;

ПП - программный продукт;

ПК - персональный компьютер;

СУБД - система управления базами данных;

COM - component object model;

OLAP - Online Analytical Processing, система обработки аналитической информации;

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

1. Microsoft Corporation Проектирование и реализация баз данных Microsoft SQL Server 2005. Учебный курс MCAD/MCSE, MCDBA/Пер. с англ. -- 2-е изд., испр. -- М.: Издательско-торговый дом Русская Редакция, 2006. - 512стр.

2. Visual Studio Documentation. MSDN Library -2005.

3. А. Горев, С. Макашарипов, Р. Ахаян. Эффективная работа с СУБД - 2004

4. Аглицкий Д.С. Российский рынок информационных технологий: проблемы и решения Д.С. Аглицкий, И.С. Аглицкий - М.: 2000. - 208с.

5. Алехина Г.В. Информационные технологии в экономике и управлении. Г.В. Алехина.- М.:МЭСИ, 2002. - 635 с.

6. Армстронг Т. ActiveX: создание Web-приложений. Пер. с англ. - К.: BHV. 1998. - 592 с.

7. Атре Ш. Структурный подход к организации баз данных Ш. Атре.: Пер. с англ. А.А. Александрова и В.Ш. Будзко; под ред В.И. Будзко. - М.: Финансы и статистика. 1983. - 468 с.

8. Баронов В.В. Автоматизация управления предприятием В.В. Баронов - М.: ИНФРА-М, 2000.- 239с.

9. Боггс У. Боггс М. UML и Rational Rose. 2002. Боггс У., Боггс М. - М.: ЛОРИ. - 2002. - 582 с.

10. Богдатских В.А. Экономика, разработка и использование программного обеспечения ЭВМ: Учебник. В.А. Богдатских. - М.: Финансы и статистика, 1995. - 288 с.

11. Буч Г. Объектно-ориентированный анализ и проектирование. Буч Г.: Пер. с англ. - М: «Издательство Бином», 1999.

12. Буч Г. Рамбо Д., Джекобсон А. UML - руководство пользователя. Буч Г., Рамбо Д., Джекобсон А.: Пер с англ. - М: «ДМК», 2001

13. Ван Тассел Д. Стиль, разработка, эффективность, отладка и испытание программ. - М.: Мир. - 1981

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

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

16. Вигерс К. Разработка требований к программному обеспечению.: Пер. с англ К. Вигерс.:- М.: Издательско-торговый дом «Русская редакция», 2004.

17. Грофф Дж. Р. Энциклопедия SQL. Дж. Р. Грофф, П. Н. Вайнберг.: Пер. с англ. - СПб: «Питер», 2003. - 896 с.

18. Дейт К. Дж. Введение в системы баз данных. К. Дж. Дейт.: Пер. с англ. - М.: Изд. Дом «Вильямс», 2002. - 1072с.

19. Джесс Либерти. Microsoft Visual C# Создание Net приложений: Пер. с англ. - К.: ВЕК+, М.: ЭНТРОП, 2002. - 704 с.

20. Диго С.М. Проектирование и использование баз данных. С.М. Диго. - М.: Финансы и статистика. 1995. - 216с.

21. Избачков Ю.С. Информационные системы. Учебник для вузов Ю.С. Избачков В.Н. Петров. 2-е изд. - СПб.: Питер, 2005. - 739 с.

22. Когаловский М.Р. Энциклопедия технологий баз данных М.Р. Когаловский. - М.: Финансы и статистика, 2002. - 800с.

23. Коллинз Г. Структурные методы разработки систем: от стратегического планирования до тестирования. Коллинз Г., Блей Дж. Пер. с англ. - М.: Финансы и статистика, 1986. 264 с.

24. Конноли Т. Бегг К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика. Конноли Т., Бегг К.: Пер. с англ. - М.: Изд. Дом «Вильямс», 2001. - 1120 с.

25. Корнеев И.К. Информационные технологии в управлении И.К Корнеев, В.А. Машурцев. - М.:ИНФРА - М, 2001. - 651 с.

26. Лабор В. В. Си Шарп: Создание приложений для Windows В. В. Лабор.-- Мн.: Харвест, 2003. -384 с.

27. Маклаков С.В. BPwin и ERwin. CASE - средства разработки информационных систем. Учебник С.В. Маклаков. - М.: ДИАЛОГ-МИФИ, 2000.

28. Мацяшек Л. А. Анализ требований и проектирование систем. Разработка информационных систем с использованием UML. Л. А. Мацяшек. Пер. с англ. - М.: Издательский дом «Вильямс». - 2002.

29. Сеппа Д. Microsoft ADO.NET/Пер. с англ. -- М.: Издательско-торговый домРусская Редакция, 2003- -- 640 стр.

30. Справочник по Microsoft OLE DB 1.1. Пер. с англ. - М.: Издательский отдел «Русская редакция» ТОО «Channel Trading Ltd». 1997. - 624 с.

31. Страуструп Б. Язык программирования С#, 3-е изд. Пер. с англ. - М.: «Издательство Бином», СПб: «Невский диалект», 1999. - 991 с.

32. Трельсен Э. Модель COM и применение ATL 3.0. Пер. с англ. - СПб: BHV. 2000. - 926 с.

33. Троелсен Э. С# и платформа.NET. Библиотека программиста. -- СПб.: Питер, 2004. --796 с.:

34. Фатрелл Т. Управление программными проектами: достижение оптимального качества при минимуме затрат.: Пер. с англ. Р.Т. Фатрелл, Д.Ф. Шафер, Л.И. Шафер. - М.: Издательский дом "Вильямс", 2003.

35. Хубаев Г.Н. Экономика проектирования и применения банков данных Г.Н. Хубаев. - Ростов-на-Дону: Изд-во РИСХМ, 1989. - 69 с

36. Хубаев Г.Н. Экономическая оценка потребительского качества программных средств: Текст лекций Г.Н. Хубаев. - РГЭА.: Ростов-на-Дону, 1997. - 94 с.

Приложение А - Спецификация требований к программному обеспечению

Введение

Назначение

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

Область действия

Областью применения данного программного продукта являются руководящий аппарат частно-государственного партнерства «Форсайт центр».

ОБЩЕЕ ОПИСАНИЕ

Описание продукта

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

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

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

вывод результата голосования;

хранение решений по заседаниям в базе данных;

вывод отчета по решениям заседаний.

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

Классы и характеристики пользователей

В таблице приведены основные категории пользователей:

Таблица А.1 ? Основные категории пользователей

Класс пользователей

Описание

Секретарь

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

Члены руководящего аппарата

Принимают непосредственное участие в заседании, так же голосуют.

Общие ограничения

Операционная среда-1. Минимальные требования к операционной системе - Windows XP/Vista/7, наличие платформы.NET Framework.

Ограничения дизайна и реализации-1. База данных должна быть спроектирована на SQL Server 2005.

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

Документация для пользователей

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

Специфические требования

Требования к внешнему интерфейсу

Интерфейсы пользователя

Интерфейсы пользователя-1. Экраны вывода должны соответствовать общепринятым стандартам.

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

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

Таблица А.2 - Требования к системе

Требование

Описание

Архитектура

Сервер данных (MS SQL Server 2005)

Среда разработки

Visual Studio 7.5

Язык программирования

С#, SQL - запросы, хранимые процедуры

Операционная система

Windows XP/Vista/7

Хранилище данных

MS SQL Server 2005

Основными системными требованиями к системе являются:

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

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

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

система должна иметь возможность наращивания в программной части.

Требования к производительности

Требования к производительности не определены.

Требования к охране труда

Требования к охране труда не определены.

Требования к безопасности

Требования к безопасности не определены.

Приложение Б. - прототипы пользовательского интерфейса

Рисунок Б.1 - Внешний вид окна авторизации

Рисунок Б.2 - Внешний вид главной формы

Рисунок Б.3 - Внешний вид окон формирования плана заседания

Приложение В. ? АТРИБУТЫ УПРАВЛЯЮЩИХ ТАБЛИЦ ПРОЕКТИРУЕМОЙ ИС

Таблица В.1 ? Спецификация таблиц базы данных

Имя поля

Тип

Значение

Атрибуты таблицы «Users» ? Пользователи

id_User

bigint

Уникальный номер пользователя

User

varchar(50)

Ф.И.О. пользователя

id_Autorise

bigint

Уникальный номер данных авторизации пользователя

Таблица В.2 ? Спецификация таблиц базы данных

Имя поля

Тип

Значение

Атрибуты таблицы «Note» ? Замечания

id_Note

bigint

Уникальный номер замечания

Note

text

Замечание

id_Agenda

bigint

Уникальный номер повестки дня

Таблица В.3 ? Спецификация таблиц базы данных

Имя поля

Тип

Значение

Атрибуты таблицы «Autorise» ? Авторизация

id_Autorise

bigint

Уникальный номер данных авторизации пользователя

login

varchar(15)

Логин пользователя

pwd

varchar(15)

Пароль пользователя

Таблица В.4 ? Спецификация таблиц базы данных

Имя поля

Тип

Значение

Атрибуты таблицы «Agenda» ? Повестка дня

id_Agenda

bigint

Уникальный номер повестки дня

Agenda

varchar(MAX)

Повестка дня

Data

date

Дата

Chairman

varchar(50)

Председатель

Place

varchar(MAX)

Место проведения заседания

Таблица В.5 ? Спецификация таблиц базы данных

Имя поля

Тип

Значение

Атрибуты таблицы «Items» ? Пункты повестки дня

id_Item

bigint

Уникальный номер пункта

id_Doc

bigint

Уникальный номер документа

id_Agenda

bigint

Уникальный номер повестки дня

Item

varchar(MAX)

Пункт

Speaker

varchar(50)

Докладчик

Таблица В.6 ? Спецификация таблиц базы данных

Имя поля

Тип

Значение

Атрибуты таблицы «Documents» ? Документы

id_Doc

bigint

Уникальный номер документа

DocName

varchar(MAX)

Название документа

StoragePlace

varchar(MAX)

Путь к файлу

Таблица В.7 ? Спецификация таблиц базы данных

Имя поля

Тип

Значение

Атрибуты таблицы «Solution» ? Решение

id_Solution

bigint

Уникальный номер решения

Solution

text

Решение

id_Agenda

bigint

Уникальный номер повестки дня

Таблица В.8 ? Спецификация таблиц базы данных

Имя поля

Тип

Значение

Атрибуты таблицы «Vote» ? Голосование

id_Vote

bigint

Уникальный номер голосования

yes

int

да

no

int

нет

Refrain

int

Воздержаться

id_Item

bigint

Уникальный номер пункта

Приложение Г. -- ВЫБОР МОДЕЛИ ЖИЗНЕННОГО ЦИКЛА

Таблица Г.1 - Выбор модели ЖЦ на основе характеристик требований

Требования

Каскадная

V-образная

Прототипирование

Спиральная

RAD

Инкрементная

Являются ли требования легко определимыми и/или хорошо известными

Да

Да

Нет

Нет

Да

Нет

Могут ли требования заранее определятся в цикле

Да

Да

Нет

Нет

Да

Да

Часто ли изменяются требования в цикле

Нет

Нет

Да

Да

Нет

Нет

Нужно ли демонстрировать требования с целью определения

Нет

Нет

Да

Да

Да

Нет

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

Нет

Нет

Да

Да

Да

Нет

Будут ли требования отражать сложность системы

Нет

Нет

Да

Да

Нет

Да

Обладает ли требование функциональными свойствами на раннем этапе

Нет

Нет

Да

Да

Да

Да

Таблица Г.2 - Выбор модели ЖЦ на основе характеристик команды разработчиков

Команда разработчиков проекта

Каскадная

V-образная

Прототипирование

Спиральная

RAD

Инкрементная

Являются ли проблемы предметной области проекта новыми для большинства разработчиков

Нет

Нет

Да

Да

Нет

Нет

Является ли технология предметной области проекта новой для большинства разработчиков

Да

Да

Нет

Да

Да

Да

Являются ли инструменты, используемые проектом, новыми для большинства разработчиков

Да

Да

Нет

Да

Нет

Нет

Изменяются ли роли участников проекта во время ЖЦ

Нет

Нет

Да

Да

Нет

Да

Могут ли разработчики проекта пройти обучение

Нет

Да

Нет

Нет

Да

Да

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

Да

Да

Нет

Нет

Да

Да

Будет ли менеджер проекта строго отслеживать прогресс проекта

Да

Да

Нет

Да

Да

Да

Важна легкость распределения ресурсов

Да

Да

Нет

Нет

Да

Да

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

Да

Да

Да

Да

Да

Да

Таблица Г.3 - Выбор модели ЖЦ на основе характеристик типа проектов и рисков


Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.