Сущность логистического бизнес-процесса. Функциональная, инфологическая и даталогическая модели предметной области. Выбор языка и средства программирования. Разработка и описание программного обеспечения для автоматизации закупок на предприятии.
При низкой оригинальности работы "Разработка подсистемы документооборота в системе управления проектами сервисной компании", Вы можете повысить уникальность этой работы до 80-100%
К минусам бумажного документооборота можно отнести следующие: медленный поиск документов, трудность отслеживания документа на всех этапах его жизненного цикла, сложность организации эффективного контроля и отчетности по исполнению резолюций, длительность сроков подготовки и согласования документов, сложность организации документооборота, если с одними и теми же документами одновременно работает несколько пользователей, невозможность или трудоемкость получения сводных отчетов и журналов и т.д. Главный инженер определяет техническую политику и направления технического развития предприятия в условиях рыночной экономики, пути реконструкции и технического перевооружения действующего производства, уровень специализации и диверсификации производства на перспективу; Обеспечивает необходимый уровень технической подготовки производства и его постоянный рост, повышение эффективности производства и производительности труда, сокращение издержек (материальных, финансовых, трудовых), рациональное использование производственных ресурсов, высокое качество и конкурентоспособность производимой продукции, работ или услуг, соответствие выпускаемых изделий действующим государственным стандартам, техническим условиям и требованиям технической эстетики, а также их надежность и долговечность. В соответствии с утвержденными бизнес-планами предприятия на среднесрочную и долгосрочную перспективу руководит разработкой мероприятий по реконструкции и модернизации предприятия, предотвращению вредного воздействия производства на окружающую среду, бережному использованию природных ресурсов, созданию безопасных условий труда и повышению технической культуры производства; Организует разработку и реализацию планов внедрения новой техники и технологии, проведения организационно-технических мероприятий, научно-исследовательских и опытно-конструкторских работ. «1С: Торговля и Склад» - представляет собой компоненту «Оперативный учет» системы «1С: Предприятие» с типовой конфигурацией для автоматизации складского учета и торговли. USECASE-ы «Выбор формы проектов», «Выбор формы договоров», «Выбор формы ведения ДС», «Просмотр информации о формах», «Выбор формы закупочные спецификации» и «Выбор формы ведения единиц измерения» связываются с другими вариантами использования, которые представляют более детальную картину работы всей программы в целом.В ходе выполнения выпускной квалификационной работы была изучена предметная область сервисно-интегрирующей компании, где необходимо было разработать программный продукт, служащий для автоматизации сложного логистического процесса внутри самой компании. По окончанию разработки программы была написана документация в виде руководства администратора и руководство пользователя, в которых дается подробное описание, как необходимо правильно установить программу и как ее в дальнейшем использовать.Даталогическая модельMAINDGV.Rows.Add(LISTCONTRACT_spec[i].name, LISTCONTRACT_spec[i].proj_proj_id.name_proj, LISTCONTRACT_spec[i].cont_cont_id.name_cont, LISTCONTRACT_spec[i].create_date, LISTCONTRACT_spec[i].author, LISTCONTRACT_spec[i].client, LISTCONTRACT_spec[i].contractor, LISTCONTRACT_spec[i].summa, LISTCONTRACT_spec[i].comment, LISTCONTRACT_spec[i].stat_stat_id.name); TREEGRIDNODE NODECHILD = node.Nodes.Add(LISTPOSITIONSFACT[i].article, LISTPOSITIONSFACT[i].name, LISTPOSITIONSFACT[i].um_um_id.short_name, LISTPOSITIONSFACT[i].count, LISTPOSITIONSFACT[i].val_val_id.name, LISTPOSITIONSFACT[i].price, LISTPOSITIONSFACT[i].summa, LISTPOSITIONSFACT[i].stat_stat_id.name, LISTPOSITIONSFACT[i].delivery, LISTPOSITIONSFACT[i].cancel, LISTPOSITIONSFACT[i].official); TREEGRIDNODE NODECHILD = node.Nodes.Add(LISTPOSITIONSDOCS[i].article, LISTPOSITIONSDOCS[i].name, LISTPOSITIONSDOCS[i].um_um_id.short_name, LISTPOSITIONSDOCS[i].count, LISTPOSITIONSDOCS[i].val_val_id.name, LISTPOSITIONSDOCS[i].price, LISTPOSITIONSDOCS[i].summa, LISTPOSITIONSDOCS[i].stat_stat_id.name, LISTPOSITIONSDOCS[i].delivery, LISTPOSITIONSDOCS[i].cancel, LISTPOSITIONSDOCS[i].official); TREEGRIDNODE NODECHILD = node.Nodes.Add(LISTPOSITIONSCHILDREN[j].article, LISTPOSITIONSCHILDREN[j].name, LISTPOSITIONSCHILDREN[j].um_um_id.short_name, LISTPOSITIONSCHILDREN[j].count, LISTPOSITIONSCHILDREN[j].val_val_id.name, LISTPOSITIONSCHILDREN[j].price, LISTPOSITIONSCHILDREN[j].summa, LISTPOSITIONSCHILDREN[j].stat_stat_id.name, LISTPOSITIONSCHILDREN[j].delivery, LISTPOSITIONSCHILDREN[j].cancel, LISTPOSITIONSCHILDREN[j].official); TREEGRIDNODE NODECHILD = node.Nodes.Add(LISTPOSITIONSCHILDREN[j].article, LISTPOSITIONSCHILDREN[j].name, LISTPOSITIONSCHILDREN[j].um_um_id.short_name, LISTPOSITIONSCHILDREN[j].count, LISTPOSITIONSCHILDREN[j].val_val_id.name, LISTPOSITIONSCHILDREN[j].price, LISTPOSITIONSCHILDREN[j].summa, LISTPOSITIONSCHILDREN[j].stat_stat_id.name, LISTPOSITIONSCHILDREN[j].delivery, LISTPOSITIONSCHILDREN[j].cancel, LISTPOSITIONSCHILDREN[j].
Введение
Документы были, есть и будут. Единственное, что меняется со временем - это их носители.
Наш динамичный и требовательный XXI век позволяет нам не волноваться о том, захватили ли мы с собой записную книжку, или папку с документами. “Все свое ношу с собой” - высшая мудрость древних нашла свою реализацию в наши дни благодаря тому, что все документы огромного предприятия могут храниться и переноситься внутри одного персонального компьютера. Однако, пока на большинстве предприятий документооборот существует в бумажной форме. Безусловно, в таком виде документооборот более привычен и традиционен, но при этом он обладает рядом недостатков, существенно перекрывающих достоинство его привычности.
К минусам бумажного документооборота можно отнести следующие: медленный поиск документов, трудность отслеживания документа на всех этапах его жизненного цикла, сложность организации эффективного контроля и отчетности по исполнению резолюций, длительность сроков подготовки и согласования документов, сложность организации документооборота, если с одними и теми же документами одновременно работает несколько пользователей, невозможность или трудоемкость получения сводных отчетов и журналов и т.д.
Таким образом, традиционный документооборот оказывается неэффективным. Все эти минусы устраняются с введением систем электронного документооборота. Для организаций, где количество документов и сложность их ведения велики, становится жизненно важной задача автоматизации документооборота с целью устранения вышеперечисленных недостатков.
В данной выпускной квалификационной работе мы разработаем специальное программное средство для предприятия сервис - интегратор «БИАЙ-лизинг».
Программное средство «Автоматизация закупок IS» будет охватывать все предприятие, а именно автоматизировать складской учет и торговлю. «Автоматизация закупок IS» предназначена для учета любых видов торговых операций. Благодаря гибкости и настраиваемости система способна выполнять все функции учета - от ведения справочников и ввода первичных документов до получения различных ведомостей и аналитических отчетов.
Программное средство преследует главную цель: автоматизация логистического бизнес - процесса.
1. Описание предметной области
1.1 Описание логистического бизнес-процесса
Логистический бизнес-процесс представляет собой цепочку сложных подпроцессов, которая начинается с момента возникновения обязательств перед заказчиком и заканчивается их полным исполнением с последующим гарантийным обслуживанием. Сложность и большой объем информации логистического процесса затрудняет работу его участников (руководитель проекта, логист, инженер, продавец). Автоматизация этого процесса позволила бы существенно снизить затраты по предоставлению услуг и ускорить исполнение обязательств перед заказчиком компании. Схема разработанного логистического процесса представлена в приложении В.
Повышение эффективности управления логистикой возможно за счет интегрированности логистической цепочки по всему жизненному циклу заказа.
Связность и согласованность действий участников логистического процесса при выполнении заказа осуществляется в автоматическом режиме корпоративной информационной системой, которая поддерживает коллективную работу в реальном времени на участках продаж, закупок, складского учета, производства, т.е. на всем пути движения соответствующих материальных, финансовых и информационных потоков.
Чем лучше обеспечена координация процессов в цепочке поставок, тем выше рентабельность предприятия изза отсутствия срывов, ускорения выполнения заказов, снижения стоимости обработки потока, своевременности и высокого качества удовлетворения потребностей клиентов.
Автоматизированные средства помогают объединить в едином информационном пространстве дистрибьюторские сети, торговые площадки, производство, складское и транспортное хозяйства, подразделения обеспечения, что дает возможность менеджерам принимать оперативные решения на основе интегрированной информации о функционировании системы в целом.
Участниками логистического процесса являются: руководитель процесса, логист, инженер, продавец.
Формирование договора является одним из стартовых звеньев, и делятся на этапы, которые в свою очередь также могут быть составными, тем самым представлять собой иерархическую структуру. Атрибутами договора являются: номер, название, вид, контрагент, дата подписи, дата окончания, общая стоимость, отгружено, оплачено, описание.
С каждым договором ассоциируется набор платежных и электронных документов.
Формирование проекта является одним из стартовых звеньев в логистической цепочке. Проект может состоять из подпроектов, которые в свою очередь также могут быть составными, тем самым представлять собой иерархическую структуру. Атрибуты проекта: код, руководитель проекта, дата начала (план, факт), дата окончания (план, факт), клиент, статус, описание. Статус проекта может принимать следующие значения: инициирован в реализации, приостановлен, в завершении, закрыт. С каждым проектом ассоциируется набор платежных и электронных документов, перечень складов. Атрибутами склада являются: наименование, материально ответственное лицо, признак закрытости, общая стоимость, адрес, описание, тип (постоянный, приобъектный, виртуальный).
Необходимо хранить историю должности материально ответственного лица склада. Для документов (файлов), проектов / договоров необходимо вести историю их изменения. Продумать ведение истории изменения файлов с помощью взаимодействия с уже готовым программным обеспечением (ПО) по документообороту.
Договорная специфика представляет собой перечень товаров и услуг. Атрибутами договорной специфики являются: название, проект, договор, дата создания, автор, клиент по проекту, контрагент по договору, статус, сумма, комментарий. Взаимосвязь проектов и договоров осуществляется через соответствующие договорные специфики. В качестве статуса договорной спецификации (ДС) выступают следующие значения: новая, согласованная, утвержденная. В рамках проекта / договора может быть несколько ДС. Необходимо вести историю ДС. ДС - это перечень сгруппированных позиций. Каждая позиция может быть составной и иметь атрибуты. Также есть два типа позиций: плановая и фактическая. При формировании фактической ДС позиции в ней могут отличаться от позиций ДС по документам (иметь другое наименование, стать составной или простой).
С каждой позицией ассоциируется номенклатура, которая группируется по товарам, услугам и правам на ПО. Атрибутами номенклатуры являются: наименование, краткое наименование, артикул, единица измерения, поставщики, вид. У номенклатуры может быть целый набор единиц измерения, а так же поставщиков. Должна быть предусмотрена возможность выбора основного поставщика. С каждой номенклатурой ассоциируется картинка(ее внешний вид).
На базе утвержденной ДС формируются закупочные спецификации (ЗС). Статус ЗС принимает два значения: утверждена или нет. В рамках ЗС с каждой позицией ассоциируется дополнительный набор атрибутов: поставщик, закупочная цена, дата поступления по документам, срок поставки, срок оплаты, счет поставщика, ответственный. Каждая позиция либо резервируется на складе, либо заказывается у поставщика.
Движение денежных средств осуществляется с помощью платежных поручений. Платежные поручения имеют определенные атрибуты.
Автоматизация логистики склада - путь к сокращению потерь предприятия.
Структура предприятия «БИАЙ-лизинг» представлена на рис. 1.
Рисунок 1 - Структура предприятия «БИАЙ-лизинг»
Директор - высшая должность в предприятии, наделенная полномочиями выбора стратегии развития компании, работы с кадрами, отладкой финансовых потоков предприятия.
Главный инженер определяет техническую политику и направления технического развития предприятия в условиях рыночной экономики, пути реконструкции и технического перевооружения действующего производства, уровень специализации и диверсификации производства на перспективу; Обеспечивает необходимый уровень технической подготовки производства и его постоянный рост, повышение эффективности производства и производительности труда, сокращение издержек (материальных, финансовых, трудовых), рациональное использование производственных ресурсов, высокое качество и конкурентоспособность производимой продукции, работ или услуг, соответствие выпускаемых изделий действующим государственным стандартам, техническим условиям и требованиям технической эстетики, а также их надежность и долговечность. В соответствии с утвержденными бизнес-планами предприятия на среднесрочную и долгосрочную перспективу руководит разработкой мероприятий по реконструкции и модернизации предприятия, предотвращению вредного воздействия производства на окружающую среду, бережному использованию природных ресурсов, созданию безопасных условий труда и повышению технической культуры производства; Организует разработку и реализацию планов внедрения новой техники и технологии, проведения организационно-технических мероприятий, научно-исследовательских и опытно-конструкторских работ.
В задачи отдела логистики входит все, кроме самого процесса производства, то есть закупка, доставка и хранение сырья, материалов или полуфабрикатов, а также хранение и сбыт готовой продукции. Целью логистической деятельности является оптимизация затрат и издержек на каждом этапе, экономия ресурсов и средств.
Работа проектного отдела тесно связана со всеми подразделениями фирмы. Проектный отдел занимается разработкой проектов как вновь строящихся, так и реконструируемых и модернизируемых автоматизированных систем. Основные направления деятельности по работе с персоналом: - прогноз и планирование потребности в кадрах;
- мониторинг, оценка качества труда;
- система отбора кадров;
- организация процесса адаптации новых работников;
- организация управления карьерой и профессиональным ростом;
- система непрерывного образования и переподготовки кадров.
Экономический отдел занимается формированием плановых показателей, ведет контроль над фактическим исполнением ранее сформированных и утвержденных планов.
1.2 Пример автоматизированных систем и сравнение с разрабатываемой системой
На данный момент, компания «БИАЙ-лизинг», благодаря использованию современных технологий управления производством работ и инновационных технических продуктов, является одной из крупнейших на рынке информационных систем. Спектр решаемых ею задач очень велик.
Так как программный комплекс разработан специально для конкретного предприятия, невозможно найти аналогов.
Но все же, похожих средств несколько, например «1С: Торговля и Склад», «Система управления Парус». «1С: Торговля и Склад» - представляет собой компоненту «Оперативный учет» системы «1С: Предприятие» с типовой конфигурацией для автоматизации складского учета и торговли.
Т.е. «1С: Торговля и Склад» выступает не как система, а лишь как компонент системы, в отличае от нашей автоматизированной системы. Так как программа состоит из комплекса компонент, ввиду ее сложности, сбои бывают чаще.
«Поэтому выгодней купить миксер, мясорубку отдельно, а не покупать кухонный комбайн». Также «1С: Предприятие» дорогая вещь, т.к. сочетает в себе множество компонент и функций.
Главная цель выпускной квалификационной работы - автоматизация логистического бизнес процесса и упрощение работы с большими объемами информации этого процесса. Определить как правильно вести проекты и договора, с минимальной затратой временных средств.
Задачи, которые решаются в выпускной квалификационной работе: - повышение скорости обработки товарных потоков для организации ускоренного сбыта;
- минимизация потерь;
- снижение издержек;
- организация эффективного управления всеми бизнес - процессами, включая функции логистической координации со смежными структурами компании.
2. Логистический бизнес-процесс
2.1 Взаимодействие бизнес-объектов
Логистический процесс представляет собой цепочку сложных подпроцессов, детальное описание которых было рассмотрено в описании модели бизнес процессов.
Участниками логистического процесса являются: руководитель процесса, логист, инженер, продавец.
Формирование договора является одним из стартовых звеньев в логистической цепочке. Он подразделяется на этапы, которые в свою очередь так же могут быть составными, тем самым представлять собой иерархическую структуру.
Атрибуты договора: 1) номер;
2) название;
3) вид;
4) контрагент;
5) дата подписи;
6) дата окончания;
7) общая стоимость;
8) отгружено;
9) оплачено;
10) описание.
С каждым договором ассоциируется набор платежных и электронных документов.
Формирование проекта является одним из стартовых звеньев в логистической цепочке. Проект может состоять из подпроектов, которые в свою очередь также могут быть составными, тем самым представлять собой иерархическую структуру.
Атрибуты проекта: 1) код;
2) РП;
3) дата начала (план, факт);
4) дата окончания (план, факт);
5) клиент;
6) статус;
7) описание.
Статус проекта может принимать следующие значения: инициирован в реализации, приостановлен, в завершении, закрыт. С каждым проектом ассоциируется набор платежных и электронных документов, перечень складов.
Атрибуты склада: 1) наименование;
2) материально ответственное лицо;
3) признак закрытости;
4) общая стоимость;
5) адрес;
6) описание;
7) тип (постоянный, приобъектный, виртуальный).
Необходимо хранить историю должности материально ответственного лица склада. Для документов (файлов), проектов / договоров необходимо вести историю их изменения. Продумать ведение истории изменения файлов с помощью взаимодействия с уже готовым ПО по документообороту.
Договорная спецификация (ДС) представляет собой перечень товаров и услуг.
Атрибуты ДС: 1) название;
2) проект;
3) договор.
4) дата создания;
5) автор;
6) клиент по проекту;
7) контрагент по договору;
8) статус;
9) сумма;
10) комментарий.
Взаимосвязь проектов и договоров осуществляется через соответствующие ДС. В качестве статуса ДС выступают следующие значения: новая, согласованная, утвержденная. Процедура утверждения ДС была описана в модели бизнес процессов. В рамках проекта / договора может быть несколько ДС. Необходимо вести историю изменений ДС.
ДС - это перечень сгруппированных позиций. Каждая позиция может быть составной, т.е. иметь иерархическую структуру.
Атрибуты позиций: 1) порядковый номер;
2) артикул;
3) номенклатура;
4) единица измерения;
5) количество;
6) валюта;
7) цена за единицу;
8) сумма;
9) срок поставки (договорная и директивная даты);
10) аннулированность;
11) официальный;
12) статус.
В качестве статуса выступают следующие значения: не заказана, заказана, изменена (если позиция в ДС по документам отличается от соответствующей позиции в фактической ДС).
Для классификации ДС на плановые (по документам) и фактические были введены типы позиций: плановая, фактическая.
При формировании фактической ДС позиции в ней могут отличаться от позиций ДС по документам (иметь другое наименование, стать составной или простой).
С каждой позицией ассоциируется номенклатура, которая группируется по товарам, услугам и правам на ПО.
Атрибуты номенклатуры: 1) наименование;
2) краткое наименование;
3) артикул;
4) единица измерения;
5) поставщики;
6) вид.
Если номенклатура из группы «Товар», то список атрибутов дополняется: 1) тип (материал или оборудование);
2) производитель;
3) серия;
4) новая или б/у.
Если же из группы «Права на ПО», то основной список атрибутов дополняется: 1) существование сублицензии;
2) учет НДС (с или без);
3) серия.
У номенклатуры может быть целый набор единиц измерения, а так же поставщиков. Должна быть предусмотрена возможность выбора основного поставщика. С каждой номенклатурой ассоциируется картинка (ее внешний вид).
На базе утвержденной ДС формируются закупочные спецификации (ЗС). Статус ЗС принимает два значения: утверждена или нет.
В рамках ЗС с каждой позицией ассоциируется дополнительный набор атрибутов: 1) поставщик;
2) закупочная цена;
3) дата поступления по документам;
4) срок поставки;
5) срок оплаты;
6) счет поставщика;
7) ответственный.
Каждая позиция либо резервируется на складе, либо заказывается у поставщика (через заказ поставщику).
Процедура утверждения ЗС была описана в модели бизнес процессов.
Движение денежных средств осуществляется с помощью платежных поручений.
Атрибуты платежного поручения: 1) номер;
2) дата;
3) вид;
4) сумма;
5) плательщик (название, ИНН, КПП, № счета);
6) получатель (название, ИНН, КПП, № счета);
7) назначение платежа;
8) комментарий;
9) банк плательщика (БНК, № счета);
10) банк получателя (БНК, № счета);
11) основной проект;
12) основной договор.
2.2 Функциональная структура предприятия
Проектная организация, на которую будет впоследствии внедрена разрабатываемая система, требует (как показало описание предметной области предприятия) объединения всех отделов предприятия заказчика сетью и создания единой БД.
2.2.1 Функциональная модель предметной области
Функциональная модель предназначена для описания существующих бизнес-процессов на предприятии и идеального положения вещей - того, к чему нужно стремиться. Данная модель построена в среде функционального моделирования BP-win, которая включает в себя три стандартные нотации: IDEF0, DFD, IDEF3. Методология IDEF0 предписывает построение иерархической системы диаграмм - единичных описаний фрагментов системы. Сначала проводится описание системы в целом и ее взаимодействия с окружающим миром (контекстная диаграмма), после чего проводится декомпозиция - система разбивается на подсистемы и каждая подсистема описывается отдельно (диаграммы декомпозиции). Затем каждая подсистема разбивается на более мелкие и так далее до достижения нужной степени подробности.
Рассмотрим предлагаемую нами функциональную модель выбранной предметной области (рис. 2).
Рисунок 2 - Контекстная диаграмма
В таблицу запишем определения стрелок на контекстной диаграмме.
Обозначение стрелок в контекстной диаграмме
Название стрелки Определение стрелки Тип стрелки
Выбор формы Выбор необходимой формы Input
Сортировка Сортировка данных по возрастанию, убыванию Control
Фильтрация Фильтрация данных с помощью sql-запросов Control
Технология «Drag and Drop» Технология работающая по принципу «Схватить и перетащить» Control
Программное средство Разрабатываемая система Mechanism
Персонал производственного отдела Инженеры, проектировщики и т.д. Mechanism
Готовый документ Данные, хранящиеся в базе Output
Чтобы посмотреть работу предприятия более детально, декомпозируем систему на несколько уровней (рис. 3 и рис. 4).
Рисунок 3 - декомпозиция первого уровня
Рисунок 4 - Декомпозиция второго уровня
2.2.2 Инфологическая модель предметной области
Диаграмма «сущность-связь» (ER) предназначена для разработки моделей данных и обеспечивает стандартный способ определения данных и отношения между ними. Фактически с помощью ER-диаграмм осуществляется детализация хранилищ данных проектируемой системы, а также документируются сущности системы и способы взаимодействия, включая идентификацию объекта важной для предметной области (сущности), свойства этих объектов (атрибуты) и отношения с другими объектами (связи).
Рисунок 5 - Инфологическая модель предметной области «Взаимодействие бизнес-объектов»
Рисунок 6 - Инфологическая модель предметной области «Взаимодействие бизнес-объектов»
Рисунок 7 - Инфологическая модель предметной области «Взаимодействие бизнес-объектов»
2.2.3 Даталогическая модель предметной области
В отличие от инфологической модели, которая осуществляет проектирование на логическом уровне, даталогическая модель позволяет рассматривать модель на физическом уровне. В реляционных БД даталогическое или логическое проектирование приводит к разработке схемы БД, то есть совокупности схем отношений, которые адекватно моделируют абстрактные объекты предметной области и семантические связи между этими объектами. Основой анализа корректности схемы являются так называемые функциональные зависимости между атрибутами БД. Под процессом модификации БД мы понимаем внесение новых данных в БД или удаление некоторых данных из БД, а также обновление значений некоторых атрибутов. Даталогическая модель представлена в приложении А. документооборот логистический автоматизация закупка
2.2.4 Диаграмма вариантов использования
Для того чтобы более точно понять, как должна работать система, все чаще используется описание функциональности системы через варианты использования (Use Case или прецеденты). Варианты использования это - описание последовательности действий, которые может осуществлять система в ответ на внешние воздействия пользователей или других программных систем. Варианты использования отражают функциональность системы с точки зрения получения значимого результата для пользователя, поэтому они точнее позволяют ранжировать функции по значимости получаемого результата.
Варианты использования предназначены в первую очередь для определения функциональных требований к системе и управляют всем процессом разработки. Все основные виды деятельности, такие как анализ, проектирование, тестирование выполняются на основе вариантов использования. Во время анализа и проектирования варианты использования позволяют понять как результаты, которые хочет получить пользователь, влияют на архитектуру системы и как должны себя вести компоненты системы, для того чтобы реализовать нужную для пользователя функциональность.
В процессе тестирования, описанные ранее варианты использования позволяют проще оценить точность реализации требований пользователей и позволяют провести пошаговую проверку этих требований.
Стратегия использования прецедентов при определении требований определяет необходимость дополнительно к вопросу "что пользователи ждут от системы?" задавать вопрос "что система должна сделать для конкретного пользователя?". Такой подход позволяет искать функции, которые нужны многим пользователям, и исключать те возможности, которые не могут помочь пользователям выполнять свои повседневные задачи.
В центре диаграммы установим актера - пользователя, взаимодействующего с шестью вариантами использования - шестью формами разработанной программы. USECASE-ы «Выбор формы проектов», «Выбор формы договоров», «Выбор формы ведения ДС», «Просмотр информации о формах», «Выбор формы закупочные спецификации» и «Выбор формы ведения единиц измерения» связываются с другими вариантами использования, которые представляют более детальную картину работы всей программы в целом.
Данная диаграмма построена в среде IBM Rational Rose Enterprise Edition v7.0.0, которая предназначена для визуального моделирования и проектирования программных систем на основе стандарта UML, позволяющих моделировать, как компоненты программного обеспечения, так и бизнес-процессы. Диаграмма вариантов использования приведена на рис. 8.
Рисунок 8 - Диаграмма вариантов использования
2.2.5 Диаграмма классов
Диаграмма классов является основным логическим представлением модели и содержит детальную информацию о внутреннем устройстве объектно-ориентированной программной системы или, используя современную терминологию, об архитектуре программной системы.
На диаграмме классов (рис. 9) представлены девять классов. Запуск программы начинается с класса «LAUNCHFORM.cs», где отображается логотип фирмы-разработчика. Далее управление передается в класс менеджера форм «MANAGERFORM», откуда можно запустить настройки (класс «SETTINGSFORM») и сами формы. В большинстве классов используются такие поля, как «connector» и «description», соответственно служащие для загрузки данных в формы из базы данных и описания выбранной формы. Представленные методы или функции преимущественно используются для добавления, удаления, обновления и загрузки данных.
Рисунок 9 - Диаграмма классов
2.2.6 Диаграмма состояний
Рассмотрим диаграмму состояний. Семантика понятия состояния довольно сложна. Дело в том, что характеристика состояний системы явным образом не зависит от логической структуры, зафиксированной на диаграмме классов. При рассмотрении состояний системы приходится отвлекаться от особенностей ее объектной структуры и мыслить категориями, описывающими динамический контекст поведения моделируемой системы.
На данной диаграмме расписаны основные состояния системы, начиная от ожидания выбора формы, заканчивая занесением изменений в базу данных. Над стрелками подписаны переходные состояния системы.
Рисунок 10 - Диаграмма состояний
2.2.7 Диаграмма компонентов
Диаграмма компонентов, в отличие от ранее рассмотренных диаграмм, описывает особенности физического представления системы. Диаграмма компонентов позволяет определить архитектуру разрабатываемой системы, установив зависимости между программными компонентами, в роли которых может выступать исходный, бинарный и исполняемый код. Во многих средах разработки модуль или компонент соответствует файлу. Пунктирные стрелки, соединяющие модули, показывают отношения взаимозависимости, аналогичные тем, которые имеют место при компиляции исходных текстов программ. Основными графическими элементами диаграммы компонентов являются компоненты, интерфейсы и зависимости между ними.
На данной диаграмме имеется главный исполняемый файл, который использует два пакета: «Forms» - графический и управленческий модуль для отображения, загрузки и обновления форм и «CONTROLSLIBRARY» - библиотечный модуль. Каждый из этих пакетов имеет собственные компоненты. В «Forms» используются компоненты для запуска каждой из форм. В «CONTROLSLIBRARY» же используются библиотечные компоненты, необходимые для реализации запускаемых форм.
Рисунок 11 - Диаграмма компонентов
3. Разработка программного средства
3.1 Выбор языка программирования
В ходе выполнения выпускной квалификационной работы была разработана программа «Автоматизация закупок IS»
Программа, разработанная в выпускной квалификационной работе, служит для использования на предприятии. Программа имеет интуитивно понятный интерфейс и позволяет использовать базу данных всем сотрудникам по сети, что значительно ускоряет и оптимизирует работу предприятия.
Для разработки был использован язык программирования C Sharp (C#) для операционных систем Windows 98/2000/XP/Vista/Seven. Листинг программы представлен в приложении В.
По сравнению с другими языками программирования C# выглядит намного проще. Многие языки обладают запутанным синтаксисом, приводящим к трудностям, как при компилировании программ, так и при их написании. Создатели C# предприняли специальные усилия для упрощения языка: - запрет прямой манипуляции памятью;
- более строгие правила преобразования типов;
- отказ от провала в следующую ветку в switch;
- запрещение множественного наследования.
C# занимает некоторую промежуточную позицию: из стандарта языка убраны наиболее неприятные и неоднозначные особенности С , но в то же время язык сохранил мощные выразительные возможности, присущие для таких языков, как С , Java или VB. Укажем некоторые особенности языка С , которые не поддерживаются C#: По умолчанию, С# запрещает прямое манипулирование памятью, предоставляя взамен богатую систему типов и сборку мусора. Непосредственная работа с памятью по-прежнему доступна в специальном режиме "опасного" кода, но требует явного декларирования. Как следствие, в C# активно используется всего один оператор доступа ".".
Преобразования типов в C# значительно строже, чем в С , в частности, большинство преобразований может быть совершено только явным образом. Кроме того, все приведения должны быть безопасными (т.е. запрещены неявные преобразования с переполнением, использование целых переменных как указателей и т.п.). Естественно, это заметно упрощает анализ типов при компиляции.
Одной из типичных ошибок в С было отсутствие оператора break при обработке одной из веток оператора switch. Проблема "провала" (fall-through) в C# решена кардинальным образом: компилятор требует наличия явного оператора перехода (break или goto case ) в любой ветке.
В C#, как и в Java, нет множественного наследования, вместо него предлагается использовать реализацию нескольких интерфейсов. Несмотря на то, что мнения по поводу множественного наследования сильно разнятся, отсутствие этого механизма в C# должно, по крайней мере, облегчить разработку компилятора.
3.2 Выбор среды разработки
Visual Studio 2010 Professional - универсальная многоплатформенная интегрированная среда всестороннего тестирования модулей и разработки веб-приложений, соблюдающая все основные критерии для обеспечения максимального качества кода. С поддерживающим работу на нескольких мониторах Visual Studio 2010 создание, отладка и развертывание приложений значительно упрощаются на всех этапах проектирования.
Visual Studio 2010 - универсальное средство для специалистов по разработке и проектированию, поддерживающее большинство платформ разработки, в том числе Windows и Windows Server, облачную и веб-среду, Office и SHAREPOINT и гарантирующее 100% корректность конечного кода.
Ключевыми функциями Visual Studio 2010 Professional являются: - организация рабочего пространства с возможностью одновременного применения нескольких средств разработки, всех необходимых для создания программного кода конструкторов и редакторов;
- возможность разработки приложений в Visual Studio 2010 через тестирование на уровне модулей и компиляцию;
- возможность создания разнообразных элементов для совместной работы над кодом в среде SHAREPOINT, в частности веб-модулей, списков, событий и рабочих процессов;
- поддержка встроенных инструментов разработки для создания приложений на платформе Windows 7, в частности мультисенсорных технологий и визуального настраиваемого интерфейса Windows Scenic Ribbon;
- построение многофункциональных веб-приложений на базе RIA и WPF;
- упрощенное развертывание в Visual Studio 2010: мгновенный перенос кода, параметров IIS и схемы БД созданных веб-приложений в среду производства, расположенную на целевом сервере.
3.3 Структура системы
Пакет Forms: LAUNCHFROM.cs - класс, с которого начинается запуск программы. Содержит в себе логотип фирмы-разработчика.
SETTINGSFORM.cs - класс, представляющий собой модальное окно настроек программы. Вызывается по кнопке "Настройки" из менеджера форм.
VEDENIEDOGOVORNIXSPECIFIKACIYFORM.cs - класс "Ведение ДС". Представляет собой форму, открывающуюся в отдельной вкладке. Вызывается по клику из дерева в менеджере форм.
DOGOVORNIESPECIFIKACIIFORM.cs - класс "Договорные спецификации". Представляет собой форму, открывающуюся в отдельной вкладке. Вызывается по клику в необходимой строке главной таблицы "Ведение ДС".
Пакет CONTROLSLIBRARY: ADDINGPANELFORSPLITCONTAINER.cs - составная часть стандартного компонента SPLITCONTAINER, представляющая собой разделительную панель с кнопками.
Draggable.cs - представляет собой панель, которую можно передвигать по форме в любых направлениях с помощью технологии "Drag and Drop".
EXTENDEDCONTEXTMENU.cs - модификация стандартного компонента CONTEXTMENU (всплывающее меню), позволяющая располагать внутри себя любые другие компоненты.
EXTENDEDDATAGRIDVIEW.cs - модификация стандартного компонента DATAGRIDVIEW (таблица), позволяющая внутри себя содержать группированные столбцы.
EXTENDEDTABCONTROL.cs - модификация стандартного компонента TABCONTROL (вкладка), в котором присутствует кнопка закрытия вкладки.
FILTERCONTROL.cs - компонент, позволяющий с помощью sql-запросов совершать фильтрацию в необходимой таблице.
TREEGRIDVIEW.cs - модификация стандартного компонента DATAGRIDVIEW (таблица), который имеет уже древовидно-табличную структуру.
BLOCKPANEL.cs - компонент, представляющий собой блок, который может принимать состояния: активный или неактивный.
PRESSEDBUTTON.cs - модификация стандартного компонента Button (кнопка), которая может принимать 2 состояния: вдавлена или не нажата.
SCROLLPANEL.cs - модификация стандартного компонента Panel (панель), при переполнении которого другими различными компонентами появляются боковые кнопки прокрутки.
Splitter.cs - компонент, представляющий собой разделительную полосу, служащую для оформления.
TEXTBOXBUTTON.cs - модификация стандартного компонента TEXTBOX (текстовое поле), в который встроена кнопка, при клике по которой открывается модальное окно со списком выбора.
Рисунок 12 - Структурная схема разработанного ПО
На рисунке 12 приведена структурная схема разработанного программного обеспечения.
Опишем каждый блок программы более подробно: Загрузка программы. На данном этапе перед самим запуском отображается логотип фирмы-разработчика и после появляется менеджер выбора форм.
Выбор форм. В менеджере доступны для выбора две формы: «Ведение ДС» и «Закупочные спецификации».
Для «Ведения ДС» действия могут развиваться следующим образом: - загрузка данных о ДС;
- фильтрация и сортировка данных пользователем;
- редактирование ДС;
- управление транзакцией;
- выбор ДС;
- предпросмотр план/факт данных.
В последнем пункте мы можем перейти на форму «Договорные спецификации», откуда доступны действия: - фильтрация, сортировка, смена порядка отображения;
- редактирование групп и позиций, перетаскивание из плана в факт;
- управление транзакцией.
Для формы «Закупочные спецификации» доступны следующие действия: - загрузка данных о закупочных спецификациях;
- фильтрация и сортировка данных пользователем;
- мониторинг закупок;
- управление транзакцией.
Если пользователь не хочет переходить на форму «Договорные спецификации» или продолжать работу с программой, то он может закрыть запущенное приложение.
3.4 Руководство администратора
В этом разделе рассмотрим все шаги, которые необходимы для установки и запуска программы «Автоматизация закупок IS» («WAREHOUSESIS»).
Установить Microsoft.NET Framework 4. Следовать инструкциям установки.
Установить Microsoft SQL Server 2008 R2. Следовать инструкциям установки.
Создать базу данных, используя скрипты. Пользователь sa. Пароль 12345.
Установить программу, запустив файл setup.exe.
При запуске запустится мастер установки (рис. 13). Необходимо нажать на кнопку «Далее».
Рисунок 13
Затем появится окно (рис.14), в котором нужно указать пап
Вывод
В ходе выполнения выпускной квалификационной работы была изучена предметная область сервисно-интегрирующей компании, где необходимо было разработать программный продукт, служащий для автоматизации сложного логистического процесса внутри самой компании.
В ходе проектирования были построены различные модели системы, которые наглядным образом показывают, каким образом она функционируют. По окончанию разработки программы была написана документация в виде руководства администратора и руководство пользователя, в которых дается подробное описание, как необходимо правильно установить программу и как ее в дальнейшем использовать.
В качестве языка программирования был выбран язык C Sharp (C#) изза его простоты в использовании и удобного графического интерфейса. В качестве системы управления реляционными базами данных была выбрана Microsoft SQL Server 2008 R2.
На основе проведенного тестирования можно сказать, что разработанный программный продукт полностью удовлетворяет поставленным задачам в начале разработки и успешно эксплуатируется в сервисно-интегрирующей компании «БИАЙ-лизинг».
Список литературы
1. Электронный документооборот. - Электрон. дан. - Режим доступа: 2. Википедия - свободная энциклопедия - Электрон. дан. - Режим доступа: http://ru.wikipedia.org/wiki/UML
3. Интернет университет информационных технологий - «Особенности разработки диаграмм вариантов использования в среде IBM Rational Rose» - Электрон. дан. - Режим доступа: http://www.intuit.ru/department/se/ibmrrose/3/
4. Интернет университет информационных технологий - «Особенности разработки диаграмм классов в среде IBM Rational Rose 2003» - Электрон. дан. - Режим доступа: http://www.intuit.ru/department/se/ibmrrose/4/
5. Интернет университет информационных технологий - «Особенности разработки диаграммы деятельности в среде IBM Rational Rose 2003» - Электрон. дан. - Режим доступа: http://www.intuit.ru/department/se/ibmrrose/10/
6. Интернет университет информационных технологий - «Особенности разработки диаграммы последовательности в среде IBM Rational Rose» - Электрон. дан. - Режим доступа: http://www.intuit.ru/department/se/ibmrrose/8/
7. Авторизованный учебный Центр Aptech Computer Education. Основы C# / Aptech Computer Education, 2004. - 248 с.
8. Авторизированный учебный Центр Aptech Computer Education. Разработка приложение с использованием WINFORMS / Aptech Computer Education, 2004. - 236 с.
9. Авторизированный учебный Центр Aptech Computer Education. Основы систем управления реляционными базами данных SQL Server / Aptech Computer Education, 2003. - 203 с.
10. Авторизированный учебный Центр Aptech Computer Education. SQL Server / Aptech Computer Education, 2003. - 157 с.
11. Pierre Henri Kuate. NHIBERNATE in Action / Tobin Harris, Christian Baver, Gavin King. - Covers Version 1.2 - Manning Publications, 2009. - 399 с.
12. Jason Dentler. NHIBERNATE 3.0 Cookbooc / Jason Dentler. - Packt Publishing, 2010. 328 c.
13. Кристиан Нейгел. C# 2008 и платформа.NET 3.5 для профессионалов / Кристиан Нейгел, Билл Ивьен, Джей Глинн, Карли Уотсон, Морган Скиннер. - Компьютерное изд-во «Диалектика», 2009. - 1392 с.
14. Пол Нильсен. Microsoft SQL Server 2005. Библия пользователя / Пол Нильсен - компьютерное изд-во «Диалектика», 2008. - 1228 с.
Вы можете ЗАГРУЗИТЬ и ПОВЫСИТЬ уникальность своей работы
