49
MS Access дает возможность поддержать все нужные типы полей, это:
счетчик, денежный, дата/время, текстовый, числовой, MEMO, логический,
гиперссылка, а также поля объектов OLE. Если в результате специальной
обработки в полях не находится никаких значений, тогда система делает
полнейшую поддержку имеющихся пустых значений [8, c. 411].
Подчеркнем то, что в MS Access в абсолютной мере осуществлено
руководство реляционными базами данных. Система MS Access осуществляет
поддержание первичные и внешние ключи и тем самым добивается целостности
данных непосредственно на уровне ядра (что не дает возможности происходить
несовместимым операциям по обновлению или удалению данных).
Рассматриваемая система база данных в MS Access не что иное как
множество инструментов для ввода, хранения, просмотра, выборки и управления
всевозможной цифровой информацией. К данным средствам можно отнести
таблицы, а также формы, отчеты и запросы.
На малых фирмах довольно простые, но, тем не менее, мощные средства
MS Access возможно применять для управления необходимыми для работы
электронными данными организации.
К направлениям внедрения Microsoft Access можно отнести следующее:
в малом бизнесе (например, бухгалтерский учет, ввод заказов, ведение
информации о клиентах, ведение информации о деловых контактах);
в работе по контракту (например, разработка внутриотраслевых
приложений, разработка межотраслевых приложений);
в крупных корпорациях (например, приложения для рабочих групп
пользователей фирмы, системы обработки различной информации);
в качестве персональной СУБД (это может быть справочник по
адресам, автоматизация инвестиционного портфеля, поваренная книга, каталоги
книг на разную тематику, компакт дисков, видеофильмов на разную тематику и
т. п.).
Основным преимуществом MS Access при применении в крупной
фирмах заключается в том, что он имеет способность делать связь с базами
данных различных форматов, которые находятся на рабочих станциях или
сетевом сервере или крупных ЭВМ. Сотрудник фирмы, который решает некие
50
задачи, не обязан тратить много времени на то, чтобы разобраться, как собрать
данные из разных электронных источников, чтобы потом при помощи
электронной таблицы сделать диаграмму. Применяя MS Access, сотрудник
довольно легко получает прямой доступ к необходимым исходным данным,
также осуществит запрос для получения нужной информации и создаст потом
отчет с вложенной в него диаграммой или же графиком – и это все
осуществляется с помощью одной программной среды (MS Access). Поэтому
данная способность брать данные из различных источников в сочетании с
легкостью применения дают возможность MS Access быть довольно мощным
средством для разработки систем обработки информации в организации.
Для больших фирм особо важным является то, что MS Access надежно
адаптирован для создания различного программного обеспечения рабочих
станций в сетях «клиент-сервер». Отличительная особенность MS Access от
других систем разработки различных приложений в среде Windows заключается
в том, что облегчения разработки форм и отчетов в MS Access экономит много
времени разработчика базы данных. Разработанные в MS Access различные
приложения могут использоваться на различных уровнях корпорации [7, c. 542].
Отметим также, что в MS Access довольно просто спроектировать
приложение, на самом деле «дружественное пользователю» и полной мере
использующее возможности его компьютера.
Разрабатываемая нами база данных «Прием заявок на ремонт и
модернизацию ПК» в MS Access будет состоять из следующих таблиц: «Склад
компьютерных комплектующих»: «Материнские платы»; «Жесткий диск»;
«Видеоадаптер»; «Мониторы»; «Клавиатура»; «Манипулятор мышь»;
«Модули памяти»; «Покупатель». Создаваемые нами таблицы в окне
«Конструктор» в MS Access позволят значительно автоматизировать управление
данными отдела по приемке заявок на ремонт и модернизацию ПК в ООО
«СпецПроект».
В базе данных «Прием заявок на ремонт и модернизацию ПК» все формы
будут разрабатываться в режиме «Конструктор форм». Для всех элементов
управления расположенных на формах базы данных
51
«Прием заявок на ремонт и модернизацию ПК» будет разработан код на
языке Visual Basic for Office для их автоматизации процесса приема заявок на
ремонт и модернизацию ПК в ООО «СпецПроект».
1.4.3. Обоснование проектных решений по техническому обеспечению
Техническое обеспечение – совокупность аппаратных средств, с
помощью которых осуществляется процесс функционирования АРМ [27]. Таким
обеспечением являются устройства отображения, обработки информации,
управления и передачи данных. Каждое из них характеризуется составом
элементов и структурой. Выбор типов элементов, их количества и взаимосвязей
связан с решением задачи разработки программного обеспечения (т.е.
информационной системы в нашем случае) [6].
Типы технических средств не могут выбираться отдельно друг от друга –
должна быть обеспечена их совместимость по входной и выходной информации
и по физическим параметрам сигналов. Для базового набора компонентов ПЭВМ
характерны [25, 20]:
системный блок, содержащий основную аппаратную часть
(микропроцессоры, контроллеры ввода-вывода, интерфейсы, ПЗУ, ОЗУ, сетевые
адаптеры);
внешние запоминающие устройства;
дисплей для отображения текстовой и графической информации;
клавиатура, предназначенная для ввода управляющих команд и
данных;
печатающее устройство (принтер), обеспечивающий получение
твердых печатных копий.
Для разработки данной АРМ необходимость приобретения
дополнительных технических средств отсутствует.
Обеспечение техническое – это объединение технических средств,
компьютерной техники, а также средств передачи информации с одного
компьютера на другие, используемых в автоматизированных системах
управления и в информационных системах. Для работы программы по приему
заявок на ремонт и модернизацию ПК достаточно тех компьютеров, которые
52
имеются в наличие у ООО «СпецПроект».
Технические характеристики ПК ООО «СпецПроект»:
Процессор: Intel Celeron Dual Core G530 (Sandy Bridge, 2.40ГГц,
LGA1155, L3 2048Kb)
Память: DDR3 2048 Mb (pc-10660) 1333MHz
Материнская плата: S1155, iH61, 2*DDR3, PCI-E16x, SVGA, DVI,
SATA, Lan, mATX, Retail
Видеокарта встроенная Intel® HD Graphics 512Мб
Сетевая карта есть
(10/100 Ethernet).
Архитектура платформ ООО «СпецПроект» включает в себя:
аппаратные средства вычислительной техники – 1 сервер, 12 рабочих
станций, накопители, а также и другое компьютерное оборудование;
аварийные планы по обеспечению бесперебойной работы аппаратуры
(главным образом – сервера) и баз данных в условиях чрезвычайных
обстоятельств.
операционные и управляющие системы, утилиты и офисные
программные системы;
Все это в полой мере подходит для полного
функционирования
разрабатываемой базы данных «Прием заявок на ремонт и модернизацию ПК».
53
II Проектная часть
2.1.Разработка проекта автоматизации
2.1.1.Этапы жизненного цикла проекта автоматизации
Модель жизненного цикла – это структура, содержащая процессы,
действия, а также задачи, которые происходят в процессе конкретной
разработки, функционирования и дальнейшее сопровождения разработанного
программного продукта в дальнейшем в течение всей жизни данной системы, от
определения определенных требований и затем до стадии завершения ее
дальнейшего применения.
На данном этапе развития имеются определенное количество моделей и
стандартов, в разной степени определяющих регламент жизненного цикла,
большую часть из них относят к заказному ПО (программному обеспеченью).
Так, например, ГОСТ 34.601-90 относят на автоматизированные системы
и он определяет стадии и этапы их создания. Также, в данном стандарте имеется
подробное описание содержания работ на каждом этапе. Стадии и этапы работы,
отраженные в данном стандарте, в довольно большой степени отражают
каскадную модель жизненного цикла.
Например, ISO/IEC 12207:1995 – это стандарт, который отражает
процессы и организацию жизненного цикла. Его относят на все без исключения
виды заказного ПО. Данный стандарт не имеет описания фаз, а также и стадий
этапов.
Custom Development Method (далее CDM) – это стандарт, который
отражает разработку различных прикладных информационных систем под заказ
потребителей данных систем – конкретный материал, детальный до уровня
различных заготовок проектных документов, направленных на применение в
проектах с использованием Oracle. Мера адаптации CDM имеет ограничение 3-
мя моделями жизненного цикла: «классическая» (заложены все необходимые
работы/задачи, а также этапы), «быстрая разработка» (Fast Track), «облегченный
подход», он рекомендуется, если в случае небольших проектов и возможности
довольно быстро прототипировать необходимые приложения.
Rational Unified Process (далее RUP) – это стандарт, который отражает
итеративную модель разработки проекта, которая включает 4-ре необходимые
54
фазы: начало, исследование, построение и затем внедрение. Любая из этих фаз
может быть при необходимости разбита на определенные этапы (итерации), в
использовании которых выдается версия либо для внутреннего, либо для
внешнего применения. Проход через 4-ре главные фазы именуется циклом
разработки, причем каждый цикл заканчивается генерацией полученной версии
проектируемой системы. Если после всего этого данная работа над заданным
проектом не завершается, то сделанный продукт в дальнейшем продолжают
развивать и заново проходя те же фазы разработки. Сущность работы в заданных
рамках RUP – это разработка и дальнейшее сопровождение моделей, а не
простых стандартных бумажных документов, посему данный процесс
непосредственно привязан к применению определенных средств моделирования
(UML), а так же определенной технологии при проектировании и дальнейшей
разработки (например, объектно-ориентированный анализ, object-oriented
analysis, OOA, объектно-ориентированное программирование, object-oriented
programming, OOP).
Microsoft Solution Framework (далее MSF) – это стандарт, который сходен
с RUP, он так же имеет 4-ре фазы: анализ, проектирование, разработка,
стабилизация, является итерационной, задает применение объектно-
ориентированного моделирования. MSF по сравнению с RUP в наиболее
значительной степени направлена на создания бизнес-приложений компаний.
Extreme Programming (далее XP) – это стандарт, который отражает
экстремальное программирование, которое на данный момент является одним из
самых новых среди исследуемых нами методологий, сформировалось в 1996
году. Во главе методологии стоит слаженная командная работа, эффектная
коммуникация непосредственно между заказчиком программы и исполнителем в
течение всего времени проекта по разработке ИС, а разработка проводится
непосредственно с применением последовательно дорабатываемых различных
взаимодополняющих прототипов [3, c. 183].
Итак, главными критериями для выбора стандарта ЖЦ будут являться:
критерий актуальности и современности применяемых методик контроля
необходимой разработки;
55
критерий разработки с применением итерационного режима с
дальнейшей возможностью контролировать затем риски;
критерий выполнения необходимого проекта на определенных
контролируемых точках, полное отсутствие каких либо других дополнительных
требований к моделированию необходимого процесса разработки и также
внедрения.
Подытоживая сказанное об описании стандартов, можно сделать вывод,
что из них являются 4 стандарта: MSF, RUP, COBIT, XP.
Такой стандарт как COBIT нам для разработки не подходит, так как
главной его целью применения «является использование аудита и стратегии
поэтапного планирования ИС и IT инфраструктуры в целом».
Такой стандарт как XP также нам не годиться, так как он не имеет
полноценно разработанных этапов жизненного цикла, таких как выбор
концепции, поэтапное планирование, дальнейшая разработка, постепенная
стабилизация и наконец, процесс внедрения.
Отсюда следует, что перед нашим выбором стоит Rup и MSF. Оба
данных стандарта являются довольно молодыми и также поддерживающими все
новейшие технологии продуктивной разработки, а также и контроля их
дальнейшего выполнения [1, c. 175].
Rational Unified Process – есть отлично созданным решением для средних
по размерам коллективов разработчиков, которые работают с использованием
только продуктов, а также и технологий фирмы Rational. Поддержка разработки
системы, а также и самой системы отражается методикой RUP, но эта
технология в большей степени достаточно сильным образом направлена на
внутри компании различные инструментальные средства.
Что касаемо Extreme Programming, то эта концепция хорошо нам
подходит для проектных групп небольшого размера и для не великих систем с
часто преобразуемыми с течением времени работы требованиями. Главная
проблема XP – это дальнейшее сопровождение программы. В следствие частой
текучки кадров в коллективе разработчиков программ большая часть проектной
информации может быть с течение времени утеряно бесследно из-за
практически в итоге отсутствующей документации по определенному проекту.
56
Что касаемо Microsoft Solutions Framework, то эта концепция является
особо сбалансированной технологией, которая ориентирована на проектные
группы малых и средних размеров. MSF не делает вообще ограничений на
применяемый инструментарий и имеет также рекомендации довольно общего
характера. Но, данные рекомендации возможно использовать для создания
определенного процесса, соответствующего надобностям группы разработчиков.
Наш проект является по размерам небольшим, поэтому включает в себя 1-го
человека.
Помимо этого, главным преимуществом MSF – это ее итерационная
модель с одномоментными уточняющими вехами (это является аналогом
каскадной модели). Поэтому, применение MSF попыталась вобрать в себя как
каскадную, так и итерационную модель дальнейшей разработки, а также и
внедрения ПО.
По рассмотренным нами ранее преимуществам, нами был избран
стандарт MSF как особо гибкий и наиболее удобный для последующей
реализации моего выбранного проекта.
Главным из преимуществ данного стандарта есть возможность такая, как
управлять параллельно и проектом разработкой нашего приложения, а также и
внедрением инфраструктуры.
Подводя итог, можно сказать, что в идеологии MSF имеются пять стадий
жизненного цикла ИС, которые в концепции MSF именуются фазами. Первым из
них является фаза выработки концепции [21, c. 173].
Цель этой фазы в создании и сплоченности проектной группы на базе
договоренности единого цельного видения. Проектная группа разработчиков
должна точно видеть, что данная группа хочет осуществить для заказчика и
определить свою цель. Заказчиком в нашем случае выступает ООО
«СпецПроект».
Вот какие задачи намечаются при фазе выработки концепций.
Управление проектируемым продуктом регулирует концептуальный и
логический дизайн; функциональная спецификация; а также и сводный план и
сводный календарный график данного проекта; бюджет. Кластер данного
управления программой намечает цели дизайна, концепцию решения, структуру
57
данного проекта. Кластер разработка в целом отвечает за оценку технологий;
логический, а также и физический дизайн проекта; план и календарный график
разработки проекта; смета разработки.
Кластер удовлетворения потребителя рассматривает сценарии/примеры
использования, пользовательские требования потребителя, требования
локализации, а также и общедоступности; пользовательская потребителя
документация/план обучения/график тестирования удобства эксплуатации;
обучение.
Кластер тестирования осуществляет оценку дизайна; необходимые
требования тестирования; план, а также и календарный график тестирования.
Кластер управление выпуском осуществляет функции оценки дизайна;
требования по эксплуатации; план и календарный график осуществления
пилотного и окончательного внедрения программы. В рамках реализации и
внедрения моего проекта своими силами и при помощи консультаций у
сотрудников ООО «СпецПроект» была разработана базы данных «Прием заявок
на ремонт и модернизацию ПК».
Сам процесс проектирования базы данных «Прием заявок на ремонт и
модернизацию ПК» – это системный способ постепенного продвижения от
абстрактных концепций к конкретным техническим деталям в данной
программе.
Отмети также, что результатами фазы планирования работы по
проектированию базы данных «Прием заявок на ремонт и модернизацию ПК»
являются: функциональная спецификация. Рассмотрение предполагаемых
рисков, а также сводный план и сводный календарный график проекта «Прием
заявок на ремонт и модернизацию ПК», развернутые среды разработки и
тестирования. От меня на этом этапе необходим обзор и выбор языка
программирования, на котором в дальнейшем будет выполнено решение,
календарный план по срокам, а также и графикам разработки. На этом этапе
просчитывается планирование всей необходимой архитектуры ИС, работу
пользователей фирмы ООО «СпецПроект» в будущей системе. Дальнейшим
этапом идет фаза разработки. На данной фазе разработки делается акцент на
создании компонента решения (вбирая в себя как документацию, так и
58
собственно программный код). Но определенная часть данной работы может
осуществляться также на фазе стабилизации в дальнейшем, если данная нужда
необходима в процессе тестирования базы данных «Прием заявок на ремонт и
модернизацию ПК». Эта фаза также включает в себя разработку инфраструктуры
программы.
Необходимо также обратить особое внимание на то, что активность
проектной команды на этом этапе не ограничена только написанием
программистами кода программы – все ролевые кластеры принимают
деятельное участие в создании, а также и тестировании решения.
Дальнейшим этапом жизненного цикла идет фаза стабилизации.
В течение данной фазы стабилизации происходит тестирование
разработанного нами решения. При этом внимание направлено на его
эксплуатацию в реалистичной модели производственной среды ООО
«СпецПроект». Осуществляется устранение выявленных ошибок, а также
дальнейшая подготовка решения к выпуску для эксплуатации в ООО
«СпецПроект».
Нельзя предугадать, сколько ошибок будет выявлено и как много
времени в дальнейшем необходимо будет для устранения неполадок в
программе. Но имеются 2-ва статистических признака, которые помогают
оценить уровень стабилизации решения. Это точка конвергенции. В данной
точке конвергенции становится существенно виден ощутимый прогресс в
дальнейшем устранении ошибок, то есть скорость дальнейшего устранения
ошибок начинает обгонять скорость их обнаружения в программе. Так, как
число найденных, но не исправленных ошибок может существенно
варьироваться даже и после того, как оно начало со временем убывать,
конвергенция может восприниматься скорее всего как тенденция, нежели как
определенный момент во времени. Вслед за этим число активных ошибок
должно постепенно уменьшаться, вплотную до точки достижения нуля. Точка
конвергенции дает проектной группе возможность разобраться, что процесс
тестирования близится к завершению.
Последующим этапом будет фаза внедрения. В течение данной фазы
происходит внедрение технологии и компоненты решения, стабилизируется