43
Требования к информационному обмену между компонентами
системы:
Автоматизированное рабочее место является однопользовательской
системой, поэтому информационный обмен между компонентами
осуществляется через оперативную память.
Требования к использованию общегосударственных и
зарегистрированных республиканских, отраслевых классификаторов,
унифицированных документов и классификаторов, действующих на данном
предприятии:
На предприятии заказчика действуют следующие классификаторы и
унифицированные документы:
ОКОНХ – общегосударственный классификатор отраслей;
ОКПО - общегосударственный классификатор предприятий и
организаций;
ИНН – индивидуальный налоговый номер;
Документы бухгалтерского учета – положение министерства финансов
№ 285/2 от 1.01.96. о бухгалтерском учете на крупных предприятиях.
Требования к применению систем управления базами данных:
Используется настольная СУБД MS Access.
Требования к структуре процесса сбора, обработки, передачи данных в
системе и представлению данных:
Сбор данных осуществляется сотрудниками организации (источники:
информация от заказчика, тех. специалистов);
Обработка данных осуществляется пользователем (мастером СМР) и
системой: мастер СМР осуществляет ввод данных в БД; система
осуществляет формирование отчетов.
Требования к защите данных от разрушений при авариях и сбоях в
электропитании системы:
Для исключения потери большего объема информации необходимо
осуществлять еженедельное резервное копирование БД.
44
Использование источника бесперебойного питания на компьютере
мастера СМР.
Требования к контролю, хранению, обновлению и восстановлению
данных:
1) Обновление данных осуществляется пользователем (мастером СМР);
Поставщики обновлений: начальник участка №3, Мастера участка №3,
технический специалист (подмерщик), Производитель работ участка №7.
2) Контроль данных осуществляется пользователем (мастером СМР).
3) Хранение данных: данные хранятся в реляционной БД.
4) Восстановление данных осуществляется пользователем (мастером
СМР).
1.4.2 Обоснование проектных решений по программному
обеспечению (ПО)
Конкретные версии компонентов ПО должны определяться на этапе
ввода в действие. ПО является покупным и должно быть лицензионным.
Общие требования к программному обеспечению:
1) программное обеспечение системы должно быть достаточным
для выполнения всех функций системы, реализуемых с применением средств
вычислительной техники, а также иметь средства организации всех
требуемых процессов обработки данных, позволяющие своевременно
выполнять все автоматизированные функции во всех регламентированных
режимах функционирования ИС;
2) программное обеспечение системы должно обладать
следующими свойствами:
функциональная достаточность (полнота);
надежность (в том числе восстанавливаемость, наличие средств
выявления ошибок);
адаптируемость;
модифицируемость;
модульность построения;
45
удобство эксплуатации.
3) программное обеспечение системы должно быть построено таким
образом, чтобы отсутствие отдельных данных не сказывалось на выполнении
функций системы, при реализации которых эти данные не используются;
4) в программном обеспечении системы должны быть реализованы
меры по защите от ошибок при вводе и обработке информации,
обеспечивающие заданное качество выполнения функций системы;
5) все компоненты программного обеспечения системы должны
быть совместимы как между собой, так и с системным программным
обеспечением;
6) эксплуатационная программная документация на систему должна
содержать сведения, необходимые персоналу системы для использования
программного обеспечения, для его первоначальной установки, запуска
программ системы.
Программное приложение должно быть реализовано c помощью пакета
MS Office.
Для относительно быстрой разработки БД применяется пакет
прикладных программ AllFusionModeller, в состав которого программы
ERwin, Bpwin (IDEF0). Интегрирующиеся на любую платформу СУБД:
Oracle, Access, dBase IV, FoxPro и т. д.
Рекомендуемые технические средства и операционная система: ПЭВМ
типа IBM PC с ОС Microsoft Windows 7, пакет MS Office приложение MS
Access.
1.4.3 Обоснование проектных решений по техническому
обеспечению
Так как разработка информационной системы не предусматривает
капитальной реорганизации существующей технологии, парк технических
средств остаётся без изменения. То есть, в системе должны в основном
использоваться технические средства (ТС) серийного производства.
46
Конфигурация локальных вычислительных сетей (ЛВС) должна
удовлетворять требованиям, предъявляемым к ЛВС, имеющим шинную
конфигурацию типа Ethernet. Система должна строиться на базе
унифицированных технических средств.
Комплекс ТС должен быть достаточным для выполнения всех
автоматизированных функций системы. Функциональные и
эксплуатационные характеристики ТС содержатся в технической и
эксплуатационной документации к комплексу технических средств.
Технические средства системы должны быть размещены с
соблюдением требований, содержащихся в технической, в том числе
эксплуатационной документации на них, и так, чтобы было удобно
использовать их при функционировании системы и выполнять техническое
обслуживание.
Защита технических средств системы от воздействия внешних
электрических и магнитных полей, а также помех по цепям питания должна
быть достаточной для эффективного выполнения техническими средствами
своего назначения при функционировании системы.
Требования по техническому обеспечению:
1. Процессор Intel Pentium II 400 МГц и выше;
2. Оперативная память 128 Мбайт и выше;
3. Жесткий диск (200 Мбайт свободного места) и выше;
4. Устройство чтения компакт дисков;
5. SVGA –дисплей;
6. принтер, формат листов: А4, скорость печати: 10 страниц в
минуту и выше;
7. Клавиатура;
8. Манипулятор мышь;
9. видео карта типа SVGA 4-8 Мб VRAM;
10. сетевая карта 100 Мбит;
Требования к структуре и функциям подразделений, участвующим в
функционировании системы или обеспечивающих эксплуатацию:
47
Оставить организационную и функциональную структуру без
изменений.
Функционирование ИС будет осуществляться:
1) по сопровождению ПО: проектировщиком;
2) по сопровождению технических средств: пользователем системы.
Директору
региональног
о центра
Екатеринбург
48
2 ПРОЕКТНАЯ ЧАСТЬ
2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
Жизненный цикл (ЖЦ) программного обеспечения (ПО) ИС
представляет собой непрерывный процесс, начинающийся с момента
принятия решения о создании ПО и заканчивающийся при завершении его
эксплуатации.
Под моделью ЖЦ ПО понимается структура, определяющая
последовательность выполнения и взаимосвязи процессов, действий и задач
на протяжении ЖЦ. Наибольшее распространение получили следующие
модели: каскадная, с промежуточным контролем и спиральная.
Модели каскадная и с промежуточным контролем включают
следующие этапы ЖЦ ПО:
Анализ;
Проектирование;
Реализацию;
Внедрение;
Сопровождение.
Каскадная модель предполагает строго последовательную реализацию
перечисленных этапов жизненного цикла. Достоинства модели:
формирование на каждом этапе законченного комплекта документации и
возможность планирования сроков завершения работ и соответствующих
затрат. Недостаток: несоответствие реальному процессу создания ПО,
который обычно не укладывается в жесткую схему и требует возврата к
предыдущим этапам до уточнения или пересмотра принятых решений.
Модель с промежуточным контролем приближает жизненный цикл к
реальному процессу создания и применения ПО. В отличие от каскадной
модели, она допускает возврат каждого этапа жизненного цикла на любой
49
предыдущий этап для выполнения межэтапной корректировки. При этом
обеспечивается большая надежность ПО, но вместе с тем увеличивается
длительность периода разработки.
Спиральная модель жизненного цикла позволяет устранить недостатки
предыдущих моделей. Основной упор в ней делается на начальные этапы:
анализ и проектирование. На них реализуемость технических решений
проверяется с помощью создания прототипов.
При спиральной схеме разработки неполное завершение работ на
очередном этапе позволяет переходить на следующий этап. Незавершенная
работа может выполняться на следующем витке спирали. Тем самым
обеспечивается возможность предъявить пользователям системы ее
некоторый работоспособный вариант для уточнения требований.
Целью дипломного проекта является разработка системы
автоматизации рабочего места мастера строительно-монтажных работ. В
связи малой сложностью разработки будет использована каскадная модель
жизненного цикла. Использование этой модели позволит формировать на
каждом этапе законченный комплект документации и планировать сроки
завершения проекта и соответствующие затрата.
Каскадная модель включает следующие этапы:
Анализ
Проектирование
Реализация
Введение
Эксплуатация.
На этапе анализа необходимо собрать информацию по планированию и
учету изготовления деталей и узлов систем вентиляции. Мастер должен
собрать и проанализировать данные, необходимые ему в программе по
автоматизации планирования и учета изготовления деталей и узлов систем
50
вентиляции. Это данные для ввода информации, обработки запросов и
формы отчетов.
На этапе проектирования по результатам представленной информации
происходит проектирование программистами базы данных и структуры
программы.
На этапе реализации программисты создают базу данных: создают все
необходимые справочники документы, регистры. Затем производят
настройку главного меню и меню всех элементов программы.
После развертывания технических, информационных и программных
средств необходимо провести окончательное тестирование системы на
развернутых средствах и убедиться в работоспособности всех модулей
системы.
На этапе эксплуатации необходимо провести обучение пользователей
работе с системой. Необходимо провести обучение всех пользователей,
которые будут работать с системой.
На первом этапе эксплуатации системы необходимо заполнить все
первичные данные:
реквизиты организации;
структура подразделений;
сотрудники организации;
и т.д.
Данные можно вносить и в процессе ввода документов по мере
необходимости, но рекомендуется имеющиеся данные внести заранее, создав
таким образом законченную структуру организации.
2.1.2 Ожидаемые риски на этапах жизненного цикла и их
описание
В ходе жизненного цикла информационной системы всегда могут
возникнуть риски, могущие сорвать разработку. Для их избежания
51
проводится оценка вероятных рисков и разрабатываются способы,
позволяющие избегнуть эти риски или минимизировать их влияние.
Рассмотрим наиболее вероятные риски по этапам жизненного цикла
информационной системы в соответсвии с выбранным стандартом.
Этап анализа – возможен риск создания концепции, которую
впоследствии будет сложно (не возможно) реализовать. В выработки
концепции должны быть описаны основные (базовые) функции
разрабатываемой информационной системы. Главное создать основу, и в
дальнейшем развивать созданную систему.
Для предотвращения возникновения рисков на этапе анализа,
необходимо четко понимать свои возможности. Для предотвращения
переоценки собственных сил, в первую очередь нужно создать общую
концепцию, в которой будут включены только базовые функции будущей
системы. И по мере углубления в тему разработки расширять
дополнительными функциями.
Этап проектирования – на этом этапе возможен риск неправильного
проектирования, разработка очень оптимистичных планов проекта, в которые
компания не успеет уложиться, вследствие чего придется увеличивать время
разработки, что повлечет за собой удорожание проекта в целом. К этапу
проектирования нужно отнестись очень важно, следить за каждым этапом и
анализировать реалистичность результатов.
Для предотвращения риска на этапе проектирования, нужно во время
проектирования заложить в график поправки на возможные задержки в
выполнении тех или иных действий. Так нужно попытаться создать гибкий
график который бы не ломался в связи задержки или опережения.
Этап реализации – возможен рисок того что разработка определенного
модуля будет сопряжен с большими трудностями, что какая-та функция
будет мешать продвижению разработки. На данной фазе важно во время
52
определить проблемный модуль или функцию и по возможности упростить
ее, заменить другой или убрать из проекта полностью.
Для предотвращения риска разработки сложного модуля, можно
принять несколько решений, либо разбить данный модуль на несколько и
решить поставленные задачи по отдельности, либо упростить сложный
модуль, если это единственный вариант преодоления риска.
Этап введения – на этом этапе возможен риск выявления большого
количества ошибок в программном коде, что потребует больших затрат на
доработку и устранения всех выявленных ошибок. Невозможно предсказать,
сколько ошибок будет найдено и как много времени понадобится на их
устранение.
Для предотвращения рисков на этапе введения, необходимо данной
фазе отвести максимально возможное время, выделенное на разработку
системы. Так как в зависимости от того на сколько качественным будет
продукт, зависит примет ли заказчик данную разработку или нет.
Эап эксплуатации – этот этап может оказаться очень длительной, если
заказчик по каким-либо причинам будет не доволен разработанным
продуктом, персонал автоматизируемой компании может негативно
относиться к внедрению нового программного обеспечения.
Для предотвращения рисков на данном этапе необходимо произвести
качественное обучение персонала еще до начала внедрения, обучить службу
сопровождения и поддержки. Понять какие проблемы могут возникнуть в
процессе внедрения и уже быть готовым к их решению. Постоянно
консультировать персонал по поводу возникших у них трудностей, создать
горячую линию для решения данных проблем.
Директору
региональног
о центра