Файл: Разработка регламента выполнения процесса «Складской учет».pdf
Добавлен: 04.04.2023
Просмотров: 116
Скачиваний: 2
СОДЕРЖАНИЕ
1. ТЕХНИКО-ЭКОНОМИЧЕСКАЯ ХАРАКТЕРИСТИКА ПРЕДМЕТНОЙ ОБЛАСТИ И ПРЕДПРИЯТИЯ
1.1 Описание предметной области. Постановка задачи.
1.2 Выбор средства для моделирования бизнес-процессов
1.3 Моделирование бизнес-процессов «как есть»
2. ИНФОРМАЦИОННОЕ ОБЕСПЕЧЕНИЕ ЗАДАЧИ
2.1 Предлагаемые мероприятия по улучшению бизнес-процессов
2.3 Структурная схема пакета (дерево вызова программных модулей)
Таблица 5 - Характеристика моделей процессов разработки ПО
|
Вес модели |
Модели |
Достоинства |
Недостатки |
|
Тяжелый |
RUP, MSF (для CMMI) |
Процессы рассчитаны на среднюю квалификацию исполнителей. Невысокие требования к стабильности команды. Нет ограничений на распределение участников. Отсутствуют ограничения по объему и сложности разрабатываемых ИС. Используются для ИС с высокими рисками. Легче получить высокий уровень сертификации стандартов качества. |
Требуют существенной управленческой надстройки. Более длительные стадии анализа и проектирования. Более формализованные коммуникации. Большие затраты на документацию длительного процесса сопровождения ПО. |
|
Легкий |
MSF (Agile), PSP/ TSP,Agile |
Меньше непроизводительных расходов, связанных с управлением ИС, рисками, изменениями, конфигурациями, сопровождением ПО. Упрощенные стадии анализа и проектирования, основной упор на разработку функциональности, совмещение ролей. Неформальные коммуникации. |
Используется для ИС с невысокими рисками и небольшого масштаба и сложности. Участники разработки должны располагаться компактно. Плохо подходят для новых проектов. Требуют более квалифицированной и стабильной команды. Сложнее получить высокий уровень сертификации стандартов качества. |
В начале 90-х годов прошлого столетия эксперты разработали более совершенные решения в области обеспечения качества, что привело к созданию целого ряда новых стандартов и методологий, таких как: ISO9001:2008, CapabilityMaturityModel (CMM), ISO/IEC15504(SPICE, введен как стандарт Российской федерации ГОСТ Р ИСО/МЭК 15504 «Информационные технологии. Оценка процессов» с 2010 г.) и стандарт ГОСТ, используемый на территории стран СНГ.
Стандарт ISO 9001:2008 направлен на применение «процессного подхода» при разработке, внедрении и улучшении результативности системы менеджмента качества с целью повышения удовлетворённости потребителей путём выполнения их требований.
Модель CMM разработана в качестве эталонной модели организации разработки ПО при реализации крупномасштабных ИС. Основой моделей CMM/CMMI является формализация процессов разработки.
Стандарт SPICEбыл создан Международной организацией по стандартизации, которая инициировала работу по созданию единого стандарта оценки программных процессов. 180/1ЕС является эталонной моделью, которая определяет процесс измерения и возможность измерения качества процесс.
ГОСТы в настоящее время действуют на территории России и других стран СНГ. Данные стандарты ориентирован на последовательный подход к разработке ПО. В табл. 6 указана возможность использования различных средств обеспечения качества ИС, использующих итеративный подход для разработки.
Таблица 6 -Возможность сертификации моделей итеративной разработки ПО
|
Модель Стандарт |
RUP |
MSF for CMM |
MSF forAgile |
PSP/TSP |
Agile |
|
ISO9000:2008 |
+ |
+ |
- |
- |
- |
|
CMM/CMMI |
3-ий уровень |
2-3-ий уровень |
2-3-ий уровень |
5-ый уровень |
- |
|
SPICE |
+ |
+ |
+ |
+ |
+ |
|
ГОСТ |
- |
- |
- |
- |
- |
где «-» означает невозможность сертификации; «+» - возможность сертификации.
Основная проблема использования ГОСТов и стандартов ІSО 9000:2008 - это слабая формализация процессов при использовании гибкой методологии.
Наиболее эффективными средствами обеспечения качества для ИТ, использующих итеративную разработку, являются CMM ISO/IEC 15504(SPICE),т.к. их использование не зависит от используемой модели разработки ИС.
В табл. 7 приводится сравнение моделей по содержанию, весу, ориентации на количество разработчиков, используемым стандартам для обеспечения качества, достоинствам и недостаткам.
Если команда достаточно велика (больше десятка разработчиков) и разрабатывает ИТ для различных отраслей или для систем разного уровня критичности - желательно выбирать для каждой разработки свой оптимальный уровень формализации и модель разработки.
Таблица 7- Сравнение моделей ИС
Содержание
|
Модели Параметры |
RUP |
MSF |
PSP/TSP |
Agile |
|||
|
XP |
CrystalClear |
FDD |
Scrum |
||||
|
абстрактный общий процесс, на основе которого организация должна создать конкретный специализированный процесс, ориентированный на ее потребности |
согласованный набор концепций, моделей и правил, описывающих управление людьми и процессами в процессе разработки решения; опирается на практический опыт Microsoft |
Набор требований к компетенциям разработчика, делает ставку на самоуправляемые команды |
набор практик: короткие релизы, переработки кода, разработка «тестами вперед», коллективное владение кодом, постоянное присутствие заказчика и стандарты кода |
Итеративная инкрементная разработка; автоматическое регрессионное тестирование; состав документации определяется участниками разработки |
функционально-ориентированная разработка, которая оперирует понятием функции или свойства системы |
итеративная разработка, которая фокусируется на постоянном определении приоритетных задач, основываясь на бизнес целях |
|
|
Команда |
свыше 40-50 человек |
группы по 3-10 человек |
3-20 разработчиков |
до 10-15 человек |
до 6 человек |
20-30 человек |
5-9 человек |
|
Вес |
тяжелый |
может быть и тяжелым, и легким |
легкий |
легкий |
|||
|
Используемые стандарты |
CMMI, ISO, SPICE |
CMMI, ISO, SPICE |
CMMI, SPICE |
CMMI, SPICE |
|||
|
Достоинства |
|
|
|
эффективность |
|
1) дает возможность планирования и предварительного проектирования, создания детального дизайна, |
1) позволяет реализовать большой объем функциональности без спецификаций момент начала разработки. |
|
Недостатки |
несогласованность решений, непродуктивные затраты ресурсов на переработку кода и на повторное решение типовых проблем в случае недостаточного уровня формализма |
не описывает детально важнейшие роли заказчика и пользователя; не рассматриваются методы управления группой проектов |
проблемы при учете рисков, сложности |
рассчитан только на команду опытных разработчиков, не разбитую на несколько частей; проблемы разрешения нетехнологичес ких рисков |
уступает XP по производительности; очень сложно заранее предсказать, какие промежуточные продукты необходимы |
Недостаток документации; значительно увеличивается стоимость последующего сопровождения продукта |
не задает технических практик; сложно добиться активного участия от разработчиков и вовлечь поставщика требований в активное участие |
Разработка ИС связана с совокупностью рисков, которые влекут за собой возникновение неопределенности в процессе создания информационного продукта. Риски влияют на все без исключения аспекты деятельности, поэтому их обязательно необходимо учитывать для разработки надежной ИС.
Реакции на возникновение различных рисков и, соответственно, методы управления рисками будут варьироваться в зависимости от выбранной модели разработки ИС. В табл. 8 предложены методы управления рисками для наиболее распространенных моделей разработки ИС с итерационным циклом разработки - RUP, MSF иAgile.
Таблица 8 -Методы для предотвращения наиболее распространенных рисков
|
Модель Тип риска |
RUP |
MSF |
Agile |
|
|
Нарушения календарного планирования, срыв сроков |
Перерасчет сроков выполнения этапов работ |
Планирование временного резерва |
Выделение сверхурочных трудочасов, повышенное внимание к предварительному планированию |
|
|
Ликвидация или уменьшение данного риска возможно путем оценки длительности определенных работ или всей разработки несколькими методами:
|
||||
|
Изменение требований |
учет увеличения трудоемкости и временных затрат в случае возможного роста требований, например, на 50% (принятие риска) |
переоценка сроков разработки каждый раз, когда требования добавляются/изменяются (ликвидация риска) |
подписание контракта с компенсацией затрат (переадресация риска заказчику) |
|
|
Текучесть кадров |
определение причин, по которым люди покидают компанию. Для изучения мотивов ухода большое значение имеет сбор и анализ информации о них. В первую очередь это сведения об общем числе уволившихся, долях сотрудников различных возрастных категорий, о работниках с низкой и высокой квалификацией, а также об их стаже работы и образовании |
определение общих потерь времени как число месяцев, которое потребуется новому сотруднику на достижение того же уровня производительности, который был у замененного им работника |
|
|
|
Нарушение спецификаций |
Политика ликвидации риска - подписание договора между заказчиком и компанией с описанием входных и выходных условий, оценка рисков независимыми экспертами |
|||
|
Низкая производительность |
улучшение организации производства и труда - повышение норм труда и расширения зон обслуживания; уменьшение числа сотрудников, не выполняющих нормы; упрощение структуры управления; повышение уровня специализации |
структурные изменения - изменения удельных весов отдельных сотрудников в зависимости от трудоемкости выполняемой работы |
повышение технического уровня производства - внедрение новых видов оборудования и ПО |
|
|
Недостаточное внимание к проекту со стороны руководства компании |
Проведение промежуточных отчетных собраний с приглашением заказчика |
Промежуточная оценка прогресса разработки ИС руководством компании с составлением отчетности перед заказчиком |
Составление договора между заказчиком и компанией с поэтапной сдачей ИС |
|
|
Отсутствие мотивации Персонала компании |
Проведение тренингов, корпоративных собраний, внедрение методик teambuilding |
Премирование персонала в зависимости от успешности выполнения задач |
Распространение акций фирмы среди персонала, выделение разработчикам % от прибыли с разработки |
|
Анализ современных средств разработки баз данных представлен в приложении 1.
1.3 Моделирование бизнес-процессов «как есть»
Основными процессами на предприятии являются:
- анализ рынка;
- проведение маркетинговых мероприятий;
- оформление заказов;
- контроль качества продукции;
- комплектация и упаковка готовой продукции;
- складирование и отправка готовой продукции.
- послепродажное обслуживание клиентов.
Анализ рынка проводится в следующей последовательности:
- сбор информации;
- анализ конъюнктуры рынка;
- конкурентный анализ;
- оценка общерыночных показателей;
- оценка внутренних показателей;
- оценка глобальных показателей;
- анализ конкурентной среды;
- анализ конкурентов;
- анализ всех полученных данных.
Проведение маркетинговых мероприятий включает в себя следующие этапы:
- планирование кампании по продвижению;
- формирование рекламной продукции по различным каналам;
- рекламирование;
- формирование базы клиентов.
Контекстная диаграмма и диаграммы декомпозиции представлены на рис. 2-11.
Рисунок 2 - Контекстная диаграмма
Рисунок 3 - Диаграмма декомпозиции (IDEF0)
Рисунок 4 - Диаграмма декомпозиции
Рисунок 5 - Диаграмма декомпозиции
Рисунок 6 - Диаграмма декомпозиции
Рисунок 7 - Диаграмма декомпозиции
Рисунок 8 - Диаграмма декомпозиции
Рисунок 9 - Диаграмма декомпозиции
Рисунок 10 – Диаграмма декомпозиции
Рисунок 11 – Дерево узлов
2. ИНФОРМАЦИОННОЕ ОБЕСПЕЧЕНИЕ ЗАДАЧИ
2.1 Предлагаемые мероприятия по улучшению бизнес-процессов
Для того чтобы приспособить экономическую информацию для эффективного поиска, обработки на ЭВМ и передачи по каналам связи, её необходимо представить в цифровом виде, с этой целью её нужно сначала упорядочить (классифицировать), а затем формализовать (закодировать) с использованием классификатора. Основными объектами классификации и кодирования являются справочные реквизиты-признаки, описывающие процессы, место, время выполнения процессов, субъекты и объекты действия, отражаемые в показателе. Кодированию в документах подлежат те признаки, по которым выполняется группировка информации в ПК. В нашей информационной системе создан локальный классификатор, с использованием иерархического метода классификации.
В автоматизированной системе посреднической деятельности кодированию подлежат следующие объекты:
- материалы;
- номенклатурные группы;
- склады;
- подразделения;
- статьи затрат;
- документы приход/расход.
Структура нормативно-справочной информации, используемой для разработки информационной системы, показана в таблице 9.
Таблица 9 -Структура нормативно-справочной информации
|
№ п/п |
Наименование кодируемого множества объектов |
Значность кода |
Система кодирования |
Вид классификатора |
|
1 |
2 |
3 |
4 |
5 |
|
1 |
Код материала |
ХХХ |
порядковая |
локальный |
|
2 |
Код номенклатурной группы |
ХХХ |
порядковая |
локальный |
|
3 |
Код склада |
ХХ |
порядковая |
локальный |
|
4 |
Код статьи затрат |
ХХ |
порядковая |
локальный |
|
5 |
Код подразделения |
ХХ |
порядковая |
локальный |
|
6 |
Код документа прихода |
ХХХХХ |
порядковая |
локальный |
|
7 |
Код документа списания |
ХХХХХ |
порядковая |
локальный |