Диплом: Автоматизация процесса управления распределением продуктов питания в ООО «Все продукты»

Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам
48
являются информация о приходе и уходе товара, выходными – отчет о статусе
точности распределения товара, а так же рекомендация по распределению
товара. Было приведено сравнение следующих СУБД: MS SQL, MySQL, Oracle
DB, PostgreSQL, по результатом которого было выбрано PostgreSQL, одна из
главных причин выбора – наименьшая цена лицензии. В качестве средства
проектирования был выбран стек технология Django и Python. Фактором
выбора является - простота поддержи на ОС Linux, отсутствие статической
типизации, а так же были определены технические характеристики серверов.
49
2. Проектная часть
2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
Модель жизненного цикла - структура, содержащая процессы, действия и
задачи, которые осуществляются в ходе разработки, функционирования и
сопровождения программного продукта в течение всей жизни системы, от
определения требований до завершения ее использования.
ГОСТ 34.601-90 распространяется на автоматизированные системы и
устанавливает стадии и этапы их создания. Кроме того, в стандарте содержится
описание содержания работ на каждом этапе. Стадии и этапы работы,
закрепленные в стандарте, в большей степени соответствуют каскадной модели
жизненного цикла.
ISO/IEC 12207:2010 стандарт на процессы и организацию жизненного
цикла. Распространяется на все виды заказного ПО. Стандарт не содержит
описания фаз, стадий этапов.
Rational Unified Process (RUP) предлагает итеративную модель
разработки, включающую четыре фазы: начало, исследование, построение и
внедрение. Каждая фаза может быть разбита на этапы, в результате которых
выпускается версия для внутреннего или внешнего использования.
Прохождение через четыре основные фазы называется циклом разработки,
каждый цикл завершается генерацией версии системы. Суть работы в рамках
RUP - это создание и сопровождение моделей, а не бумажных документов,
поэтому этот процесс привязан к использованию конкретных средств
моделирования (UML), а так же конкретной технологии проектирования и
разработки (объектно-ориентированный анализ, object-oriented analysis, OOA,
объектно-ориентированное программирование, object-oriented programming,
OOP).
50
Microsoft Solution Framework (MSF) схожа с RUP, так же включает четыре
фазы: анализ, проектирование, разработка, стабилизация, является
итерационной, предполагает использование объектно-ориентированного
моделирования. MSF в сравнении с RUP в большей степени ориентирована на
разработку бизнес-приложений.
Extreme Programming (XP). В основе методологии командная работа,
эффективная коммуникация между заказчиком и исполнителем в течение всего
проекта по разработке ИС, а разработка ведется с использованием
последовательно дорабатываемых прототипов.
Основными критериями для выбора стандарта ЖЦ будут актуальность и
современность используемых методик контроля разработки, а так же
разработка в итерационном режиме с возможностью контролировать риск и
выполнения самого проекта на неких контрольных точках, отсутствие
дополнительных требований по моделированию процесса разработки и
внедрения.
Резюмируя описание стандартов выше, итерационными из них являются 2
стандарта: MSF, RUP.
Методология Agile не подходит, хоть и является новой. Дело в том, что
данная методология делает уклон на общение, уменьшая объемы письменной
документации. Разрабатываемая ИС подразумевает её развитие, чему
противоречит методология Agile c краткой документацией.
Стандарт COBIT тоже не подходит, так как основной целью его
использования является проведения аудита и стратегического планирования ИС
и IT инфраструктуры в целом.
51
Стандарт XP тоже не подходит, так как он не содержит полноценных
этапов ЖЦ, таких как выработка концепции, планирование, разработка,
стабилизация, внедрение.
Следовательно, перед выбором остались две методологии: RUP, MSF. В
таблице 6 представлены основные показатели стандартов Жизненного цикла
ИС.
Таблица 6
Основные показатели стандартов Жизненного цикла ИС
Техно
логия
Оптимальн
ая команда
Соответствие
стандартам
Допустимые
технологии и
инструменты
Удобство
модификации и
сопровождения
RUP
10 - 40
человек
стандарты Rational
UML и продукты
Rational
Удобно
MSF
3 - 20
человек
адаптируема
любые
Удобно
XP
2 - 10
челвоек
стандарты
отсутствуют
любые
Сложно, так как
зависимость от
конкретных
участников
коллектива
Microsoft Solutions Framework является наиболее сбалансированной
технологией, ориентированной на проектные группы малых и средних
размеров. MSF не накладывает никаких ограничений на используемый
инструментарий и содержит рекомендации весьма общего характера. Однако,
эти рекомендации могут быть использованы для построения конкретного
процесса, соответствующего потребностям коллектива разработчиков.
Наш проект является небольшим, включает в себя 3 человека. Этапы
разработки и тестирования проводятся в среде разработки Python. Кроме того,
основным преимуществом MSF является итерационная модель одновременно с
уточняющими вехами (аналог каскадной модели). Таким образом, реализация
52
MSF попыталась объединить каскадную и итерационную модель разработки и
внедрения ПО.
Основываясь на описанные выше преимущества, мною был выбран
стандарт Microsoft Solution Framework как наиболее подходящий для
реализации моего проекта в силу его гибкости и удобности. Одним из главных
его преимуществ хочу отметить возможность управления одновременно и
проектом разработкой приложения и внедрением инфраструктуры. Microsoft
Solution Framework содержит в себе 4 стадии ЖЦ ИС. В идеологии Microsoft
Solution Framework команда проекта делиться на 6 участников, каждый из
которых имеет свою роль в проекте, наделён обязанностями и имеет свою зону
ответственности. Эти роли называются кластерами, за каждым из которых
может быть закреплён не один человек. Приведу список шести кластеров:
управление продуктом, управление программой, разработка, удовлетворение
потребителя, тестирование, управление выпуском. В каждой фазе, за каждым
ответственным лицом закреплены определенные задачи. Вот какие задачи
ставятся в фазе выработки концепций:
Управление продуктом - регулирует концептуальный и логический
дизайн, функциональная спецификация, сводный план и сводный
календарный график проекта.
Управление программой - формирует цели дизайна, концепцию решения,
структуру проекта.
Разработка - отвечает за оценку технологий, логический и физический
дизайн, план и календарный график разработки
Удовлетворения потребителя - рассматривает сценарии/примеры
использования, пользовательские требования, требования локализации и
общедоступности, пользовательская документация/план обучения/график
тестирования удобства эксплуатации, обучение.
53
Тестирования - формирует оценку дизайна, требования тестирования,
план и календарный график тестирования.
Управление выпуском - выполняет функции оценки дизайна,
эксплуатационные требования, план и календарный график пилотного и
окончательного внедрения. Я объединил задачи кластеров и сформировал
из них 3 ответственных лица, они же и есть команда проекта
1) Программист и системный администратор, отвечают за работу следующих
кластеров:
Управление программой,
Разработка
удовлетворение пользователей
2) Технический директор отвечает за работу следующих кластеров:
Управление продуктом
Тестирование
управление выпуском
Выходной информацией и результатами данной фазы является подбор
кандидатов и назначение наиболее подходящих из них к требуемым задачам на
исполнение двух ролей, то есть формирование команды, несмотря на то, что
она состоит всего из трех человек. В нашем проекте на данном этапе будет
определен состав и роли участников.
Следующим этапом ЖЦ ИС идёт фаза планирования. Основной её целью
является составление планов проекта. Она включает в себя подготовку
проектной группой функциональной спецификации, разработку дизайнов,
подготовку рабочих планов, оценку проектных затрат и сроков разработки
различных составляющих проекта. Результатами фазы планирования являются:
функциональная спецификация, описание возможных рисков, сводный план и
54
сводный календарный график проекта, развернутые среды разработки и
тестирования. От программиста на данном этапе требуется выбор языка
программирования, на котором будет реализовано решение, календарный план
со сроками и графикам разработки. Технический директор на данном этапе
продумывает всю архитектуру ИС, включая взаимодействие почтового сервера,
веб сервера, СУБД, работу пользователей и инженеров в будущей системе.
Следующим этапом идет фаза разработки. На фазе разработки проектная
группа фокусируется на создании компонент решения (включая как
документацию, так и программный код). Однако некоторая часть этой работы
может продолжаться также на фазе стабилизации, если такая необходимость
выявлена в процессе тестирования. Данная фаза также включает в себя
разработку инфраструктуры. Таблица 7 описывает основные задачи и сферы
ответственности каждого из ролевых кластеров проектной группы во время
фазы разработки.
Таблица 7
Ответственность участников в фазе разработки
Ролевой кластер
Фокус
Управление продуктом
Концептуальный дизайн, анализ бизнес-требований,
коммуникационный план
Управление
программой
Концептуальный и логический дизайн,
функциональная спецификация, сводный план и
сводный календарный график проекта
Разработка
Оценка технологий, логический и физический
дизайн, план и календарный график разработки
Удовлетворение
потребителя
Сценарии/примеры использования, пользовательские
требования, требования локализации и
общедоступности, пользовательская
документация/план обучения/график тестирования
удобства эксплуатации, обучение
Тестирование
Оценка дизайна, требования тестирования, план и
календарный график тестирования
55
Продолжение таблицы 7
Ролевой кластер
Фокус
Управление выпуском
Оценка дизайна, эксплуатационные
требования, план и календарный
график пилотного и окончательного
внедрения
Следует обратить внимание, что активность проектной команды на этом
этапе не ограничивается написанием разработчиками кода – все ролевые
кластеры принимают деятельное участие в создании и тестировании решения.
Результатами фазы разработки являются: исходный и работоспособный код
приложений, окончательное описание функционала разрабатываемого решения,
сценарии тестов. В нашем случае от программиста на данном этапе требуется
предоставить программу клиент для работы системного администратора и
написание полной документации к ней. От системного администратора
требуется создать работоспособную среду, описанную в предыдущем этапе.
Следующим этапом идёт фаза стабилизации. Во время фазы
стабилизации производится тестирование разработанного решения. При этом
внимание фокусируется на его эксплуатации в реалистичной модели
производственной среды. Обычно в начале фазы стабилизации скорость
выявления ошибок командой тестирования превосходит скорость, с которой
эти ошибки могут устраняться командой разработчиков. Результатами фазы
стабилизации являются: окончательная документация выпуска, материалы
поддержки решения, результаты и инструментарий тестирования, исходный и
работоспособный код приложений, проектная документация. В моём проекте
на данном этапе программистом корректируются ошибки в разрабатываемой
им программе, компилируется версия релиз и после отсутствия ошибок
выпускается окончательная сборка исполняемого кода, параллельно с этим
дополняется документация к работе с программой. В таблице 8 приведены
основные задачи и сферы ответственности каждого из ролевых кластеров
проектной группы во время фазы стабилизации.
56
Таблица 8
Ответственность участников в фазе стабилизации
Ролевой кластер
Фокус
Управление продуктом
Ожидания заказчика
Управление программой
Управление функциональной спецификацией,
мониторинг проекта, доработка планов
Разработка
Разработка программного кода и инфраструктуры,
документирование конфигураций
Удовлетворение
потребителя
Обучение, доработка плана обучения,
тестирование удобства, графический дизайн
Тестирование
Функциональное тестирование, выявление
проблем, тестирование документации, доработка
плана тестирования
Управление выпуском
Доработка планов внедрения (включая пилотное
внедрение)
Следующим этапом идет фаза внедрения. Во время этой фазы проектная
группа внедряет технологии и компоненты решения, стабилизирует внедренное
решение, передает работу персоналу поддержки и сопровождения и получает
со стороны заказчика окончательное одобрение результатов проекта. В таблице
13 приведено описание основных задач и сфер ответственности каждого из
ролевых кластеров проектной группы во время фазы внедрения. Результатами
фазы являются: информационные системы эксплуатации и поддержки, отчеты,
журналы протоколов, массивы данных и программный код, разработанный во
время проекта, отчет о завершении проекта, показатели удовлетворенности
заказчика и потребителей, описание последующих шагов. Внедрение является
общим понятием и для него существуют разные стратегии реализации, которые
напрямую зависят от срока исполнения и качества ИС, получаемой на выходе.
Существуют четыре основные стратегии внедрения системы:
«Параллельная стратегия» - когда одновременно работают старая
(ручная) и новая система, и их выходные документы сравниваются. Если
57
они согласуются длительное время, осуществляется переход на новую
систему.
«Скачок» - это резкий переход от старой системы к новой, без
дополнительных проверок и с полным отказом от старой системы.
«Пилотный проект» - это наиболее часто используемая стратегия.
"Пилотный проект" - это тактика "скачка", но применяемая к
ограниченному числу процессов. Область применения стратегии -
небольшой участок деятельности. Такой подход снижает риск и наиболее
надежен.
«Узкое место» - это малая часть производственного процесса. При
использовании подхода "узкое место" план внедрения выполняется
только для "узкого места" и для людей, работающих в нем.
Мной выбрана стратегия «Пилотный проект». Будет осуществлен резкий
переход к автоматизированной системе управления распределением продуктов
питания. Областью применения внедрения будет отдел управления торговой
сетью. Такой подход не затронет работу всей ИС, а лишь автоматизирует
рутинную часть.
Под моделью жизненного цикла понимается структура, определяющая
последовательность выполнения и взаимосвязи процессов, действий и задач,
выполняемых на протяжении жизненного цикла. Модель жизненного цикла
зависит от специфики информационной системы и специфики условий, в
которых последняя создается и функционирует.
На данный момент основными моделями жизненного цикла являются:
Спиральная модель
Каскадная модель
Итерационная модель

Смотрите также:

"Автоматизация обработки заявок ООО "Проектно-Строительная Компания"
"Автоматизация процесса аттестации персонала для ООО "Нэт Бай Нэт Холдинг"
"Анализ интернет-активности конкурентов ( на примере конкурентов "Газпром нефть")
"Бухгалтерский учёт и аудит расчётов с подотчётними лицами в организации на примере ООО "ЛОЦ 10""
«Психологическое сопровождение персонала в организации на примере ООО «Крокус»
Agile-методология в управлении проектами на примере ООО «Ресурсный центр «Академия КлассИнфо»
Aвтoмaтизaция пpoцecca вeдeния инфopмaциoннoй бaзы o дoлжнocтяx и вaкaнcияx c укaзaниeм тpeбoвaний к уpoвню знaний и нaвыкoв кaндидaтoв для гpуппы кaдpoв вoйcкoвoй чacти 3474»
Cовершенствование деловой оценки персонала в организации (на примере ООО "Даймонд кейтеринг развитие")
Cовершенствование управления рентабельности предприятия (на примере гуипп «бендерская типография «полиграфист»)
Event - менеджмент: реализация проекта (на примере ООО "АГРОПАК")