1.1 Словесное описание задачи
Требуется разработать информационную систему для автоматизации работы крупного предприятия, такого как РЖД. Система должна обеспечивать нижеперечисленные возможности:
- предоставление каталога работ или услугу;
- прием заказов выбранных клиентом;
- реализация функции оформления заказа;
- формирование платежной ведомости;
- обеспечение прямой связи с соответствующим клиентом для решения интересующих вопросов;
- реализация online оповещения;
- формирование отчетов.
Данная информационная система предусмотрена для работы следующих групп пользователей:
1 администратор системы;
2 администратор БД;
3 работники коммерческого отдела;
4 внешние пользователи;
5 клиенты.
Администратор системы реализует следующие функции:
- регистрация новых пользователей в системе;
- расстановка привилегий пользователя;
- редактирование данных;
- обработка и рассылка по отделам сформированных документов (отчеты, счет-фактуру, договор, акт, указ, приказ);
- проверка корректности данных;
- создание новых разделов в каталоге.
При использовании системы работники коммерческого отдела выполняют следующие задачи:
1 Контроль актуальности выставленного на показ контента сайта.
2 Обновление содержания разделов каталога.
Для загрузки нового вида товара работнику необходимо зайти в режим модератора, выбрать соответствующий раздел каталога и заполнить значения полей специальной формы. В форме содержатся следующие сведения о клиента:
- регистрационный номер (табельный);
- должность, отдел;
- коэффициенты;
- дата устройства на работу;
- фотографии.
После заполнения формы администратор или сотрудник коммерческого отдела сохраняет ее, и клиент добавляется в выбранный раздел каталога.
Все регистрационные номера должны (табельные) быть уникальны и присваиваются каждому клиенту в соответствии с приходной ведомостью от начальника отдела.
Информатика программирование : Автоматизация финансово-экономического ...
... решений охватывающие все стороны деятельности финансово-экономических отделов. Автоматизация обработки финансовой информации проводится как органическая ... вертикальная структура подразделений, подразумевающая внутренние расчеты за продукцию, работы и услуги, позволяет поддерживать непрерывность ... стран СНГ; 2) по отраслевому признаку выделены следующие сегменты : энергетика; прочие потребители (в их ...
1 Загрузка и удаление новостной информации.
Администраторы осуществляют прямую связь с клиентом через диалоговую форму, где авторизованный пользователь задает интересующий вопрос, либо непосредственно с помощью телефонной связи, доступной по активной ссылке.
Внешние пользователи имеют возможность просматривать общедоступный информационный контент, а также запросить регистрацию в системе. Чтобы пройти регистрацию необходимо заполнить специальную форму регистрации:
- логин;
- пароль;
- специальность, ;
- ФИО/портфолио.
Клиент может:
1 Просматривать информационный контент.
2 Производить online совещания или консультации.
3 Формировать отчет.
Клиент осуществляет прямую связь с авторизованным пользователем через диалоговую форму или по телефону.
1.2 Анализ риска
Размерно-ориентированные метрики прямо измеряют программный продукт и процесс его разработки. Основываются размерно-ориентированные метрики на LOC-оценках. LOC-оценка — это количество строк в программном продукте.
Функционально-ориентированные метрики косвенно измеряют программный продукт и процесс его разработки. Вместо подсчета LOC-оценки при этом рассматривается не размер, а функциональность или полезность продукта. Для этого используется 5 информационных характеристик:
1 Количество внешних вводов пользователя (все вводы пользователя, по которым поступают разные прикладные данные).
2 Количество внешних выводов (все выводы по которым пользователю поступают рассчитанные данные, документы).
3 Количество внешних запросов (диалоговый ввод, который приводит к немедленному программному ответу без дополнительных вычислений).
4 Внутренние логические файлы.
5 Внешние интерфейсные файлы.
На основе этих и других оценок получают оценку FP. С помощью, которой затем вычисляют LOC-оценку. При этом все расчеты и оценки проводятся до создания программного продукта позволяя оценить затраты до начала работ. С помощью этих характеристик и рассчитывается проект, разработанный в данной работе. Расчет транзакций приведен в таблицах 1.2.1, 1.2.2,1.2.3,1.2.4, 1.2.5.
Таблица 1.2.1 — Внешние вводы
|
Транзакции: Внешние вводы |
|||||||
|
Название ввода |
Поля ввода и элементы данных |
Кол-во элементов данных |
Ссылки на файлы |
Ранг |
Кол-во вводов |
Общая сложность (общ. ранг) |
|
|
Регистрация |
Кнопка: Зарегистрироваться; Поля: Логин, Пароль. |
3 |
0-1 |
Низкий =3 |
1 |
3*1=3 |
|
|
Вход |
Копка:
Поля: Логин, Пароль. |
3 |
0-1 |
Низкий =3 |
1 |
3*1=3 |
|
|
Добавление/редактирование записи |
Копка: Добавить, Сохранить; Поля: Регистрационный номер, Должность, специальность, Портфолио, Дата поступления, Фотографии. |
9 |
2 |
Средний=4 |
1 |
4*1=4 |
|
|
Бухгалтерия |
Копка: Добавить, Сохранить;
Поля: Ввод. |
4 |
0-1 |
Низкий =3 |
1 |
3*1=3 |
|
|
Оплата зарплата/ премия |
Копка: Оплатить. Поля: Фамилия, Имя, Вид карты, Номер карты, Срок действия(2 поля — месяц, год), CVV2 |
7 |
2 |
Средний =4 |
1 |
4*1=4 |
|
Таблица 1.2.2 — Внешние выводы
|
Транзакции: Внешние выводы |
|||||||
|
Название вывода |
Поля вывода и элементы данных |
Кол-во элементов данных |
Ссылки на файлы |
ранг |
Кол-во выводов |
Общая сложность (общ. ранг) |
|
|
Вывод ландинга |
Поле: Картинка |
1 |
1 |
Низкий=4 |
1 |
4*1=4 |
|
|
Вывод каталога клиента |
Поле: Отдел, Должность, Специальность, Портфолио |
4 |
1 |
Низкий=4 |
2 |
4*2=8 |
|
|
Просмотр |
Поле: Текстовое поле, Изображение |
2 |
1 |
Низкий=4 |
2 |
4*2=8 |
|
|
Результаты поиска |
Поле: Текстовое поле |
1 |
1 |
Низкий=4 |
1 |
4*1=4 |
|
Таблица 1.2.3 — Внешние запросы
|
Транзакции: Внешние запросы |
|||||||
|
Название запроса |
Поля ввода и элементы данных |
Кол-во элементов данных |
Ссылки на файлы |
ранг |
Кол-во запросов |
Общая сложность (общ. ранг) |
|
|
Кнопки меню |
Кнопки: Главная, Каталог, Услуги, Помощь клиентам, О нас, Контакты |
6 |
1 |
Низкий=3 |
1 |
3*1=3 |
|
|
Поиск |
Кнопки:
Поля: Поле ввода |
2 |
1 |
Низкий=3 |
1 |
3*1=3 |
|
|
Вопрос |
Кнопки:
Поля: Текстовое поле |
2 |
1 |
Низкий=3 |
1 |
3*1=3 |
|
|
Запрос на продолжение программы в режиме редактирования |
MessageBox Кнопки: Продолжить |
2 |
0-1 |
Низкий=3 |
1 |
3*1=3 |
|
|
Запрос на переход в главное меню |
Пункт меню: Главное меню |
1 |
0-1 |
Низкий=3 |
2 |
3*2=6 |
|
|
Запрос авторизацию |
MessageBox |
2 |
0-1 |
Низкий=3 |
1 |
3*1=3 |
|
Таблица 1.2.4 — Внутренние логические файлы
|
Внутренние логические файлы |
|||||||
|
Название файла |
Поля ввода и элементы данных |
Кол-во элементов данных |
Кол-во элементов данных-записей |
ранг |
Кол-во файлов |
Общая сложность (общ. ранг) |
|
|
Логический Файл `*.jpeg’ |
Картинки |
2500 |
1 |
Низкий (7) |
1 |
7*1=7 |
|
|
Логический Файл `html'(сформированный документ) |
— |
1 |
Низкий (7) |
1 |
7*1=7 |
||
Таблица 1.2.5 — Внешние интерфейсные файлы
|
Внешние интерфейсные файлы |
|||||||
|
Название файла |
Поля ввода и элементы данных |
Кол-во элементов данных |
Кол-во элементов данных-записей |
ранг |
Кол-во файлов |
Общая сложность (общ. ранг) |
|
|
База данных клиентов |
Копка: Добавить, Сохранить; Поля: Регистрационный номер, Должность, Специальност, Портфолио Дата поступления, Изображение. |
8 |
>5 |
Средний (7) |
1 |
7*1=7 |
|
|
База данных пользователей |
Копка: Добавить, Сохранить; Поля: Логин, Имя, Пароль. |
5 |
>5 |
Средний (7) |
1 |
7*1=7 |
|
Таблица 1.2.6 — Исходные данные для расчета
|
Имя характеристики |
Ранг, сложность, количество |
||||
|
Низкий |
Средний |
Высокий |
Итого |
||
|
Внешние вводы |
3×3= 9 |
2×4 =8 |
0x6 = 0 |
= 17 |
|
|
Внешние выводы |
6×4 =24 |
0x5 =0 |
0x7 = 0 |
= 24 |
|
|
Внешние запросы |
7х3 = 21 |
0x4 =0 |
0x6 =0 |
= 21 |
|
|
Внутренние логические файлы |
2×7= 14 0x5 = 0 |
0x 10= 0 2×7 = 14 |
0x15 = 0 0x10 =0 |
= 14 = 14 |
|
|
Общее количество S = |
90 |
||||
Таблица 1.2.7 — Определение системных параметров приложения
|
Системный параметр |
Описание |
F i |
||
|
Передача данных |
F 1 = 5 |
|||
|
Обработка данных |
F 2 = 4 |
|||
|
Производительность |
F 3 = 1 |
|||
|
Распространенность |
F 4 = 5 |
|||
|
Скорость транзакций |
F 5 = 4 |
|||
|
Оперативный ввод данных |
F 6 = 3 |
|||
|
Эффективность работы |
F 7 = 3 |
|||
|
Оперативное обновление |
F 8 = 3 |
|||
|
Сложность обработки |
F 9 = 3 |
|||
|
Повторная используемость |
F 10 = 5 |
|||
|
Легкость инсталляции |
F 11 = 3 |
|||
|
Легкость эксплуатации |
F 12 = 4 |
|||
|
Разнообразные условия размещения |
F 13 = 5 |
|||
|
Простота изменений |
F 14 = 3 |
|||
|
Итого |
51 |
|||
После сбора всей необходимой информации приступаем к расчету FP-метрики по формуле (1).
FP = SЧ (0,65+ 0,01 Ч) (1)
где S — общее количество транзакций.
FP=90Ч (0,65+0,01Ч51)=104,4
Пересчет FP-оценок в LOC-оценки производится по формуле (2).
LOC= FPЧ53 (2)
LOC=104,4Ч53=5533,2
Расчет COCOMO-метрик вычисляется по формуле (3).
ЗАТРАТЫ = А Ч М е ЧРАЗМЕРв [чел.-мес], (3)
где А — масштабный коэффициент А = 2,5;
- РАЗМЕР — размер ПО выраженный в тысячах LOC;
М e — множитель поправки зависит от 7 формирователей затрат, характеризующих работу, процесс и персонал (см. табл. ниже);
В — отражает нелинейную зависимость затрат от размера проекта (от длины кода LOC).
Значение показателя степени В изменяется в диапазоне 1,01… 1,26, зависит от 5 масштабных факторов W i и вычисляется по формуле (4).
- (4)
Общая характеристика масштабных факторов W i приведена в таблице 1.2.8, а таблица 1.2.9 позволяет определить оценки этих факторов. Оценки принимают 6 значений: от очень низкой (5) до сверхвысокой (0).
Таблица 1.2.8 — Характеристика масштабных факторов W i
|
Масштабный фактор ( W i ) |
Пояснение |
W i |
|
|
1 Предсказуемость, наличие прецедентов PREC |
Отражает предыдущий опыт организации в реализации проектов этого типа. Очень низкий (=5) означает отсутствие опыта. Сверхвысокий (=0) означает, что организация полностью знакома с этой прикладной областью (ранее такое уже выполняли) |
5 нет опыта |
|
|
2 Гибкость разработки FLEX |
Отражает степень гибкости процесса разработки. Очень низкий означает, что используется заданный процесс. Сверхвысокий означает, что клиент установил только общие цели |
3 среднее |
|
|
3 Разрешение архитектуры / Разрешение рисков в архитектуре RESL |
Отражает степень выполняемого анализа риска. Очень низкий (=5) означает малый анализ. Сверхвысокий (=0) означает полный и сквозной анализ риска |
3 среднее |
|
|
4 Связность группы TEAM |
Отражает, насколько хорошо разработчики группы знают друг друга и насколько удачно они совместно работают. Очень низкий (=5) означает очень трудные взаимодействия. Сверхвысокий, (=0) означает интегрированную группу, без проблем взаимодействия |
0 — один в группе, сам студент выполняет |
|
|
5 Зрелость процесса РМАТ |
Означает зрелость процесса в организации. Вычисление этого фактора может выполняться по вопроснику СММ |
2 -низкое |
|
|
=13 |
|||
= 1,14
Таблица 1.2.9 — Формирователи затрат EM i для раннего этапа проектирования
|
Обозначение |
Название |
EM i |
|
|
1 PERS |
Возможности (способности) персонала (Personnel Capability) |
1 |
|
|
2 RCPX |
Надежность и сложность продукта (Product Reliability and Complexity) |
0.5 |
|
|
3 RUSE |
Требуемое повторное использование (Required Reuse) Необходимость повторного использования |
1 |
|
|
4 PDIF |
Трудность (сложность) платформы (Platform Difficulty) |
HTML средне сложная = 0.7 |
|
|
5 PREX |
Опытность персонала (Personnel Experience) |
1 |
|
|
6 FСIL |
Средства поддержки (Facilities) Возможности |
1 |
|
|
7 SCED |
График (Schedule) Сроки |
Сроки не жесткие = 0.6 |
|
|
Итого: |
=1*0.5*1*0.7*1*1*0.6=0,21 |
||
ЗАТРАТЫ = 2.5 Ч 0,21Ч5,533 1,14 [чел.-мес]=3.7 [чел.-мес]
Данный проект может быть выполнен одним человеком примерно за 3.7 месяца.
1.3 Формализация требований с использованием модели прецедентов
Диаграмма прецедентов определяет поведение системы с точки зрения пользователя. Диаграмма прецедентов рассматривается как главное средство для первичного моделирования динамики системы, используется для выяснения требований к разрабатываемой системе, фиксации этих требований в форме, которая позволит проводить дальнейшую разработку.
Каждая такая диаграмма — это описания сценария поведения, которому следуют действующие лица (Актеры).
Рассмотрим общую и расширенную диаграммы прецедентов на Рисунке 1.3.1 и Рисунке 1.3.2.
Рисунок 1.3.1- Общая диаграмма прецедентов деятельности
Для уточнения и детализации последовательности действий, совершаемых системой при выполнении ее вариантов использования, рекомендуется дополнять этот тип диаграмм сценариями. Для этой цели предложен шаблон:
Таблица 1.3.1 Шаблон для написания сценария отдельного варианта
|
Главный раздел |
Раздел «Типичный ход событий» |
Раздел «Исключения» |
Раздел «Примечания» |
|
|
Имя варианта использования |
Типичный ход событий, приводящий к успешному выполнению варианта использования |
Исключение №1 Исключение №2 Исключение №3 |
Примечания |
|
|
Клиенты |
||||
|
Цель |
||||
|
Краткое описание |
||||
|
Тип |
||||
|
Ссылки на другие варианты использования |
||||
На основе предложенного шаблона разработан текстовый сценарий. Он будет дополнять диаграмму, раскрывая содержание отдельных действий, выполняемых системой и клиентам в процессе формирования заданий.
В следующем разделе сценария описывается последовательность действий, которая приводит к успешному выполнению данного варианта использования. В данном случае инициатором действий выступает администратор ИС.
Таблица 1.3.2 Раздел «Типичный ход событий»
|
Действия актеров |
Отклик системы |
|
|
1 Администратор ИС выбирает сортировку данных по алфавиту или по возрастанию. Исключение №1: администратор ИС не имеет возможности упорядочить все данные сразу, а только по одному параметру. |
2 Система отображает записи в соответствии с параметрами сортировки в БД. |
|
|
3 Администратор ИС выбирает поиск работ. Исключение №2: администратор ИС не имеет права доступа: ввод / редактирование / удаление информации. |
4 Система выдает работы (услуги) по заданному критерию. |
|
|
5 Пользователь (клиент) выбирает формирование отчетов. Исключение №3: отсутствие записей |
6 Система формирует отчет. |
|
Таблица 1.3.3 Раздел «Исключения»
|
Действия клиентов |
Отклик системы |
|
|
Исключение №1: администратор ИС не имеет возможности упорядочить все данные сразу, а только по одному параметру. |
||
|
7. Пользователь (клиент) отменяет упорядочивание данных. |
Система предлагает отменить упорядочивание данных. |
|
|
Исключение №2: администратор ИС не имеет прав доступа ввод / редактирование / удаление информации о лекарствах. |
||
|
8. Пользователь (клиент) отменяет добавление / удаление / изменение данных по продажам лекарств. |
Система предлагает отменить добавление / удаление / изменение данных по продажам лекарств. |
|
|
Исключение №3: отсутствие записей по работам за месяц. |
||
|
9. Пользователь (клиент) отменяет формирование отчета. |
Система предлагает не формировать отчет. |
|
2.1 Выделение классов (Модель предметной области)
Модель предметной области — самая важная часть объектно-ориентированного анализа. Она отображает основные (с точки зрения моделирующего) классы понятий (концептуальные классы) предметной области.
Концептуальный класс — это представление идеи или объекта. Можно рассматривать в терминах:
- символы (symbol) — слова или образы, представляющие концептуальный класс;
- содержание (intension) — определение концептуального класса;
- расширение (extension) — набор примеров, к которым применим концептуальный класс.
Для выделения концептуальны классов нам необходимо воспользоваться одним из методов:
- Использование списка категорий концептуальных классов
- Метод основанный на выделении существительных
Данный метод состоит в выделении существительных из текстового описания предметной области и их выборе в качестве кандидатов в концептуальные классы и атрибуты. Данный метод следует применять с осторожностью. Между существительными и концептуальными классами нет взаимодействия.
Для моделирования предметной области применяется и другой прием — шаблоны анализа . Шаблоны — это готовые модели предметной области, созданные специалистами. Они широко описаны в литературе.
Так как готового шаблона для данной системы не существует, воспользуемся методом, основанном на выделение существительных. При рассмотрении предметной области можно выделить следующие классы, необходимые для должного функционирования системы: Клиент, который объединяет под собой понятия сотрудник, должность, портфолио, в свою очередь заказ состоит из Строк, в которых содержится информация о необходимой работе или услуг, Сотрудников можно подобрать в Каталоге, разделенном по категориям.
Рисунок 2.1.1- Диаграмма классов предметной области
2.2 Определение системных операций
Системная операция — операция, входящая в открытый интерфейс системы для обработки входных системных событий, которые система выполняет как чёрный ящик. Весь набор системных операций, выполняемых в процессе всех прецедентов, определяет открытый системный интерфейс, в ракурсе которого система рассматривается как единый компонент или класс.
При описании системных операций используют следующие понятия:
- операция (имя операции и её параметры);
- ссылки (прецеденты, в рамках которых может выполняться эта операция);
- предусловия (предположение о состоянии системы или объектов модели предметной области до выполнения операции;
- выполнение этих условий не проверяется в рамках логики выполнения данной операции, а предполагается, что они истинны);
- постусловия (состояния объектов модели предметной области после завершения операции).
