Размещено на http://www.allbest.ru/

Краткая аннотация

Курсовой проект является разработкой автоматизации рабочего места менеджера, ведущего учет и анализ расходов сотрудников организации «ИУиБ», с помощью программных средств : Microsoft SQL Server 2000 и Delphi 7, Erwin, BP Win, CASE-систем.

Ниже описываются общие сведения о современных информационных системах, инструментах и методологиях разработки программного обеспечения, формировании технического задания (ТЗ) на проектирование информационной системы

Глоссарий основных терминов

АРМ менеджера, ведущего учет и анализ расходов сотрудников организации «ИУиБ»



Введение

Цель

Глоссарий содержит описания терминов, используемых при проектировании АРМ менеджера, ведущего учет и анализ расходов сотрудников организации «ИУиБ»

Определяются основные понятия, непосредственно связанные с составлением отчета учетов расхода .

Контекст

Глоссарий создан в рамках проекта АРМ менеджера, ведущего учет и анализ расходов сотрудников организации «ИУиБ»



Понятия, используемые при описании исходной информации

расход

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

Работа

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

Работа является реализацией некоторого типа работ и относится к конкретному отчету

Денежные средства

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

Задание (элемент плана)

Задание - атомарная единица планирования менеджером. В процессе предварительного планирования каждой работе соответствует своё задание (отношение 1:1). При планировании менеджером в случае необходимости работы разбиваются на элементы - элементарные отчеты Задание ассоциируется с одной единицей денежных средств и одним или более сотрудникам. Один из работников является ответственным исполнителем.

Задание не может превышать по продолжительности рабочую смену.

Сотрудник

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

Штатное расписание

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

Бригада

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

Смена

Смена - временной интервал в течение суток. Как правило, различают три 8-часовые, две двенадцатичасовые смены и работу «в день», например - с 9 до 18.

Расписание смены

Расписание - график чередования смен при работе бригады.

Понятия, используемые при планировании

Статус работы

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

Допустимый интервал.

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

Критический срок составления отчета учетов расхода.

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

Коллизия

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

Используемые документы

Предварительный план составления отчета

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

Сменное задание

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

SQL Server - мощная многофункциональная система управления базами данных (СУБД).

ERwin Data Modeler (ранее называвшийся AllFusion Data Modeler) -- программный продукт в области реализации средств CASE-технологий.

ПО - программное обеспечение.

Rational Unified Process (RUP) -- методология разработки программного обеспечения, созданная компанией Rational Software.

Microsoft Solutions Framework (MSF) -- методология разработки программного обеспечения, предложенная корпорацией Microsoft. MSF

SWEBOK (Software Engineering Body of Knowledge) -- документ, подготавливаемый комитетом Software Engineering Coordinating Committee, в который вовлечено сообщество IEEE Computer Society.

ISO/IEC 12207 [5] (ISO - International Organization of Standardization - Международная организация по стандартизации, IEC - International Electrotechnical Commission - Международная комиссия по электротехнике)- основной нормативный документ, регламентирующий ЖЦ ПО.

ГОСТ 34.601-90 - Российский стандарт для проектирования автоматизированной системы.

Модель ЖЦ ПО - это структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ.

ЖЦ ПО - это непрерывный процесс, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации.

СУБД - система управления базой данных.



Введение

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

В последнее десятилетие ушедшего века ситуация претерпела качественные изменения. Если попытаться сформулировать "портрет" современной информационной системы масштаба предприятия в виде десятка тезисов, то мы увидим, что она имеет:

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

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

? наличие средств коммуникации и элементов корпоративного решения задач коллективом пользователей.

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

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

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

? инвариантность (в определенных пределах) к аппаратным и операционным средам функционирования серверных и клиентских приложений.

? использование стандартизованных языков и протоколов для представления и манипулирования данными.

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

Корпоративные Информационные Системы предназначены для автоматизации деятельности предприятия. В англоязычной литературе понятие "КИС" неразрывно связано с понятием "ERP" (Enterprise Resource Planning). В основе ERP-систем лежит международный стандарт управления предприятием MRP-II (Manufacture Resource Planning), обеспечивающий возможность учета, анализа и планирования основных ресурсов - финансов, человеческих, материальных. Соответственно, корпоративные ERP-системы - набор интегрированных приложений, которые комплексно, в едином информационном пространстве поддерживают все основные аспекты управленческой деятельности предприятий: планирование ресурсов (финансовых, человеческих, материальных) для производства товаров (услуг), оперативное управление выполнением планов (включая снабжение, сбыт, ведение договоров), все виды учета и анализ результатов хозяйственной деятельности.

Среди требований, предъявляемых к современным КИС:

? централизация данных в единой базе (в основе всегда промышленная СУБД).

? близкий к реальному времени режим работы.

? сохранение общей модели управления для предприятий разных отраслей.

? поддержка территориально-распределенных структур.

? работа на широком круге аппаратно-программных платформ и СУБД.



Глава 1. Анализ предметной области и формирование ТЗ на проектирование ИС

1.1 Понятие ЖЦ системы

Одним из базовых понятий методологии проектирования ИС является понятие жизненного цикла ее программного обеспечения (ЖЦ ПО).

ЖЦ ПО - это непрерывный процесс, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации.

Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207 [5] (ISO - International Organization of Standardization - Международная организация по стандартизации, IEC - International Electrotechnical Commission - Международная комиссия по электротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.

Структура ЖЦ ПО (по стандарту ISO/IEC 12207) включает три группы процессов:

? основные процессы ЖЦ ПО - приобретение, поставка, разработка, эксплуатация, сопровождение.

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

? организационные процессы - управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого ЖЦ, обучение.

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

Эксплуатация включает в себя работы по внедрению компонентов ПО в эксплуатацию, в том числе:

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

? обеспечение эксплуатационной документацией.

? проведение обучения персонала и т.д..

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

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

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

Обеспечение качества проекта связано с проблемами верификации, проверки и тестирования ПО.

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

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

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

1.1.1 Процессы жизненного цикла ПО

? Основные:

o Приобретение (действия и задачи заказчика, приобретающего ПО).

o Поставка (действия и задачи поставщика, который снабжает заказчика программным продуктом или услугой).

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

o Эксплуатация (действия и задачи оператора -- организации, эксплуатирующей систему).

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

? Вспомогательные:

o Документирование (формализованное описание информации, созданной в течение ЖЦ ПО).

o Управление конфигурацией (применение административных и технических процедур на всем протяжении ЖЦ ПО для определения состояния компонентов ПО, управления его модификациями).

o Обеспечение качества (обеспечение гарантий того, что ИС и процессы ее ЖЦ соответствуют заданным требованиям и утвержденным планам).

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

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

o Совместная оценка (оценка состояния работ по проекту: контроль планирования и управления ресурсами, персоналом, аппаратурой, инструментальными средствами).

o Аудит (определение соответствия требованиям, планам и условиям договора).

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

? Организационные:

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

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

o Усовершенствование (оценка, измерение, контроль и усовершенствование процессов ЖЦ).

o Обучение (первоначальное обучение и последующее постоянное повышение квалификации персонала).

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

1. Инициирование приобретения.

2. Подготовка заявочных предложений.

3. Подготовка и корректировка договора.

4. Надзор за деятельностью поставщика.

5. Приемка и завершение работ.

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

1. Формирование требований к системе.

2. Формирование списка программных продуктов.

3. Установление условий и соглашений.

4. Описание технических ограничений (среда функционирования системы и т. д.).

1.1.2 Модели жизненного цикла ПО

Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО. Под моделью ЖЦ понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ. Модель ЖЦ зависит от специфики ИС и специфики условий, в которых последняя создается и функционирует. Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки. Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы. К настоящему времени наибольшее распространение получили следующие две основные модели ЖЦ:

? каскадная модель (70-85 г.г.);

? спиральная модель (86-90 г.г.).

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

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

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

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

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

Для преодоления перечисленных проблем была предложена спиральная модель ЖЦ, делающая упор на начальные этапы ЖЦ: анализ и проектирование. На этих этапах реализуемость технических решений проверяется путем создания прототипов. Каждый виток спирали соответствует созданию фрагмента или версии ПО, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации. Разработка итерациями отражает объективно существующий спиральный цикл создания системы. Неполное завершение работ на каждом этапе позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем. При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации. Главная же задача - как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований.

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

Итерационная модель.

Естественное развитие каскадной и спиральной моделей привело к их сближению и появлению современного итерационного подхода, который представляет рациональное сочетание этих моделей. Различные варианты итерационного подхода реализованы в большинстве современных технологий и методов (RUP, MSF, XP).

1.1.3 ERwin Data Modeler

ERwin Data Modeler (ранее называвшийся AllFusion Data Modeler) -- программный продукт в области реализации средств CASE-технологий.

Позволяет проводить описание, анализ и моделирование модели данных -- построитель мета-моделей данных. Занимает одно из лидирующих мест в своём сегменте рынка. В настоящее время выпускается компанией Computer Associates. Распространяется на коммерческой основе. Включает три стандартные методологии: IDEF0 (функциональное моделирование), DFD (моделирование потоков данных) и IDEF3 (моделирование потоков работ). Эти методологии по-своему уникальны. Каждая из них может быть выполнена отдельно с помощью BPwin, но их совокупность, заключённая в модель даёт аналитику полную картину предметной области клиента.

1.1.4 SQL Server

SQL Server - мощная многофункциональная система управления базами данных (СУБД). Она имеет дружественный и интуитивно понятный интерфейс пользователя, позволяющий изучить все средства и возможности SQL Server без написания сложных для понимания строк программного кода.



1.1.5 Borland Delphi 7

Delphi -- это объектно-ориентированная среда для визуального построения программных продуктов, основанная на языке Object Pascal, который является переработанной и существенно дополненной версией Turbo

Pascal фирмы Borland.

Программирование в Delphi состоит из двух основных этапов:

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

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

С момента первой реализации языка Pascal технологии программирования сделали огромный шаг вперед. И, несмотря на то, что Pascal тоже развивался, его последней версии, выпущенной фирмой Borland в 1990 году, существенно недостает возможностей, присущих другим современным языкам программирования. В среде Delphi используется обновленный вариант этого популярного языка. Изменения коснулись, прежде всего, объектно-ориентированной части Pascal, однако, казалось бы, вполне законченные инструменты структурного и модульного программирования также приобрели некоторые новые особенности.

1.2 Описание методологий и методов анализа предметной области

1.2.1 RUP

Rational Unified Process (RUP) -- методология разработки программного обеспечения, созданная компанией Rational Software. В основе RUP лежат следующие принципы:

? Ранняя идентификация и непрерывное (до окончания проекта) устранение основных рисков.

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

? Ожидание изменений в требованиях, проектных решениях и реализации в процессе разработки.

? Компонентная архитектура, реализуемая и тестируемая на ранних стадиях проекта.

? Постоянное обеспечение качества на всех этапах разработки проекта (продукта).

? Работа над проектом в сплочённой команде, ключевая роль в которой принадлежит архитекторам.

Жизненный цикл разработки.

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



В фазе Начало:

? Формируются видение и границы проекта.

? Создается экономическое обоснование (business case).

? Определяются основные требования, ограничения и ключевая функциональность продукта.

? Создается базовая версия модели прецедентов.

? Оцениваются риски.

При завершении начальной фазы оценивается достижение вехи целей жизненного цикла (англ. Lifecycle Objective Milestone), которое предполагает соглашение заинтересованных сторон о продолжении проекта.

В фазе Уточнение производится анализ предметной области и построение исполняемой архитектуры. Это включает в себя:

? Документирование требований (включая детальное описание для большинства прецедентов).

? Спроектированную, реализованную и оттестированную исполняемую архитектуру.

? Обновленное экономическое обоснование и более точные оценки сроков и стоимости.

? Сниженные основные риски.

Успешное выполнение фазы разработки означает достижение вехи архитектуры жизненного цикла (англ. Lifecycle Architecture Milestone).

Во время фазы Построение происходит реализация большей части функциональности продукта. Фаза Построение завершается первым внешним релизом системы и вехой начальной функциональной готовности (Initial Operational Capability).

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

1.2.2 MSF

Microsoft Solutions Framework (MSF) -- методология разработки программного обеспечения, предложенная корпорацией Microsoft. MSF опирается на практический опыт Microsoft и описывает управление людьми и рабочими процессами в процессе разработки решения. MSF представляет собой согласованный набор концепций, моделей и правил. MSF состоит из двух моделей и трех дисциплин. Начинать изучение MSF лучше с моделей, а затем перейти к дисциплинам. MSF содержит:

? модели:

o модель проектной группы

o модель процессов

? дисциплины:

o дисциплина управление проектами

o дисциплина управление рисками

o дисциплина управление подготовкой

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

Модель процессов MSF (MSF process model) представляет общую методологию разработки и внедрения IT решений. Особенность этой модели состоит в том, что благодаря своей гибкости и отсутствию жестко навязываемых процедур она может быть применена при разработке весьма широкого круга IT проектов. Эта модель сочетает в себе свойства двух стандартных производственных моделей: каскадной (waterfall) и спиральной (spiral). Модель процессов в MSF 3.0 была дополнена ещё одним инновационным аспектом: она покрывает весь жизненный цикл создания решения, начиная с его отправной точки и заканчивая непосредственно внедрением. Такой подход помогает проектным группам сфокусировать свое внимание на бизнес-отдаче (business value) решения, поскольку эта отдача становится реальной лишь после завершения внедрения и начала использования продукта.

Дисциплина управления рисками (risk management) -- это одна из ключевых дисциплин Microsoft Solutions Framework® (MSF). MSF видит в изменениях и возникающей из-за них неопределенности неотъемлемые части жизненного цикла информационных технологий. Дисциплина управления рисками в MSF отстаивает превентивный подход к работе с рисками в условиях такой неопределенности, непрерывное оценивание рисков и использование информации о рисках в рамках процесса принятия решений на протяжении всего жизненного цикла проекта. Данная дисциплина предлагает принципы, идеи и рекомендации, подкрепленные описанием пошагового процесса для успешного активного управления рисками. Этот процесс включает в себя выявление и анализ рисков; планирование и реализацию стратегий по их профилактике и смягчению возможных последствий; отслеживание состояния рисков и извлечение уроков из обретенного опыта.

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

Дисциплина управления подготовкой -- это также одна из ключевых дисциплин Microsoft Solutions Framework (MSF). Она посвящена управлению знаниями, профессиональными умениями и способностями, необходимыми для планирования, создания и сопровождения успешных решений. Дисциплина управления подготовкой MSF описывает фундаментальные принципы MSF и дает рекомендации по применению превентивного подхода к управлению знаниями на протяжении всего жизненного цикла информационных технологий. Эта дисциплина также рассматривает планирование процесса управления подготовкой. Будучи подкрепленной испытанными практическими методиками, дисциплина управления подготовкой предоставляет проектным группам и отдельным специалистам базу для осуществления этого процесса.

1.2.3 SWEBOK

SWEBOK (Software Engineering Body of Knowledge) -- документ, подготавливаемый комитетом Software Engineering Coordinating Committee, в который вовлечено сообщество IEEE Computer Society. Назначение SWEBOK -- в объединении знаний по инженерии программного обеспечения (разработке программного обеспечения).

Документ является одним из трёх документов, созданных совместными усилиями IEEE-CS и ACM, призванных обеспечить следующее:

? определить необходимый набор знаний и рекомендуемые практики;

? определить этические и профессиональные стандарты;

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

Эта книга представляет собой первый компонент необходимый набор знаний и рекомендуемые практики.

Второй документ, посвящённый этическим и профессиональным стандартам для инженерии ПО, выпущен в 1998 году.

Третий документ (SE2004), выпущенный в 2004 году, посвящён составлению учебного плана по программной инженерии.

1.3 Документы по анализу предметной области

1.3.1 Бизнес-требования

Техническое задание

АРМ менеджера, ведущего учет и анализ расходов сотрудников организации < ИУиБ >



Логическая схема базы данных «РАСХОДЫ»

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

? Учет расходов ведет сотрудник бухгалтерии.

? Подробный отчет утверждает главный бухгалтер и готовит сводный отчет топ-менеджеру организации.

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

1.3.2 Видение

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

Настоящий документ разрабатывается в рамках проекта автоматизации деятельности организации ««ИСЭ-РАСХОД»».

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

Позиционирование

Деловые преимущества

В настоящее время учет расходов денежных средств в организации ««ИСЭ-РАСХОД»» ведется на основе использования электронных таблиц. В сравнении с имеющимся, новое решение позволит обеспечить более удобный режим доступа заинтересованных лиц к информации, повысить быстродействие, обеспечить надёжное хранение данных и более полный охват функций, подлежащих автоматизации.



Определение проблемы

Проблема	Недостаточно оперативный обмен информацией между сотрудником бухгалтерии, ведущим учет расходов и всеми взаимодействующими с ним лицами.
Затрагивает	Сотрудника бухгалтерии, главного бухгалтера, топ-менеджера и весь личный состав организации
Её следствием является	Задержки выполнения отчетов
Успешное решение	Оптимальный учет расходов

Проблема	Высокая трудоёмкость ведения учета расходов
Затрагивает	Сотрудника бухгалтерии, главного бухгалтера, топ-менеджера
Её следствием является	Затянутость процесса составления отчетов , появление ошибок при их составлении
Успешное решение	Исключение ошибок, повышение эргономичности работы

Определение позиции изделия

Для	Организации ««ИУиБ»»
которой	Требуется оптимизировать учет и анализ расходов сотрудниками организации
(Название продукта)	АРМ менеджера, ведущего учет и анализ расходов сотрудников организации
который	Основан на промышленной СУБД и высоконадёжен
В отличие от	Существующего механизма на основе электронных таблиц
наш продукт	Исключает ошибки при ведении учета

Описания пользователей

Сведения о пользователях

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

Профили пользователей

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

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

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

Ключевые потребности пользователей

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

Краткий обзор изделия

Контекст использования системы

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

Сводка возможностей

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

Предположения и зависимости

Система будет использоваться на территориально сосредоточенном (без внешних филиалов) организации.

В случае изменений в формах документов АРМ должна претерпеть малосущественные изменения (нужно будет модифицировать отчётные формы).

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

Возможности учета расходов

Структурированное описание учета расходов

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

Расчёт нормативного времени выполнения работ по внесению отчета учетов расхода

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

Передача отчета на организацию

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

Планирование работы цехов

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

Назначение исполнителей

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

Контроль исполнения и оперативная корректировка планов

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

Ограничения

Внедрение системы не должно занимать более 3 месяцев.

В ядре системы должна быть представлена промышленная СУБД реляционного доступа.

Все обращения к информации должны осуществляться через драйвер ODBC.

Показатели качества

Применимость

Время, необходимое для обучения обычных пользователей - 3 рабочих дня (24 часа), для обучения продвинутых пользователей - 1 рабочий день (8 часов).

? Время отклика для типичных учетов - не более 5 секунд, для сложных учета - не более 20 секунд.

Надежность

Доступность - время, затрачиваемое на обслуживание системы не должно превышать 3% от общего времени работы.

Среднее время безотказной работы - 10 рабочих дней.

Максимальная норма ошибок или дефектов - 1 ошибка на десять тысяч строк кода.

Другие требования к изделию

Применяемые стандарты

Система должна соответствовать всем стандартам интерфейса пользователя Microsoft® Windows®.

Системные требования

Минимальные системные требования:

64 Mb памяти

3 Mb свободного дискового пространства

процессор с тактовой частотой 850 MHz

Операционная система Windows ХР.

Эксплуатационные требования

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

Требования к документации

Руководство пользователя

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

Интерактивная справка

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

Руководства по установке и конфигурированию, файл Read Me

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

Маркировка и пакетирование

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

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

1.4 Поиск акторов и вариантов использования

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

Краткое описание акторов представлено в табл. 1.

Актор	Краткое описание
Менеджер	Ведет учет расходов личного состава организации. По всем этим расходам готовит документов в виде отчета о расходах.
Главный Бухгалтер	Утверждает подробный отчет и готовит сводный отчет топ-менеджеру организации.
Топ-менеджер	Топ-менеджер анализирует отчет, сопоставляя его с плановыми документами. и формирует корректирующие документы (приказы, указания) на предмет корректировки сметы расходов.

Выявление вариантов использования

Выявленные варианты использования сведены в таблицу 2.

Табл. 2. Выявление вариантов использования

Основной актор	Наименование	Формулировка
Менеджер	Регистрация отчетов расхода	Этот вариант использования позволяет менеджеру передавать в бухгалтерию новые отчеты о расходах
Менеджер	Регистрация срочного отчета расходов	Этот вариант использования позволяет менеджеру передавать в бухгалтерию новые отчеты о расходах, которые необходимо выполнить в срок.
Менеджер	Изменение отчета	Менеджер может откорректировать информацию о отчете в организации
Менеджер	Удаление расхода	При необходимости снятия расхода с организации менеджер или бухгалтер вызывает функцию «Удаление расчета».
Менеджер	Запрос о расходов	Используется менеджером для поиска нужной информации о состоянии расходов организации, необходимой для клиента.
Топ-менеджер	Планирование нового отчета	Топ-менеджер размещает отчет в план в «хвост» очереди
Топ-менеджер	Коррекция плана	Топ-менеджер корректирует план при появлении каких-либо нестыковок
Главный бухгалтер	Назначение исполнителей	Главный бухгалтер назначает исполнителям работы из сменного задания
Главный бухгалтер	Фиксация результатов	Главный бухгалтер фиксирует результаты



1.5 Описание ключевых прецедентов

1.5.1 Поиск ключевых вариантов использования

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

Для дальнейшей детализации выбраны три прецедента:

? M1. Регистрация учета;

? D1. составление нового отчета;

? D3Составление срочного отчета.

Прецедент D1: Составление нового отчета

Составление нового отчета

Краткое описание

менеджер размещает вновь поступивший от менеджера рачход в план в «хвост» очереди. Действующие лица этого прецедента - Бухгалтер.

Поток событий

Прецедент начинается, когдаМенеджер выбирает деятельность “планировать новый отчет” из «Главной формы» АРМ «Учет расходов».

Базовый поток - Составление нового отчета

Менеджер выбирает «составлять новый отчет».

Система отображает список новых расходов, подлежащих составлению отчета.

Менеджер выбирает из предложенного списка расход, который он желает составить отчет.

Систем определяет, что статус отчета - «Обычный».

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

Система отображает список совместимых ресурсов. Ресурс отображается в том случае, если в учете есть хотя бы один расход, для которой он допустим.

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

Менеджер выбирает работу расхода

Система ограничивает набор доступных ресурсов, «затеняя» несовместимые.

Система делает соответствующие отметки в базе данных.

Система удаляет расход из списка вновь поступивших отчетов.

1.5.2 Альтернативные потоки

Составление по частям

Если при выполнении п. 10 основного потока расходов Менеджеру не удалось обнаружить интервал необходимого раздела, то

1. Менеджер выбирает «составить учет расходов по частям».

2. Менеджер находит на шкале одного из доступных ресурсов интервал произвольного размера и размещает (drag and drop) туда работу отчета.

3. Система разбивает работу на интервалы и размещает её на свободные позиции выбранного ресурса.

4. Переход к п. 11 основного потока событий.

Составление отчета в срок невозможно

Если Менеджер обнаружил, что он не может определить вид расхода с соблюдением зафиксированного в отчете срока, то

1. Менеджер выбирает «отменить составление».

2. Система отправляет уведомление Бухгалтеру «Отчет №… не может быть спланирован с соблюдением оговоренного с сотрудником срока».



1.5.3 Специальные требования

Время составления одного отчета не должно превышать 3 дней.

Предусловия

Регистрация

Перед тем как начинается этот прецедент, Менеджер зарегистрирован в системе.

Постусловия

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

Точки расширения

Если при выполнении п. 4 выясняется, что отчет имеет статус «Срочный», Система переходит к выполнению расширяющего прецедента «Составления срочного отчета»

Прецедент M1. Регистрация учета расходов

Регистрация учета расходов

Краткое описание

Поток событий

Базовый поток - Регистрация учета расходов

Альтернативные потоки

Специальные требования

Предусловия

Постусловия

Точки расширения

Прецедент D3. Составление срочного отчета

Составление срочного отчета

Краткое описание

Поток событий

Базовый поток - Составление срочного отчета

Альтернативные потоки

Специальные требования

Предусловия

Постусловия

Точки расширения

1.6 Анализ и спецификация специальных требований

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

Сопутствующая информация представлена в следующих документах:

? Требованиях совладельцев

? Видении Описании акторов и вариантов использования

? Описании ключевых вариантов использования

Авторизация и аутентификация пользователей в системе

В АИС должны быть представлены справочник ролей пользователей (Бухгалтер, Главный бухгалтер, Топ-менеджер) и справочник пользователей. Должна быть возможность регистрации пользователя и назначения пользователю роли.

Ведение справочника работ

Расходы, включаемые в описание отчета, выбираются из справочника типов расходов. В АИС должны быть представлены средства управления типами расходов.

Ведение справочника ресурсов

В АИС должны быть представлены средства управления типами ресурсов (оператор/оборудование), справочниками персонала и оборудования.

Применимость

Удобство использования

Интерфейсы АРМ «Бухгалтер», «Главный бухгалтер» и «Топ-менеджер» должны быть рассчитаны на предварительно обученных специалистов, хорошо ориентирующихся в бухгалтерии и достаточно хорошо - в компьютерных интерфейсах; время обучения не должно превышать 1 рабочий недели.

Помощь в режиме online

Все АРМ должны поддерживать контекстную справку в форме стандартного help операционной системы.

Надежность

Доступность

АРМ Бухгалтера, Главного бухгалтера и Топ-менеджера должны быть доступны в рабочие дни в рабочее время (как правило, с 8 до 18, если иное не указано распоряжением по предприятию).

Время, затрачиваемое на обслуживание системы не должно превышать 3% от общего времени работы.

Наработка на отказ

Среднее время безотказной работы - 10 рабочих дней.

Норма дефектов

Максимальная норма ошибок или дефектов - 1 ошибка на десять тысяч строк кода.

Производительность

Одновременно работающие пользователи

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

Время отклика

Время отклика для типичных задач - не более 5 секунд, для сложных задач - не более 20 секунд.

Пригодность к эксплуатации

Масштабируемость

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

...