Создание и внедрение модуля информационной системы для автоматизации учета приема аварийных автомобилей и реализации б/у запчастей

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Справочники

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

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

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

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

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

Документы

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

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

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

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

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

Отчеты

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

Рисунок 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.7 - Заполнение документа «Акт приема-передачи ТС»

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

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

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

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

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

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

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

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

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

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

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

Для развертывания разрабатываемой системы был составлен план действий, который приведен в таблице 2.

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

Действие	Описание действия
1. Резервное копирование	Производится резервное копирование данных пользователя при его участии и согласовании путем переноса информации на сменные носители (СD, 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-средств. Конечные пользователи на этой фазе оценивают получаемые результаты и вносят коррективы, если в процессе разработки система перестает удовлетворять определенным ранее требованиям. Тестирование системы осуществляется непосредственно в процессе разработки [9].

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Диаграмма Ганта представлена в Приложении Е.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(4.1)

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

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

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

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

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

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

(4.2)

R_k - годовые денежные поступления в течении n лет.

k - количество лет на сколько рассчитан проект.

IC - стартовые инвестиции.

i - ставка дисконтирования.

По расчетам данной формулы 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

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

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

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

(4.4)

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

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

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

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

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

5. Форсайт

5.1 Основы Форсайта

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

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

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

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

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

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

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

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

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

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

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

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

1. Формирование объекта В технологическом Форсайте объект определен сферой проведения Форсайта: авиастроение, нанотехнологии и т.д. В Общественно-политическом Форсайте объект конструируется специально.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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