Дипломная (вкр): Реализация и аттестация информационной системы

–       стандартные, специализированные и индивидуальные решения. В системе программ "1С:Предприятие" сочетается стандартизация решений и учет индивидуальных потребностей;

–       единая технологическая платформа. В основе системы программ «1С:Предприятие» лежит единая технологическая платформа. Она является фундаментом для построения всех прикладных решений;

–       непрерывное развитие системы. Состав программ «1С:Предприятия» и набор их функции динамично развиваются вместе с изменением типовых потребностей отечественных предприятий и организаций;

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

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

.2 Анализ предметной области

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

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

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

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

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

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

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

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

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

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

На территории автосервиса находиться магазин автозапчастей, в котором представлен широкий ассортимент запчастей для автомобилей ВАЗ и других отечественных автомобилей.

Магазин работает без перерывов и выходных. В среднем за день магазин принимает 80-100 клиентов, в том числе и тех которые в данный момент обслуживаются в автосервисе. Обслуживание одного клиента занимает порядка 5-10 минут.

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

Ниже представлены IDEF диаграммы бизнес-процессов протекающих в данной организации (Рисунки 1.1, 1.2, 1.3).

Рисунок 1.1 - Общая модель функционирования автосервиса

Рисунок 1.2 - Декомпозиция общей модели

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

Документы необходимые для приема автомобиля:

–  паспорт транспортного средства (ПТС);

–       свидетельство о регистрации автомобиля (если автомобиль не снят с учета);

–       генеральную доверенность (если не являетесь собственником автомобиля) сроком действия не менее 4 месяцев;

–       паспорт владельца автомобиля.

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

Рисунок 1.3 - Диаграмма процесса приема аварийных автомобилей

.3 Сбор требований

Сбор требований является важной частью в разработке и внедрении автоматизированной информационной системы. Здесь разрабатываются необходимые требования, функции, особенности внедряемой автоматизированной информационной системы. Лучше всего это выяснять у того, кто будет непосредственной работать с новой программой. Так как я буду разрабатывать АИС на платформе 1С:Предприятие 8.0, то необходимо консультироваться с бухгалтером организации. В результате, я выяснил, что в программе должны быть реализованы:

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

–       перечень выполняемых работ;

–       перемещение, списание, реализация товаров;

–       учет наличия товаров на складе;

–       учет возврата товара поставщикам;

–       учет заработной платы;

–       ведение бухгалтерии;

–       хранение данных о принятых автомобилях;

–       учет наличия б\у запчастей.

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

Так же программа должна содержать большое количество отчетов, необходимых для контроля деятельности автосервиса:

–  Складские отчеты;

–       Анализ продаж;

–       Наряд-заказ;

–       Кассовые операции.

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

В процессе сбора требований к проектируемой системе составляется документ об образе и границах проекта (Приложение А).

Документ об образе и границах (vision and scope document) собирает бизнес - требования в единый документ, который подготавливает основу для последующей разработки проекта.

.4 Анализ и моделирование требований

После того, как были определены и собраны требования для реализации программного модуля, спроектированы DFD диаграммы бизнес-процессов приема автомобилей и выписки документа «Заказ-наряд», представленные на рисунке 1.4 и 1.5.

Рисунок 1.4 - DFD диаграмма процесса приема аварийных автомобилей

Рисунок 1.5 - DFD диаграмма процесса составления Заказ-наряда

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

–  бухгалтер;

–       продавцы;

–       старший механик.

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

Таблица 1.1 - Варианты использования

.5 Спецификация требований

Спецификация требований к ПО (Software Requirements Specification, SRS) имеет ключевое значение для всего жизненного цикла разработки программного продукта. На основании SRS достигается согласие между заказчиками и производителями программного продукта. В спецификации SRS полностью описаны функции, которые должен выполнять разрабатываемый программный продукт. Позволяющая потенциальным пользователям определить степень соответствия продукта их потребностям, а также пути модификации продукта для того, чтобы он был максимально полезен в решении их задач.

По типу описание требований осуществляется по следующим категориям, которые описаны и представлены в таблице 1.2.

Таблица 1.2 - Категории описания требований

Категория F (функциональные требования). Функциональные требования к системе определяют, действия системы, которые она должна выполнять. Функциональные требования реализуются через функции системы. Под функцией АС подразумевается совокупность действий АС, направленная на достижение определенной цели или аспект определенного поведения системы , а под задачей - функция или часть функции АС, представляющая собой формализованную совокупность автоматических действий, выполнение которых приводит к результату заданного вида.

Описание функциональных требований изображено в таблице 1.3.

Таблица 1.3 - Функциональные требования

Вторая категория в описании требований является категория C (системные требования). Системные требования - детализированное описание системных функций и ограничений.

Описания системных требований представлены в таблице 1.4.

Таблица 1.4 - Системные требования

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

Таблица 1.5 - Требования к представлению

Четвертой категорией является требования к рискам (R). Данная категория требований направлена на то, чтобы максимально улучшить работу пользователя т.е. уменьшить риск некорректного внесения данных в систему. Описания требований к рискам представлены в таблице 1.6.

Таблица 1.6 - Требования к рискам

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

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

.6 Аттестация требований

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

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

Прототип главного меню представлен на рисунке 1.6.

Рисунок 1.6 - Прототип главного меню

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

Существует две базовых методологии проектирования информационных систем: структурный и объектно-ориентированный анализ.

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