Разработка автоматизированной информационной системы учета заявок на ремонт подвижного состава на примере предприятия РМ ПАТП-6
Содержание
Содержание
Введение
Актуальность и место решаемой задачи информационного
обеспечения в предметной области
Цели и задачи курсовой работы
. Разработка требований к программному обеспечению
.1 Анализ существующих решений по автоматизации
предметной области
.2 Анализ предметной области
.3 Выбор методологии проектирования информационной системы
.4 Сбор требований
.5 Анализ и моделирование требований
.6 Спецификация требований
.7 Аттестация требований
Выводы
. Проектирование информационной системы
.1 Архитектурное проектирование
.2 Проектирование пользовательского интерфейса
.3 Проектирование баз данных
.3.1 Концептуальное проектирование БД
.3.2 Разработка логической модели данных
.3.3 Разработка физической модели данных
.4 Обоснование выбора платформы создания информационной
системы
.5 Проектирование модулей
Выводы по главе
. Реализация и аттестация информационной системы
.1 Реализация приложения
.2 Взаимодействие приложения с источниками данных
(технология доступа к данным, sql-запросы, хранимые процедуры)
.3 Тестирование приложения
.4 Методика развертывания приложения
Выводы по главе
. Управление информационным проектом
.1 Выбор жизненного цикла разработки ПО
.2 Определение цели и области действия программного
проекта
.3 Создание структуры пооперационного перечня работ
.4 Идентификация задач и действий
.5 Оценка размера и возможности повторного использования
ПО
.6 Оценка длительности и стоимости разработки ПО
.7 Распределение ресурсов проекта
.8 Оценка экономической эффективности проекта
Выводы по главе
Заключение
Список сокращений
СПИСОК ИСПОЛЬЗОВАННой литературы
Приложение A
Введение
Актуальность
и место решаемой задачи информационного обеспечения в предметной области
Ростовское Муниципальное пассажирское автотранспортное предприятие №6
является филиалом Муниципального унитарного предприятия «Ростовпассажиртранс» и
выполняет часть его производственных функций. Основным направлением
деятельности филиала являются перевозка пассажиров.
Исходными данными для решения задач текущего и перспективного планирования
работы городского пассажирского транспорта являются материалы комплексного
обследования подвижного состава всех видов транспорта, а также пассажирских
потоков.
Анализ материалов обследования в пределах сложившейся маршрутной схемы
позволяет обеспечить более полное представление о количестве исправного
транспорта на потоке. Обследование дает возможность произвести расчет
количества неисправностей на единицу транспорта за день, месяц, год, а также
узнать точное количество сходов и выходов единиц транспорта, на основании
данных полученных в результате обследования.
Кроме того, данные обследования содержат сведения, необходимые для
разработки комплексной транспортной схемы и могут быть использованы при решении
ряда планово - экономических и инженерных задач в области перспектив
транспортного и городского строительства.
Задачей обследования является:
- выявление типов, а соответственно причин сходов единицы
транспорта по участкам трассы как по одному маршруту, так и по всем маршрутам;
- подсчет количества сходов в будние, выходные дни, а также
расчет среднемесячного количества затрат на восстановление всех функций
транспорта;
- выявление данных о сотрудниках осуществляющих перевозки
пассажиров;
- подсчет количества по группировкам причин сходов за день,
месяц, год как по одной единице транспорта, так и по всем.
Обследование осуществляется следующим образом: на территории въезда в
автопарк находится механик, который регистрирует время вошедших и вышедших
единиц подвижного состава на каждый день, по каждому индивидуальному гаражному
номеру, занеся данные в специальные бланки, на которых указано плановое время
отправления и прибытия машины, гаражный номер, данные о водителе и т.д. В
случае если транспорт выезжает позже планового времени из автопарка или въезжает
в него также позднее времени по графику, формируется заявка на данную единицу
состава с указанием типа и причины неисправности, а также номером и датой
заявки. Собранные за день обследования материалы в дальнейшем обрабатываются
вычислительным центром предприятия.
Информация о количестве сошедших с маршрута автомашин, необходима для
передачи данных в соответствующие государственные органы с целью возмещения
затрат на ремонт.
Полученные данные о количестве сходов, времени поездки, количестве рейсов
заносятся в базу данных. Это дает возможность получить следующие данные:
- общее количество сходов за день, месяц, год по видам
транспорта и по каждому маршруту;
- основные эксплуатационные показатели работы маршрутов;
- наиболее часто встречаемые неисправности каждой единицы
транспорта по каждому гаражному номеру и в целом по транспортной сети и т.д.
Цели и задачи
курсовой работы
Целью данной курсовой работы является разработка информационной системы,
учета сходов подвижного состава городского автотранспорта на примере
предприятия РМПАТП-6.
Задачами курсовой работы являются, создание программного обеспечения
(ПО), которое автоматизировала процесс учета сходов городского автотранспорта
на примере предприятия РМПАТП-6. Для создания данной программы необходимо
выполнить следующие задачи:
- выполнение сбора, спецификации и аттестации требований;
- выполнение проектирования базы данных;
- выполнение проектирования программного продукта;
- разработать информационную систему (ИС);
- тестирование блока формирование отчета;
- выполнить развёртывание программного продукта (ПП);
- обучить пользователей работе с программным продуктом.
1. Разработка
требований к программному обеспечению
1.1 Анализ
существующих решений по автоматизации предметной области
Анализируя существующие решения по автоматизации предметной области в
организации, выявлен тот факт, что в организации не существует подобной системы
учета сходов подвижного состава, как и не существует в СУБД FoxPro, которую используют в РМПАТП-6 для
работы со справочниками, входными и выходными документами.
На данный момент не существует подобных систем для решения поставленных
задач по автоматизации.
В настоящее время информационная система предприятия, реализована в среде
FoxPro, функционирующей под оболочкой DOS, с помощью которой ведется обработка
данных. Учет сходов автотранспорта в данный момент на предприятии не
автоматизирован.
Основными недостатками данной системы (FoxPro) предприятия являются:
- отсутствие удобочитаемости и правильности оформления отчетов по сходам;
- расчеты производятся с использованием устаревшего
программного обеспечения (FoxPro);
- процесс работы с данной информационной системой является
трудоемким, что в свою очередь обеспечивает превышение трудозатрат.
Для устранения недостатков в информационной системе предприятия было
предложено разработать новую информационную систему. Новая система будет
основана на использовании базы данных MS Access, обращение к базе данных будет осуществляться с использованием
SQL - запросов, в дальнейшем предполагается переход на SQL-server c использованием
интерфейса MS Access. Использование новой информационной системы облегчит
процесс работы, создания отчетов. Интерфейс системы будет обновлен для работы
под семейства операционных систем Win32 (Windows XP и т. п.). Также, новая
информационная система должна обеспечить больший уровень защиты, т.к. данная
система не на должном уровне обеспечивает защищённость данных.
Одна из задач предприятия - это вести учет сходов подвижного состава.
Поэтому для решения этой проблемы необходимо автоматизировать процесс обработки
результатов обследования транспортного потока предприятия, что приведет к
сокращению времени на формирование необходимых документов и отчетов.
1.2 Анализ
предметной области
Анализ предметной области, является одним из важнейших этапов проекта,
определяющим организацию работ на РМПАТП-6, целью которого является выявление,
классификация и формализация информации обо всех аспектах предметной области,
влияющих на конечный результат.
Ростовское Муниципальное пассажирское автотранспортное предприятие №6 (РМ
ПАТП-6) является филиалом Муниципального унитарного предприятия «Муниципальная
Транспортная Компания «Ростовпассжиртранс» (МУП «МТК «Ростовпассажиртранс») и
выполняет часть его производственных функций.
Организационная структура компании изображена в соответствии с рисунком
1.
Рис.1 - Организационная структура предприятия РМ ПТАП№6
Основными направлениями деятельности филиала являются:
- оказание услуг по обеспечению бесперебойного движения
электрического и автомобильного транспорта, улучшение транспортного
обслуживания пассажиров;
- рациональное использование трудовых и материальных ресурсов;
- содержание и текущий ремонт подвижного состава, зданий,
сооружений, механизмов находящихся на балансе;
- организация всех видов деятельности, необходимых для
нормальной деятельности как МТК в целом, так и филиала в частности, не
запрещенных законодательством РФ и Уставом МТК;
- поддержание в технически исправном состоянии подвижного
состава, оборудования, согласно техническим правилам.
Работа служб нацелена на планирование, учет, контроль, анализ перевозок.
Важнейшим фактором формирования передвижений в городе является структура
единой транспортной сети. Эта структура определяется видами используемого в
городе транспорта и может быть охарактеризована составляющими ее транспортными
сетями. Различают в основном три вида городского транспорта: пассажирский,
грузовой и специальный. Пассажирский транспорт составляют муниципальный
транспорт, коммерческий и личный индивидуального пользования.
В состав предприятия входят следующие отделы:
· Общее руководство (директор, зам.директора по перевозкам,
главный инженер);
· Производственно-техническая служба (ПТС);
· Отдел технического контроля (ОТК);
· Производственно-технический отдел (ПТО);
· Отдел главного механика;
· Материально-техническое снабжение (МТС);
· Отдел бухгалтерского учета и отчетности (ОБУ и О);
· Планово-экономический отдел (ПЭО);
· Служба эксплуатации (ОЭ);
· Безопасность движения (БД);
· Отдел информатики и вычислительной техники
· Отдел охраны труда;
· ГО и МОБ работа;
· Отдел кадров;
· Общее делопроизводство;
Анализируя существующие решения по автоматизации предметной области в
организации, выявлен тот факт, что на данный момент в организации не существует
подобной системы учета сходов подвижного состава, как и не существует в
системной оболочке FoxPro, которую
используют для работы со справочниками, входными и выходными документами в
РМПАТП-6.
Содержание и форма представления результатов формирования требований к
АИС определяются потребностями последующих этапов жизненного цикла ее создания,
которые, в свою очередь, зависят от внешних условий проекта, а также от
предполагаемых к применению методологий, технологий и инструментов. Однако различия
в современных методах не касаются некоторых общих положений.
Должен быть разработан комплекс моделей предметной области, подлежащей
автоматизации (т. е. моделей «как надо»). Этот комплекс моделей представляет
собой совокупность диаграмм, выполненных в какой-либо нотации;
структурированных спецификаций, описывающих элементы модели (например, процессы
и структуры данных при использовании методов структурного подхода), а также
перечень нормативных и операционных документов предметной области, являющихся
первоисточником информации, представленной в диаграммах и спецификациях.
Степень подробности результатов должна быть достаточной для выполнения
следующего этапа работ (как правило, общесистемное проектирование) в
соответствии с выбранным подходом. Кроме того, степень подробности моделей
должна быть достаточной для планирования всего проекта.
Классическая схема анализа изображена на рисунке 1.1.
Рисунок 1.1 - Классическая схема анализа предметной области
Функциональной модель «как есть» позволяет собрать и представить в
формализованном виде информацию о существующем состоянии предметной области,
после чего должно последовать переосмысление состава и технологии
бизнес-процессов с учетом разработки комплексной АИС, что приводит к построению
модели «как надо». Когда функциональная модель «как надо» построена и все
структуры данных собраны, производится построение концептуальной модели данных.
Наиболее удобным языком моделирования бизнес-процессов является IDEF0. В IDEF0 система представляется как совокупность
взаимодействующих работ или функций. Такая чисто функциональная ориентация
является принципиальной, функции системы анализируются независимо от объектов,
которыми они оперируют. Это позволяет более четко смоделировать логику и
взаимодействие процессов организации.
В IDEF0 система представляется как
совокупность взаимодействующих работ или функций. Такая функциональная
ориентация является принципиальной т.к. функции системы анализируются
независимо от объектов, которыми они оперируют. Это позволяет более четко
смоделировать логику и взаимодействие процессов организации.
Основу методологии IDEF0
составляет графический язык описания бизнес процессов. Модель IDEF0 представляет собой совокупность
иерархически упорядоченных и взаимосвязанных диаграмм. Каждая диаграмма
является единицей описания системы и располагается на отдельном листе.
Целью построения функциональных моделей обычно является выявление
наиболее слабых и уязвимых мест деятельности организации, анализ преимуществ
новых бизнес-процессов и степени изменения существующей структуры организации
деятельности. Анализ недостатков начинают с построения модели AS-IS (как есть), т.е. модели существующей организации работы.
Модель AS-IS может строиться на основе изучения документации (положений о
предприятии, должностных инструкций, приказов, отчетов и т.п.), анкетирования и
опроса или других источников. Полученная модель AS-IS служит для
выявления неуправляемых работ, работ необеспеченных ресурсами, ненужных и
неэффективных работ, дублирующихся работ и других недостатков в организации
деятельности организации.
Процессы, протекающие в организации можно представить в виде диаграмм IDEF0 (рисунок 1.2).
Рисунок 1.2 - Процесс деятельности организации
Управлением транспорта Ростова-на-Дону и рядом других городских
организаций постоянно решаются вопросы обслуживания населения города.
Весь круг вопросов рассматривается в рамках пяти основных последовательно
решаемых задач:
- организация транспортной системы;
- планирование пассажирских перевозок и работы подвижного
состава;
- управление движением пассажирского транспорта;
- расчет производственной программы технического обслуживания
парка машин;
- учет работы подвижного и водительского состава.
Организация транспортной системы
Состоит в составлении рациональных маршрутных схем обслуживания
населения.
Планирование пассажирских перевозок и работы подвижного состава
Единым документом, планом, отражающим, с одной стороны потребности в
пассажирских перевозках и с другой стороны эксплуатационные возможности
РМПАТП-6, являются маршрутные расписания движения.
Управление движением пассажирского транспорта
Работа маршрутизированных видов пассажирского транспорта на улицах города
подчиняется правилам дорожного движения, контролируется и управляется
сотрудниками автоинспекции, находящимися в контакте с диспетчерской службой,
службой безопасности движения РМПАТП. Отсюда задачи диспетчерской службы:
- организация выпуска машин из парка на маршрут и приемки их с
линии;
- постоянная регистрация количества и качества выполнения
рейсов каждой подвижной единицей, работающей на линии;
- оперативная организация работы аварийных средств - линейная
техпомощь подвижному составу;
- оперативная организация изменения режима движения в случае
неблагоприятных погодных условий, обслуживание спортивных и культурно массовых
мероприятий.
Расчет производственной программы технического обслуживания парка машин
Для расчета производственной программы технического обслуживания
исходными данными служат:
- производственная программа эксплуатации парка автомобилей;
- принимаемая прогрессивная система и методы технического
обслуживания и ремонта подвижного состава;
- установление нормы пробега подвижного состава до проведения
отдельных видов технического обслуживания, ремонтов, а так же нормативы
трудоемкости работ, применительно к условиям эксплуатации.
Учет работы подвижного и водительского состава
Для решения задач учета применяются персональные компьютеры. На них
составляются диспетчерские наряды, учет внутрисменных, целодневных простоев,
учет работы водителя на линии, участие в ремонте.
1.3 Выбор
методологии проектирования информационной системы
Структурированное программирование было основной концепцией с первых дней
разработки программного обеспечения. Стандартные блоки кода создавались для
типичных операций, а затем копировались в другие приложения. Это сокращало
сроки разработки новых программ, но затрудняло внесение изменений, поскольку
необходимо было редактировать все вставленные стандартные блоки /18/. На основе
структурированного программирования сформировалась концепция
объектно-ориентированного программирования.
С помощью объектно-ориентированного подхода создаются блоки кода, или
объекты. Объекты могут использоваться в разных приложениях. Для изменения
объекта достаточно выполнить редактирование.
По сути, все современные приложения являются объектно-ориентированными, а
некоторые языки программирования предполагают использование
объектно-ориентированных структур. Объектно-ориентированный подход представляет
собой другой метод просмотра приложений. Все приложения делятся на небольшие
элементы кода - объекты, относительно независимые друг от друга.
В структурированном программировании требуется больше усилий для создания
законченных приложений.
При объектно-ориентированном подходе особое внимание уделяется как
информации, так и поведению, что позволяет создавать гибкие системы,
допускающие изменение их поведения или содержащейся в них информации.
В соответствии с традиционным подходом основное внимание должно уделяться
информации, с которой работает система. В зависимости от того, какая информация
нужна пользователям, проектируются базы данных для хранения этой информации,
создаются экраны для ее вывода и встраивается возможность распечатки отчетов.
Иначе говоря, прежде всего, необходимо сфокусировать внимание на самой
информации, а к поведению системы можно обратиться позже. Такой подход
называется ориентированным на данные.
Структурный подход известен под самыми разными
названиями, среди них такие, как «разделяй и властвуй», иерархическая
декомпозиция и другие, по отношению к проектированию сложной программной
системы это означает, что ее необходимо разделять (декомпозировать) на
небольшие подсистемы, каждую из которых можно разрабатывать независимо от
других. Это позволяет при разработке подсистемы любого уровня держать в уме
информацию только о ней, а не обо всех остальных частях системы. Правильная
декомпозиция является главным способом преодоления сложности разработки больших
систем. Понятие «правильная» по отношению к декомпозиции означает следующее:
- количество связей между отдельными
подсистемами должно быть минимальным;
- связность отдельных частей внутри
каждой подсистемы должна быть максимальной.
Структура системы должна быть таковой, чтобы все
взаимодействия между ее подсистемами укладывались в ограниченные, стандартные
рамки:
- каждая подсистема должна
инкапсулировать свое содержимое (скрывать его от других подсистем);
- каждая подсистема должна иметь четко
определенный интерфейс с другими подсистемами.
Итак, сущность структурного подхода к разработке ПО
заключается в ее декомпозиции (разбиении) на автоматизируемые функции: система
разбивается на функциональные подсистемы, которые, в свою очередь, делятся на
подфункции, те - на задачи и так далее до конкретных процедур. При этом система
сохраняет целостное представление, в котором все составляющие компоненты
взаимоувязаны. При разработке системы «снизу-вверх», от отдельных задач ко всей
системе, целостность теряется, возникают проблемы при описании информационного
взаимодействия отдельных компонентов.
Все наиболее распространенные методы структурного
подхода базируются на ряде общих принципов:
- принцип «разделяй и властвуй»;
- принцип иерархического упорядочения -
принцип организации составных частей системы в иерархические древовидные
структуры с добавлением новых деталей на каждом уровне.
В структурном подходе в основном две группы средств,
описывающих функциональную структуру системы и отношения между данными. Каждой
группе средств соответствуют определенные виды моделей (диаграмм), наиболее
распространенными среди них являются:
DFD (Data Flow Diagrams) - диаграммы потоков данных;
SADT (Structured Analysis
and Design Technique - метод структурного анализа и
проектирования) - модели и соответствующие функциональные диаграммы;
ERD (Entity - Relationship Diagrams)
- диаграммы «сущность-связь».
На стадии проектирования DFD используются для описания структуры проектируемой
системы/16/.
Перечисленные модели в совокупности дают полное
описание ПО независимо от того, является ли система существующей или вновь
разрабатываемой.
Для проектирования разрабатываемой системы был выбран структурный подход.
1.4
Сбор требований
Перед началом разработки ИС необходимо определить состав документов. На
этапе сбора требований подготавливается подборка существующих в организации
документов (входных, выходных) на основании которых разрабатывается ИС, для
этого были выполнены следующие шаги /1, 18, 33/:
- собраны образцы бланков существующих в организации
нормативно-справочных документов (НСИ);
- собраны образцы бланков существующих в организации входных
документов;
- собраны образцы бланков существующих в организации выходных
документов;
- собраны образцы заполнения существующих в организации (НСИ);
- собраны образцы заполнения существующих в организации входных
документов;
- собраны образцы заполнения существующих в организации
выходных документов.
Заполненные образцы бланков нормативно-справочных документов (НСИ) и
выходные документы (приложение Д, рисунки Д.1-Д.13).
Самое главное в любой рабочей деятельности - это «Сбор требований» т.к.
если разработчик будет знать то, что от него хотят чтобы он сделал, то и
конечный результат будет удовлетворять обеих сторон. Максимально упрощенный и
удобный процесс работы, сопровожденный минимизацией временных трудозатрат и
наличие продуктивного результата, повысит работоспособность и результативность.
1.5
Анализ и моделирование требований
Этап анализа и моделирования требований начинается с метода анализа оптимальной
организации работ - стандарт IDEF0
- (TO BE). Диаграмма IDEF0
- (TO BE) строится на основе диаграммы IDEF0 - (AS IS) /3, 4, 10/ . Контекстная диаграмма IDEF0 - (TO BE) представлена на рисунке 1.4.
Рисунок 1.4 - Контекстная диаграмма IDEF0 процесса деятельности Организации
Детализация процессов (TO-BE) представлена в приложении А, на
рисунках А.1-А.9.
На рисунке 1.5 представлена диаграмма первого уровня декомпозиции
процесса деятельности организации (IDEF0). Она используется для детализации бизнес-процессов деятельности
организации /21, 24/.
Рисунок 1.5- Диаграмма первого уровня декомпозиции процесса деятельности
организации (IDEF0)
До начала разработки информационной системы необходимо определить состав
документов. Для этого был проведен анализ, стандартизация, унификация подборки
существующих в организации документов. Все документы были увязаны в единую
унифицированную систему документов.
1.6 Спецификация
требований
Требования к системе разбиваются на две самостоятельные группы -
требования к функциям и нефункциональные требования. Основой выявления
требований первой группы является модель бизнес-процессов предприятия, на базе
которой, собственно, и формируется иерархия требований. К числу
нефункциональных требований относятся:
- правовые и законодательные требования;
- качественные характеристики создаваемой системы, включая
требования к ее практичности, надежности, производительности и возможностям
поддержки;
- требования по безопасности;
- другие требования, например касающиеся операционных систем и
сред, совместимости и проектных ограничений.
На основании выявленных требований разрабатывается техническое задание
(ТЗ) на создаваемую систему и, по необходимости, частные технические задания на
ее компоненты (подсистемы). ТЗ создается на основе ГОСТ 34.602-89. ТЗ на
создание автоматизированной системы включает следующие основные разделы:
- общие сведения;
- назначение и цели создания ИС;
- характеристика объекта автоматизации;
- требования к системе;
- состав и содержание работ по созданию системы;
- порядок контроля и приемки системы;
- требования к составу и содержанию работ по подготовке
предприятия к вводу системы в действие.
Раздел «Общие сведения» содержит справочную информацию, в том числе
полное наименование системы, ее условное обозначение, название предприятий
разработчика и заказчика (пользователя) системы и их реквизиты, перечень
документов, на основании которых создается система, плановые сроки начала и окончания
работы по созданию системы, сведения об источниках и порядке финансирования
работ.
В разделе «Характеристика объекта автоматизации» проводятся общие
сведения о предприятии согласно его уставу, перечень основных видов
деятельности и бизнес-процессов.
В следующих разделах ТЗ приводятся сведения об объекте автоматизации,
требования к системе в целом, также к ее функциональной и обеспечивающей части.
При формировании требований к системе в целом указывается перечень и
основные характеристики подсистем, требования к взаимосвязям и совместимости
созданной системы со смежными системами, требования к режиму функционирования
АИС, к ее надежности и безопасности, описание стандартизации системы и ее
унификации.
1.7 Аттестация
требований
Аттестация требований - процесс проверки требований на достоверность,
непротиворечивость, полноту и выполнимость. Аттестация должна
продемонстрировать, что требования действительно определяют ту систему, которую
хочет иметь заказчик. Проверка требований важна, т. к. ошибка в спецификации
требований могут привести к переделке системы и большим затратам, если будут
обнаружены во время процесса разработки системы или после введения её в
эксплуатацию. Стоимость внесения в систему изменений, необходимых для
устранения ошибок в требованиях, намного выше, чем исправление ошибок
проектирования или кодирования. Причина в том, что изменение требований обычно
влечёт за собой значительные изменения в системе, после внесения, которых она
должна пройти повторное тестирование.
Во время процесса аттестации должны быть выполнены различные типы
проверок документации требований:
- проверка правильности требований;
Системы, предназначены для разных пользователей с различными
потребностями, и поэтому набор требований будет равными для всех пользователей
системы. Однако дальнейшие размышления и анализ могут привести к необходимости
введения дополнительных или новых функций.
- проверка на непротиворечивость;
Это означает, что в требованиях не должно быть противоречащих друг другу
ограничений и различных описаний одной и той же системной функции.
- проверка на полноту;
Должна содержать требования, которые определяют все системные функции и
ограничения, налагаемые на систему.
- проверка на выполнимость;
Существует ряд методов аттестации требований:
- обзор требований;
- прототипирование;
- генерация тестовых сценариев;
- автоматизированный анализ непротиворечивости.
Диаграмма потоков пользовательского интерфейса используется для изучения
взаимосвязей между основными элементами пользовательского интерфейса.
Прототипы позволяют решать три основные задачи: прояснение и завершение
процесса формулировки требований, исследование альтернативных решений и
создание конечного продукта.
Прототип показывает внешний вид экранов пользовательского интерфейса и
позволяет осуществлять частичную навигацию между ними. Он позволяет
пользователям исследовать поведение предполагаемой системы в тех или иных
ситуациях для уточнения требований, а также выяснить, смогут ли они с помощью
системы, основанной на прототипе, выполнять свою работу. Диаграмма потоков
пользовательского интерфейса показана на рисунке 1.6.
Рисунок 1.6 - Диаграмма потоков пользовательского интерфейса
Выводы
В данном разделе был проведен процесс анализа предметной области, собраны
необходимые требования к разрабатываемой системе, осуществлено
бизнес-моделирование процессов, выполнено специфицирование и аттестация
требований к программному продукту, что позволило приступить к следующей стадии
разработки, проектирование информационной системы.
2.
Проектирование информационной системы
.1
Архитектурное проектирование
Одним из важнейших этапов разработки является архитектурное
проектирование, которое заключается в сборе всех возможных пожеланий к работе
системы, которые только могут прийти в голову пользователям и аналитикам.
Позднее эти данные должны будут систематизированы и структурированы, но на
данном этапе в ходе интервью с пользователями и изучения документов, аналитик
должен собрать как можно больше требований к будущей системе, что не так
просто, как кажется на первый взгляд. Пользователи часто сами не представляют,
что они должны получить в конечном итоге.
На этапе тестирования ИС используется как локальное приложение.
На этапе эксплуатации ИС будет использоваться как многопользовательское
приложение, существует несколько способов перехода системы на
многопользовательский доступ.
Планируется в дальнейшем, переход работы приложений в организации на SQL, следовательно, можно перекинуть
хранилища данных Access на SQL, а интерфейсы пользователя
использовать в Access/12/.
Осуществить настройку Access
на многопользовательский доступ, MS Access имеет такую функцию.
Архитектурное проектирование предполагает выбор архитектуры, на которой
будет базироваться информационная система.
Для проектирования информационной системы применима клиент-серверная
технология. Данная технология обеспечивает большую скорость вычислений,
надёжность хранимых данных, легкость поддержки информационной системы.
Под клиент-серверным приложением мы будем понимать информационную
систему, основанную на использовании серверов баз данных. Общее представление
информационной системы в архитектуре «клиент-сервер» изображено на рисунке 2.1.
Со стороны клиента выполняется код приложения, в который обязательно входят
компоненты, поддерживающие интерфейс, выполняющий все вычисления, операции
ввода/выводы, редактирования и сохранения данных.
На сторону SQL - сервер
приходится только одна функция - это хранение введённых данных.
Рисунок 2.1 - Представление информационной системы в архитектуре
«клиент-серверная»
Под сервером обычно понимают процесс, который обеспечивает функции по
управлению базой данных и предоставляет необходимые ресурсы процессам-клиентам,
посылающим запросы на соответствующий вид обслуживания. Задачей клиента
является инициирование связи с сервером, определение вида запроса на
обслуживание, получение от сервера записей из базы данных, подтверждение
окончания обслуживания. Все вопросы, связанные с синхронизацией работы клиентов
и управлением выделением им необходимых ресурсов при работе с базой данных,
возлагаются на сервер.
Архитектура СУБД типа «клиент-сервер» дает возможность организовать
содержательную обработку данных в интересах конечных пользователей на рабочих
станциях.
Архитектура СУБД типа «клиент-сервер» инвариантна по отношению к
физическому способу организации связи между клиентом и сервером. Они могут
функционировать как в одном, так и в нескольких узлах вычислительной сети. Если
клиент и сервер располагаются в одном и том же компьютере узла сети, то это
снижает производительность сервера, так как часть вычислительных ресурсов
используется на обслуживание клиента. Если же клиент и сервер располагаются в
разных узлах сети, то это замедляет доступ к базе данных, так как клиент и
сервер связаны средой с более низкой пропускной способностью, чем оперативная
память ПК. Однако этот недостаток обычно компенсируется за счет использования
дополнительной вычислительной мощности, предоставляемой оборудованием рабочих
станций.
Для повышения производительности сервер базы данных посылает клиенту
только данные, которые релевантные выданному запросу, что уменьшает объем
передаваемой по сети информации.
2.2
Проектирование пользовательского интерфейса
При проектировании прототипов пользовательского интерфейса была
использована СУБД Access.
СУБД - это специальный комплекс программ и языков, по средствам которого
организуется централизованное управление базами данных и обеспечивается доступ
к ним.
В состав любой СУБД входят языки двух типов:
- язык описания данных (с его помощью описываются типы данных, их структура
и связи);
- язык манипулирования данными (язык запросов к БД),
предназначенный для организации работы с данными в интересах всех типов
пользователей.
Интерфейс - это общение между компьютером и человеком. На практическом
уровне, интерфейс - это набор стандартных приемов взаимодействия с техникой.
При работе с компьютером у пользователя формируется система ожидания
одинаковых реакций на одинаковые действия, что постоянно подкрепляет
пользовательскую модель интерфейса.
Другой составляющей интерфейса является свойство его конкретности и
наглядности. Это осуществляется применением плана панели, использованием цветов
и другой выразительной техники, с которым непосредственно общается
пользователь.
Приложение состоит из не визуальных и визуальных компонентов работы с БД,
компонентов для выдачи отчетов, а также модулей данных. Визуальные компоненты
служат для представления данных из не визуальных компонентов, т.е. служат целям
обеспечения интерфейса пользователя при работе с данными.
Модули данных служат для централизованного хранения отдельных экземпляров
не визуальных компонентов с целью придания тем или иным наборам данных единообразного
поведения приложения.
Прототип пользовательского интерфейса верхнего уровня можно посмотреть
ниже на рисунке 2.2.
Рисунок 2.2 - прототип пользовательского интерфейса верхнего уровня
Прототип пользовательского интерфейса нижнего уровня можно посмотреть
ниже на рисунке 2.3.
Рисунок 2.3 - прототип пользовательского интерфейса нижнего уровня
.3
Проектирование баз данных
.3.1
Концептуальное проектирование БД
Концептуальная схема базы данных и концептуальные
спецификации взаимодействующих с ней процессов представляют собой формальную
высокоуровневую спецификацию статических и динамических свойств БД. Данная
спецификация СУБД является независимой т.к. не использует моделей и языковых
средств никакой конкретной СУБД. Она формализует требования к БД на
семантическом уровне и служит в качестве исходных данных логического
проектирования, которое ведется с учетом особенностей конкретной СУБД.
Средством формализации структурных и поведенческих
свойств БД на семантическом уровне служит концептуальная модель данных. В
состав ее структурных понятий входят объекты и агрегаты, их свойства и
специализации на классы, а также классификационные решетки, с помощью которых
выделяются пересечения классов разных специализаций.
Для этапа концептуального проектирования БД
реализована в виде автоматизированного получения начальных концептуальных
спецификаций проекта БД: начальной схемы и начальных спецификаций процессов.
Концептуальная схема БД должна интегрировать структурные потребности всех
информационных задач проектируемой системы. Начальный вариант схемы определяет
состав основных объектов предметной области, выступающих в роли глобальных
поставщиков информации для информационных задач. Детальные потребности этих
задач в элементах данных рассредоточены в макетных спецификациях и могут
оказаться не учтенными в структуре объектов предметной области.
Концептуальная модель данных представлена на рисунке 2.4.
Рисунок 2.4 - Концептуальная модель.
программный обеспечение пользовательский модуль
2.3.2
Разработка логической модели данных
Логическая модель данных строилась на основе концептуальной модели
данных, отражающей представление отдельного пользователя о предметной области
приложения, и проверка полученной модели с помощью методов нормализации и
контроля выполнения транзакций /19/.
Логическая модель описывает понятия предметной области, их взаимосвязь, а
также ограничения на данные, налагаемые предметной областью. Данные
представляются так, как выглядят в реальном мире, и могут называться так, как
они называются в реальном мире. Эта модель данных является начальным этапом
будущей базы данных. Логическая модель данных является визуальным
представлением структур данных, их атрибутов и бизнес-правил.
Логическая модель строится в терминах информационных единиц, но без
привязки к конкретной СУБД. Более того, она необязательно должна быть выражена
средствами именно реляционной модели данных. На рисунке представлена логическая
модель (рисунок 2.5).
Рисунок 2.5 - Логическая модель
После создания полной и адекватной логической модели
можно переходить к созданию физической модели базы данных.
2.3.3
Разработка физической модели данных
Цель физического проектирования - создание базовой функциональной схемы
реляционной базы данных на основе логической модели данных.
Физическая модель данных зависит от конкретной СУБД, фактически является
отображением системного каталога. В физическом уровне модели содержится
информация обо всех объектах базы данных. Отношения, разработанные на стадии
формирования логической модели данных, преобразуются в таблицы, атрибуты
становятся столбцами таблиц, для ключевых атрибутов создаются уникальные
индексы, домены преображаются в типы данных, принятые в конкретной СУБД. На
рисунке (рисунок 2.6) ниже отображена физическая модель данных ИС.
Рисунок 2.6 - Физическая модель
На рисунке 2.7 ниже отображена схема данных БД.
Рисунок 2.7 - Схема данных
.4
Обоснование выбора платформы создания информационной системы
В качестве операционной среды при реализации АИС будет использоваться
операционная оболочка Microsoft Windows
XP, так как это наиболее
распространенная и приспособленная для пользователя среда, с дружественным
пользовательским интерфейсом. Операционная среда Microsoft Windows XP является многозадачной, высокопроизводительной. Это
интегрированная среда, которая обеспечивает эффективный обмен текстовой,
графической и видеоинформацией между отдельными программами.
В качестве системы разработки будет использоваться среда MS Access 2003, SQL-server. Выбор данной среды обусловлен
следующими причинами:
1. Данная среда является ведущей средой быстрой разработки
приложений на рынке благодаря следующим особенностям:
- визуальная среда разработки;
- полное использование возможностей среды WINDOWS.
2. Наибольший опыт разработчика работы именно в этой среде.
. Пожелание заказчика (в перспективе возможна доработка этого приложения
силами других разработчиков).
Минимальными требования, предъявляемые MS Access 2003 к ПК - это Intel-совместимая платформа ПК, процессор от Intel Pentium 3 и выше, ОЗУ 256 MB, OS MS XP.
Исполняемый файл БД «АТП.mdb»
во время работы может менять свой размер даже в том случае, если данные не
изменялись. Это обусловлено внутренней организацией и логикой работы MS Access. Увеличение размера файла может быть вызвано тем, что
СУБД может создавать временные объекты (таблицы, запросы) внутри собственно БД
и исполняемых модулей, а также кэшировать результаты запросов к данным.
.5
Проектирование модулей
В данном пункте описывается программные модули системы. Информационная
система обработки данных о сходах, имеет в своем наличии следующие модули.
Модули состоят из кода, который реализует функционирование приложения,
обработчики событий для форм и их компонент.
Программные модули системы:
- модуль «ввода данных»;
- модуль «редактирования ввода данных»;
- модуль «справочники»;
- модуль «редактирования справочников»;
- модуль «пароль»;
- модуль «администрирование»;
- модуль «просмотра отчетов»
- CloseForm.
Модуль «CloseForm» позволяет при закрытии формы главного меню закрывать
его в оригинальном виде.
Выводы по
главе
И в конце поводя итоги по главе проектирования информационной системы,
хочу добавить, что процесс проектирования системы является одним из наиболее
важных этапов разработки программного обеспечения, т.к. небольшая доля
формального планирования может значительно повысить эффективность
разрабатываемого ПО. Кроме того, когда система четко разбита и спроектирована,
далее будет легче поддерживать разработанный продукт, и развивать его.
Также было выполнено проектирование базы данных информационной системы, а
именно построены концептуальная, логическая и физическая модели, был произведен
анализ и выбор системы управления базами данных. Также обоснован выбор
платформы проектируемой информационной системы.
3. Реализация и аттестация информационной системы
.1 Реализация
приложения
На основе данных проектирования информационной системы была выполнена
реализация приложения.
Формы представляют собой интерфейсы или диалоговые окна, в которых
происходит работа с вводом, редактированием информации.
Для обеспечения защиты от несанкционированного доступа к информации,
связанной с учетом заявок на ремонт предусмотрена система паролей (рисунок 3.1)
при загрузке ИС, если пароль верный, то пользователь допускается к работе с
АИС.
Рисунок 3.1 - Окно входа в ИС
Ниже представлена форма разработанного приложения, отображающая кнопки,
поля, вводимые данные. При разработке пользовательского интерфейса, было
создано меню в виде кнопочной формы. Ниже изображен разработанный интерфейс
главной формы (рисунок 3.2), программный код VBA (приложение Б, рисунок Б.1). В главной форме
расположены основные кнопки для работы с ИС, которые представляют собой
переходы на формы справочников, ввода данных, отчетов, администрирования.
На следующем рисунке 3.3 изображена форма пользовательского интерфейса в
виде кнопочной формы, для работы со справочной информацией, в которую входят
справочники подвижного состава, сотрудников, марок автомашин, нарядов, список
причин сходов и опозданий.
Рисунок 3.2 - Главная форма
Рисунок 3.3 - Форма справочники
На следующем рисунке 3.4 изображена форма авторизации пользователя, для
входа под своими идентификационными данными.
Рисунок 3.4 - Форма авторизации
После авторизации, автоматически происходит переходит на форму ввода
данных в виде полей для заполнения данных и кнопок, для работы непосредственно
по нарядам подвижного состава, представленную на рисунке 3.4, (программный код VBA (приложении Б, рисунок Б.2).)
Наличие большого количества кнопок обусловлено, возможностью быстрого
оформления всех необходимых документов для своевременного предоставления
отчетности.
Рисунок 3.4 - Форма ввода данных
На следующем рисунке 3.5 представлена форма для просмотра отчетности по
сходам автомашин парка предприятия.
Рисунок 3.5 - форма просмотра отчетности по автомашинам
На рисунке 3.6 представлена форма для ввода, редактирования данных по
ремонту единицы подвижного состава по выбранному наряду («Листок учета»).
Рисунок 3.6 - форма «Листок учета»
На следующем рисунке 3.7 изображено форма пользовательского интерфейса в
виде кнопочной формы, для формирования отчетов для учета заявок, сводных таблиц
и т.д. в разрезе дат, программный код VBA (приложении Б, рисунок Б.6).
Рисунок 3.7 - форма создания отчетов
На следующем рисунке 3.8 изображено окно на вход формы защиты БД.
Рисунок 3.8 - форма защиты БД.
Формы нормативно-справочной информации изображены на рисунках Е.1-Е.5 в
приложении Е. Выходные документы изображены на рисунках Д.1-Д.13 в приложении
Д.
.2
Взаимодействие приложения с источниками данных (технология доступа к данным,
sql-запросы, хранимые процедуры)
Для того чтобы пользователь ИС мог использовать информацию хранящуюся в
базе данных СУБД Microsoft SQL Server 2003, необходимо выбрать и реализовать технологию
доступа к базе данных. Основной технологией доступа к данным, выступают sql-запросы (приложение Г, рисунки
Г.1-Г.15). На рисунке 3.9 показан sql-запрос, отображающий существующие на выбранную дату наряды автопарка на
форме.
Рисунок 3.9 - Пример sql-запроса
На следующем рисунке 3.10 отображен sql-запрос, осуществляющий выборку и группировку
сформированных листов учета по гаражному номеру.
Рисунок 3.10 - Пример sql-запроса
Хранимые данные записаны в таблицах среды разработки ИС.
Таблица «Механик ОТК» хранит информацию, которая включает в себя: ИД
гаражного номера, время выезда, заезда автомашины, ее гаражный номер, дату
выписки и закрытия ремонта, а также причины схода, все данные таблицы являются
реквизитами автомашин при обследовании, рисунок 3.11.
Рисунок 3.11 - Таблица «Механик ОТК»
Таблица «Лист учета» изображенная на рисунке 3.12 хранит информацию о
количестве начисленных технических обслуживаний по всем гаражным номерам.
Рисунок 3.12 - Таблица «Лист учета»
Остальные таблицы с данными ИС в приложении Г, рисунках Г.16-Г.21.
3.3
Тестирование приложения
Надежность программного обеспечения (ПО) характеризует работу без отказов
в течение определенного периода времени, рассчитанная с учетом стоимости для
пользователя каждого отказа /7/. Надежность программного обеспечения как
определяющий элемент его качества закладывается на этапе разработки и
проектирования, реализуется на этапе реализации ПО /9/. Критерии, определяющие
надежность ПО - выбор режима работы ПО. Поэтому для обеспечения надежности ПО
зачастую используют такие термины, тестирование, отладка, контроль и испытание.
Тестирование - процесс выполнения программы или части программы, с
намерением или целью найти ошибки;
Контроль - попытка найти ошибки в тестовой, или моделируемой среде;
Испытание - попытка найти ошибки, выполняя программу в заданной реальной
среде;
Аттестация - авторитетное подтверждение правильности программы. При
тестировании с целью аттестации выполняется сравнение с некоторыми заранее
определённым стандартом;
Отладка не является разновидностью тестирования. Хотя «отладка» и
«тестирование» часто используются как синонимы, под ними подразумеваются разные
виды деятельности. Тестирование - деятельность, направленная на обнаружение
ошибок; отладка направлена на установление точной природы известной ошибки.
ГОСТ Р28195-89 Оценка качества программных средств.
ISO/IEC 9126: 1991 Information Technology Software Product
Quality Characteristics.
Стандарты разработки ПО ESA PSS-05-0-1991.
Тестирование ИС осуществлялась на основе тестового примера методом
черного ящика (приложение К). Тестирование методом «Черного ящика» предполагает
обработку системы как «непрозрачного объекта», таким образом, знание внутренней
структуры в явном виде не используется. Тестирование этим методом обычно
подразумевает проверку функциональных возможностей. Синонимами понятия метода
«Черного ящика» являются: поведенческое тестирование, функциональное
тестирование, метод непрозрачного ящика, метод закрытого ящика. При
тестировании программного обеспечения методом «Черного ящика» тестировщик знает
только набор вводимых параметров и ожидаемые на выходе результаты, каким
образом программа достигает этих результатов ему неизвестно. Тестировщик
никогда не проверяет программный код и не нуждается в дополнительном знании
программы кроме как в ее техническом описании. Были заданы тестируемые функции
комплекса, желаемые результаты и результаты после тестирования /28/.
Целью тестирования является нахождение несоответствия в работоспособности
(ПО) с одной стороны, и его внешними спецификациями (описанием функций, входных
и выходных дынных, внешних эффектов), с другой стороны.
Руководствуясь внешними спецификациями, тесты проводились для каждой
ситуации и каждой возможности, для каждой границы областей допустимых значений
всех входных данных, областей изменения данных, для всех недопустимых условий.
Тексты программы были проверены, чтобы убедиться, что все условные
переходы были выполнены в каждом направлении.
Проверен текст на её чувствительность к отдельным особым значениям
входных данных и были добавлены соответствующие тесты.
В результате реализации данного типа тестирования было зафиксировано, что
все условные переходы выполняются в каждом направлении, не происходит
«зацикливания» в модуле при граничных значениях индексов циклов, также как и не
обнаружено сбоев в работе модуля при невыполнении тела какого-либо из циклов,
система реагирует на граничные значения водимых данных корректно.
Комплексное тестирование - процесс поисков несоответствия системы ее
исходным целям. Это наиболее творческий из всех видов тестирования. Оно состоит
из следующих шагов:
Тестирование стрессов. Распространенный недостаток больших систем в том,
что они функционируют как будто бы нормально при слабой или умеренной нагрузке,
но выходят из строя при большой нагрузке и в стрессовых ситуациях реальной
среды. Тестирование стрессов представляет попытки подвергнуть систему крайнему
«давлению».
Для проведения тестов осуществлялось большое количество запросов к БД. В
результате теста не было зафиксировано никаких отклонений в работе программы.
Тестирование объёма. В то время как при тестировании стрессов делается
попытка подвергнуть систему серьёзным нагрузкам в короткий интервал времени,
тестирование объема представляет собой попытку предъявить системе большие
объёмы данных в течение более длительного времени.
Для проведения тестов создавалась БД как можно больших размеров,
создавались очереди документов, выводимых на печать, использовались граничные
значения числовых форматов. В результате теста также не было зафиксировано
отклонений в работе программы, обработка запросов БД осуществлялась с незначительным
замедлением.
Тестирование конфигурации. Многие системы обеспечивают работу различных
конфигураций аппаратуры и ПО. Число таких конфигураций часто слишком велико, но
необходимо проверить хотя бы максимальную и минимальную конфигурации. Система была
проверена со всеми аппаратными устройствами, с которыми она может осуществлять
работу.
Тестирование защиты. Так как внимание к вопросам сохранения секретности в
сегодняшнем автоматизированном обществе возрастает, к большинству систем
предъявляются определенные требования по обеспечению защиты от
несанкционированного доступа. Цель тестирования защиты - нарушить секретность в
системе.
В результате проведения теста было зафиксировано, что пользователь, не
имеющий доступа к системе, проникнуть в нее не может.
3.4 Методика
развертывания приложения
Для нормального функционирования системы требуется операционная система Microsoft Windows XP, а также установленный пакет MS Office 2003 c
обязательным приложением MS Access 2003, SQL-server.
Для развертывания приложения необходимо, чтобы на жестком диске объем
свободного места был не менее 30 Мб. Для установки приложения был создан Install.exe, автоматически сгенерировавший инсталляционный пакет
проекта. Чтобы установить ИС, достаточно запустить файл Install.exe, и далее следовать инструкциям мастера установки.
Перед запуском приложения необходимо прочитать руководство пользователя,
которое установится в папке с ИС учета подвижного состава.
Выводы по
главе
При разработке любого проекта, независимо от дипломного проекта,
необходимо учитывать определенное количество критериев. Приступая
непосредственно к выполнению работы по созданию ИС, разработчик должен обладать
такой информацией о будущей системе, которая позволила бы ему без задержек и
переделок закончить работу в срок и с гарантированным качеством.
4. Управление информационным проектом
4.1 Выбор
жизненного цикла разработки ПО
Жизненный цикл разработки ПО представляет собой методику, охватывающую
все стандарты и процедуры, оказывающие влияние на планирование, сбор требований
и анализ, разработку проекта, конструирование и внедрение программной системы.
Для каждого проекта можно применить отдельную модель жизненного цикла /11/.
В нашем случае итерационная модель является наиболее правильным выбором.
Разработка системы предполагает возвращения к предыдущим фазам проектирования
системы.
Графическое представление итерационной модели ИС представлено на рисунке
4.1.
Рисунок 4.1 - Графическое представление итерационной модели
Итерационная модель хорошо зарекомендовала себя при построении
информационных систем, для которых в самом начале разработки можно достаточно
точно и полно сформулировать все требования, с тем, чтобы предоставить
разработчикам свободу реализовать их как можно лучше с технической точки
зрения.
Применение итерационной модели характерно для ситуаций, когда требования
и их реализация максимально чётко определены и понятны. Итерационная модель
хорошо функционирует при её применении в циклах разработки программного
продукта, в которых используется неизменяемое определение продукта и вполне
понятные технические методики.
Преимущества итерационной модели.
- модель хорошо известна потребителям, не имеющим отношения к
разработке ПО, и конечным пользователям.
- она упорядоченно справляется со сложностями и хорошо
срабатывает для тех проектов, которые достаточно понятны.
- она весьма доступна для понимания.
- она проста и удобна для применения, так как процесс
разработки выполняется поэтапно.
- её структурой может руководствоваться даже слабо
подготовленный в техническом плане персонал.
- она отличается стабильностью требований.
- она хорошо срабатывает тогда, когда требования к качеству
доминируют над требованиями к затратам и графиком выполнения проекта.
- она способствует осуществлению строгого контроля менеджмента
проекта.
- она облегчает работу менеджеру проекта по составлению плана и
комплектации команды разработчиков.
Итерационная модель хорошо функционирует при её применении в циклах
разработки программного продукта, в котором используется неизменяемое
определение продукта и вполне понятные технические методики.
Выбор модели жизненного цикла разработки программного обеспечения
является важным этапом. Поэтому для проекта выбор модели жизненного цикла
разработки программного обеспечения проводился на основе анализа требований к
проекту, характеристик команды разработчиков и конечных пользователей, а также
типа проекта и рисков. Данные представлены в приложении В.
Подсчитав количество ответов, которые были подчеркнуты, можно составить
таблицу моделей жизненного цикла с проставленными суммарными баллами. По
результатам выбирается та модель жизненного цикла, у которой наибольший
суммарный балл (таблица 1).
Таблица 1 - Определение приемлемой модели ЖЦ
|
Модель ЖЦ
|
Вес в баллах
|
|
Каскадная модель ЖЦ
|
5
|
|
Итерационная модель ЖЦ
|
14
|
В данном случае суммарный балл имитационной модели ЖЦ наибольший. Это
означает, что для реализации проекта целесообразно применить имитационную
модель ЖЦ ПО.
4.2
Определение цели и области действия программного проекта
Целью программного проекта является разработка системы учета сходов
подвижного состава для предприятия РМПАТП-6
В программном проекте предстоит автоматизировать следующие
бизнес-процессы:
- формирование и ведение нормативно-справочной информации;
- формирование и ведение информации о количестве сошедших,
находящихся на ремонте и вышедших с ремонта автомашин;
- ведение полной информации о персонале, включая прием и
увольнение сотрудников на работу;
- формирование различных выходных документов;
- подготовку и анализ разнородной информации и статистических
данных.
Проект будет:
- для внутреннего использования;
- системой для ввода, обработки данных;
Проект не будет:
- полномасштабной информационной системой организации;
- требовать использования услуг внешних разработчиков.
Автоматизированная информационная система «Учета заявок на ремонт
подвижного состава» предназначена предоставлять оперативную информацию для
руководства организации, подготавливать информацию для передачи данных в
соответствующие государственные органы с целью возмещения затрат на перевозку.
Разработанное техническое задание для разрабатываемого проекта
представлено в ТЗ.
4.3 Создание
структуры пооперационного перечня работ
Процесс создания информационной системы для РМПАТП-6 можно представить в
виде перечня работ, который разрабатывался в приложении Microsoft Office Project 2007 - и включает следующие этапы:
Анализ и требования к программному обеспечению
- анализ требований;
- создание черновой версии спецификации проекта;
- определение сроков выполнения работ;
- постановка задачи;
- составление технического задания;
- составление графика выполнения работ;
- оценка стоимости проекта;
- разработка графика сдачи.
Проектирование
- разработка общей информационной модели системы;
- разработка функциональных моделей системы в целом, а также
подсистем;
- создание логической модели данных;
- определение уровней бизнес-логики;
- построение экранных форм, диалогов, отчетов;
- создание пользовательского интерфейса.
Разработка
- реализация базы данных;
- реализация пользовательского интерфейса;
- определение параметров модульной и уровневой архитектуры;
- назначение персонала для разработки;
- разработка кода.
Тестирование модулей
- тестирование модулей компонента в соответствии со
спецификацией продукта;
- выявление ошибок в спецификациях продукта;
- изменение неправильного кода.
Разработка документации
- разработка справки;
- разработка руководства пользователя;
- доработка документации для пользователей с учетом замечаний.
Внедрение
- определение методики обучения;
- разработка обучающих материалов;
- обучение.
(Microsoft Office Project 2007) - это программный продукт, который позволяет
правильно распределить график работ между членами команды разработчиков ПО
/47/. Правильно построенный пооперационный перечень работ позволяет четко
распределить время, для каждого этапа разработки программного обеспечения
начиная с анализа предметной области и заканчивая внедрением системы. Каждый
этап имеет временные параметры начала и завершения работ, что позволяет
распределить по времени полную разработку проекта.
Более наглядное представление структуры пооперационного перечня работ
приводится в приложении Ж, на рисунке Ж.1.
4.4
Идентификация задач и действий
Для идентификации задач и действий используют диаграмму Гантта. Визуально
диаграмма Гантта представляет собой последовательность действий, выполняемых в
рамках данного проекта. При выполнении больших проектов, содержащих множество
действий и другой отображаемой информации, диаграммы Гантта могут быть очень
громоздкими.
Рабочий график содержит информацию о продолжительности работы, её
основных стадиях, сведения о конечных результатах, а также информацию,
поступившую от ответственных за выполнение соответствующих задач. Для
представления графика работ используется диаграмма Гантта. Фактически этот вид
диаграмм хорошо известен даже тем, кто никогда не сталкивался с разработкой
каких-либо проектов. На диаграмме Гантта слева перечислены производственные
действия, а справа указаны периоды в виде полосок, длина которых соответствует
длительности исполнения каждого этапа в соответствии с временной шкалой
(приложение Ж, рисунок Ж.2).
Определение задач и необходимые трудозатраты для их достижения
представлены в таблице 2.
Таблица 2 - Использование задач
|
Наименование задачи
|
Необходимый ресурс
|
Трудозатраты
|
|
Анализ предметной области
|
|
177ч
|
|
Определение целевого
назначения проекта
|
Руководитель проекта
|
17ч
|
|
Аналитик
|
17ч
|
|
Определение ожидаемого результата
|
Руководитель
проекта
|
23ч
|
|
Аналитик
|
23ч
|
|
Определение
сроков выполнения работ
|
Руководитель
проекта
|
7ч
|
|
Аналитик
|
7ч
|
|
Постановка задачи
|
Руководитель
проекта
|
14ч
|
|
Аналитик
|
14ч
|
|
Составление
технического задания
|
Руководитель
проекта
|
10ч
|
|
Аналитик
|
10ч
|
|
Составление
графика выполнения работ
|
Руководитель
проекта
|
10ч
|
|
Аналитик
|
10ч
|
|
Оценка стоимости
проекта
|
Аналитик
|
15ч
|
|
Проектирование
|
|
344ч
|
|
Теоретическое
описание применяемых методов
|
Аналитик
|
14ч
|
|
Проектировщик
|
14ч
|
|
Определение
функций системы
|
Аналитик
|
20ч
|
|
Проектировщик
|
24ч
|
|
Создание модели
функционирования системы
|
Проектировщик
|
64ч
|
|
Создание
логической модели данных
|
Проектировщик
|
64ч
|
|
Определение
уровней бизнес - логики
|
Аналитик
|
24ч
|
|
Проектировщик
|
48ч
|
|
Создание пользовательского
интерфейса
|
Дизайнер
|
48ч
|
|
Проектировщик
|
24ч
|
|
Разработка
|
|
308ч
|
|
Реализация базы
данных
|
Программист
|
90ч
|
|
Реализация
пользовательского интерфейса
|
Программист
|
94ч
|
|
Внедрение системы
|
Программист
|
124ч
|
|
Тестирование
|
|
96ч
|
|
Тестирование
модулей
|
Тестер
|
48ч
|
|
Отладка
|
Программист
|
48ч
|
|
Составление
документации
|
|
144ч
|
|
Разработка
справки
|
Программист
|
24ч
|
|
Дизайнер
|
24ч
|
|
Разработка
руководства пользователя
|
Программист
|
48ч
|
|
Дизайнер
|
24ч
|
|
Создание итогового отчета по
проекту
|
Руководитель
проекта
|
12ч
|
|
Аналитик
|
12ч
|
|
|
|
|
|
4.5 Оценка
размера и возможности повторного использования ПО
Оценка
длительности и стоимости разработки ПО
В ходе проектирования были определены сроки выполнения работ по созданию
автоматизированной информационной системы для РМПАТП-6, представлены в
приложении…
Стоимость разработки программного обеспечения рассчитывается по формуле
4.1:
, (4.1)
где: СРПО - стоимость разработки программного обеспечения;
ПС - почасовая ставка использования ресурса;
Q -
количество часов использования ресурса;
i -
номер ресурса.
Почасовая ставка использования ресурса для проекта разрабатываемой
информационной системы представлена в таблице 7, количество часов использования
ресурса - в таблице 2.
.6
Распределение ресурсов проекта
В процессе создания автоматизированной информационной системы была
выявлена необходимость введения трудовых ресурсов, представленных в таблице 7.
Таблица 7 - Ресурсы проекта
|
Название ресурса
|
Тип ресурса
|
Количество
|
Стандартная ставка (р./ч)
|
|
Руководитель проекта
|
Трудовой
|
1
|
130,00
|
|
Аналитик
|
Трудовой
|
1
|
90,00
|
|
Проектировщик
|
Трудовой
|
1
|
90,00
|
|
Программист
|
Трудовой
|
1
|
100,00
|
|
Дизайнер
|
Трудовой
|
1
|
80,00
|
|
Тестер
|
Трудовой
|
1
|
70,00
|
Распределение ресурсов проекта при создании автоматизированной
информационной системы «Учет сходов подвижного состава» для организации
РМПАТП-6 можно представить в следующем виде:
1. Руководитель проекта:
- определение целевого назначения проекта;
- определение ожидаемого результата;
- определение сроков выполнения работ;
- постановка задачи;
- составление технического задания;
- составление графика выполнения работ;
- создание итогового отчета по проекту.
2. Аналитик:
- определение целевого назначения проекта;
- определение ожидаемого результата;
- определение сроков выполнения работ;
- постановка задачи;
- составление технического задания;
- составление графика выполнения работ;
- оценка стоимости проекта;
- теоретическое описание применяемых методов;
- определение функций системы;
- определение уровней бизнес - логики;
- создание итогового отчета по проекту.
3. Проектировщик:
- теоретическое описание применяемых методов;
- определение функций системы;
- создание модели функционирования системы;
- создание логической модели данных;
- определение уровней бизнес-логики;
- создание прототипов пользовательского интерфейса.
4. Программист:
- реализация базы данных;
- реализация ядра системы;
- реализация пользовательского интерфейса;
- внедрение системы;
- отладка;
- разработка справки;
- разработка руководства пользователя.
5. Дизайнер:
- создание прототипов пользовательского интерфейса;
- разработка справки;
- разработка руководства пользователя.
6. Тестер:
- тестирование модулей;
- тестирование ИС.
4.7 Оценка
экономической эффективности проекта
Назначением данной ИС является повышение эффективности предприятия
РМПАТП-6, как в денежной, так и во временной форме, для которого
разрабатывается система. Цель проектирования и внедрения такой
автоматизированной информационной системы заключается в автоматизации и замене
ручного труда, автоматизированным трудом с высвобождением персонала. Разработка
данной системы приведет к экономии затрат, связанных с оформлением выходных
документов и ведения учета заявок на ремонт.
Эффективность - выполнение требуемых функций при минимальных затратах
ресурсов. Ежемесячные затраты составят 10000 рублей. Срок, на который
рассчитывается проект (n) 2
года. Стартовые инвестиции (IC)
30000 рублей. Ставка дисконтирования - 12%. Дополнительная прибыль от
реализации проекта (DP) = 50000 руб.
Rk -
ежемесячные денежные поступления в течение периода рассчитывается по формуле
(4.2)
, (4.2)
NPV (net present value) центральный показатель -
текущая стоимость денежных потоков за вычетом текущей стоимости денежных
оттоков. Это обобщенный конечный результат инвестиционной деятельности в абсолютном
измерении. При разовой инвестиции расчет чистого приведенного дохода можно
рассчитать по следующей формуле (4.3):
, (4.3)
где: DPk - ежемесячная дополнительная прибыль
от реализации проекта;
IC -
стартовые инвестиции;
Zk -
ежемесячные затраты на реализацию проекта;
i -
Ставка дисконтирования.
Показатель
NPV является абсолютным приростом, который оценивает, во
сколько приведенный доход перекрывает приведенные затраты.
при
NPV > 0 проект следует принять;
при
NPV < 0 проект не принимается,
при
NPV = 0 проект не имеет ни прибыли, ни убытков.
Так
как NPV > 0, то проект следует принять.
Показатель
NPV отражает прогнозную оценку изменения экономического
потенциала фирмы в случае принятия данного проекта.
Коэффициент
возврата инвестиций рассчитывается по формуле (4.4):
, (4.4)
Если
ROI > 0%, то проект прибылен.
После расчета коэффициента возврата инвестиций необходимо вычислить
внутреннюю норму доходности
Внутренней нормы доходности (IRR - internal rate of return) - это ставка
дисконтирования, приравнивающая сумму приведенных доходов от инвестиционного
проекта к величине инвестиций, т.е. вложения, окупаются, но не приносят
прибыль.
Выбираются два значения коэффициента дисконтирования, которые изображены
в таблице 8, при которых функция NPV меняет свой знак, и используют формулу
(4.5):
, (4.5)
Таблица 8 - Ставка дисконтирования
|
Ставка дисконтирования 1
|
Ставка дисконтирования 2
|
|
0,25
|
0,50
|
|
1-год
|
32000
|
1-год
|
26666
|
|
2-год
|
25641
|
2-год
|
17777
|
|
NPV1=
|
57641р.
|
NPV2=
|
14443р.
|
Для анализа инвестиций применяют такой показатель, как срок окупаемости
(формула 4.6) - продолжительность времени, в течение которого дисконтированные
на момент завершения инвестиций прогнозируемые денежные поступления равны сумме
инвестиций. Иными словами - это сумма лет, необходимых для возмещения стартовых
инвестиций:
, (4.6)
Срок
окупаемости проекта десять месяцев.
Выводы по
главе
В этой главе дипломного проекта проведено определение цели и области
действия программного продукта, также сформулированы задачи проекта и его
рамки. Для реализации проекта произведено обоснование выбора жизненного цикла
программной системы и показано, что наиболее оптимальным вариантом модели жизненного цикла является
«Итерационная модель». Для эффективного процесса управления разработкой проекта
разработана структура пооперационного перечня работ.
Также в дипломе проведен расчет экономической эффективности разработки
информационной системы поставок готовой продукции. Анализ экономической
эффективности показывает эффективность от внедрения разрабатываемой
информационной системы.
Заключение
В дипломном проекте в процессе разработки АИС «Учета заявок на ремонт
подвижного состава» для РМПАТП-6 были решены следующие задачи:
В первой главе определены цели и задачи дипломного проектирования,
актуальность.
Во второй главе данного дипломного проекта проведен анализ предметной
области, в результате чего проанализированы:
- организационная структура РМПАТП-6;
- основные направления деятельности и функции предприятия.
Анализ документооборота отдела информатизации позволил выявить основные
выходные документы, используемые при решении задач введения учета заявок на
ремонт, построить схемы информационных потоков и т.д. Бизнес-процессы учета
заявок на ремонт, реализованы с использованием IDEF0, это позволило выявить основные функциональные
задачи, подлежащие автоматизации при создании автоматизированной информационной
системы. Для проектирования разрабатываемой системы был выбран структурный
подход.
Данные исследования позволили сформулировать требования к разрабатываемой
ИС, которые были согласованы с заказчиками, конечными пользователями и
разработчиком ИС.
В третьей главе проведена разработка информационного обеспечения системы
учета заявок на ремонт. Выполнено проектирование базы данных ИС, а именно
построены концептуальная, логическая и физическая модели. Также обоснован выбор
платформы проектируемой информационной системы. На основе анализа предметной
области выявлены и классифицированы документы различного функционального
назначения.
В четвертой главе дипломного проекта проведено обоснование выбора операционной
системы и инструментального средства для разрабатываемой ИС «Учета заявок на
ремонт подвижного состава» для РМПАТП-6.
В результате выполненного анализа инструментальных средств выявили, что
качестве программного обеспечения выбрана операционная система Windows XP, как наиболее распространенная, а среда разработки - MS Access как наиболее оптимальное средство разработки с точки
зрения разработчика. Так как визуальная технология разработки программ -
позволяет быстро создавать приложения путём размещения в форме стандартных
компонентов. При этом соответствующий код программы автоматически генерируется.
Такая технология освобождает разработчика от рутинной работы по созданию
пользовательского интерфейса и позволяет уделить больше внимания внутренней организации
данных и обработке данных.
В заключение четвертой главы приводится достаточно подробное описание
работы с системой, которое иллюстрируется экранными формами.
В пятой главе дипломного проекта проведено определение цели и области
действия программного продукта, также сформулированы задачи проекта и его
рамки. Для реализации проекта произведено обоснование выбора жизненного цикла
программной системы и показано, что наиболее оптимальным вариантом модели жизненного цикла является
«Итерационная модель». Для эффективного процесса управления разработкой проекта
разработана структура пооперационного перечня работ.
Также в дипломном проекте проведен расчет экономической эффективности разработки
ИС «Учет заявок на ремонт подвижного состава». Анализ показывает эффективность
внедрения разрабатываемой информационной системы. Экономический эффект от
внедрения системы очевиден. Экономия достигается за счет ускорения
информационного обмена, более эффективной обработки данных, снижения
вероятности ошибок. В заключении можно сделать вывод, что цели, поставленные в
работе, достигнуты, задачи выполнены.
Список сокращений
ИС - информационная система;
ПО - программное обеспечение;
СУБД - система управления базами данных;
ЖЦ - жизненный цикл;
АИС - автоматизированная информационная система;
ТЗ - техническое задание;
БД - база данных;
РМПАТП - ростовское муниципальное пассажирское автотранспортное
предприятие.
Список использованной литературы
1. Вендров,
А.М. Проектирование программного обеспечения экономических информационных
систем: Учебник /А.М. Вендров / - М.: Финансы и статистика, 1996.
2. Виленский,
П.Л. Оценка эффективности инвестиционных проектов: Теория и практика. Учебное
пособие. - 2-е изд., перераб. и доп./ П.Л. Виленский, В.Н. Лившиц, С.А. Смоляк/
- М.: Дело, 2002.
. Вендров,
А.М. CASE- технологии - современные методы
проектирования информационных систем. Учебник / А.М. Вендров/ -М.: Финансы и
статистика, 1998.
. Гейн,
К. Системный структурный анализ: средства и методы. Учебник: пер с англ. /К.
Гейн, Т. Сарсон/ - М.: Эйтекс, 1992.
. Диго,
С.М. Проектирование и эксплуатация баз данных. Учебник /С.М. Диго/ - М.:
Фмнансы и статистика, 1995.
. Глушков,
В.М. Основы безбумажной информатики. Учебник - 2-е изд., испр. /В.М. Глушков/-
М.: Наука, 1987.
. Дрогобыцкий,
И.Н. Проектирование автоматизированных информационных систем. Учебник /И.Н.
Дрогобыцкий/ - М.: Финансы и статистика, 1992.
. Баронов,
В.В. Автоматизация управления предприятием. Учебник/ В.В. Баронов, Г.Н. Калянов,
Ю.Н. Попов/ - М.: ИНФРА-М, 2000.
. Дубров,
А.М. Компонентный анализ и эффективность в экономике. Учебное пособие /А.М.
Дубров /- М.: Финансы и статистика, 2001.
. Зиндер,
Е.З. Бизнес - реинжиниринг и технологии системного проектирования. Учебное пособие
/Е.З. Зиндер/ -М.: Центр информационных технологий, 1996.
. Дрогобыцкий,
И.Н. Управление проектированием информационных систем. Учебник /И.Н.
Дрогобыцкий/ - М.: Финансы и статистика, 1992.
. Грабер.
М.Р. Введение в SQL. Учебное
пособие. / М.Р. Грабер / СПб.: Лори, 2003.
. Зиндер,
Е.З. Реинжиниринг + информационные технологии = новое системное проектирование.
//Открытые системы. - 1996 -№1. - С. 56-59.
. Калянов,
Г.Н. Системное проектирование - новый вид деятельности на российском рынке //
Информационные технологии. - 1995. - №3. -С. 20-21.
. Ивлев,
В.А. Построение бизнес-системы// Компьютер Пресс. -1996. - Июнь, - С. 120-122.
. Ивлев,
В.А. Реорганизация деятельности предприятий: от структурной к процессной
организации. Учебник
/В.А. Ивлев, Т.В. Попова/ - М.: Научтехлитиздат, 2000.
17. Калашян,
А.Н. Структурные модели бизнеса: DFD-
технологии. Учебник /А.Н. Калашян, Г.Н. Калянов/ - М.: Финансы и статистика,
2003.
. Калянов,
Г.Н. Теория и практика реорганизации бизнес-процессов. Учебник /Г.Н. Калянов/ -
М.:СИНТЕГ, 2000.
. Лапа,
А.В. Проектирование бизнес - процессов предприятия на основе системы управления
знаниями. Учебник / А.В. Лапа, Ю.Ф. Тельнов, / - М.:Физматлит, 2002.
. Карпова,
Т.С. Базы данных: модели, разработка, реализация. Учебник /Т.С. Карпова/. -
СПб.: Питер, 2002.
. Кравченко,
В.Ф. Организационный реинжиниринг. Учебное пособие / В.Ф. Кравченко, Е.Ф.
Кравченко, П.В. Забелин/ - М.: Приор, 1999.
. Кукушкин,
А.А. CASE-моделирование информационных
процессов. Учебник /А.А. Кукушкин, А.А. Овсянников/ - Орел: ВИПС, 1998.
. Калянов,
Г.Н. CASE. Структурный системный анализ
(автоматизация и применение). Учебник /Г.Н. Калянов/- М.: Лори, 1996.
24. Лагоша,
Б.А. Методы и модели совершенствования организационных структур. Учебник /Б.А.
Лагоша/ - М.: Наука, 1988.
. Маклаков,
С.В. BPwin, Erwin. CASE-средства
разработки информационных систем. Учебник /С.В Маклаков/ - М.: ДИАЛОГ - МИФИ, 1999.
26. Трахтенгерц,
Э.А. Компьютерная поддержка принятия решений. Учебник /Э.А. Трахтенгерц/- М.:
СИНТЕГ, 1998.
. Передерий,
Н. Организация труда руководителя на базе ЭВМ. // Управление персоналом. -
1999. -№6. - С. 10-12.
. Борзов
Ю.В. «Методы тестирования и отладки программ ЭВМ». Рига, ЛГУ им. П. Стучки,
1997.
. Скотт,
К. UML. Основные концепции. Учебник: пер с
англ. /К. Скотт/ - М.: Издательский дом «Вильямс», 2002.
. Тельнов,
Ю.Ф. Реинжиниринг бизнес - процессов. Компонентная методология. Учебник. - 2-е
изд., перераб. и доп. /Ю.Ф. Тельнов/ - М.:Финансы и статистика, 2004. -
320с.:ил.
. Марка,
Д.А. Методология структурного системного анализа и проектирования SADT Учебник: пер. с англ. /Д.А. Марка,
К. МакГоун/ - М.: Метатехнология, 1993.
. Резник,
С.Д. Управление кафедрой. Учебник. - 2-е изд., перераб. и доп. /С.Д. Резник/-
М.: ИНФРА-М, 2004.
. Трахтенгерц,
Э.А. Субъективность в компьютерной поддержке управленческих решений. Учебник
/Э.А. Трахтенгерц/-М.: СИНТЕГ, 2001.
. Шапот,
М.Д. Инструментальные средства поддержки реинжиниринга бизнес - процессов.
Учебник/ М.Д. Шапот/ - М.: ЦРДЗ, 1996.
. Эрик
Дж. Н. Проектирование баз данных с помощью UML. Учебник: пер. с англ. /Дж.Н. Эрик, А.М. Роберт/ -
СПб.: Издательский дом «Вильямс», 2002.
. Дж.
Тельман, «Основы систем баз данных», М,: Финансы и статистика, 1993.
. Хаммер,
М. Реинжиниринг корпорации: манифест революции в бизнесе. Учебник: пер. с англ.
/М. Хаммер, Дж. Чампи/ - Спб.: Изд-во С.-Петербург. Ун-та, 1997.
. Черемных,
С.В.. Структурный анализ систем: IDEF -
технологии. Учебник /С.В. Черемных/- М.: Финансы и статистика, 2001.
. Брудник
С.С. «Экономическое содержание дипломных проектов», М.:ГАНГ, 2005.
. Брудник
С.С. «Определение экономической эффективности программных средств в АСУ» -
М.:ГАНГ, 1995.
41. Справочная
система Microsoft Office Project 2003 RUS
42. Юдицкий,
С.А. Методология структурного анализа и логическог проектирования сложных
информационно - управляющих систем.// Приборы и системы управления. - 1994. -
№4. - С. 15 -25.
43. Скрипкин
К.Г. Экономическая эффективность информационных систем. - М.: ДМК Пресс,
2002.-256с.
44. Программирование на
MSAccess, VB [электронный документ] (http://am.rusimport.ru/MsAccess/topic.aspx) Проверено 19.05.08
. Программирование на
MS Access, VBA, разработка баз данных [электронный документ] (http://msa.dimsign.ru/index.php)
Проверено 21.05.08
Приложение A - Обоснование
выбора ЖЦ разработки ПО
Таблица В.1 - Выбор модели ЖЦ на основе характеристик требований
|
Требования
|
Каскадная
|
Имитационная
|
|
Могут ли требования заранее
определятся в цикле
|
Да
|
Нет
|
|
Являются ли требования легко
определимыми и/или хорошо известными
|
Да
|
Нет
|
|
Часто ли изменяются
требования в цикле
|
Нет
|
Да
|
|
Нужно ли демонстрировать
требования с целью определения
|
Нет
|
Да
|
|
Требуется ли демонстрация
возможностей проверка концепции
|
Нет
|
Да
|
|
Будут ли требования отражать
сложность системы
|
Нет
|
Да
|
|
Обладает ли требование
функциональными свойствами на раннем этапе
|
Нет
|
Да
|
Таблица В.2 - Выбор модели ЖЦ на основе характеристик проектов и рисков
|
Тип проекта и риски
|
Каскадная
|
Имитационная
|
|
Будет ли проект
идентифицировать новое направление продукта для организации
|
Нет
|
Да
|
|
Будет ли проект являться
расширением существующей системы
|
Нет
|
Нет
|
|
Будет ли финансирование
проекта стабильным на всем протяжении ЖЦ
|
Да
|
Нет
|
|
Ожидается ли длительная
эксплуатация продукта в организации
|
Да
|
Да
|
|
Должна ли быть высокая
степень надежности
|
Нет
|
Да
|
|
Будет ли система изменяться,
возможно, с применением непредвиденных методов, на этапе сопровождения
|
Нет
|
Да
|
|
Доступны ли повторно
используемые компоненты
|
Нет
|
Да
|
|
Являются ли достаточными
ресурсы (время, деньги, инструменты, персонал)
|
Нет
|
Да
|
Таблица В.3 - Выбор модели ЖЦ на основе характеристик пользователей
|
Коллектив пользователей
|
Каскадная
|
Имитационная
|
|
Будет присутствие
пользователей ограниченно в ЖЦ
|
Да
|
Да
|
|
Будут ли пользователи
знакомы с определением системы
|
Нет
|
Да
|
|
Будет ли заказчик
отслеживать ход выполнения проекта
|
Нет
|
Да
|