Проектирование, разработка и внедрение информационной системы, предназначенной для автоматизации документооборота и учета по приему аварийных автомобилей и составлению заказ-нарядов. Взаимодействие приложения с источниками данных. Оценка стоимости ПО.
Возможности по управлению заказами покупателей рассчитаны на торговые предприятия, использующие схемы работы: - работа со склада; Пользователь может в любой момент получить актуальную информацию о текущем состоянии заказа: сколько каких товаров заказано поставщикам, сколько зарезервировано на складах, сколько осталось отгрузить, сколько оплачено заказчиком и т.п. Все этапы прохождения заказа и корректировки по нему могут фиксироваться в системе соответствующими документами, что позволяет отслеживать историю взаимоотношений с клиентами и поставщиками, оценивать эффективность и надежность работы с ними. Поддерживаются все операции, связанные с заказом, закупкой, хранением, продажей запасных частей, взаиморасчетами с покупателями и поставщиками, а также операции по ремонту автомобилей. К основным преимуществам данных систем можно отнести относительную низкую стоимость внедрения данной системы и дальнейшую технологическую поддержку, а также еще ряд преимуществ: - решение актуальных задач учета и управления.При проектировании современных информационных систем организаций их архитектура должна разрабатываться с учетом многих заинтересованных сторон, она должна быть понятной пользователям, дать возможность разработчикам сделать план и графики системы, позволять определять ключевые интерфейсы, функции и технологии, а также позволять оценить график и бюджет исполнения проекта. Файловый вариант работы с информационной базой рассчитан на персональную работу одного пользователя или работу небольшого количества пользователей в локальной сети. Исключена ситуация, когда пользователь может по ошибке (например, при копировании информационной базы) перепутать различные файлы информационной базы и привести, таким образом, систему в неработоспособное состояние. Программа, работающая у пользователя, взаимодействует с сервером 1С: Предприятия 8.0, а сервер при необходимости обращается к базе данных MS SQL Server. Чтобы создать эффективный интерфейс, который делал бы работу с программой приятной, нужно понимать, какие задачи будут решать пользователи с помощью данной программы и какие требования к интерфейсу могут возникнуть у пользователей.Техническое задание Полное название организации: ИП Кузнецов В.Г. Реквизиты организации: Ставропольский край, г.Автосервис ИП Кузнецова В.Г. осуществляет следующие виды услуг: - сервисный ремонт автомобилей; Информационная система должна учитывать все особенности работы его внутреннего документооборота, формирования первичной документации, представления и формирования отчетности. Среда должна обеспечивать уровень надежности хранения и эффективность доступа, которые соответствуют области применения информационной системы В систему будет встроен модуль, предназначенный для авторизации пользователей система должна функционировать на платформе Windows /2000/XP;Рисунок Г.1 - Печатная форма «Акт осмотра ТС»Запустить приложение Окно «Авторизация» Логин, пароль - верные Отобразилось окно авторизации. Запустить приложение Окно «Авторизация» Логин, пароль - неверные Отобразилось окно авторизации. Окно справочника «Автомобили» Отобразилось окно справочника «Автомобили» Отобразилось окно «Сведения об автомобиле». Окно «Акт Приема-передачи ТС» Отобразилось окно «Акт Приема-передачи ТС» Отобразилось окно с сообщением о невозможности проведения документа в связи с тем, что не заполнено поле сотрудника организации. Отобразилось окно «Акт Приема-передачи ТС» Отобразилось окно с сообщением о невозможности проведения документа в связи с тем, что не заполнено поле сотрудника организации.
Введение
Сфера услуг как отрасль экономической деятельности представляет собой совокупность организаций, цель которых - оказание разнообразных платных услуг по индивидуальным заказам населения. Таким образом, сфера услуг решает важнейшие социально-экономические задачи, и ее значение в жизни общества неуклонно возрастает. Одним из видов таких услуг являются услуги автосервиса.
Рассматриваемая дипломная работа написана на базе автосервиса ИП Кузнецова В.Г.
Целью дипломного проекта является создание и внедрение модуля информационной системы для автоматизации учета приема аварийных автомобилей и реализации б\у запчастей.
Программа должна обеспечивать: - работу с входными данными (полная информация о поступившем автомобиле, перечень доступных запчастей);
- получение выходных документов (накладная, счет-фактура, заказ-наряд и другие);
- формирование отчетов (получение данных на бумажных носителях об операциях взаиморасчетов с клиентами).
Хранение всей информации в электронных базах данных позволит структурировать информацию, что даст возможность быстрого поиска необходимых данных.
В данном дипломном проекте рассмотрена деятельность автосервиса и автомагазина. Организация оказывает услуги по ремонту различных автомобилей отечественного и зарубежного производства, реализует запчасти для всех моделей автомобилей марки ВАЗ, ГАЗ, УАЗ, автохимию, автокосметику и многое другое. Осуществляет прием аварийных автомобилей с последующей продажей их по запчастям.
Все перечисленные операции требуют четкого и правильного документирования, ведения учета и отчетности. В тоже время, использование бумажных носителей, ведение рукописного учета продаж и выполненных работ, предполагает затрату большого количества времени и сил. А так же создает определенные трудности при поиске необходимых данных и их анализе. Поэтому необходима информационная система автоматизации деятельности магазина и автосервиса, создание базы данных, где будет храниться вся информация о товарообороте, выполненных работах, принятых автомобилях, а так же иная необходимая информация, связанная с деятельностью организации. Разработать удобные для работы формы, приятный интерфейс. Все это поможет сократить время составления заказ-нарядов, накладных, отчетов по складу и прочих документов. Позволит хранить информацию о поставщиках, клиентах, принятых автомобилях в базе данных, структурировать ее в более удобный вид, что значительно повысит эффективность работы.
Предлагаемая программа реализует информационную справочную систему, предназначенную для организации: - учета распределения работ по отделам и работникам;
Данная информационная система может применяться в автосервисах и магазинах реализующих автозапчасти. Она легка в обращении, позволяет хранить большое количество сведений в одной базе данных, экономит рабочее время за счет автоматизации некоторых рутинных операций. Таким образом, система позволит повысить производительность труда, помогая выполнить работу лучше, быстрее и дешевле.
1. Разработка требований к программному обеспечению
1.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С:Предприятия» и набор их функции динамично развиваются вместе с изменением типовых потребностей отечественных предприятий и организаций;
- высокий уровень безопасности системы, что подразумевает не только контроль доступности тех или иных ресурсов системы и защищенность информации на всех этапах функционирования, но и отслеживание выполняемых действий с высокой степенью достоверности.
Все вышеперечисленные преимущества подтолкнули к выбору данной платформы, для разработки приложения.
1.2 Анализ предметной области
Автосервис выполняет весь спектр работ, связанных с ремонтом и техническим обслуживанием отечественных и зарубежных автомобилей.
Процесс технического обслуживания автомобилей представляет собой совокупность выполняемых в рациональной последовательности технологических операций, набор которых определяется как техническим состоянием автомобиля, так и желанием и возможностями заказчика.
Как правило, первым этапом является мойка автомобиля, чистка его основных агрегатов и узлов и последующее диагностирование. Предполагается применение различных методов диагностирования - от визуальных, применения специальных передвижных приборов и стендов, до компьютерной диагностики (в том числе геометрии подвески, двигателей, схода-развала).
Применение средств автоматизации предполагается также на этапе мойки - сервис-центр оснащен автоматической мойкой, для легковых автомобилей, укомплектованной большим количеством приспособлений, в том числе системой очистки и рециркуляции воды.
К основному подъемно-смотровому оборудованию и сооружениям относятся осмотровые канавы, эстакады и подъемники, а к вспомогательному домкраты, гаражные опрокидыватели и т.п. На ремонтном участке оборудован специализированный пост для замены смазочного материала в агрегатах автомобилей и дозаправки его охлаждающей жидкостью и воздухом. В процессе замены используются ГСМ фирмы «Мобил», стоимость которых соответствует официальным прейскурантам этой фирмы для дилеров и авторизованных сервисных станций.
При замене агрегатов и сборке автомобилей для облегчения труда и повышения производительности применяют различные средства механизации сборочных работ. Сборка должна производиться на специальных стендах или приспособлениях, обеспечивающих устойчивое положение собираемого изделия или его сборочной единицы.
Для устранения механических повреждений деталей (трещин, отколов, пробоин и т.п.) планируется применение сварочных работ. Автосервис располагает всем необходимым оборудованием для проведения кузовного ремонта. Производит любые арматурные, кузовные и окрасочные работы на автомобилях ВАЗ и других отечественных автомобилях. Сертифицированные специалисты имеют большой опыт в восстановлении машин, попавших в аварию, включая полное восстановление авто после аварии. На все выполненные работы по кузовному ремонту и покраске предоставляется гарантия 6 месяцев.
Организация производит полный комплекс работ, связанных с прохождением ТО и ремонтом автомобилей. Осуществляют разборку и дефектовку узлов и агрегатов автомобиля, их замену, диагностику блоков электронного управления и электрооборудования автомобиля, промывку топливной системы.
Специалисты автосервиса помогут клиенту выбрать те работы, которые следует провести с автомобилем, порекомендуют и предложат качественные расходные материалы именно для вашего автомобиля, выполнят работы в строгом соответствии с регламентом производителя.
При ремонте автомобилей помимо оригинальных запчастей и расходных материалов могут быть использованы ничем не уступающие неоригинальные запасные части от известных производителей, выбранных нами путем опытного анализа, на которые дается гарантия.
На территории автосервиса находиться магазин автозапчастей, в котором представлен широкий ассортимент запчастей для автомобилей ВАЗ и других отечественных автомобилей.
Магазин работает без перерывов и выходных. В среднем за день магазин принимает 80-100 клиентов, в том числе и тех которые в данный момент обслуживаются в автосервисе. Обслуживание одного клиента занимает порядка 5-10 минут.
Организация осуществляет прием аварийных автомобилей для дальнейшей реализации по запчастям. Продажа производиться как отдельными деталями, так и целыми блоками, например, двигатель в сборе или коробка передач. По желанию клиента детали могут быть установлены непосредственно в автосервисе.
Ниже представлены IDEF диаграммы бизнес-процессов протекающих в данной организации (Рисунки 1.1, 1.2, 1.3).
Рисунок 1.1 - Общая модель функционирования автосервиса
Рисунок 1.2 - Декомпозиция общей модели
Процесс принятия аварийных авто проходит в три этапа. На первом происходит первичный осмотр автомобиля, оценка повреждений с последующим утверждением его стоимости и, наконец, подготовка необходимого пакета документов для покупки автомобиля. Документы готовятся либо владельцем авто, либо самой организацией, в зависимости от договоренности сторон.
Документы необходимые для приема автомобиля: - паспорт транспортного средства (ПТС);
- свидетельство о регистрации автомобиля (если автомобиль не снят с учета);
- генеральную доверенность (если не являетесь собственником автомобиля) сроком действия не менее 4 месяцев;
- паспорт владельца автомобиля.
На втором этапе, после окончательной покупки автомобиля организацией, слесари автосервиса производят разбор автомобиля на составляющие части. Наконец, на третьем этапе все детали и агрегаты подлежат проверке качества, после чего отправляются на склад.
Рисунок 1.3 - Диаграмма процесса приема аварийных автомобилей
1.3 Сбор требований
Сбор требований является важной частью в разработке и внедрении автоматизированной информационной системы. Здесь разрабатываются необходимые требования, функции, особенности внедряемой автоматизированной информационной системы. Лучше всего это выяснять у того, кто будет непосредственной работать с новой программой. Так как я буду разрабатывать АИС на платформе 1С:Предприятие 8.0, то необходимо консультироваться с бухгалтером организации. В результате, я выяснил, что в программе должны быть реализованы: - учет поступления товаров;
- перечень выполняемых работ;
- перемещение, списание, реализация товаров;
- учет наличия товаров на складе;
- учет возврата товара поставщикам;
- учет заработной платы;
- ведение бухгалтерии;
- хранение данных о принятых автомобилях;
- учет наличия б\у запчастей.
Также программа должна уметь вести полный документооборот предприятия, вести учет оказанных услуг, возможность расчета остатков и движения товаров и т.д.
Так же программа должна содержать большое количество отчетов, необходимых для контроля деятельности автосервиса: - Складские отчеты;
- Анализ продаж;
- Наряд-заказ;
- Кассовые операции.
Программа должна будет выполнять все функции учета реализации: от ввода первичных документов до получения различных ведомостей и аналитических отчетов по реализации товара и услуг.
В процессе сбора требований к проектируемой системе составляется документ об образе и границах проекта (Приложение А).
Документ об образе и границах (vision and scope document) собирает бизнес - требования в единый документ, который подготавливает основу для последующей разработки проекта.
1.4 Анализ и моделирование требований
После того, как были определены и собраны требования для реализации программного модуля, спроектированы DFD диаграммы бизнес-процессов приема автомобилей и выписки документа «Заказ-наряд», представленные на рисунке 1.4 и 1.5.
Рисунок 1.4 - DFD диаграмма процесса приема аварийных автомобилей
Рисунок 1.5 - DFD диаграмма процесса составления Заказ-наряда
В ходе анализа требований были выявлены следующие действующие лица: - бухгалтер;
- продавцы;
- старший механик.
Создаваемая подсистема будет предназначена для автоматизации ведения документооборота и финансовой отчетности автосервиса и автомагазина и предусматривает для каждого выявленного пользователя системы набор функций, представленных в таблице 1.
Таблица 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 Система должна обеспечивать сохранность данных.
Важнейшим документом на данном этапе, проектирования является спецификация требований к программному обеспечению.
Спецификация требований является основным документом, определяющим требования и порядок создания ИС. Данный документ должен содержать состав и наименование комплексов задач, требования по изменению организационной структуры, состав обеспечивающих подсистем.
1.6 Аттестация требований
Аттестация должна продемонстрировать, что требования действительно определяют ту систему, которую хочет иметь заказчик. Проверка требований важна, так как ошибки в спецификации требований могут привести к переделке системы и большим затратам, если будут обнаружены во время разработки системы или после введения ее в эксплуатацию.
Для аттестации требований будет использован метод прототипирования. В этом случае конечным пользователям и заказчику демонстрируется некий прототип системы.
Прототип главного меню представлен на рисунке 1.6.
Рисунок 1.6 - Прототип главного меню
1.7 Выбор методологии проектирования информационной системы
Существует две базовых методологии проектирования информационных систем: структурный и объектно-ориентированный анализ.
Сущность структурного подхода к разработке информационной системы заключается в ее декомпозиции на автоматизируемые функции: система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее. Процесс разбиения продолжается вплоть до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. При разработке системы «снизу-вверх» от отдельных задач ко всей системе целостность теряется, возникают проблемы при информационной стыковке отдельных компонентов.
Все наиболее распространенные методологии структурного подхода базируются на ряде общих принципов. В качестве двух базовых принципов используются следующие: 1. принцип «разделяй и властвуй» - принцип решения сложных проблем путем их разбиения на множество меньших независимых задач, легких для понимания и решения;
2. принцип иерархического упорядочивания - принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.
Использование объектно-ориентированных методов позволяет создать описание (модель) предметной области в виде совокупности объектов - сущностей, объединяющих данные и методы обработки этих данных (процедуры). Каждый объект обладает своим собственным поведением и моделирует некоторый объект реального мира. С этой точки зрения объект является вполне осязаемой вещью, которая демонстрирует определенное поведение.
В объектном подходе акцент переносится на конкретные характеристики физической или абстрактной системы, являющейся предметом программного моделирования. Объекты обладают целостностью, которая не может быть нарушена. Таким образом, свойства, характеризующие объект и его поведение, остаются неизменными. Объект может только менять состояние, управляться или становиться в определенное отношение к другим объектам.
Наиболее подходящей методологией проектирования ИС является структурная.
Вывод
В данном разделе дипломного проекта проведен анализ предметной области, в результате которого показано, что для информационной системы достаточно важными являются задачи взаимодействия с клиентами, планирования ассортимента товара. Проанализированы организационная структура и основные бизнес-процессы организации. Бизнес-процессы формализованны с использованием нотаций IDEF0, что позволило выявить основные функциональные задачи, подлежащие автоматизации при создании информационной системы. Проведенные исследования позволили сформулировать требования к разрабатываемой системе, которые были согласованы с заказчиками, конечными пользователями и разработчиками информационной системы. автоматизация документооборот данные заказ
2. Управление информационным проектом
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. При обращении к той или иной информационной базе пользователь должен указать только имя сервера и имя информационной базы, а система запрашивает соответственно имя и пароль пользователя.
1С: Предприятие 8.0 использует возможности MS SQL Server для эффективной выборки информации: - механизм запросов ориентирован на максимальное использование MS SQL Server для выполнения расчетов и составления отчетов;
- просмотр больших динамических списков обеспечивается без выполнения большого количества обращений к базе данных; при этом пользователю предоставляются возможности эффективного поиска, а также настройки отбора и сортировки.
Для разработки данной программы выбран файловый вариант работы, который рассчитан на персональную работу одного пользователя или работу небольшого количества пользователей в локальной сети. Пример данной архитектуры представлен на рисунке 2.3.
Рисунок 2.3 - Архитектура «Файл-сервер»
Выбор данной архитектурной модели обуславливается тем, что проектируемая система работает с небольшими объемами информации, а также при использовании данной модели нет необходимости в приобретении дополнительных программных продуктов для управления базами данных, что приводит к снижению бюджета внедрения ИС.
2.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].
2.4 Обоснование выбора платформы создания информационной системы
В качестве платформы для разработки системы была выбрана «1С: Предприятие 8».
Состав прикладных механизмов «1С: Предприятия» ориентирован на решение задач автоматизации учета и управления предприятием. В «1С: Предприятие 8» реализован современный эргономичный интерфейс, за счет чего повышена комфортность работы пользователей при работе с системой в течение длительного времени.
Система «1С: Предприятие 8» является открытой системой. Предоставляется возможность для интеграции практически с любыми внешними программами и оборудованием на основе общепризнанных открытых стандартов и протоколов передачи данных.
Система прав доступа позволяет разрешать доступ пользователей только к тем данным, которые необходимы им для выполнения определенных функций в прикладном решении.
Мощные средства формирования отчетов и печатных форм обеспечивают широкие возможности оформления и интерактивной работы.
Технологическая платформа «1С: Предприятие 8» обеспечивает различные варианты работы прикладного решения: от персонального однопользовательского, до работы в масштабах больших рабочих групп и предприятий. Ключевым моментом масштабируемости является то, что повышение производительности достигается средствами платформы, и прикладные решения не требуют доработки при увеличении количества одновременно работающих пользователей. Единая технологическая платформа, лежащая в основе системы программ «1С: Предприятие 8.0», является фундаментом для построения всех прикладных решений. Наличие единой технологической платформы не просто облегчает создание отдельных прикладных решений и обеспечивает их невысокую стоимость. Главное преимущество такого подхода - стандартизация разработки, обеспечение масштабируемости и обеспечение быстрого внедрения современных технологий во всех прикладных решениях.
Наличие единой платформы и общей методологии позволяет создавать специализированные и индивидуальные решения на базе стандартных, добавляя в них только необходимые отличия, учитывающие специфику отрасли или конкретного предприятия.
С экономической точки зрения это позволяет обеспечить достаточно низкую стоимость отраслевых и индивидуальных решений, так как затраты на их создание существенно ниже, чем затраты на разработку программы с нуля. Это обеспечивает высокую скорость создания и внедрения решений, так как максимально используется отработанная функциональность и методология, содержащиеся в типовых решениях.
Очень важным преимуществом такого подхода является унификация обучения пользователей. Например, обучившись на курсах по «1С: Предприятию 8.0» или имея опыт работы с какой либо из программ, пользователь достаточно быстро осваивает возможности специализированных или индивидуальных решений [34, 38, 39].
2.5 Проектирование модулей
Программные модули в конфигурации системы «1С: Предприятие» не являются самостоятельными программами в общепринятом понимании этого слова, поскольку они являются только частью всей конфигурации задачи. Программный модуль - это своего рода «контейнер» для размещения текстов процедур и функций, вызываемых системой во время исполнения задачи в определенные моменты работы. Поэтому программный модуль не имеет формальных границ своего описания типа: «Начало модуля» - «Конец модуля».
Место размещения конкретного программного модуля предоставляется конфигуратором в тех точках конфигурации задачи, которые требуют описания специфических алгоритмов функционирования. Эти алгоритмы следует оформлять в виде процедур или функций, которые будут вызваны самой системой в заранее предусмотренных ситуациях (например, при нажатии кнопки в диалоговом окне). Каждый отдельный программный модуль воспринимается системой как единое целое, поэтому все процедуры и функции программного модуля выполняются в едином контексте.
Каждый программный модуль связан с остальной частью конфигурации задачи. Эта связь называется контекстом выполнения модуля. Следует различать два вида контекста: - глобальный контекст задачи;
- локальный контекст выполнения конкретного модуля.
Глобальный контекст виден всем программным модулям и определяет общую языковую среду конфигурации.
Локальный контекст модуля образуется тем конкретным местом конфигурации задачи, для которого использован программный модуль. Локальный контекст виден только конкретному программному модулю и определяет для модуля набор непосредственно доступных модулю значений агрегатных типов данных, их атрибутов и методов. Однако контекст модуля можно передать как объект в виде параметра при вызове процедур и функций. Кроме того, контекст модуля определяет тот набор методов, которые доступны только в данном контексте. Локальный контекст предназначен для того, чтобы дать возможность управлять частными аспектами поведения задачи, присущими данному модулю [34].
Различают следующие виды программных модулей: - общие модули;
- модуль приложения;
- модуль внешнего соединения;
- модули прикладных объектов;
- модули форм.
Общие модули принадлежат всей конфигурации в целом, но в отличие от модуля приложения их может быть несколько, например, модули РАСЧЕТНАЛОГОВ, ОБРАБОТКАДОКУМЕНТОВ. Общие модули не могут содержать объявлений переменных, и в них нет раздела основной программы, таким образом, они состоят только из процедур и функций.
Модуль приложения относится ко всей конфигурации в целом и может быть только один. Модуль приложения является аналогом глобального модуля в версии 7.7. Он отвечает за пользовательскую сессию (сеанс) работы с 1С:Предприятием 8.0.
Модуль внешнего соединения в конфигурации может быть только один. Если конфигурация запускается не в режиме клиентской сессии, а через СОМ-соединение, то вместо модуля приложения используется модуль внешнего соединения.
Модули прикладных объектов - у некоторых прикладных объектов конфигурации могут быть собственные модули, например, модуль документа РАСХОДНАЯНАКЛАДНАЯ, модуль справочника Номенклатура. Не следует их путать с модулями форм этих объектов.
У каждой формы есть модуль, в котором определяется поведение формы и действия, выполняемые из нее, например, открытие других форм.
При создании информационной системы автоматизации складского учета и учета выполненных работ в автосервисе, были спроектированы, включая системные предопределенные, программные модули, приведенные ниже [36].
Справочники
Данный раздел описывает назначение и использование справочников Конфигурации. Подробно описывает заполнение справочников. Описание справочников содержит функциональное описание, то есть, для каких целей служит данный справочник, какую информацию и как в нем необходимо заполнить, а также назначение и порядок заполнения полей. Раздел состоит из следующих частей: - справочник СКЛАДЫ;
- справочник НОМЕНКЛАТУРА;
- справочник КОНТРАГЕНТЫ;
- справочник АВТОМОБИЛИ КЛИЕНТОВ.
Список литературы
Данный раздел описывает оформление и использование документов Конфигурации: последовательность заполнения документа, правила работы с его товарным составом, действия с документами. По каждому виду документов приводится функциональное назначение документа, какие документы можно выписать на основании данного и, обратно, на основании каких документов он может быть выписан. В разделе описаны следующие документы: - заказ-наряд;
- расходная накладная;
- приходная накладная;
- акт приема-передачи автомобиля.
Отчеты
Данный раздел описывает назначение и использование отчетов Конфигурации, настройки перед выводом отчетов. Для каждого отчета описано, что выводится в конкретных графах и строках отчета. В разделе описаны следующие отчеты: - отчет Заказ-наряды;
- отчет Остатки товаров;
- отчет Продажи.
Выводы к разделу
В данном разделе было рассмотрено логическое представление проектируемой информационной системы, были построены диаграммы последовательности действий в системе. Была спроектирована база данных. Все перечисленные действия были необходимы для реализации информационной системы, таким образом, чтоб система удовлетворяла всем требованиям заказчика. Для разрабатываемой информационной системы была выбрана платформа «1С: Предприятие 8.0.»
3. Реализация и аттестация информационной системы
3.1 Реализация приложения
На данном этапе происходит реализация приложений. Этот этап создания ИС является наиболее сложным и трудоемким для разработчика. Это происходит изза того, что на этом этапе должны быть реализованы в полном объеме все требования предъявляемые заказчиком к разрабатываемой системе. Эти требования должны быть четко и в нужной форме отображены в разрабатываемой системе. Иначе, если этого не произойдет, придется процесс реализации выполнять заново. Каждый разработчик должен выбрать для себя оптимальную среду для разработки системы, но следует заметить, что при реализации приложения никак не обойтись без написания программного кода. Именно при написании программного кода, будут реализовываться некие функции, которые должна выполнять система. В зависимости от выбранной среды реализации системы, программный код будет выглядеть по-разному.
Основная цель создания ИС - это автоматизация документооборота по приему аварийных автомобилей и составление заказ-нарядов на выполнение работ в автосервисе. Платформой для разработки ИС выбрана «1С: Предприятие 8.0». Все объекты, используемые при проектировании ИС в «1С: Предприятии» описаны в конфигураторе.
Ниже на рисунке 3.1 представлено окно конфигурации с созданными документами.
Рисунок 3.1 - Окно конфигурации с созданными документами
Для составления Акта принятия-передачи транспортного средства необходимо открыть форму документа «Акт приема передачи ТС». В появившемся окне следует заполнить все обязательные поля, они выделены красным подчеркиванием. В табличной части «Опции\оборудование» можно составить список опций автомобиля, его комплектацию. На вкладке «Перечень повреждений», кратко описываются повреждения автомобиля и возможные неисправности. Если продавец не является владельцем автомобиля, а продает его по генеральной доверенности, то устанавливаем флажок «Генеральная доверенность» и заполняем поле «Владелец автомобиля». При нажатии кнопки «Печать» появляется возможность выбора выходных форм документа, непосредственно акт приема-передачи автомобиля и акт его осмотра. Примеры печатных форм представлены в приложении Г, пример формы документа - рисунок 3.2.
Рисунок 3.2 - Форма документа «Акт приема передачи ТС»
Данные об автомобилях хранятся в справочнике «Автомобили», поэтому для заполнения данных о принятом автомобиле, в первую очередь, необходимо создать новую запись в справочнике и заполнить основные поля. Сведения об автомобиле автоматически будут отображены на форме документа.
Пример форм справочника «Автомобили» изображен на рисунке 3.3.
Рисунок 3.3 - Формы справочника «Автомобили»
Документ «Заказ-наряд» заполняется аналогично предыдущему документу, за исключением табличной части. Данный документ содержит две табличные части «Товар» и «Услуги». Порядок их заполнения одинаков, сначала производится выбор товара или услуги из справочника «Номенклатура», затем указываем необходимое количество. Цена и общая сумма рассчитываются автоматически при изменении номенклатуры и количества товара. В поле «Причина обращения» дается краткое описание неисправности, с которой обратился клиент. Данные об автомобиле клиента, также хранятся в справочнике «Автомобили» и при выборе автоматически заполняются поля отображающие сведения об автомобиле на форме документа «Заказ-наряд». Пример формы документа «Заказ-Наряд» приведен на рисунке 3.4.
Рисунок 3.4 - Формы документа «Заказ-Наряд»
При нажатии кнопки «ОК» или «Записать» происходит проведение документа по нескольким регистрам накопления сведений. Кнопка «Печать» осуществляет построение печатных форм «Заказ-наряд» и «Акт выполненных работ». Примеры печатных форм приведены в приложении Б, а исходный код формы документа в приложении В.
3.2 Взаимодействие приложения с источниками данных
Встроенные средства «1С: Предприятие 8.0» позволяют создавать и управлять базами данных, построенных на основе конфигурации, при этом, весь этот процесс полностью скрыт от разработчика, поэтому нет возможности описать используемую модель взаимодействия приложения с БД. Весь механизм обмена данными приложения с БД построен на запросах.
Для работы с запросами, в «1С: Предприятие 8» использует объект встроенного языка «Запрос», фрагмент запроса приведен на рисунке 3.6.
Рисунок 3.6 - Пример запроса
Он позволяет получать информацию, хранящуюся в полях базы данных, в виде выборки, сформированной по заданным правилам. Исходную информацию запрос получает из набора таблиц. Эти таблицы представляют данные реальных таблиц базы данных в удобном для анализа виде. Их можно разделить на две большие группы: реальные и виртуальные. Реальные таблицы, в свою очередь, могут быть объектными (ссылочными) или не объектными (не ссылочными). Отличительной особенностью реальных таблиц является то, что они содержат данные какой-либо одной реальной таблицы, хранящейся в базе данных. Виртуальные таблицы формируются, в основном, из данных нескольких таблиц базы данных.
Алгоритм, по которому данные выбираются из исходных таблиц запроса, описывается в тексте запроса на специальном языке - языке запросов. Текст запроса состоит из нескольких частей: - описание запроса;
- объединение запросов;
- упорядочивание результатов;
- автоупорядочивание;
- описание итогов.
Обязательной частью запроса является только первая - описание запроса. Все остальные присутствуют по необходимости.
Описание запроса определяет источники данных, поля выборки, группировки и т.д. Объединение запросов определяет, как будут объединены результаты выполнения нескольких запросов.
Упорядочивание результатов определяет условия упорядочивания строк результата запроса.
Автоупорядочивание позволяет включить режим автоматического упорядочивания строк результата запроса.
Описание итогов определяет, какие итоги необходимо рассчитывать в запросе и каким образом группировать результат.
Таблица значений - это двумерный массив в 1С, который предназначен для хранения и обработки промежуточных данных, возникающих в процессе работы программы. Таблица значений часто применяется при программировании на 1С, потому что имеет множество полезных возможностей и работает очень быстро. Список значений - это аналог одномерного массива в 1С, который предназначен для хранения и обработки промежуточных данных. Список значений может быть наполнен значениями любого типа, то есть, в одном списке типы хранимых данных могут быть разными. Одним из примеров использования данного объекта может служить организация выбора конкретного документа из списка возможных документов, сформированного по сложному алгоритму.
3.3 Тестирование приложения
Тестирование - процесс выполнения программы с целью обнаружения ошибок. Тестирование обеспечивает: - обнаружение ошибок;
- демонстрацию соответствия функций программы ее назначению;
- демонстрацию реализации требований к характеристикам программы;
- отображение надежности как индикатора качества программы.
Процесс тестирования программного обеспечения осуществляется на основе фактических или смоделированных входных данных (как стандартных, так и не стандартных) при определенных контролируемых условиях, другими словами, производится проверка работы программ с данными, подобным реальным, которые будут обрабатываться в процессе эксплуатации системы.
Существуют 2 принципа тестирования программы: функциональное тестирование (тестирование «черного ящика»);
При тестировании методом «белого ящика» известна внутренняя структура программы. Объектом тестирования здесь является не внешнее, а внутреннее поведение программы. Проверяется корректность построения всех элементов программы и правильность их взаимодействия друг с другом.
Тестирование «черного ящика» (функциональное тестирование) позволяет получить комбинации входных данных, обеспечивающих полную проверку всех функциональных требований к программе. Программное изделие здесь рассматривается как «черный ящик», чье поведение можно определить только исследованием его входов и соответствующих выходов.
Принцип «черного ящика» не альтернативен принципу «белого ящика». Скорее это дополняющий подход, который обнаруживает другой класс ошибок.
Тестирование «черного ящика» обеспечивает поиск следующих категорий ошибок: - некорректных или отсутствующих функций;
- ошибок интерфейса;
- ошибок во внешних структурах данных или в доступе к внешней базе данных;
- ошибок характеристик (необходимая емкость памяти и т. д.);
- шибок инициализации и завершения.
Подобные категории ошибок способами «белого ящика» не выявляются. В отличие от тестирования «белого ящика», которое выполняется на ранней стадии процесса тестирования, тестирование «черного ящика» применяют на поздних стадиях тестирования. При тестировании «черного ящика» пренебрегают управляющей структурой программы. Здесь внимание концентрируется на информационной области определения программной системы. При тестировании на этом этапе основное внимание уделяется пригодности решения для работы в условиях живого производства. Основное внимание уделяется исправлению ошибок и определению их важности, а также подготовки продукта к выпуску.
Тестирование ИС проводилось функциональным методом «черного ящика».
Этот тип тестирования основан на тестировании путем взаимодействия с приложением через графический интерфейс пользователя и анализа выводимых результатов. Метод предполагает обработку системы как «неизвестного объекта», таким образом, знание внутренней структуры в явном виде не используется. Тестирование этим методом обычно подразумевает проверку функциональных возможностей. При таком тестировании тестировщик знает только набор вводимых параметров и ожидаемые на выходе результаты, каким образом программа достигает этих результатов, ему не известно. Тестировщик никогда не проверяет программный код и не нуждается в дополнительном знании программы, кроме как ее технического описания. [5]
Целью тестирования является проверка правильности навигации, ввода, обработки и вывода данных. Метод заключается в выполнении каждого варианта использования, используя верные и неверные данные, чтобы проверить следующее: - при использовании верных данных имеет место ожидаемый результат или сообщение об успехе;
- при использовании неверных данных отображается соответствующее предупреждение/сообщение об ошибке.
Рассмотрим работу документа «Акт приема-передачи ТС».
При корректном заполнении реквизитов документа (Рисунок 3.7) нажатие на кнопку ОК позволяет записать и провести документ. А по кнопке выбора формы для печати выводится печатная форма акта (Рисунок 3.8).
В случае выполнения заведомо ошибочных действий с документом, например, попытка записать и провести документ по кнопке ОК, если не заполнены требуемые реквизиты по документу, будет высвечено предупреждение об ошибке с указанием не заполненного поля и проведение документа выполнено не будет. Пример окна формы с ошибкой заполнения приведен на рисунке 3.9.
Рисунок 3.9 - Сообщение об ошибке при заполнении документа
3.4 Методика развертывания приложения
На этом этапе разработчик (или команда) развертывает необходимые для решения технологии и компоненты, проект переходит на стадию сопровождения и поддержки, а заказчик окончательно утверждает его. После развертывания команда проводит оценку проекта и опрос пользователей, чтобы выяснить степень их удовлетворенности.
Цели этапа развертывания: - перенести решение в промышленную среду;
- признание заказчиком факта завершения проекта.
Развертывание компонентов, характерных для конкретного места установки, состоит из нескольких стадий: подготовки, установки, обучения и формального одобрения. Результатами этапа развертывания системы являются системы сопровождения и поддержки, хранилище документов, где размещаются все версии документов и кода, разработанных в течение проекта. Для развертывания разрабатываемой системы был составлен план действий, который приведен в таблице 2.
Таблица 3.1 - План развертывания приложения
Действие Описание действия
1. Резервное копирование Производится резервное копирование данных пользователя при его участии и согласовании путем переноса информации на сменные носители (CD, DVD)
2. Установка базовых компонентов решения Применение технологий, обеспечивающих работу решения.
3. Установка клиентского приложения Перенос на компьютер пользователя и установка окончательного варианта разработанной ИС и базы данных
4. Обучение Производится обучение пользователей по работе с системой, разработчик убеждается в правильности и понимании работы ИС клиентами
5. Передача базы знаний проекта клиенту Заказчику передается вся проектная документация
6. Закрытие проекта Составляется отчет о закрытии проекта. Заказчик подписывает акт приемки.
Выводы к разделу
В данном разделе дипломного проекта рассмотрены реализация информационной системы, приведены фрагменты программного кода. Реализованы функции и процедуры взаимодействия с базой данных. Описаны способы нахождения ошибок в приложении, также описаны методики тестирования, которые использовались при тестировании приложения, и развертывания приложения.
4. Управление информационным проектом
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).
Rapid Application Development (RAD) - это жизненный цикл процесса проектирования, созданный для достижения более высокой скорости разработки и качества ПО, чем это возможно при традиционном подходе к проектированию.
RAD предполагает, что разработка ПО осуществляется небольшой командой разработчиков за срок порядка трех-четырех месяцев путем использования инкрементного прототипирования с применением инструментальных средств визуального моделирования и разработки. Технология RAD предусматривает активное привлечение заказчика уже на ранних стадиях - обследование организации, выработка требований к системе. Причины популярности RAD вытекают из тех преимуществ, которые обеспечивает эта технология (рисунок 4.1).
Рисунок 4.1 - RAD технология
Наиболее существенными из них являются: - высокая скорость разработки;
- низкая стоимость;
- высокое качество.
Последнее из указанных свойств подразумевает полное выполнение требований заказчика как функциональных, так и нефункциональных, с учетом их возможных изменений в период разработки системы, а также получение качественной документации, обеспечивающей удобство эксплуатации и сопровождения системы. Это означает, что дополнительные затраты на сопровождение сразу после поставки будут значительно меньше. Таким образом, полное время от начала разработки до получения приемлемого продукта при использовании этого метода значительно сокращается.
Применение технологии RAD целесообразно, когда: - требуется выполнение проекта в сжатые сроки. Быстрое выполнение проекта позволяет создать систему, отвечающую требованиям сегодняшнего дня.
- нечетко определены требования к ПО. В большинстве случаев заказчик весьма приблизительно представляет себе работу будущего программного продукта и не может четко сформулировать все требования к ПО. Требования могут быть вообще не определены к началу проекта либо могут изменяться по ходу его выполнения.
- проект выполняется в условиях ограниченности бюджета. Разработка ведется небольшими RAD группами в короткие сроки, что обеспечивает минимум трудозатрат и позволяет вписаться в бюджетные ограничения.
- интерфейс пользователя (GUI) есть главный фактор. Нет смысла заставлять пользователя рисовать картинки. RAD технология дает возможность продемонстрировать интерфейс в прототипе, причем достаточно скоро после начала проекта.
- проект большой, но поддается разделению на более мелкие функциональные компоненты. Если предполагаемая система велика, необходимо, чтобы ее можно было разбить на мелкие части, каждая из которых обладает четкой функциональностью. Они могут выпускаться последовательно или параллельно (в последнем случае привлекается несколько RAD групп).
- ПО не обладает большой вычислительной сложностью.
Жизненный цикл ПО по методологии RAD состоит из четырех фаз: - фаза анализа и планирования требований;
- фаза проектирования;
- фаза построения;
- фаза внедрения.
На фазе анализа и планирования требований пользователи системы определяют функции, которые она должна выполнять, выделяют наиболее приоритетные из них, требующие проработки в первую очередь, описывают информационные потребности. Определение требований выполняется в основном силами пользователей под руководством специалистов-разработчиков. Ограничивается масштаб проекта, определяются временные рамки для каждой из последующих фаз. Кроме того, определяется сама возможность реализации данного проекта в установленных рамках финансирования, на данных аппаратных средствах и т.п. Результатом данной фазы должны быть список и приоритетность функций будущей ИС, предварительные функциональные и информационные модели ИС.
На фазе проектирования часть пользователей принимает участие в техническом проектировании системы под руководством специалистов-разработчиков. CASE-средства используются для быстрого получения работающих прототипов приложений. Пользователи, непосредственно взаимодействуя с ними, уточняют и дополняют требования к системе, которые не были выявлены на предыдущей фазе. Более подробно рассматриваются процессы системы. Анализируется и, при необходимости, корректируется функциональная модель. Каждый процесс рассматривается детально. При необходимости для каждого элементарного процесса создается частичный прототип: экран, диалог, отчет, устраняющий неясности или неоднозначности. Определяются требования разграничения доступа к данным. На этой же фазе происходит определение набора необходимой документации. После детального определения состава процессов оценивается количество функциональных элементов разрабатываемой системы и принимается решение о разделении ИС на подсистемы, поддающиеся реализации одной командой разработчиков за приемлемое для RAD-проектов время - порядка 60 - 90 дней. С использованием CASE-средств проект распределяется между различными командами (делится функциональная модель). Результатом данной фазы должны быть: - общая информационная модель системы;
- функциональные модели системы в целом и подсистем, реализуемых отдельными командами разработчиков;
- точно определенные с помощью CASE-средства интерфейсы между автономно разрабатываемыми подсистемами;
Все модели и прототипы должны быть получены с применением тех CASE-средств, которые будут использоваться в дальнейшем при построении системы. Данное требование вызвано тем, что в традиционном подходе при передаче информации о проекте с этапа на этап может произойти фактически неконтролируемое искажение данных. Применение единой среды хранения информации о проекте позволяет избежать этой опасности.
В отличие от традиционного подхода, при котором использовались специфические средства прототипирования, не предназначенные для построения реальных приложений, а прототипы выбрасывались после того, как выполняли задачу устранения неясностей в проекте, в подходе RAD каждый прототип развивается в часть будущей системы. Таким образом, на следующую фазу передается более полная и полезная информация.
На фазе построения выполняется непосредственно сама быстрая разработка приложения. На данной фазе разработчики производят итеративное построение реальной системы на основе полученных в предыдущей фазе моделей, а также требований нефункционального характера. Программный код частично формируется при помощи автоматических генераторов, получающих информацию непосредственно из репозитория CASE-средств. Конечные пользователи на этой фазе оценивают получаемые результаты и вносят коррективы, если в процессе разработки система перестает удовлетворять определенным ранее требованиям. Тестирование системы осуществляется непосредственно в процессе разработки. После окончания работ каждой отдельной команды разработчиков производится постепенная интеграция данной части системы с остальными, формируется полный программный код, выполняется тестирование совместной работы данной части приложения с остальными, а затем тестирование системы в целом. Завершается физическое проектирование системы: - определяется необходимость распределения данных;
- производится анализ использования данных;
- производится физическое проектирование базы данных;
- определяются требования к аппаратным ресурсам;
- определяются способы увеличения производительности;
- завершается разработка документации проекта.
Результатом фазы является готовая система, удовлетворяющая всем согласованным требованиям.
На фазе внедрения производится обучение пользователей, организационные изменения и параллельно с внедрением новой системы осуществляется работа с существующей системой (до полного внедрения новой). Так как фаза построения достаточно непродолжительна, планирование и подготовка к внедрению должны начинаться заранее, как правило, на этапе проектирования системы. Приведенная схема разработки ИС не является абсолютной. Возможны различные варианты, зависящие, например, от начальных условий, в которых ведется разработка: разрабатывается совершенно новая система; уже было проведено обследование предприятия и существует модель его деятельности; на предприятии уже существует некоторая ИС, которая может быть использована в качестве начального прототипа или должна быть интегрирована с разрабатываемой.
4.2 Определение цели и области действия программного проекта
Цель проекта - разработка автоматизированной системы учета принятых аварийных автомобилей и формирования заказ-нарядов на выполнение работ, которая удовлетворяет всем необходимым требованиям и внедрена в автосервисе ИП Кузнецова В.Г.; она должна иметь удобный пользовательский интерфейс, обеспечивающий удобства ввода, обработки и получения необходимой информации о принимаемых автомобилях и автоматического составления заказ-нарядов.
- Общие требования, предъявляемые к автоматизированной системе, следующие: - обеспечение ввода, обработки и хранение сведений о принятых автомобилях;
- быстрота обработки информации за счет автоматизации возможных операций пользователя системы;
- формирование отчетных форм;
- формирование актов;
- расширяемость системы, то есть возможность ее доработки в случае повышения требований к автоматизированной системе;
- удобный пользовательский интерфейс.
Область действия данной информационной системы - автосервис «Автомастер» ИП Кузнецов В.Г. Операционная система Windows XP.
4.3 Создание структуры пооперационного перечня работ
Для создания уникального продукта или услуги нужно осуществить некоторую последовательность работ. Задача планирования проекта заключается в том, чтобы достаточно точно оценить сроки исполнения и стоимость этих работ. Чем точнее дана оценка, тем выше качество плана проекта. Чтобы дать точную оценку, нужно хорошо представлять состав работ проекта, то есть знать, какие именно работы нужно выполнить для получения его результата. Только после того, как составлен список проектных работ, оценивается длительность каждой из них, и выделяются ресурсы, необходимые для их выполнения. И лишь затем можно оценить стоимость и сроки исполнения каждой задачи и, в результате сложения, общую стоимость и срок проекта. Вот почему определение состава работ является первым шагом при планировании проекта. Определение состава проектных работ начинается с определения этапов (или фаз) проекта. В проекте создание системы «Автоматизация документооборота по приему аварийных автомобилей и составление заказ-нарядов на выполнение работ в автосервисе» могут быть выделены фазы: - разработка требований к программному обеспечению;
- проектирование информационной системы;
- реализация и аттестация информационной системы;
- внедрение системы.
После того как состав фаз и их результаты определены, нужно определить последовательность этих фаз относительно друг друга и крайние сроки их исполнения. Затем нужно определить, из каких работ состоят фазы, в какой последовательности исполняются эти работы и в какие крайние сроки нужно уложиться при их исполнении. Пооперационный перечень работ представлен на рисунке 4.2.
Рисунок 4.2 - Пооперационный перечень работ
4.4 Идентификация задач и действий
Все работы можно классифицировать по своим характеристикам: длительности, трудозатратам и количеству людских ресурсов. Данные параметры связаны друг с другом: трудозатраты задачи равны произведению длительности на количество людских ресурсов. Задачи в плане проекта могут быть трех типов: с фиксированными длительностью, трудозатратами и количеством ресурсов.
Для того чтобы реализовать ту или иную задачу необходимы ресурсы (человек или оборудование). Ресурсы необходимые для реализации информационной системы автоматизации рабочего места торгового представителя представлены на рисунке 4.3.
Рисунок 4.3 - Ресурсы необходимые для реализации ИС
4.5 Оценка размера и возможности повторного использования ПО
В большинстве программных проектов применяется повторное использование некоторых программных модулей. Это обычно случается там, где разработчики проекта знают о ранее созданных программных продуктах, в составе которых есть компоненты, приблизительно удовлетворяющие требованиям разрабатываемых компонентов. Эти компоненты модифицируются, в соответствии с новыми требованиями и затем включаются в состав новой системы.
Повторное использование может обеспечить прогресс на следующих направлениях: - своевременность (быстрота доведения проектов до завершения). При использовании уже существующих компонентов нужно меньше разрабатывать, а, следовательно, ПО создается быстрее;
- сокращение объема работ по сопровождению ПО. Если кто-то разработал ПО, то он же отвечает и за его последующее развитие т.к. в скором времени, возможно, пользователи внедренной информационной системы начнут просить добавления новых функциональных возможностей программного продукта;
- эффективность. Факторы, способствующие возможности повторного использования ПО, побуждают разработчиков пользоваться наилучшими алгоритмами и структурами данных, известными в их конкретной сфере деятельности. При разработке большого проекта невозможно оптимизировать все его детали. Следует стремиться к достижению наилучших решений в своей области знаний, а, в остальном, использовать профессиональные разработки.
- совместимость. Должна присутствовать гибкость программного продукта с другими системами, что существенно повысить его качество, то есть программный продукт должен легко совмещаться с другими.
- инвестирование. Создание повторно используемого ПО позволяет сберечь плоды знаний и открытий лучших разработчиков, превращая временные ресурсы в постоянные. Поэтому не нужно будет инвестировать на создание того, что было разработано ранее и может быть использовано при создании новой программы.
Платформа 1С:Предприятие, в которой разрабатывалась информационная система, все повторяемые модули (процедуры, функции и переменные) позволяет описывать в глобальном модуле конфигурации и производить многократное их использование. Это во многом ускоряет процесс разработки, снижает объем программы, а также позволяет избежать появления ошибок при повторном проектировании.
4.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)
Rk - годовые денежные поступления в течении n лет. k - количество лет на сколько рассчитан проект.
IC - стартовые инвестиции. i - ставка дисконтирования.
По расчетам данной формулы NPV = 3460 руб.
Показатель NPV является абсолютным приростом, поскольку оценивает, на сколько приведенный доход перекрывает приведенные затраты. Так как NPV > 0, то проект следует принять.
Коэффициент возврата инвестиций (ROI) рассчитывается по формуле 4.3
(4.3)
По расчетам (ROI) = 111.53%
Далее необходимо рассчитать срок окупаемости проекта по упрощенной формуле: nok = Число лет до года окупаемости (Не возмещенная стоимость на начало года окупаемости / Приток наличности в течение года окупаемости)
Таблица 4.1 - Вспомогательная таблица расчета срока окупаемости проекта
