Файл: Разработка и реализация конфигурации "Магазин инструментов" в среде 1С: Предприятие (Управленческая характеристика предметной области конфигурирования).pdf

Для почтового сервера критериями выбора будет отказоустойчивость и высокая скорость работы подсистемы обработки данных. Для него будут использоваться высоко производительные жёсткие диски WD RAPTOR со скоростью вращения шпинделя более 12000 об в мин. И отдельный RAID контроллер, поддерживающий реализацию массива данных Raid 10, который предоставляет и высокую скорость работы и высокую отказоустойчивость подсистемы данных.

Таблица1. 4- Аппаратная конфигурация почтового сервера

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

Таблица 1.5-Перечисления

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

Рисунок 1.2-Перечисление «Каиегории»

Справочники

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

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

«Города»;

«Фирмы»;

«Товары»;

«Филиалы»;

«Менеджеры»;

Договора контрагентов.

Справочник «Города»

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

Таблица 1.3-Города

Рисунок 1.4- Справочник «Города»

Справочник «Фирмы»

Данный справочник содержит список фирм, которые сотрудничают с нашим предприятием.

Таблица 1.4-Фирмы

В режиме конфигурации справочник «Фирмы» будет выглядеть следующим образом:

Рисунок 1.5- Справочник «Фирмы»

Справочник «Товары»

Данный справочник содержит список товаров.

Таблица 1.5-Товары

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

Рисунок 1.6- Справочник «Товары»

Справочник «Филиалы»

Данный справочник содержит список филиалов компании, в разных городах.

Таблица 1.6-Филиалы

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

Рисунок 1.7- Справочник «Филиалы»

Справочник «Менеджеры»

Данный справочник содержит список сотрудников организации.

Таблица 1.7-Структура справочника

В режиме конфигурации справочник «Менеджеры» будет выглядеть следующим образом:

Рисунок 1.8-Справочник «Менеджеры»

2. Проектная часть

2.1. Информационныое обеспечение задачи

Рисунок 1 – Документ «Поступление товаров»

Рисунок 2 – Код процедуры расчета общей и итоговой суммы

Рисунок 3 –Продажа товара

Рисунок 4 Код процедуры расчета общей и итоговой суммы

Рисунок 5 – Документ на перемещение товара на выставку

Рисунок 6 – Документ на перемещение товара с выставки

Рисунок 7 – Отчет о движении товара

Рисунок 8 – Создание отчет о движении товара

Рисунок 9 – отчет менеджеров

Рисунок 10 – Создание отчета менеджеров

Рисунок 11 – Отчет остатков

Рисунок 12 – Создание отчета остатков

Рисунок 13 – Отчет сотрудников

Рисунок 14Создание отчета сотрудников

Рисунок 15 –Отчет поступления товара

Рисунок 16 - Создание отчета поступление товара

Рисунок 17 -Печать документа поступления товара

2.2. Информационная модель и её описание

ГОСТ 34.601-90 распространяется на автоматизированные системы и устанавливает стадии и этапы их создания. Кроме того, в стандарте содержится описание содержания работ на каждом этапе. Стадии и этапы работы, закрепленные в стандарте, в большей степени соответствуют каскадной модели жизненного цикла [2]. ISO/IEC 12207:1995 стандарт на процессы и организацию жизненного цикла. Распространяется на все виды заказного ПО. Стандарт не содержит описания фаз, стадий этапов.[3] Custom Development Method (и, методика Oracle) по разработке прикладных информационных систем под заказ - конкретный материал, детализированный до уровня заготовок проектных документов, рассчитанных на использование в проектах с применением Oracle. Степень адаптивности CDM ограничивается тремя моделями ЖЦ: "классическая" (предусмотрены все работы/задачи и этапы), "быстрая разработка" (Fast Track), "облегченный подход", рекомендуемый в случае малых проектов и возможности быстро прототипировать приложения. Rational Unified Process (RUP) предлагает итеративную модель разработки, включающую четыре фазы: начало, исследование, построение и внедрение. Каждая фаза может быть разбита на этапы (итерации), в результате которых выпускается версия для внутреннего или внешнего использования. Прохождение через четыре основные фазы называется циклом разработки, каждый цикл завершается генерацией версии системы. Если после этого работа над проектом не прекращается, то полученный продукт продолжает развиваться и снова минует те же фазы [3]. Суть работы в рамках RUP - это создание и сопровождение моделей, а не бумажных документов, поэтому этот процесс привязан к использованию конкретных средств моделирования (UML), а так же конкретной технологии проектирования и разработки (объектно-ориентированный анализ, object-oriented analysis, OOA, объектно-ориентированное программирование, object-oriented programming, OOP). Microsoft Solution Framework (MSF) сходна с RUP, так же включает четыре фазы: анализ, проектирование, разработка, стабилизация, является итерационной, предполагает использование объектно-ориентированного моделирования. [8]. MSF в сравнении с RUP в большей степени ориентирована на разработку бизнес-приложений. Extreme Programming (XP). Экстремальное программирование является самым новым среди рассматриваемых методологий, сформировалось в 1996 году. В основе методологии командная работа, эффективная коммуникация между заказчиком и исполнителем в течение всего проекта по разработке ИС, а разработка ведется с использованием последовательно дорабатываемых прототипов. Стандарт COBIT мне не подходит, потому что основной целью его использования “является проведения аудита и стратегического планирования ИС и IT инфраструктуры в целом”[18] Стандарт XP мне тоже не подходит, так как он не содержит полноценных этапов ЖЦ, таких как выработка концепции, планирование, разработка, стабилизация, внедрение. Следовательно, перед выбором стоит Rup и MSF. Оба стандарта являются молодыми и поддерживающими всё новые технологии продуктивной разработки и контроля их выполнения Основные особенности MSF, RUP и XP сведены в таблицу 3. По ней можно судить, что Rational Unified Process является хорошо сбалансированным решением для средних по размерам коллективов разработчиков, работающих с применением продуктов и технологий компании Rational. Сопровождение разработки системы и самой системы регламентируется методологией RUP, однако данная технология достаточно сильно ориентирована на внутрифирменные инструментальные средства. Extreme Programming хорошо подходит для проектных групп малого размера и для небольших систем с часто изменяемыми требованиями. Основная проблема XP - сопровождение. В случае текучки кадров в коллективе разработчиков значительная часть проектной информации может быть утеряна из-за практически отсутствующей документации. В таблице 2.2 представлены основные показатели стандартов Жизненного цикла ИС

Таблица 2.2-Технологии MSF, RUP и XP

Microsoft Solutions Framework является наиболее сбалансированной технологией, ориентированной на проектные группы малых и средних размеров. MSF не накладывает никаких ограничений на используемый инструментарий и содержит рекомендации весьма общего характера. Однако, эти рекомендации могут быть использованы для построения конкретного процесса, соответствующего потребностям коллектива разработчиков.[3] Наш проект является небольшим, включает в себя 3 человека и этапы разработки и тестирования проводятся в среде разработки Python. Кроме того основным преимуществом MSF является итерационная модель одновременно с уточняющими вехами (аналог каскадной модели). Таким образом, реализация MSF попыталась объединить каскадную и итерационную модель разработки и внедрения ПО[18] По описанным выше преимуществам, мною был выбран стандарт MSF как наиболее гибкий и удобный для реализации моего проекта. Одним из преимуществ этого стандарта является возможность управлять одновременно и проектом разработкой приложения и внедрением инфраструктуры. Итак, в идеологии MSF существует 5 стадий жизненного цикла ИС, которые в понятии MSF называют фазами. Первый из них это Фаза выработки концепции. Цель данной фазы в создании и сплочении проектной группы на основе выработки единого видения. Проектная группа должна четко представить себе, что она хочет сделать для заказчика и сформулировать свою цель. Заказчиком в нашем случае выступаем мы сами и весь холдниг единовременно. В идеологии MSF команда проекта делиться на 6 участников, каждый из которых имеет свою роль в проекте, наделён обязанностями и имеет свою зону ответственности. эти роли MSF назвала кластерами, за каждым из которых может быть закреплён не один человек, итак вот они: Управление продуктом, Управление программой, Разработка, Удовлетворение потребителя, Тестирование, Управление выпуском. В каждой фазе для каждого ответственного лица, закреплённого за кластером закрепляются определённые задачи. Вот какие задачи ставятся в фазе выработки концепций. Управление продуктом регулирует Концептуальный и логический дизайн; функциональная спецификация; сводный план и сводный календарный график проекта; бюджет.. Кластер Управление программой формирует цели дизайна, концепцию решения, структуру проекта. Кластер Разработка отвечает за Оценка технологий; логический и физический дизайн; план и календарный график разработки; смета разработки. Кластер удовлетворения потребителя рассматривает Сценарии/примеры использования, пользовательские требования, требования локализации и общедоступности (accessibility); пользовательская документация/план обучения/график тестирования удобства эксплуатации; обучение. Кластер Тестирования формирует Оценка дизайна; требования тестирования; план и календарный график тестирования.. Кластер управление выпуском выполняет функции Оценка дизайна; эксплуатационные требования; план и календарный график пилотного и окончательного внедрения. К сожалению или к счастью, но в рамках создания и внедрения моего проекта силами сотрудников ИТ департамента, использовать 6 и более человек для фоновой задачи, бюджет которого ограничен лишь премией крайне нецелесообразно. Я объединил задачи кластеров и сформировал из них 3 ответственных лица, они же и есть команда проекта

1)Программист на которого возложены следующие кластеры :

Управление программой,

Разработка

удовлетворение пользователей

2) менеджер проекта, он же внедренец, он же тестировщик, на него возложены следующие кластеры:

Управление продуктом,

Тестирование

управление выпуском .

Выходной информацией и результатами данной Фазы является подбор кандидатов и назначение наиболее подходящих из них к требуемым задачам на исполнение двух ролей, то есть формирование команды, несмотря на то, что она состоит всего из двух человек. В нашем проекте на данном этапе будут определены состав и роли участников Составлена смета по времени и планирование бюджета данного проекта. Следующим этапом ЖХ ИС идёт Фаза планирования. Основной её целью является составлению планов проекта. Она включает в себя подготовку проектной группой функциональной спецификации, разработку дизайнов, подготовку рабочих планов, оценку проектных затрат и сроков разработки различных составляющих проекта. Процесс проектирования – это систематический способ продвижения от абстрактных концепций к конкретным техническим деталям. Результатами фазы планирования являются: функциональная спецификация, Описание возможных рисков, Сводный план и сводный календарный график проекта, развернутые Среды разработки и тестирования. От программиста на данном этапе требуется обзор и выбор я языка программирования, на котором будет реализовано решение, + календарный план по срокам и графикам разработки. Менеджер проекта на данном этапе продумывает всю архитектуру ИС, включая взаимодействие почтового сервера, веб сервера, Субд, работу пользователей и инженеров в будущей системе. Следующим этапом следует Фаза разработки. На фазе разработки проектная группа фокусируется на создании компонент решения (включая как документацию, так и программный код). Однако некоторая часть этой работы может продолжаться также на фазе стабилизации, если такая необходимость выявлена в процессе тестирования. Данная фаза также включает в себя разработку инфраструктуры. Следует обратить внимание, что активность проектной команды на этом этапе не ограничивается написанием разработчиками кода – все ролевые кластеры принимают деятельное участие в создании и тестировании решения. Таблица 11 описывает основные задачи и сферы ответственности каждого из ролевых кластеров проектной группы во время фазы разработки. Результатами фазы разработки являются: Исходный и исполнимый код приложений, Скрипты установки и конфигурирования, Окончательное описание функционала разарабатываемого решения , Материалы поддержки решения, сценарии тестов. В нашем случае от программиста на данном этабе требуется предоставить программу клиент для работы Инженеров ИТ и написание полной документации к ней. От руководителя проекта требуется создать работоспособную среду описанную в предыдущем этапе. Во время фазы стабилизации производится тестирование разработанного решения. При этом внимание фокусируется на его эксплуатации в реалистичной модели производственной среды. Проектная группа занимается приоритезацией и устранением ошибок, а также подготовкой решения к выпуску.Обычно в начале фазы стабилизации скорость выявления ошибок командой тестирования превосходит скорость, с которой эти ошибки могут устраняться командой разработчиков. Невозможно предсказать, сколько ошибок будет найдено и как много времени понадобится на их устранение. Однако существует два статистических признака, помогающих проектной группе оценить уровень стабилизации решения. Это точка конвергенции (bug convergence).В точке конвергенции (bug convergence) становится заметен существенный прогресс в устранении ошибок, то есть скорость устранения ошибок начинает превосходить скорость их обнаружения. Поскольку количество найденных, но не устраненных ошибок может колебаться даже после того, как оно начало убывать, конвергенция может рассматриваться скорее как тенденция, нежели как фиксированный момент во времени. Вслед за этой вехой количество активных ошибок должно продолжать убывать, вплоть до точки достижения нуля. Точка конвергенции дает проектной группе возможность понять, что процесс тестирования близится к концу. Таблица 12 описывает основные задачи и сферы ответственности каждого из ролевых кластеров проектной группы во время фазы стабилизации. Результатами фазы стабилизации являются: Окончательный продукт (golden release), Документация выпуска (release notes), Материалы поддержки решения, Результаты и инструментарий тестирования, Исходный и исполнимый код приложений, Проектная документация. В моём проекте на данном этапе Программистом корректируются ошибки в разрабатываемой им программе, компилируется версия релиз кандидат и после отсутствия критических ошибок по всем веткам функционала программы выпускается окончательная сборка исполняемого кода, параллельно с этим дополняется документация к работе с программой. Руководителем проекта на данном этапе набирает группу тестирования из 2-3 инженеров, которые будут пользоваться этой программой каждый день и тестирует все ветки функционала по разработанным ранее сценариям и формирует дополнения, которые можно будет реализовать в следующей версии. Во время этой фазы проектная группа внедряет технологии и компоненты решения, стабилизирует внедренное решение, передает работу персоналу поддержки и сопровождения и получает со стороны заказчика окончательное одобрение результатов проекта. По завершению внедрения проектная группа производит анализ выполненной работы и удовлетворенности заказчика