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

Учет поступления основных средств

Введение

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

1. Видение и рамки

«Учет поступления ОС» должна предоставить возможность конечным пользователям в полном объеме осуществлять операции просмотра, добавления, редактирования и удаления объектов данных. Программа Учет поступления ОС так же должна предоставлять просмотр сведений об ОС, ПО, осуществлять расчеты количества и сумм по ТС и ПО, расчет отклонения фактических показателей от плановых, формировать отчеты и осуществлять анализ отклонений между планом и фактом (по этапам проекта) для организаций в разрезе сторонних средств и самофинансирования. Описывается процесс моделирования информационной системы и получение файла (файлов) модели в среде популярного CASE-средства. Напр., контекстная диаграмма и диаграмма декомпозиции с использованием BPWin 4.0 в стандарте IDEF 0 (DFD).

Рис. 1. Контекстная диаграмма информационной системы «Учет поступления ОС»

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

· Система должна предоставлять форму вводу данных

· Система должна предоставлять форму просмотра данных о ОС, ПО, организациях, поставщиках;

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

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

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

· Система должна предоставлять возможность указания для технических средств и ПО приобретаются ли они за счет сторонних средств или за счет самофинансирования.

· Система должна предоставлять возможность ввода плановых этапов проекта и указание, на каком этапе и какие КТС должны использоваться (количество и сумма с НДС и без НДС) для каждой организации;

· Система должна предоставлять возможность ввода данных по этапам с указанием фактического приобретения КТС (количество и сумма с НДС и без НДС) для каждой организации;

· Система должна предоставлять возможность формирования отчетов;

· Система должна предоставлять возможность авторизации пользователей;

· Система должна предоставлять конфиденциальность данных.

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

2. История проекта

03.09.11 - собрана проектная группа;

29.09.11 - была утверждена концепция проекта;

утверждена структура проекта;

была утверждена оценка рисков;

была утверждена функциональная спецификация;

была утвержден сводный план и сводный календарный график проекта;

3. Цели дизайна

3.1 Требования пользователя

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

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

Система должна реагировать на все возможные действия пользователя.

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

Основными требованиями с точки зрения пользователя (менеджера) являются:

· авторизированный доступ к системе;

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

· возможность быстро просматривать данные плана и факта по этапам;

· возможность получения отчетов.

Основными требованиями с точки зрения пользователя (координатора) являются:

· возможность редактирования справочников;

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

· возможность быстро просматривать данные плана и факта по этапам;

· возможность быстро просматривать данные о ПО, ОС;

· возможность расчета количества и сумм ПО и ОС;

· возможность определения способа финансирования (самофинансирование или сторонние средства);

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

· Возможность получения отчетов.

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

Диаграмма состояний программного продукта «Учет поступления ОС» для координатора

Диаграмма состояний программного продукта «Учет поступления ОС» для менеджера

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

Требования к решению с точки зрения среды, в которой оно должно будет функционировать после внедрения:

Для сервера:

процессор типа Pentium Dual 1,87 ГГц;

объем ОЗУ не менее 1Gb;

ОС Windows 7;

web server IIS;

сервер БД MySQL.

Для клиента:

Браузер Google Chrome;

Частота процессора 1,4 ГГц;

Память 512 Мб;

ОС Windows 7/XP.

Сценарии использования

Диаграмма бизнес-варианта использования задачи «Учет поступления ОС»

- формирование этапов проекта;

- ввод данных о КТС;

- анализ плановых и фактических поступлений ОС по организациям;

- формирование отчетности.

4.  возможности и неподдерживаемые сценарии

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

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

На данном этапе разработки проект не содержит требований, нуждающихся в предположениях.

6. Проект решения

6.1 Концептуальный проект

Описание концептуального проекта представлено контекстной диаграммой:

Контекстная диаграмма информационной системы «Учет поступления ОС»

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

- вход: спецификация ПО, спецификация ТС, информация о поставщиках, информация об организациях, данные об этапах;

- выход: плановая ведомость приобретения ОС по организациям, ведомость фактического поступления ОС в организации на дату;

- ресурсы: координатор, менеджер.

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

Первый уровень декомпозиции контекстной диаграммы «Учет ведения ОС»

6.2 Логический проект

Логическая модель БД

6.3 Физический проект

Физическая модель БД

7. Требования к инсталляции и деинсталляции

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

8. Риски

Вероятность риска - это вероятность того, что событие действительно произойдет. Только риск с оценкой вероятности больше 0% представляет опасность для проекта. Риски с вероятностью 100% уже реализовались; другими словами, это известные проблемы. Группа может найти более эффективным такой подход, при котором используются от 1 до 3 точек на этой шкале, соответствующие 25, 50 и 75%, потому что иногда несущественное различие в оценках вероятности - например, 60% или 70% - вызывает лишние споры.

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

Полезным показателем важности риска является воздействие - произведение вероятности риска на его влияние. Для этого все риски должны быть приведены к единой шкале.

В результате анализа возможных рисков, были выделены наиболее важные риски (таблица 1).

Таблица 1

основной средство контрольный технический

Размещено на Allbest.ru