Обзор и анализ бухгалтерских технологий

При открытии такого окна в модальном режиме оно занимает все пространство экрана, перекрывая панели 1С: Предприятия и панели Windows.

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

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

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

Рисунок 11. Окно редактирования

Наряду с этим, могут существовать общие формы, не принадлежащие конкретным объектам прикладного решения (рисунок 12).

Рисунок 12. Общие формы

Каждый объект прикладного решения может использоваться для выполнения некоторых стандартных действий. Например, для любого справочника может потребоваться отображать список его элементов, отображать отдельные элементы справочника, отображать группу справочника, выбирать элементы и группы элементов из справочника. Для любого документа список таких действий будет гораздо меньше: просмотр списка документов, выбор из списка документов и просмотр отдельного документа.

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

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

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

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

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

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

а) поля ввода с функциональными кнопками (выбор, очистка, открытие значений);

б) редактирование в одном элементе любых типов данных;

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

г) современный эргономичный дизайн элементов управления.

Элементы управления предназначены для отображения и редактирования данных в форме. Также как и сама форма, элементы управления связаны с данными при помощи реквизитов формы.

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

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

Например, если элемент управления поле ввода, связать с данными, имеющими тип Строка, то оно будет иметь вид (рисунок 13).

Рисунок 13. Поле ввода

Если же поле ввода связать с данными, имеющими тип Дата, то внешний вид поля ввода изменится: появятся символы разделителей даты и дополнительная кнопка выбора (рисунок 14).

Рисунок 14. Поле ввода для даты

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

Рисунок 15. Выбор даты

Если же поле ввода связать с каким-либо объектом прикладного решения, то у него появятся две дополнительные кнопки: кнопка очистки и кнопка выбора, имеющая уже другую пиктограмму, т.к. предназначена для выбора нужного объекта прикладного решения из формы списка (рисунок 16).



Рисунок 16. Форма списка

Элементы управления, используемые в формах 1С:Предприятия, ориентированы на выполнение бизнес-задач. Например, поле ввода может иметь ряд дополнительных кнопок: выбора из списка, выбора, очистки, регулирования и открытия. Кроме этого, у поля ввода существует режим автоотметки незаполненного (подчеркивание красным пунктиром), который позволяет выделять поля, обязательные для заполнения пользователем (рисунок 17).

Рисунок 17. Поле ввода с дополнительными кнопками

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

Рисунок 18. Виды поля вывода

Например, для поля ввода, содержащего число, нажатие на кнопку выбора будет приводить к открытию калькулятора (рисунок 19).



Рисунок 19. Поле ввода для числа

А для поля ввода, содержащего дату, нажатие той же самой кнопки будет приводить к открытию календаря (рисунок 20).

Рисунок 20. Ввод даты

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

Рисунок 21. Поля для ввода неопределенного типа

Специальная пиктограмма в кнопке выбора (Т) говорит о том, что для этого поля ввода еще не определен тип вводимых данных. При нажатии на эту кнопку система откроет специальное окно для выбора типа данных, которые будут содержаться в этом поле.

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

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

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

а) разнообразные возможности оформления отчета, включая тип и размер шрифта, цвет текста и фона, тип и цвет рамки, рисунки и многое другое;

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

в) поддерживается механизм расшифровок, когда при щелчке на строке или ячейке отчета формируется более детальный отчет или открывается объект базы данных;

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

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

е) в табличном документе могут быть расположены диаграммы различного вида для наглядного представления экономической информации в графическом виде;

ж) табличный документ может быть легко сохранен в файл MXL, а также в другие форматы, например, лист Excel, MXL7 и др.

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

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

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

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



Рисунок 22. Окно сообщения

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

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

Рисунок 23. Окно предупреждения

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

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

2.2 Аппаратные интерфейсы

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

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

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

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

Используемый компьютер должен иметь следующие характеристики:

а) процессор - частота не менее 1 Ггц;

б) оперативная память - не менее 512 Мб;

в) жесткий диск - не менее 40 Гб;

г) мышь;

д) клавиатура.

2.3 Программные интерфейсы

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

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

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

Программные компоненты, необходимые для функционирования приложения:

а) операционная система - Windows98 и выше;

б) «1С: Предприятие 8.2»;

в) аппаратный ключ HASP.

HASP - мультиплатформенная аппаратно-программная система защиты программ и данных от нелегального использования и несанкционированного распространения разработанная компанией Aladdin Knowledge Systems Ltd. По утверждению www.softkey.info на 2005 год являлся одним из самых широкоприменяемых аппаратных средств для защиты ПО.

Защита HASP включает в себя:

а) электронный ключ HASP;

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

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

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

Электронные ключи HASP выпускаются в различных исполнениях:

а) USB-брелок;

б) LPT-ключ с возможностью «прозрачного» подключения других ключей и устройств;

в) PCMCIA-карта;

г) внутренняя плата стандарта PCI и ISA.

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

Электронный ключ (также аппаратный ключ, иногда донгл от англ. dongle) - аппаратное средство, предназначенное для защиты программного обеспечения (ПО) и данных от копирования, нелегального использования и несанкционированного распространения.

Электронный ключ - небольшое по размерам аппаратное устройство.

Основой данной технологии является специализированная микросхема ASIC, либо специализированный защищённый микроконтроллер, имеющие уникальные для каждого ключа алгоритмы работы. Донглы также имеют защищённую энергонезависимую память небольшого объёма, более сложные устройства могут иметь встроенный криптопроцессор (для аппаратной реализации шифрующих алгоритмов), часы реального времени. Аппаратные ключи могут иметь различные форм-факторы, но чаще всего они подключаются к компьютеру через USB-, LPT- или PCMCIA-интерфейсы.

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

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

Многие компании, работающие в области защиты информации, предлагают свой взгляд на то, каким должен быть электронный ключ. На российском рынке наиболее известны следующие линейки продуктов (в алфавитном порядке): Guardant от компании «Актив», HASP от Aladdin, LOCK от Astroma Ltd., Rockey от Feitian, SenseLock от Seculab, Sentinel от SafeNet и др.

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

а) проверка наличия подключения ключа;

б) считывание с ключа необходимых программе данных в качестве параметра запуска;

в) запрос на расшифрование данных или исполняемого кода, необходимых для работы программы (предварительно разработчик защиты шифрует часть кода программы и, понятно, непосредственное выполнение такого зашифрованного кода приводит к ошибке);

г) проверка целостности исполняемого кода путём сравнения его текущей контрольной суммы с оригинальной контрольной суммой, считываемой с ключа;

д) запрос к встроенным в ключ часам реального времени (при их наличии) и т. д.

Стоит отметить, что некоторые современные ключи (ключи Senselock от Seculab, Rockey6 Smart от Feitian) позволяют разработчику хранить отдельные части кода приложения (например, недетерминированные специфические алгоритмы разработчика, получающие на вход большое число параметров) и исполнять их в самом ключе на его собственном микропроцессоре. Помимо защиты ПО от нелегального использования такой подход позволяет защитить используемый в программе алгоритм от изучения и клонирования конкурентами.

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

Алгоритм шифрования может быть секретным или публичным. Секретные алгоритмы разрабатываются самим производителем средств защиты, в том числе и индивидуально для каждого заказчика. Главным недостатком использования таких алгоритмов является невозможность оценки криптографической стойкости. С уверенностью сказать, насколько надёжен алгоритм, можно было лишь постфактум: взломали или нет. Публичный алгоритм, или «открытый исходник», обладает криптостойкостью несравнимо большей. Такие алгоритмы проверяются не случайными людьми, а рядом экспертов, специализирующихся на анализе криптографии. Примерами таких алгоритмов могут служить широко используемые ГОСТ 28147-89, AES, RSA, Elgamal и др.

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

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

Важно то, что для использования автоматического инструмента защиты не требуется доступ к исходному коду приложения. Помимо использования автоматической защиты, разработчику ПО предоставляется возможность самостоятельно разработать защиту, интегрируя систему защиты в приложения на уровне исходного кода. Для этого в SDK включены библиотеки для различных языков программирования, содержащие описание функциональности API для данного ключа. API представляет собой набор функций, предназначенных для обмена данными между приложением, системным драйвером (и сервером в случае сетевых ключей) и самим ключом. Функции API обеспечивают выполнение различных операций с ключом: поиска, чтения и записи памяти, шифрования и расшифрования данных при помощи аппаратных алгоритмов, лицензирования сетевого ПО и т. д.

Умелое применение данного метода обеспечивает достаточно высокий уровень защищённости приложений. Нейтрализовать защиту, встроенную в приложение, достаточно трудно вследствие её «размытости» в теле программы.

2.4 Детальные требования

2.4.1 Функциональные требования

Модуль должен быть предназначен для выполнения следующих основных технологических операций:

а) конфигурация не должна быть изменена;

б) данные нужно получать из бухгалтерских итогов за требуемый период;

в) данные должны обрабатываться корректно и сохраняться во внешний файл;

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

д) подоходный налог должен рассчитываться по удельному весу;

е) шаблон создаваемой таблицы должен быть переформирован в текст и перекодирован в кодировке UTF8.

2.4.2 Нефункциональные требования

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

Т.к. модуль должен разрабатываться для 1С Предприятия, то возникает ограничение по платформе Windows: это платформа Windows 2000, Windows XP, Windows Vista и др. версии платформы выше Windows 98.

3. Специальная часть

3.1 Моделирование предметной области

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

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

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

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

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

К моделям предметных областей предъявляются следующие требования:

формализация, обеспечивающая однозначное описание структуры
предметной области;

понятность для заказчиков и разработчиков на основе применения
графических средств отображения модели;

реализуемость, подразумевающая наличие средств физической реализации модели предметной области в ПО;

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

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

Структурный аспект предполагает построение:

объектной структуры, отражающей состав взаимодействующих в процессах материальных и информационных объектов предметной области;

функциональной структуры, отражающей взаимосвязь функций (действий) по преобразованию объектов в процессах;

структуры управления, отражающей события и бизнес-правила, которые воздействуют на выполнение процессов;

организационной структуры, отражающей взаимодействие организационных единиц предприятия и персонала в процессах;

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

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

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

3.2 Спецификация вариантов использования

3.2.1 Распределение требований по субъектам и вариантам использования

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

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

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

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

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

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

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

не соединять стрелкой два варианта использования непосредственно. Диаграммы данного типа описывают только сами варианты использования, а не порядок их выполнения. Для отображения порядка выполнения вариантов использования применяют диаграммы деятельности;

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

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

Достоинства модели вариантов использования заключаются в том, что она:

определяет пользователей и границы системы;

определяет системный интерфейс;

удобна для общения пользователей с разработчиками;

используется для написания тестов;

является основой для написания пользовательской документации;

хорошо вписывается в любые методы проектирования (как объектно-ориентированные, так и структурные).

Прецедент (Use case) представляет собой некий целостный набор функций, имеющих определенную ценность для субъекта. Субъект, который не общается с прецедентом, не имеет смысла, однако обратное утверждение не всегда верно (т.е. прецедент, который не общается с субъектом - вещь допустимая). Могут существовать некоторые прецеденты, которые обобщают или уточняют основной прецедент и не взаимодействуют непосредственно с субъектами. Они используются как внутренние в модели прецедентов и помогают основному прецеденту выработать результат, предоставляемый субъекту.

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

3.2.2 Описательная спецификация варианта использования

Каждый прецедент должен быть описан с помощью документально зафиксированного потока событий (flow of events). Описание должно содержать следующие разделы:

а) краткое описание;

б) участвующие субъекты;

в) предусловия, необходимые для инициирования прецедентов;

г) детализированное описание потока событий, которое включает:

1) основной поток, который можно разбить для того, чтобы показать подчиненные потоки событий;

2) альтернативные потоки для определения исключительных ситуаций.

3.2.3 Соответствие функциональных требований и классов-сущностей

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

Определение внутреннего состояния системы дается в модели классов (class model). К элементам, принимающим участие в моделировании классов, относятся сами классы, атрибуты и операции классов, ассоциации, агрегации и композиции, а также обобщения. Диаграмма классов (class diagram) дает обобщенное визуальное представление обо всех этих элементах модели.

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

3.3 Статический вид системы

3.3.1 Диаграммы вариантов использования

Диаграмма прецедентов (англ. use case diagram, диаграмма вариантов использования) - диаграмма, на которой отражены отношения, существующие между акторами и прецедентами

Основная задача - представлять собой единое средство, дающее возможность заказчику, конечному пользователю и разработчику совместно обсуждать функциональность и поведение системы (рисунок 24).

Рисунок 24. Диаграмма прецедентов

3.3.2 Диаграмма классов на уровне сущностей

Диаграмма классов, Class diagram - статическая структурная диаграмма, описывающая структуру системы, она демонстрирует классы системы, их атрибуты, методы и зависимости между классами.

Подставив в соответствие функциональные требования и классы-сущности составим диаграмму классов (рисунок 25).

Рисунок 25. Диаграмма классов на уровне сущностей

Композиция -- более строгий вариант агрегации. Известна также как агрегация по значению. Композиция имеет жёсткую зависимость времени существования экземпляров класса контейнера и экземпляров содержащихся классов. Если контейнер будет уничтожен, то всё его содержимое будет также уничтожено.

Различия между композицией и агрегацией

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

Графически обобщение представляется линией с пустым треугольником у супертипа. Обобщение также известно как наследование или «is a» взаимосвязь.

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

Графически представляется пунктирной стрелкой, идущей от зависимого элемента к тому, от которого он зависит.

Зависимость может быть между экземплярами, классами или экземпляром и классом.

3.3.3 Диаграмма деятельности

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

Графически диаграмма деятельности представляется в форме графа деятельности, вершинами которого являются состояния действия, а дугами - переходы от одного состояния действия к другому. Таким образом, диаграммы деятельности можно считать частным случаем диаграмм состояний. Именно они позволяют реализовать в языке UML особенности процедурного и синхронного управления, обусловленного завершением внутренних деятельностей и действий. Метамодель UML предоставляет для этого необходимые термины и семантику. Основным направлением использования диаграмм деятельности является визуализация особенностей реализации операций классов, когда необходимо представить алгоритмы их выполнения. При этом каждое состояние может являться выполнением операции некоторого класса либо ее части, позволяя использовать диаграммы деятельности для описания реакций на внутренние события системы. Под деятельностью англ. activity понимается спецификация исполняемого поведения в виде координированного последовательного и параллельного выполнения подчинённых элементов - вложенных видов деятельности и отдельных действий англ. action, соединённых между собой потоками, которые идут от выходов одного узла ко входам другого.

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



Рисунок 26. Диаграмма деятельности

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

Таким образом, диаграммы деятельности можно считать частным случаем диаграмм состояний. Именно они позволяют реализовать в языке UML особенности процедурного и синхронного управления, обусловленного завершением внутренних деятельностей и действий. Метамодель UML предоставляет для этого необходимые термины и семантику. Основным направлением использования диаграмм деятельности является визуализация особенностей реализации операций классов, когда необходимо представить алгоритмы их выполнения.

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

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

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

Валовая прибыль вычисляется:

Валовая прибыль = Чистый доход от продаж - Себестоимость реализованной продукции или услуги.

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

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

Ведомость-список, сводка каких-либо данных. В данном отчете можно посмотреть ведомость запасов на складах за указанный период (рисунок 28 и рисунок 29).

Рисунок 27. Валовая прибыль



Рисунок 28. Ведомость по запасам

Рисунок 29. Ведомость по запасам

Ведомость учета денежных средств показывает движение денежных средств на складе за указанный период (рисунок 30 и рисунок 31).



Рисунок 30. Ведомость учета денежных средств

Рисунок 31. Ведомость учета денежных средств

4. Обоснование экономической эффективности работы

4.1 Выбор и обоснование методики расчета экономической эффективности

Экономический эффект - разность между результатами деятельности хозяйствующего субъекта и произведенными для их получения затратами. Различают положительный и отрицательный экономический эффект. Положительный экономический эффект достигается в случае, когда результаты (продукт в стоимостном выражении) превышают затраты. Этот эффект называется прибылью. Для его получения необходимо расширение производства, либо экономия ресурсов на единицу продукта, либо и то, и другое. Если затраты превышают результаты, имеет место отрицательный экономический эффект, т. е. убыток.

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

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

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

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

Показатели экономической эффективности программного изделия определяются:

экономической оценкой результатов влияния программного изделия на конечный результат их использования (основное направление анализа и расчета показателей эффективности - для прикладных программных изделий);

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

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

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

4.2 Расчет экономической эффективности разработки и внедрения приложения “Учет и анализ финансовой деятельности предприятия”

4.2.1 Расчет затрат на разработку и внедрение данного приложения

Затраты на разработку и внедрение приложения составляют:

,

где - затраты на разработку технического задания;

- затраты на проектирование приложения;

- затраты на программную реализацию;

- затраты на тестирование приложения;

- затраты на внедрение приложения;

- затраты на приобретение комплекса технических средств.

4.2.2 Расчет затрат на разработку технического задания

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

,

где - заработная плата разработчика за месяц;

- время, затраченное на разработку алгоритма решения поставленной задачи;

. - отчисления на социальные нужды (11%).

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

 0.11 = 50000 / 22 3 0.11 = 750(тенге),

С_тз = 50000 / 22 3 + 750 = 7568 (тенге).

4.2.3 Расчет затраты на проектирование приложения

Затраты на проектирование приложения определяются:

,

где - заработная плата разработчика за день;

В - время, затраченное на разработку алгоритма решения поставленной задачи;

Отч. - отчисления на социальные нужды (11%).

На проектирование алгоритма приложения было затрачено 5 дней. Заработная плата разработчика составляет 50000 тенге в месяц. Тогда затраты на проектирование алгоритма приложения составляют:

50000 / 22 5 0.11 = 1250 (тенге),

= 50000 / 22 5 + 1250 = 12614 (тенге).

4.2.4 Расчет затрат на программную реализацию

Затраты на программную реализацию определяются формулой:

,

где, - стоимость машинного времени, затраченного на отладку программы;

- фонд заработной платы программиста, занятого написанием и отладкой программы.

где - время, затраченное при работе на ЭВМ в день;

- количество дней работы на ЭВМ;

- стоимость часа машинного времени.

где - оклад программиста, занятого написанием программы, за день;

- отчисления на социальные нужды (11%).

Количество дней работы на ЭВМ составляет 30 дней, в день на программную реализацию затрачивалось 5 часов в день, в то время как стоимость машинного времени составляет 140 тг в час. Заработная плата программиста составляет 50000 тенге в месяц. Следовательно затраты на реализацию будут вычислены таким образом:

= 5 140 = 21000 (тенге),

= 0.11 = 30 50000 / 22 0.11 = 7500 (тенге),

= * + = 30 75000 / 22 + 7500 = 75680 (тенге),

= + = 21000 + 75680 = 96680(тенге).

4.2.5 Расчет затрат на тестирование приложения

Затраты на тестирование приложения составляют:

,

где - стоимость машинного времени, затраченного на отладку приложения;

- фонд заработной платы программиста, занятого написанием и отладкой приложения.

,

где - время, затраченное при работе на ЭВМ в день;

- количество дней работы на ЭВМ;

- стоимость часа машинного времени.

где, - оклад программиста, занятого написанием приложения, за день;

- отчисления на социальные нужды (11%).

В день на тестирование приложения затрачивалось 4 часов, а количество дней работы на ЭВМ составляет 18 дней. Стоимость машинного времени составляет 140 тг в час. Заработная плата программиста составляет 50000 тенге в месяц. Следовательно, затраты на тестирование приложения будут вычислены таким образом:

= 4 18 140 = 10080 (тенге),

= 0.11 = 18 50000 / 22 0.11 = 4500(тенге),

Ф_З/П = + = 18 50000 / 22 + 4500 = 45410 (тенге),

= + = 10080 + 45410 = 55490 (тенге).

4.2.6 Расчет затрат, связанных с внедрением приложения

Расчет затрат, связанных с внедрением приложения:

,

где - стоимость машинного времени на время внедрения;

- фонд заработной платы программиста на время внедрения.

,

где - время работы на ЭВМ в день;

- количество дней работы на ЭВМ;

- стоимость часа машинного времени.

где - оклад программиста, занятого внедрением приложения;

- отчисления на социальные нужды (11%);

Д - количество рабочих дней в месяц.

Для внедрения приложения программист должен установить в систему определенные компиляторы, отладочные программы. Количество дней работы на ЭВМ составляет 1 день, в день на внедрение данного реализованного приложения затрачивалось 4 часа, стоимость машинного времени составляет 140 тг в час. Заработная плата программиста составляет 40000 тенге в месяц. Следовательно, затраты на внедрение приложения будут вычислены таким образом:

=4 1 140 = 560 (тенге),

 = 0.11 = 40000 1 / 22 0.11 = 200 (тенге),

= 40000 1 / 22 + 200 = 2018 (тенге),

= 560 + 2018 = 2578 (тенге).

4.2.7 Расчет затрат на комплекс технических средств

Затрат на комплекс технических средств определяются формулой:

где - стоимость компьютера;

- стоимость принтера.

Для реализации приложения остановимся на следующем составе технических средств:

компьютеры (CPU Intel Pentium 4 630 BOX 3.0 ГГц/ 2Мб/ 800МГц LGA775.);

принтеры (HP LaserJet Pro P1102).

= 80000 (тенге);

= 15000 (тенге);

= 95000 (тенге).

Теперь можно вычислить и затраты на разработку и внедрение приложения:

=7568 + 12614 +96680 +55490 +2578 + 95000 = 269930 (тенге)

4.2.8 Расчет затрат до внедрения приложения

Раньше учетом и анализом финансовой деятельности предприятия занимались 2 сотрудника.

Затраты на решение задачи без использования программы рассчитываются по формуле:

где - отчисления на социальные нужды (11%);

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

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

где - заработная плата работников;

- количество работников.

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

= 400002 12 = 960000 (тенге),

= 960000 0.11 = 105600 (тенге),

= 960000 + 105600 = 1065600 (тенге).

4.2.9 Расчет затрат после внедрения приложения

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

...