Реализация и аттестация информационной системы

Введение

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

Рассматриваемая дипломная работа написана на базе автосервиса ИП Кузнецова В.Г.

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

Программа должна обеспечивать:

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

–       получение выходных документов (накладная, счет-фактура, заказ-наряд и другие);

–       формирование отчетов (получение данных на бумажных носителях об операциях взаиморасчетов с клиентами).

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

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

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

Предлагаемая программа реализует информационную справочную систему, предназначенную для организации:

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

–       учета стоимости произведенных работ;

–       складского учета;

–       полного документооборота предприятия;

–       приема и учета б\у запчастей и автомобилей;

–       заказов, хранения, закупок, продаж запасных частей.

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

1. Разработка требований к программному обеспечению

 

.1 Анализ существующих решений по автоматизации

 

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

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

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

С: Управление торговлей 8.

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

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

Управление продажами.

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

–       планирование продаж;

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

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

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

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

–  работа со склада;

–       работа под заказ;

–       совмещение стратегий.

Обработку заказа покупателя можно разбить на следующие этапы:

–  формирование заказа;

–       автоматическое резервирование заказанных товаров на складе и в заказах поставщикам;

–       корректировка заказа;

–       составление и контроль календарного плана оплаты заказа;

–       оформление приема товаров, заказанных у поставщиков;

–       отгрузка товаров покупателю;

–       закрытие заказа.

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

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

Управление закупками.

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

–  оперативное планирование закупок;

–       оформление заказов поставщикам и контроль их исполнения;

–       платежный календарь расхода денежных средств.

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

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

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

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

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

Учет товаров на складах компании.

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

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

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

«1С: Управление торговлей 8» - это готовое прикладное решение, в основе которого лежит мощная технологическая платформа нового поколения "1С: Предприятие 8". В комплект поставки программного продукта, помимо платформы, входит конфигурация "Управление торговлей".

«1С: Управление торговлей 8» обеспечивает автоматический подбор данных, необходимых для ведения бухгалтерского учета, и передачу этих данных в «1С: Бухгалтерию 8». Кроме того, предусмотрена передача данных в бухгалтерские конфигурации системы программ "1С: Предприятие 7.7".

Альфа-Авто:Автозапчасти+Автосервис, ред. 3. Проф.

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

Общие сведения:

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

–       на каждую запчасть заводится отдельная карточка, которая содержит следующую информацию: каталожный номер, продажные и закупочные цены, ставки налогов, рекомендованный минимальный остаток (для формирования Заказа на поставку), единицы измерения;

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

–       в системе, возможно, вести учет взаимозаменяемых деталей;

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

–       при работе с каталогом товара существует возможность его сортировки по «Наименованию» либо по реквизиту «Каталожный номер», также имеется возможность отбора номенклатурных позиций в запросе по вхождению заданных символов в наименование, каталожный номер, код;

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

–       автоматическое списание себестоимости товаров происходит по одному из заданных методов: по среднему, FIFO, LIFO;

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

–       типовое решение позволяет покупать и продавать номерные агрегаты и сопровождать эту деятельность выпиской соответствующих документов;

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

–       типоразмерам (радиус, ширина, высота);

–       профилям (радиальный, диагональный и т.п.);

–       сезонности;

–       индексам нагрузки и скорости;

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

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

–    блок торговли;

–       блок работы по заказам;

–       блок реализации (консигнации);

–       внутренний документооборот.

Программа «АвтоМагазин 8» компании AutoSoft. Ее стоимость составляет 8500-10000 рублей.

Программа АвтоМагазин позволяет:

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

–       вести полный документооборот предприятия;

–       осуществлять многоуровневый складской учёт;

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

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

–       вести различные справочники (по структуре склада, по бригадам, валютам и многое другое);

–       экспортировать информацию в различные внешние программы (1С, БЭСТ, ИНФО-Бухгалтер и др.);

–       самостоятельно производить настройки и модификацию данных в программе.

Техническая информация:

–    возможность работы в сети. Сетевая платформа клиент-сервер (FireBird 2.0);

–       возможность работы в терминальном режиме (Windows 2003, Citrix);

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

–       возможность одновременного запуска двух и более программ с одного компьютера;

–       реализовано на языке программирования Delphi 7.1.

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

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

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

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

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

–       стандартные, специализированные и индивидуальные решения. В системе программ "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	Требования к функциям (задачам), выполняемым системой
C	Требования к системе в целом;
P	Требования к представлению
R	Требования, определяющие риски, которым должно быть уделено основное внимание при разработке системы

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

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

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

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

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

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

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

Требование	Тип	Описание.
Архитектура	C	Сервер данных (1C).
Язык программирования	C	1C
Операционная система	C	Windows XP.

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

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

Требование	Тип	Описание.
Общий интерфейс	P	Он не должен быть перегружен, прост для понимания.
Обязательные поля ввода	P	Обязательные поля для ввода должны быть выделены.

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

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

Требование	Тип	Описание
Соответствие полей с занесенными данными	R	Предоставленные поля должны соответствовать типу ввода данных.
Результаты поиска данных	R	Полное соответствие реальным данным.
Сохранность данных	R	Система должна обеспечивать сохранность данных.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Наиболее подходящей методологией проектирования ИС является структурная.

Выводы к разделу

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

автоматизация документооборот данные заказ

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

.1 Архитектурное проектирование

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

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

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

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

Файловый вариант

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

Рисунок 2.1 - Представление файлового варианта 1С

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

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

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

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

Клиент - серверный вариант

Клиент-серверный вариант предназначен для использования в рабочих группах или в масштабе предприятия. Он реализован на основе трехуровневой архитектуры «клиент сервер» (рисунок 2.2):

Рисунок 2.2 - Представление клиент-серверного варианта 1С

На одном из компьютеров работает сервер 1С:Предприятия 8.0. Программа, работающая у пользователя, взаимодействует с сервером 1С: Предприятия 8.0, а сервер при необходимости обращается к базе данных MS SQL Server. При этом физически сервер 1С: Предприятия 8.0 и MS SQL Server могут располагаться как на одном компьютере, так и на разных. Это позволяет администратору при необходимости распределять нагрузку между серверами.

Использование сервера 1С: Предприятия 8.0 позволяет сосредоточить на нем выполнение наиболее объемных операций по обработке данных.

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

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

С: Предприятие 8.0 использует возможности MS SQL Server для эффективной выборки информации:

–       механизм запросов ориентирован на максимальное использование MS SQL Server для выполнения расчетов и составления отчетов;

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

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

Рисунок 2.3 - Архитектура «Файл-сервер»

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

.2 Проектирование пользовательского интерфейса

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

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

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

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

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

–       элементы управления системой;

–       навигация между блоками системы;

–       визуальный дизайн экранов программы;

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

–       снижение количества ошибок пользователя;

–       снижение стоимости поддержки системы;

–       улучшение морального состояния персонала;

–       уменьшение расходов на изменение пользовательского интерфейса по требованию пользователей;

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

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

Справочники - это прикладные объекты конфигурации. Они позволяют хранить в информационной базе данные, имеющие одинаковую структуру и списочный характер. Каждый элемент справочника характеризуется кодом и наименованием. Система поддерживает режим автоматической нумерации элементов, при котором она самостоятельно может генерировать код для нового элемента справочника. Помимо кода и наименования, каждый элемент справочника, как правило, содержит некоторую дополнительную информацию, которая подробно описывает этот элемент [12, 32].

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

Рисунок 2.1 - Форма справочника «Контрагенты»

Справочник «Автомобили» хранит информацию об автомобилях клиентов.

Рисунок 2.2 - Форма справочника «Автомобили»

Документы - это прикладные объекты конфигурации. Они позволяют хранить в прикладном решении информацию о совершенных хозяйственных операциях или о событиях, произошедших в "жизни" предприятия вообще. Это могут быть, например, приходные накладные, приказы о приеме на работу, счета, платежные поручения и т.д. Каждый документ характеризуется номером, датой и временем. Система поддерживает режим автоматической нумерации документов, при котором она самостоятельно может генерировать номер для нового документа. Важными характеристиками документа являются дата и время. Они позволяют установить строгую временную последовательность совершения операций. Таким образом, документы могут отличаться друг от друга не только номером, но и своим положением на временной оси. В результате всегда можно сказать, какая из двух операций была совершена раньше [12, 32].

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

Рисунок 2.2 - Форма Документа «Заказ-Наряд»

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

Рисунок 2.2 - Форма Документа «Акт приема-передачи ТС»

2.3 Проектирование базы данных

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

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

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

Особое внимание при построении модели уделяют целостности и отсутствию избыточности данных. Избыточность - это многократное повторение одних и тех же данных). Если в БД имеется несколько описаний одного и того же объекта, то все экземпляры этих описаний, кроме одного будут избыточными. При анализе схемы данных было выявлено отсутствие избыточности данных.

Целостность - это непротиворечивость одних данных другим. Целостность зависит от степени избыточности данных. Например, если в БД имеется несколько описаний одного преподавателя, то при изменении принадлежности данного преподавателя к кафедре в одном описании нарушается целостность данных. Однако, даже при не избыточности данных может возникнуть нарушение целостности. Пусть из БД удаляются сведения о некотором преподавателе. Теперь ссылки на этого преподавателя в зарегистрированных до удаления преподаваемых предметах в преподаваемых группах будут неправильными и также квалифицируются как нарушение целостности. Кроме целостности и не избыточности при проектировании БД учитывают возможность быстрого выполнения запросов к БД и оптимального использования ресурсов, а также разграничение доступа для разных групп пользователей.

При проектировании базы данных создаются два уровня модели - логический и физический. Логический уровень - это абстрактный взгляд на данные, на нем данные представляются так, как выглядят в реальном мире, и могут называться так, как они называются в реальном мире. Логический уровень модели данных является универсальным и никак не связан с конкретной реализацией системы управления базами данных[19, 23].

Рисунок 2.3 - Логическая модель данных

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

Рисунок 2.4 - Физическая модель данных

База данных проектируемой информационной системы будет реализована собственными средствами поддержки баз данных платформа «1С:Предприятие». Это обуславливается тем, что возможности, предоставляемые платформой, позволяют справляться с задачами, поставленными перед информационной системой, т.к. объемы обработки информации не являются «узким местом» ИС.

Встроенные средства поддержки баз данных платформы «1С: Предприятие» поддерживают многопользовательскую работу с базой данных. Использование встроенных возможностей платформы «1С: Предприятие» позволяет снизить стоимость внедрения информационной системы, т.к. не требует приобретения дополнительного ПО для управления СУБД [30].

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

В качестве платформы для разработки системы была выбрана «1С: Предприятие 8».

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

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

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

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

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

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

Очень важным преимуществом такого подхода является унификация обучения пользователей. Например, обучившись на курсах по «1С: Предприятию 8.0» или имея опыт работы с какой либо из программ, пользователь достаточно быстро осваивает возможности специализированных или индивидуальных решений [34, 38, 39].

.5 Проектирование модулей

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

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

Каждый программный модуль связан с остальной частью конфигурации задачи. Эта связь называется контекстом выполнения модуля. Следует различать два вида контекста:

–       глобальный контекст задачи;

–       локальный контекст выполнения конкретного модуля.

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

Локальный контекст модуля образуется тем конкретным местом конфигурации задачи, для которого использован программный модуль. Локальный контекст виден только конкретному программному модулю и определяет для модуля набор непосредственно доступных модулю значений агрегатных типов данных, их атрибутов и методов. Однако контекст модуля можно передать как объект в виде параметра при вызове процедур и функций. Кроме того, контекст модуля определяет тот набор методов, которые доступны только в данном контексте. Локальный контекст предназначен для того, чтобы дать возможность управлять частными аспектами поведения задачи, присущими данному модулю [34].

Различают следующие виды программных модулей:

–       общие модули;

–       модуль приложения;

–       модуль внешнего соединения;

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

–       модули форм.

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

Модуль приложения относится ко всей конфигурации в целом и может быть только один. Модуль приложения является аналогом глобального модуля в версии 7.7. Он отвечает за пользовательскую сессию (сеанс) работы с 1С:Предприятием 8.0.

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

Модули прикладных объектов - у некоторых прикладных объектов конфигурации могут быть собственные модули, например, модуль документа РасходнаяНакладная, модуль справочника Номенклатура. Не следует их путать с модулями форм этих объектов.

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

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

Справочники

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

–       справочник СКЛАДЫ;

–       справочник НОМЕНКЛАТУРА;

–       справочник КОНТРАГЕНТЫ;

–       справочник АВТОМОБИЛИ КЛИЕНТОВ.

Документы

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

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

–       расходная накладная;

–       приходная накладная;

–       акт приема-передачи автомобиля.

Отчеты

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

–       отчет Заказ-наряды;

–       отчет Остатки товаров;

–       отчет Продажи.

 

Выводы к разделу

В данном разделе было рассмотрено логическое представление проектируемой информационной системы, были построены диаграммы последовательности действий в системе. Была спроектирована база данных. Все перечисленные действия были необходимы для реализации информационной системы, таким образом, чтоб система удовлетворяла всем требованиям заказчика. Для разрабатываемой информационной системы была выбрана платформа «1С: Предприятие 8.0.»

3. Реализация и аттестация информационной системы

.1 Реализация приложения

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

Основная цель создания ИС - это автоматизация документооборота по приему аварийных автомобилей и составление заказ-нарядов на выполнение работ в автосервисе. Платформой для разработки ИС выбрана «1С: Предприятие 8.0». Все объекты, используемые при проектировании ИС в «1С: Предприятии» описаны в конфигураторе.

Ниже на рисунке 3.1 представлено окно конфигурации с созданными документами.

Рисунок 3.1 - Окно конфигурации с созданными документами

Для составления Акта принятия-передачи транспортного средства необходимо открыть форму документа «Акт приема передачи ТС». В появившемся окне следует заполнить все обязательные поля, они выделены красным подчеркиванием. В табличной части «Опции\оборудование» можно составить список опций автомобиля, его комплектацию. На вкладке «Перечень повреждений», кратко описываются повреждения автомобиля и возможные неисправности. Если продавец не является владельцем автомобиля, а продает его по генеральной доверенности, то устанавливаем флажок «Генеральная доверенность» и заполняем поле «Владелец автомобиля». При нажатии кнопки «Печать» появляется возможность выбора выходных форм документа, непосредственно акт приема-передачи автомобиля и акт его осмотра. Примеры печатных форм представлены в приложении Г, пример формы документа - рисунок 3.2.

Рисунок 3.2 - Форма документа «Акт приема передачи ТС»

Данные об автомобилях хранятся в справочнике «Автомобили», поэтому для заполнения данных о принятом автомобиле, в первую очередь, необходимо создать новую запись в справочнике и заполнить основные поля. Сведения об автомобиле автоматически будут отображены на форме документа.

Пример форм справочника «Автомобили» изображён на рисунке 3.3.

Рисунок 3.3 - Формы справочника «Автомобили»

Документ «Заказ-наряд» заполняется аналогично предыдущему документу, за исключением табличной части. Данный документ содержит две табличные части «Товар» и «Услуги». Порядок их заполнения одинаков, сначала производится выбор товара или услуги из справочника «Номенклатура», затем указываем необходимое количество. Цена и общая сумма рассчитываются автоматически при изменении номенклатуры и количества товара. В поле «Причина обращения» дается краткое описание неисправности, с которой обратился клиент. Данные об автомобиле клиента, также хранятся в справочнике «Автомобили» и при выборе автоматически заполняются поля отображающие сведения об автомобиле на форме документа «Заказ-наряд». Пример формы документа «Заказ-Наряд» приведен на рисунке 3.4.

Рисунок 3.4 - Формы документа «Заказ-Наряд»

При нажатии кнопки «ОК» или «Записать» происходит проведение документа по нескольким регистрам накопления сведений. Кнопка «Печать» осуществляет построение печатных форм «Заказ-наряд» и «Акт выполненных работ». Примеры печатных форм приведены в приложении Б, а исходный код формы документа в приложении В.

.2 Взаимодействие приложения с источниками данных

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

Для работы с запросами, в «1С: Предприятие 8» использует объект встроенного языка «Запрос», фрагмент запроса приведен на рисунке 3.6.

Рисунок 3.6 - Пример запроса

Он позволяет получать информацию, хранящуюся в полях базы данных, в виде выборки, сформированной по заданным правилам. Исходную информацию запрос получает из набора таблиц. Эти таблицы представляют данные реальных таблиц базы данных в удобном для анализа виде. Их можно разделить на две большие группы: реальные и виртуальные. Реальные таблицы, в свою очередь, могут быть объектными (ссылочными) или не объектными (не ссылочными). Отличительной особенностью реальных таблиц является то, что они содержат данные какой-либо одной реальной таблицы, хранящейся в базе данных. Виртуальные таблицы формируются, в основном, из данных нескольких таблиц базы данных.

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

–       описание запроса;

–       объединение запросов;

–       упорядочивание результатов;

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

–       описание итогов.

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

Описание запроса определяет источники данных, поля выборки, группировки и т.д. Объединение запросов определяет, как будут объединены результаты выполнения нескольких запросов.

Упорядочивание результатов определяет условия упорядочивания строк результата запроса.

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

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

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

.3 Тестирование приложения

Тестирование - процесс выполнения программы с целью обнаружения ошибок. Тестирование обеспечивает:

–       обнаружение ошибок;

–       демонстрацию соответствия функций программы ее назначению;

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

–       отображение надежности как индикатора качества программы.

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

Существуют 2 принципа тестирования программы:

функциональное тестирование (тестирование «черного ящика»);

структурное тестирование (тестирование «белого ящика»).

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

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

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

Тестирование «черного ящика» обеспечивает поиск следующих категорий ошибок:

–       некорректных или отсутствующих функций;

–       ошибок интерфейса;

–       ошибок во внешних структурах данных или в доступе к внешней базе данных;

–       ошибок характеристик (необходимая емкость памяти и т. д.);

–       шибок инициализации и завершения.

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

Тестирование ИС проводилось функциональным методом «черного ящика».

Этот тип тестирования основан на тестировании путем взаимодействия с приложением через графический интерфейс пользователя и анализа выводимых результатов. Метод предполагает обработку системы как «неизвестного объекта», таким образом, знание внутренней структуры в явном виде не используется. Тестирование этим методом обычно подразумевает проверку функциональных возможностей. При таком тестировании тестировщик знает только набор вводимых параметров и ожидаемые на выходе результаты, каким образом программа достигает этих результатов, ему не известно. Тестировщик никогда не проверяет программный код и не нуждается в дополнительном знании программы, кроме как ее технического описания. [5]

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

–       при использовании верных данных имеет место ожидаемый результат или сообщение об успехе;

–       при использовании неверных данных отображается соответствующее предупреждение/сообщение об ошибке.

Рассмотрим работу документа «Акт приема-передачи ТС».

При корректном заполнении реквизитов документа (Рисунок 3.7) нажатие на кнопку ОК позволяет записать и провести документ. А по кнопке выбора формы для печати выводится печатная форма акта (Рисунок 3.8).

Рисунок 3.7 - Заполнение документа «Акт приема-передачи ТС»

Рисунок 3.8 - Печатная форма квитанции на оплату

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

Рисунок 3.9 - Сообщение об ошибке при заполнении документа

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

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

Цели этапа развертывания:

–       перенести решение в промышленную среду;

–       признание заказчиком факта завершения проекта.

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

Таблица 3.1 - План развертывания приложения

Действие	Описание действия
1. Резервное копирование	Производится резервное копирование данных пользователя при его участии и согласовании путем переноса информации на сменные носители (СD, DVD)
2. Установка базовых компонентов решения	Применение технологий, обеспечивающих работу решения.
3. Установка клиентского приложения	Перенос на компьютер пользователя и установка окончательного варианта разработанной ИС и базы данных
4. Обучение	Производится обучение пользователей по работе с системой, разработчик убеждается в правильности и понимании работы ИС клиентами
5. Передача базы знаний проекта клиенту	Заказчику передаётся вся проектная документация
6. Закрытие проекта	Составляется отчёт о закрытии проекта. Заказчик подписывает акт приёмки.

Выводы к разделу

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

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

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

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

К. Вигерс в своей книге «Разработка требований к программному обеспечению описал обоснование модели выбора жизненного цикла на основе характеристик требований, участников команды разработчиков, типа проектов и рисков, характеристик пользователей. Таблицы приведены в Приложении Д.

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

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

Характеристика	Каскадная	V-образная	Прототипирование	Спиральная	RAD	Инкрементная
Требования	4	4	3	3	7	3
Участники команды разработчиков	5	6	4	3	7	6
Коллектив пользователей	3	6	5	8	7	8
Типы проектов и рисков	2	2	3	2	3	4
Итого	14	18	15	16	24	21

Результатом проведенных исследований наиболее подходящей моделью жизненного цикла для разработки системы учета заказов такси модель быстрой разработки приложений (RAD).Application Development (RAD) - это жизненный цикл процесса проектирования, созданный для достижения более высокой скорости разработки и качества ПО, чем это возможно при традиционном подходе к проектированию.предполагает, что разработка ПО осуществляется небольшой командой разработчиков за срок порядка трех-четырех месяцев путем использования инкрементного прототипирования с применением инструментальных средств визуального моделирования и разработки. Технология RAD предусматривает активное привлечение заказчика уже на ранних стадиях - обследование организации, выработка требований к системе. Причины популярности RAD вытекают из тех преимуществ, которые обеспечивает эта технология (рисунок 4.1).

Рисунок 4.1 - RAD технология

Наиболее существенными из них являются:

–       высокая скорость разработки;

–       низкая стоимость;

–       высокое качество.

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

Применение технологии RAD целесообразно, когда:

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

–       нечетко определены требования к ПО. В большинстве случаев заказчик весьма приблизительно представляет себе работу будущего программного продукта и не может четко сформулировать все требования к ПО. Требования могут быть вообще не определены к началу проекта либо могут изменяться по ходу его выполнения.

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

–       интерфейс пользователя (GUI) есть главный фактор. Нет смысла заставлять пользователя рисовать картинки. RAD технология дает возможность продемонстрировать интерфейс в прототипе, причем достаточно скоро после начала проекта.

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

–       ПО не обладает большой вычислительной сложностью.

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

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

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

–       фаза построения;

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

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

На фазе проектирования часть пользователей принимает участие в техническом проектировании системы под руководством специалистов-разработчиков. CASE-средства используются для быстрого получения работающих прототипов приложений. Пользователи, непосредственно взаимодействуя с ними, уточняют и дополняют требования к системе, которые не были выявлены на предыдущей фазе. Более подробно рассматриваются процессы системы. Анализируется и, при необходимости, корректируется функциональная модель. Каждый процесс рассматривается детально. При необходимости для каждого элементарного процесса создается частичный прототип: экран, диалог, отчет, устраняющий неясности или неоднозначности. Определяются требования разграничения доступа к данным. На этой же фазе происходит определение набора необходимой документации. После детального определения состава процессов оценивается количество функциональных элементов разрабатываемой системы и принимается решение о разделении ИС на подсистемы, поддающиеся реализации одной командой разработчиков за приемлемое для RAD-проектов время - порядка 60 - 90 дней. С использованием CASE-средств проект распределяется между различными командами (делится функциональная модель). Результатом данной фазы должны быть:

–  общая информационная модель системы;

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

–       точно определенные с помощью CASE-средства интерфейсы между автономно разрабатываемыми подсистемами;

–       построенные прототипы экранов, отчетов, диалогов.

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

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

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

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

–       производится анализ использования данных;

–       производится физическое проектирование базы данных;

–       определяются требования к аппаратным ресурсам;

–       определяются способы увеличения производительности;

–       завершается разработка документации проекта.

Результатом фазы является готовая система, удовлетворяющая всем согласованным требованиям.

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

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

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

–  Общие требования, предъявляемые к автоматизированной системе, следующие:

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

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

–       формирование отчетных форм;

–       формирование актов;

–       расширяемость системы, то есть возможность её доработки в случае повышения требований к автоматизированной системе;

–       удобный пользовательский интерфейс.

Область действия данной информационной системы - автосервис «Автомастер» ИП Кузнецов В.Г. Операционная система Windows XP.

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

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

–       разработка требований к программному обеспечению;

–       проектирование информационной системы;

–       реализация и аттестация информационной системы;

–       внедрение системы.

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

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

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

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

Для того чтобы реализовать ту или иную задачу необходимы ресурсы (человек или оборудование). Ресурсы необходимые для реализации информационной системы автоматизации рабочего места торгового представителя представлены на рисунке 4.3.

Рисунок 4.3 - Ресурсы необходимые для реализации ИС

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

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

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

–  своевременность (быстрота доведения проектов до завершения). При использовании уже существующих компонентов нужно меньше разрабатывать, а, следовательно, ПО создается быстрее;

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

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

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

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

Платформа 1С:Предприятие, в которой разрабатывалась информационная система, все повторяемые модули (процедуры, функции и переменные) позволяет описывать в глобальном модуле конфигурации и производить многократное их использование. Это во многом ускоряет процесс разработки, снижает объем программы, а также позволяет избежать появления ошибок при повторном проектировании.

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

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

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

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

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

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

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

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

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

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

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

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

4.8 Оценка экономической эффективности проекта

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

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

Дополнительная прибыль от реализации проекта (DP) = 32000 рублей. Дополнительна прибыль была спрогнозирована экспертами предприятия. За основу расчета было взято время, затрачиваемое на ручное заполнение документов диспетчерами, и рассчитана прибыль от увеличения принимаемых заказов при автоматизированном формировании документов.

Стартовые инвестиции (IC) = 30000 рублей.

Ставка дисконтирования (i) = 12%.

Срок, на который рассчитан проект (n) = 2 года.

Дополнительная прибыль от реализации проекта (DP) = 32000 рублей.

Ежегодные затраты на реализацию проекта (Z1) = 12000 рублей.

Ежегодные затраты на реализацию проекта (Z2) = 8000 рублей.

Годовые денежные поступления можно рассчитать по формуле 4.1.

                                                                                              (4.1)

Годовые денежные поступления (R1) = 20000 рублей.

Годовые денежные поступления (R2) = 24000 рублей.

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

Центральным показателем в рассматриваемом методе является показатель NPV (net present value) - текущая стоимость денежных потоков.

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

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

Чистый приведенный доход (NPV) рассчитывается по формуле 4.2

                                                         (4.2)

- годовые денежные поступления в течении n лет.- количество лет на сколько рассчитан проект.- стартовые инвестиции.- ставка дисконтирования.

По расчетам данной формулы NPV = 3460 руб.

Показатель NPV является абсолютным приростом, поскольку оценивает, на сколько приведенный доход перекрывает приведенные затраты. Так как NPV > 0, то проект следует принять.

Коэффициент возврата инвестиций (ROI) рассчитывается по формуле 4.3

                                                                      (4.3)

По расчетам (ROI) = 111.53%

Далее необходимо рассчитать срок окупаемости проекта по упрощенной формуле: nок = Число лет до года окупаемости + (Не возмещенная стоимость на начало года окупаемости / Приток наличности в течение года окупаемости)

Таблица 4.1 - Вспомогательная таблица расчёта срока окупаемости проекта

Показатели	Значения
Период (лет)	0	1	2
Денежный поток	-30000	20000	24000
Дисконтированный денежный поток	-30000	18500	22450
Накопленный дисконтированный денежный поток	-30000	-17800	3460

 = 1,79

Срок окупаемости nok = 1,79 года (1 год и 11 месяцев)

Так как ROI = > 100% то проект считается прибыльным.

Далее необходимо рассчитать индекс прибыльности (PI). Индекс прибыльности показывает, сколько мы заработаем денег с каждого вложенного рубля, и рассчитывается по формуле 4.4

                                                                       (4.4)

Таким образом, индекс прибыльности равен (PI) =1,2

На основании представленных результатов можно сделать вывод, что внедрение системы учета заказов такси в ООО «Крымское АТП» - целесообразно.

 

Выводы к разделу

В четвертой главе дипломного проекта при решении задач управления проектом разработки информационной системы проведено определение цели и области действия программного продукта, сформулированы задачи проекта и его рамки. Для реализации проекта произведено обоснование выбора жизненного цикла программной системы и показано, что наиболее оптимальным вариантом модели жизненного цикла является RAD технология. Для эффективного процесса управления разработкой проекта разработана структура пооперационного перечня работ, которая представлена в виде иерархического дерева и в виде списка. С использованием пакета Microsoft Project 2007 разработана диаграмма Ганта, построен календарный график работ и проведено ресурсное планирование проекта.

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

 

5. Форсайт

 

.1 Основы Форсайта

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

Форсайт ориентирован на определение возможных вариантов будущего. Основой для оценки вариантов будущего являются экспертные оценки. Методология Форсайт вобрала в себя десятки традиционных и достаточно новых экспертных методов. При этом происходит их постоянное совершенствование, отработка приёмов и процедур, что обеспечивает повышение обоснованности предвидения перспектив научно-технического и социально-экономического развития. Основной вектор развития методологии направлен на более активное и целенаправленное использование знаний экспертов, участвующих в проектах. Обычно в каждом из форсайт-проектов применяется комбинация различных методов, в числе которых экспертные панели, Дельфи (опросы экспертов в два этапа), SWOT-анализ, мозговой штурм, построение сценариев, технологические дорожные карты, деревья релевантности, анализ взаимного влияния и др. Чтобы учесть все возможные варианты и получить полную картину привлекается, как правило, значительное число экспертов. Так, в японских долгосрочных прогнозах научно-технологического развития, проводимых каждые пять лет, участвует более 2-х тысяч экспертов, которые представляют все важнейшие направления развития науки, технологий и техники, а в последнем корейском проекте участвовали более 10 тысяч экспертов.

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

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

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

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

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

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

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

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

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

Этапы Форсайта:

3.      Формирование объекта В технологическом Форсайте объект определен сферой проведения Форсайта: авиастроение, нанотехнологии <mhtml:file://C:\Documents%20and%20Settings\Admin\Рабочий%20стол\оксане\форсайд\Форсайт%20%20Википедия.mht!/wiki/%D0%9D%D0%B0%D0%BD%D0%BE%D1%82%D0%B5%D1%85%D0%BD%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D0%B8> и т.д. В Общественно-политическом Форсайте объект конструируется специально.

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

.        Сканирование Этап предполагает формирование "карты сферы" (стейкхолдеры, эксперты, компании), выбор методов исследования и проведение экспертных опросов.

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

.        Планирование и Исполнение Этап предполагает разработку и создание дорожных карт, включение всех стейкхолдеров в обсуждение будущего, изменение стратегии и действий заказчика Форсайта (изменение стратегии, формирование новых проектов и программ).

Опыт Форсайт-проектов западных стран показывает, что в первую очередь необходимо отказаться от того, что такие объекты, как например, качество жизни населения, уже есть. Необходимо отвечать на другие вопросы: чего же хотим мы (реальные участники проекта), чего мы хотим достигнуть в будущем, на что будем работать, к чему прилагать усилия. Это связано с тем, что такие понятия как качество жизни, уровень доверия, гражданское общество - являются социокультурными феноменами, они не существуют объективно, а формируются как эффект определенной социальной практики. При проведении технологического Форсайта разработка или продукт, то есть зона приложения усилий, чаще всего задается заказчиком. Здесь же он требует специальной проработки и организации сложной коммуникации. В общественно-политических форсайт-проектах этот этап выделяется в отдельный и называется выработкой «существенных условий» .

Следующим шагом прорисовывается экспертная среда и вырабатываются ответы на вопросы:

–       Кого считать экспертом?

–       Кого, на каком этапе и в каком качестве включать в проект?

–       Кто составляет круг лиц, принимающих решения?

–       Какие тенденции существуют и как оценить их влияние?

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

5.2 Методы Форсайта

Форсайт ориентирован на определение возможных вариантов будущего. Основой для оценки вариантов будущего являются экспертные оценки. Методология Форсайт вобрала в себя десятки традиционных и достаточно новых экспертных методов. При этом происходит их постоянное совершенствование, отработка приёмов и процедур, что обеспечивает повышение обоснованности предвидения перспектив научно-технического и социально-экономического развития. Основной вектор развития методологии направлен на более активное и целенаправленное использование знаний экспертов, участвующих в проектах. Обычно в каждом из форсайт-проектов применяется комбинация различных методов, в числе которых экспертные панели, Дельфи (опросы экспертов в два этапа), SWOT-анализ, мозговой штурм, построение сценариев, технологические дорожные карты, деревья релевантности, анализ взаимного влияния и др (рисунок 5.1). Чтобы учесть все возможные варианты и получить полную картину привлекается, как правило, значительное число экспертов. Так, в японских долгосрочных прогнозах научно-технологического развития, проводимых каждые пять лет, участвует более 2-х тысяч экспертов, которые представляют все важнейшие направления развития науки, технологий и техники, а в последнем корейском проекте участвовали более 10 тысяч экспертов.

Рисунок 5.1 - Система методов Форсайта

Рассмотрим наиболее распространенный технологии:

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

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

Метод дельфи - это технология, которая применяется для прогнозирования и экспертизы. Метод был разработан в 1953 году Гордоном и Хелмером в RAND Corp. Суть метода состоит в структурировании процесса групповой коммуникации, направленном на создание условий эффективной работы группы над комплексной проблемой. Метод дельфи использует итерративные независимые опросы экспертной панели, которые позволяют определять вероятность, значение и следствие факторов, тенденций и событий, связанных с обсуждаемой проблемой. После первого тура опросов участники экспертной панели получают все ответы, данные другими участниками, без указания авторов ответов. Этот прием позволяет экспертам уточнить и скорректировать свои позиции.

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

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

SWOT - метод анализа в стратегическом планировании, заключающийся в разделении факторов и явлений на четыре категории: Strengths (Сильные стороны), Weaknesses (Слабые стороны), Opportunities (Возможности) и Threats (Угрозы). SWOT-анализ позволяет определить причины эффективной или неэффективной работы компании на рынке и на основании этого разработать стратегию дальнейшего развития.

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

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

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

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

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

5.3 SWOT - анализ

Классический SWOT-анализ предполагает определение сильных и слабых сторон в деятельности фирмы, потенциальных внешних угроз и благоприятных возможностей и их оценку в баллах относительно среднеотраслевых показателей или по отношению к данным стратегически важных конкурентов. Классическим представлением информации такого анализа являлось составление таблиц сильных сторон в деятельности фирмы (S), ее слабых сторон (W), потенциальных благоприятных возможностей (О) и внешних угроз (Т).

На пересечении SW с OT проставляется экспертная оценка их взаимного влияния в баллах. Итоговая сумма баллов по строкам и столбцам показывает приоритетность учета того или иного фактора при формировании стратегии.

Правила проведения SWOT-анализа

Чтобы на практике избежать возможных ошибок и извлечь максимум пользы из SWOT-анализа, необходимо соблюдать несколько правил.

.        По возможности максимально конкретизировать сферу проведения SWOT-анализа. При проведении анализа, охватывающего весь бизнес, его результаты скорее всего будут слишком обобщенными и бесполезными для практического применения. Фокусирование SWOT-анализа на положении компании в разрезе конкретного рынка/сегмента даст намного более полезные для практического применения результаты.

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

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

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

–       использует ли компания внутренние сильные стороны или отличительные преимущества в своей стратегии? Если компания не имеет отличительных преимуществ, то какие из ее потенциальных сильных сторон могут ими стать?

–       являются ли слабости компании ее уязвимыми местами в конкуренции и/или они не дают возможности использовать определенные благоприятные обстоятельства? Какие слабости требуют корректировки, исходя из стратегических соображений?

–       какие благоприятные возможности дают компании реальные шансы на успех при использовании ее квалификации и доступа к ресурсам?

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

При сборе данных и анализе предметной области была построена матрица SWOT - анализа, которая показала наиболее оптимальные планы дальнейшей деятельности организации.

Матрица SWOT - анализа представлена на рисунке 5.2.

Рисунок 5.2 - матрица SWOT - анализа

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

Заключение

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

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

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

–      анализ объекта автоматизации и разработка требований к программному обеспечению;

–       проектирование информационной системы;

–       реализация информационной системы;

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

–       В процессе анализа, проектирования, реализации и управления разработкой информационной системы начисления и учета платы за обучение были выполнены следующие действия:

–       анализ существующих решений по автоматизации предметной области;

–       выбор методологии проектировании информационной системы;

–       анализ предметной области и сбор требований;

–       составление необходимой для проектирования документации - ТЗ и ТЭО на разрабатываемую ИС;

–       аттестация требований;

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

–       выбор платформы для реализации ИС - выбрана платформа «1С:Предприятие 8.0»;

–       реализация информационной системы.

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

 

Список использованных источников

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

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

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

.        Баронов В.В. Информационные технологии и управление предприятием М.: Компания АйТи, 2006. - 256с.

.        Бояркин В.Э., Филатов А.И., «1С:Предприятие 8. Конвертация данных: обмен данными между прикладными решениями».

.        Богатин Ю.В. Оценка эффективности бизнеса и инвестиций. Учебное пособие для ВУЗов - М.: Финансы, ЮНИТИ - ДАНА, 2004.

.        Богданов В.В. Управление проектами в Microsoft Project 2003: Учебный курс. - СПб.: Питер, 2003.

.        Вендров А.М. Проектирование программного обеспечения экономических информационных систем - М.: Финансы и статистика, 2002 - 448

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

.        Габец А.П., Гончаров Д.И. «1С:Предприятие 8.0. Простые примеры разработки».

.        Габец А., Гончаров Д., Козырев Д., Кухлевский Д., Радченко М., «Профессиональная разработка в системе 1С:Предприятие 8».

.        Грофт Р. CASE - средства / [Электронный документ] (www.interface.ru) Проверенно. 23.04.2009.

.        Дубянский В. М. 1С:Предприятие. Конфигурирование и администрирование для начинающих. Экспресс - курс. - СПб.: БХВ-Петербург, 2005. - 176 с.: ил.

.        Ельцов В.А., «Организация электронного обмена данными с торговыми партнерами и банками в системе программ 1С:Предприятие 8».

.        Зиндер, Е.З. Проектирование баз данных: новые требования, новые подходы / СУБД. - 1996.

.        Карпова Т.С. «Базы данных: модели, разработка, реализация», 2002.

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

.        Колесников С.Н. Инструментарий бизнеса: современные методологии управления предприятием. - М.: Издательско-консультационная компания «Статус-Кво 97», 2004. -336с.

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

.        Леффингуэлл Д., Уидриг Д. Принципы работы с требованиями к программному обеспечению. Унифицированный подход: Пер. с англ. - М.: Издательский дом «Вильямс», 2002 - 448 с.

.        Л.А. Мацяшек.- М.: Издательский дом «Вильямс», 2002.

.        Митичкин С.А., Практика программирования в 1С:Предприятие 8.0, М.: Издательский Дом «КомБук», 2004. - 272 с.

.        Михайлов С. Е., 1С - программирование как дважды два. Самоучитель. СПб.: Тритон, 2005. - 173, с: ил.

.        Михайлов А. В. 1С:Предприятие 7.7/8.0: системное программирование. СПб.: БХВ-Петербург, 2005. - 336 с.: ил.

.        Пайрон Т. Использование Microsoft Project 2003. - М.: Издательский дом «Вильямс», 2003.

.        Радченко М. «1С:Предприятие 8.0. Практическое пособие разработчика. Примеры и типовые приемы».

.        Смирнова Г. Н. Проектирование экономических информационных систем: Учебник - М.: Финансы и статистика, 2003.

.        Тимофеев Г. Конфигурирование и администрирование 1С:Предприятия. Учебный курс. - Ростов н\Д: Феникс, 2001.

.        Тиори, Т. Проектирование структуры базы данных: Пер. с англ. / Т. Тиори, Дж. Фрай. - М.: Мир, 2000.

.        Усиков Т. Н. 1С:Предприятие. Эффективное программирование - М.: Новое знание, 2004. - 446 с.

.        Фатрелл Р.Т. Управление программными проектами: достижение оптимального качества при минимуме затрат - М.: Издательский дом «Вильямс», 2003.

.        Филимонова Е.В. Практическая работа в 1С:Предприятие 8.0. - Ростов н/Д.: Феникс, 2004.

.        Хрусталева Е.Ю., «Разработка сложных отчетов в 1С:Предприятии 8.0. Система компоновки данных».

.        Шапиро, В.Д. Управление проектами - СПб.: Изд. «Два-Три», 2001.

.        Шафер, Дональд, Ф., Управление программными проектами: достижение оптимального качества при минимуме затрат.: Пер. с англ. - М.: Издательский дом «Вильямс», 2004. - 1136 с.

Приложение А

 

Техническое задание

Общие сведения.

1.  Полное название организации: ИП Кузнецов В.Г.

2.      Реквизиты организации: Ставропольский край, г. Невинномысск, ул. Степная 22.

.        Полное название разработчика: Галканов Павел Викторович

.        Реквизиты разработчика: Ставропольский край, г. Невинномысск, ул. Гагарина 45/2.

Обоснование цели создания АИС

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

Характеристика объекта автоматизации

Автосервис ИП Кузнецова В.Г. осуществляет следующие виды услуг:

–       сервисный ремонт автомобилей;

–       прием аварийных автомобилей с последующим разбором на запчасти;

–       реализация запчастей и автокосметики.

Требования к системе.

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

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

Требования к надежности

Работа системы должна быть стабильной и отказоустойчивой.

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

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

Требования к защите информации от несанкционированного доступа

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

Требования к информационному обеспечению

В основе информационной системы лежит среда хранения и доступа к данным

Функции

–    индивидуальность интерфейса для каждого пользователя;

–       система должна функционировать на платформе Windows /2000/XP;

–       поддержка всех функций буфера обмена;

–       наличие средств для проведения отчётности.

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

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

Производительность

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

Предположения и зависимости

Заказчик должен иметь ОС Windows XP, платформу 1С: Предприятие 8.0.

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

Система предназначена:

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

-        для ввода, обработки данных;

-        для эксплуатации работниками организации.

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

Ограничения

Система разрабатывается только для внутреннего пользования работниками автосервиса ИП Кузнецова В.Г.

Лингвистическое обеспечение.

Применение встроенного языка программирования в платформе 1С: Предприятие 8.0.

Программное обеспечение.

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

Техническое обеспечение.

Персональные компьютеры должны быть с процессором не ниже Pentium IV с сетевой картой пропускной способностью 100 Mb/s.

Состав и содержание работ по созданной системе.

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

Требования к составу и содержанию работ по подготовке к вводу системы в действие.

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

Приложение Б

 

Примеры печатных форм

Рисунок Г.1 - Печатная форма «Акт осмотра ТС»

Рисунок Б.1 - Печатная форма «Акт приема-передачи ТС»

Рисунок Б.2 - Печатная форма документа «Заказ-наряд»

 

Приложение В

 

Примеры исходного кода форм документов

Рисунок В.1 - Фрагмент кода модуля документа «Акт приема-передачи ТС»

Рисунок В.2 - Фрагмент кода процедуры печати акта приема-передачи ТС

Рисунок В.3 - Фрагмент кода модуля документа «Заказ-Наряд»

Рисунок В.4 - Фрагмент кода процедуры печати Акта выполненных работ

Приложение Г

 

Таблица Г.1 - Таблица тестовых данных взаимодействия заказчика с системой

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

Приложение Д

Обоснование модели выбора жизненного цикла

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

Требования	Каскадная	V-образная	Прототипирование	Спиральная	RAD	Инкрементная
Являются ли требования легко определимыми и/или хорошо известными	Да	Да	Нет	Нет	Да	Нет
Могут ли требования заранее определятся в цикле?	Да	Да	Нет	Нет	Да	Да
Часто ли будут изменяются требования в цикле?	Нет	Нет	Да	Да	Нет	Нет
Нужно ли демонстрировать требования с целью определения	Нет	Нет	Да	Да	Да	Нет
Требуется ли для демонстрации возможностей проверка концепции	Нет	Нет	Да	Да	Да	Нет
Будут ли требования отражать сложность системы	Нет	Нет	Да	Да	Нет	Да
Обладает ли требование функциональными свойствами на раннем этапе	Нет	Нет	Да	Да	Да	Да

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

Команда разработчиков проекта	Каскадная	V- образная	Прототипирование	Спиральная	RAD	Инкрементная
Являются ли проблемы предметной области проекта новыми для большинства разработчиков	Нет	Нет	Да	Да	Нет	Нет
Является ли технология предметной области проекта новой для большинства разработчиков	Да	Да	Нет	Да	Нет	Да
Являются ли инструменты, используемые проектом, новыми для большинства разработчиков	Да	Да	Нет	Да	Нет	Нет
Изменяются ли роли участников проекта во время ЖЦ	Нет	Нет	Да	Да	Нет	Да
Могут ли разработчики проекта пройти обучение	Нет	Да	Нет	Нет	Да	Да
Является ли структура более значимой для разработчиков, чем гибкость	Да	Да	Нет	Нет	Нет	Да
Будет ли менеджер проекта строго отслеживать прогресс проекта	Да	Да	Нет	Да	Нет	Да
Важна легкость распределения ресурсов	Да	Да	Нет	Нет	Да	Да
Приемлет ли команда равноправные обзоры инспекций, менеджмент/обзоры заказчиков, а так же стадии	Да	Да	Да	Да	Нет	Да

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

Тип проекта и риски	Каскадная	V-образная	Прототипирование	Спиральная	RAD	Инкрементная
Будет ли проект идентифицировать новое направление продукта для организации	Нет	Нет	Да	Да	Нет	Да
Будет ли проект иметь тип системной интеграции	Нет	Да	Да	Да	Да	Да
Будет ли проект являться расширением существующей системы	Нет	Да	Нет	Нет	Да	Да
Будет ли финансирование проекта стабильным на всем протяжении ЖЦ	Да	Да	Да	Нет	Да	Нет
Ожидается ли длительная эксплуатация продукта в организации	Да	Да	Нет	Да	Нет	Да
Должна ли быть высокая степень надежности	Нет	Да	Нет	Да	Нет	Да
Будет ли система изменяться, возможно, с применением непредвиденных методов, на этапе сопровождения	Нет	Нет	Да	Нет	Да
Является ли график ограниченным	Нет	Нет	Да	Да	Да	Да
Являются ли «прозрачными» интерфейсные модули	Да	Да	Нет	Нет	Нет	Да
Доступны ли повторно используемые компоненты	Нет	Нет	Да	Да	Да	Нет
Являются ли достаточными ресурсы (время, деньги, инструменты, персонал)	Нет	Нет	Да	Да	Нет	Нет

Таблица Д.4 - Выбор модели ЖЦ на основе характеристик пользователей

Коллектив пользователей	Каскадная	V-образная	Прототипирование	Спиральная	RAD	Инкрементная
Будет ли присутствие пользователей ограниченно в ЖЦ	Да	Да	Нет	Да	Нет	Да
Будут ли пользователи знакомы с определением системы	Нет	Нет	Да	Да	Нет	Да
Будут ли пользователи ознакомлены с проблемами предметной области	Нет	Нет	Да	Нет	Да	Да
Будут ли пользователи вовлечены во все фазы ЖЦ	Нет	Нет	Да	Нет	Да	Нет
Будет ли заказчик отслеживать ход выполнения проекта	Нет	Нет	Да	Да	Нет	Нет

 

Приложение Е - Диаграмма Ганта