Страницы: 1 2
Оглавление
- Введение
- 1. Анализ задачи
- 1.1. Актуальность разработки
- 1.2. Роль приложений и платформы Android в современном обществе
- 1.3. Технологии построения API для взаимодействия с ИС
- 1.4. Словесное описание задачи
- 1.5. Структура программы
- 1.6. Расчет FP-метрик и LOC-метрик
- 1.7. Расчет COCOMO-МЕТРИК
- 1.8. Модель прецедентов
- 2. Проектирование
- 2.1. Проектирование базы данных api сервера
- 2.2. Построение диаграммы классов хранения и обработки данных Android приложения
- 2.3. Построение диаграммы последовательности Android приложения
- 3. Реализация
- 3.1. Настройка рабочего пространства
- 3.1.1. Debian
- 3.1.2. Панель управления Webmin
- 3.1.3. Протокол L2TP
- 3.1.4. Файловый сервер Samba
- 3.2. пользование симметричного шифрования
- 3.3. Разработка интерфейса приложения
- 3.4. Разработка API сервера
- Заключение
- Список использованных источников
Введение
Важной проблемой в учебном процессе в высшем учебном заведении является задача автоматизации учебного расписания. Использование информационных систем в учебном секторе, в наше время, не является редкостью. В современном вузе достаточно много процессов подлежат автоматизации, начиная от совсем мелких задач, заканчивая полной автоматизацией ВУЗа.
Системы автоматизации в ВУЗах внедряются в первую очередь для повышения качества образования, объектами автоматизации могут быть как преподавательский состав так и администрация университета.
В разных ВУЗах процесс автоматизации происходит по разному, несмотря на то что понятие образовательной деятельности едино для всех образовательных учреждений. Значительное влияние оказывает финансирование автоматизации и готовность сотрудников ВУЗа использовать предлагаемых рынком информационных услуг и программных продуктов.
Разработка мобильного android-приложения «Кабинет РГУПС» обеспечит легкость и доступность пользования расписанием, позволит преподавателям и студентам, как очникам, так и заочникам быстро ориентироваться в нагрузке своего рабочего дня, а также планировать ближайшие дни заранее.
1. Анализ задачи
1.1. Актуальность разработки
Изменение средств и форм обучения, а так же стремительный прогресс средств вычислительной техники, диктуют необходимость внедрения информационных технологий в образование.
Следует начать с определения понятия «автоматизация». Автоматизация это применение технических и программных средств, освобождающих человека от непосредственного участия в процессах получения, преобразования, передачи и использования информации. Формализация предшествует процессу автоматизации, то есть необходимо получить полный набор однозначно трактуемых инструкций, исходя из которых достигается результат реализации процесса.
Одно из главных преимуществ автоматизации — при ускорении выполнения операций снижается количество ошибок при их выполнении, снижаются издержки на реализацию операций и повышение качества. Автоматизация может считаться успешной, в результате внедрения и использования которой удалось возвратить инвестированные в нее средства.
Этапы автоматизации, применяемые в целом к деятельности того или иного учреждения. Все этапы требует осмысленного и последовательного выполнения.
Этап 1: постановка проблемы, оценка необходимости автоматизации и возможностей предприятия;
Этап 2: формирование требований к программно-аппаратному комплексу, выбор или реализация программного продукта и технического обеспечения;
Этап 3: внедрение программного продукта;
Этап 4: послегарантийное обслуживание программно-аппаратного комплекса.
В начале процесса автоматизации необходимо ясно и четко сформулировать свои требования к ней. Требуется определить какие именно функции необходимо автоматизировать. Так же необходимо учитывать, что при внедрении автоматизированных систем снижается степень влияния человеческого фактора на выполнение тех или иных операций.
Необходимо выделить сотрудника из числа руководителей высшего звена, ответственного за проведение данного процесса и уполномоченного принимать решения по вопросам автоматизации.
Обязательным условием является выделение квалифицированных специалистов, отвечающих за разработку или внедрение программного продукта. Каждый отдельный специалист в рамках своих обязанностей должен уметь оперативно устранять возникающие в системе отказы, выявлять и устранять нарушения условий эксплуатации, решать те или иные проблемы пользователей.
Выбор среды разработки программного продукта не следует отделять от выбора технического обеспечения, на котором предстоит в дальнейшем работать. Не следует забывать об интеграции в единое информационное пространство, что позволяет использовать ранее реализованные компоненты и единую базу данных. Это ведет к повышению гибкости информационной системы в целом и снижает дублирование уже имеющейся информации.
Пред проектным обследованием учреждения обычно называют описанный процесс анализа деятельности ВУЗа. Модель организации стоится ходе обследованием организации, и описывает не только взаимодействие структурных единиц, но и информационные потоки, а так же операции.
После определения требований к программному продукту, необходимо определиться с будущей функциональностью полнотой будущей программы.
1.2. Роль приложений и платформы Android в современном обществе
XXI век – это век информационных технологий. Технологии прочно вошли в нашу жизнь: они окружают нас повсюду. Компания Google и ее инженеры, создали операционную систему, позволяющую разрабатывать сторонние приложения, начиная от самых простых в виде фонарика и заканчивая распределенным расчетом вычислений.
Компания Google создала открытую операционную систему Android. Android (Андроид) – операционная система для множества устройств основанная на ядре Linux. Изначально разрабатывалась компанией Android Inc., которую купила Google.
Более 75 % рынка смартфонов, оснащены операционной системой Android. Каждый разработчик электронного устройства имеет возможность переделать Android под свое устройство, гарантируя совместимость своего оборудования со сторонними приложениями для этой ОС. Это оказалось выигрышной тактикой. Раньше, до выхода Android каждый производитель самостоятельно писал или покупал у кого-то операционную систему, и не мог обеспечить совместимость массы полезных программ, созданных программистами всего мира, то после выхода ОС Android перед производителями чаще встает вопрос, какую версию Android им нужно поддерживать.
Установка Android на телефоны дала возможность с разрабатывать новые модели мобильных устройств, расширяя функционал – как телефонов, так и самой операционной системы при этом, не теряя совместимости с массой полезных приложений. Появление программ, предназначенных для помощи пользователю в самых разных ситуациях, привело к тому, что человек, скорее всего, найдет приложение для практически любого случая в жизни. Пользователю предоставляются приложения для покупки билетов, социальных сетей, картографических сервисов. При использовании SIP телефонии связываться с людьми в любой части планеты практически бесплатно.
Все это, наряду с легкостью разработки приложений, делает рассматриваемую платформу одной из наиболее востребованных в современном обществе.
Раньше рынок мобильных платформ делили множество платформ мобильных ОС, то на текущий момент можно выделить только 2 основные платформы: iOS и Google Android, которые делят около 90% всего рынка. Доля Google Android достигает 75%, т.е. каждый третий смартфонов, работают под управлением мобильной платформы от Google.
В таблице 1 представлены данные по различным версиям Android, которые мы также используем для анализа, чтобы после подвести общий итог и сделать выбор. Статистика собрана за двухнедельный период на основе обращений к сервису Google Play.
Таблица 1. Распределение версий ОС Android, на 1-е августа 2016
| Название версии | Уровень API | Распределение |
| 1.5 Cupcake | 3 | 0.2% |
| 1.6 Donut | 4 | 0.5% |
| 2.1 Eclair | 7 | 4.2% |
| 2.2 Froyo | 8 | 15.5% |
| 2.3 – 2.3.2 Gingerbread | 9 | 0.3% |
| 2.3.3 – 2.3.7 | 10 | 60.3% |
| 3.1 Honeycomb | 12 | 0.5% |
| 3.2 | 13 | 1.8% |
| 4.0 – 4.0.2 Ice Cream Sandwich | 14 | 0.1% |
| 4.0.3 – 4.0.4 | 15 | 15.8% |
| 4.1 Jelly Bean | 16 | 0.8% |
Разработка для платформы Android ведется преимущественно на языке Java. Для создания необходимо специальное программное обеспечение. Самые последние версии этого ПО можно загрузить на официальном сайте разработчика. К этому программному комплексу относятся такие инструменты как JRE (Java Runtime Environment) и JDK (Java Development Kit). JRE представляет собой среду выполнения – минимальную реализацию виртуальной машины, в которой запускается и выполняется программный код. JDK – это в свою очередь целый набор инструментов, комплект разработчика приложений на языке Java. На самом деле, JRE также входит в состав JDK, равно как и различные стандартные библиотеки классов Java, компилятор javac, документация, примеры кода и разнообразные служебные утилиты. Весь набор ПО распространяется свободно и имеет реализацию для различных ОС. В состав JDK не входит среда разработки, разработчик должен установить ее отдельно. При разработке под ОС Android рекомендуется использовать среду разработки Android Studio от Google.
Невозможно отрицать, что в сфере информационных технологий вчерашние инновации – это сегодняшние привычные вещи. Чтобы идти «в ногу со временем», специалистам необходимо использовать концепцию постоянного обучения, и главным является своевременное освоение наиболее значительных, распространенных и перспективных технологий. Технологии разработки под данную ОС относятся именно к таковым. Можно сделать вывод о целесообразности разработки клиентского приложения на базе ОС Android.
1.3. Технологии построения API для взаимодействия с ИС.
API(интерфейс программирования приложений) — набор готовых классов, процедур, функций, структур, констант для использования во внешних программных продуктах.
API часто используется при разработке веб-приложений и сервисов. Как правило API определяет определенный набор HTTP-запросов, а для ответа используются такие структуры, как XML или JSON. Web API является синонимом веб-службы, основными технологиями работы которой являются SOAP и REST.
SOAP
SOAP –(Simple Object Access Protocol) – протокол основанный на XML, определяющий правила передачи данных между прикладными системами через интернет. SOAP устанавливает стандарт взаимосвязи клиента и сервера, в основе заложен принцип вызова удаленных процедур, которые принимают различные параметры, в зависимости от которых возвращают значения. Для представления любой информации, передаваемой от клиента к серверу и наоборот, используется XML.
Разрабатывался с расчетом использования по протоколу HTTP , однако может задействовать иные транспортные протоколы, например SMTP.
REST
REST(Representational State Transfer) – это архитектурный стиль построения распределенных систем, описывающий принципы разработки программного обеспечения. REST использует протокол HTTP, данные передаются в виде распространенных стандартных форматов (HTML,XML,JSON). Основными достоинствами REST является его простота, а также кэширование, что увеличивает скорость и масштабируемость системы, функциональная совместимость. Из этих данных можно сделать выводы о том, что SOAP это целое семейство протоколов и стандартов, что говорит о его избыточности и тяжеловесности по сравнению с REST. SOAP использует HTTP как транспортный протокол, а REST основан на нем, из этого следует что все технологии такие как, кэширование на уровне сервера, масштабируемость, используются в архитектуре REST ,в то время как в SOAP необходимо искать другие средства. Так же преимуществом REST над SOAP является то, что SOAP привязан к XML, в то время как REST может использовать JSON и другие форматы данных.
1.4. Словесное описание задачи
В рамках данной работы рассматривается процесс систематизации информационных баз данных университета, которые используются при автоматизации расписания занятий факультетов высшего учебного заведения на сайте РГУПС. Происходит выгрузка расписание из информационной системы РГУПС, которая будет применима для android-приложения «Кабинет РГУПС» в качестве информационной базы.
Данная программа обеспечивает:
- оперативное получение и обновление расписания очного и заочного отделения, а также посещаемости, успеваемости и результатах тестирования студента;
- возможность поиска преподавателя и просмотра его пар;
- добавление неограниченного количества пользователей в приложение;
- добавление заметок к любым парам а так же прикреплении любых файлов к этим заметкам;
- возможность связаться с разработчиком через встроенный чат технической поддержки;
1.5. Структура программы
Для упрощения разработки и возможности дальнейшего портирования приложения под другие операционные системы было принято решение о разделении графической части приложение и части хранения и обработки данных.
Функциональная структура разрабатываемого нами программного обеспечения состоит из следующих модулей:
Графическая часть:
- модуль отображения расписания очной формы обучения;
- модуль отображения расписания заочной формы обучения;
- модуль отображения посещаемости;
- модуль отображения успеваемости;
- модуль отображения результатов тестирования;
- модуль настроек приложения;
- модуль виджета;
- модуль отображения текущей пары на панели уведомлений;
- модуль отображения и поиска преподавателей;
- модуль чата технической поддержки;
Часть хранения и обработки данных:
- модуль хранения и обработки посещаемости;
- модуль хранения и обработки расписания очной формы обучения;
- модуль хранения и обработки расписания заочной формы обучения;
- модуль хранения и обработки учетных данных;
- модуль хранения и обработки успеваемости;
- модуль хранения и обработки результатов тестирования;
- модуль синхронизации данных;
- сервисный модуль.
Модуль отображения расписания очной формы обучения обеспечивает отображение расписания, навигацию между днями и неделями, верхними и нижними неделями, просмотр произвольной даты с помощью календаря. В модуле так же выводится наглядная информация о посещаемости студента в виде цветовой подкраски каждой пары в зависимости от того был студент на паре или нет, в конце каждой недели имеется краткая сводка о посещаемости студента за эту неделю. Также модуль отображает расписание преподавателя если в дне присутствуют пару у заочников то в расписание вставляется пара заочной формы обучение с пометкой.
Модуль отображения расписания заочной формы обучения обеспечивает отображение расписания, навигацию между днями, неделями обучения.
Модуль отображения посещаемости обеспечивает отображение посещаемости студента в виде суммарной сводки за весь семестр и детальной, понедельной сводке с отображением информации за каждую неделю семестра с возможностью перехода в модуль отображения расписания для наглядного просмотра посещаемости студента.
Модуль отображения успеваемости обеспечивает отображение успеваемости студента за весь срок обучения с возможностью выбора семестра для просмотра успеваемости, а так же с группировкой результатов по типу аттестации.
Модуль отображения результатов тестирования обеспечивает отображение результатов тестирования за весь срок обучения с возможностью выбора семестра для просмотра результатов, а так же с группировкой в зависимости от вида тестирования.
Модуль настроек приложения позволяет детально настроить интерфейс приложения и выполнить экстренное обновление базы данных приложения в случае ее сбоя.
Модуль виджета позволяет на рабочем столе мобильного устройства отобразить информацию о текущей паре.
Модуль отображения текущей пары на панели уведомлений позволяет отобразить информацию о текущей паре в панели уведомлений.
Модуль отображения и поиска преподавателей позволяет произвести поиск по преподавателям университета с возможностью сортировки преподавателей по критериям.
Модуль чата технической поддержки позволяет через интерфейс приложения связаться с разработчиком.
Модуль хранения и обработки посещаемости выполняет функцию доступа к базе данных, выборку данных за семестр, выборку данных за неделю и за конкретный день.
Модуль хранения и обработки расписания очной формы обучения выполняет функцию доступа к базе данных, выборку расписания определенной группы, а так же расписание преподавателя
Модуль хранения и обработки расписания заочной формы обучения выполняет функцию доступа к базе данных, выборку расписания для группы, выборку расписания для преподавателя, выборку пары преподавателя в конкретный день.
Модуль хранения и обработки учетных данных выполняет функцию доступа к базе данных, выборку и удаление учетных записей зарегистрированных в приложении
Модуль хранения и обработки успеваемости выполняет функцию доступа к базе данных, выборку списка семестров, выборку успеваемости по конкретному семестру
Модуль хранения и обработки результатов тестирования выполняет функцию доступа к базе данных, выборку списка семестров, выборку результатов тестирования за конкретный семестр
Модуль синхронизации данных выполняет одностороннюю синхронизацию с сервером, обновляет расписание, посещаемость, успеваемость, результаты тестирования
Сервисный модуль выполняет внутренние задания, такие как запуск синхронизации по расписанию, обновление виджета.
1.6. Расчет FP-метрик и LOC-метрик
Метрика программного обеспечения – это мера, позволяющая получить численное значение некоторого свойства программного обеспечения или его спецификаций. Поскольку количественные методы хорошо зарекомендовали себя в других областях, многие теоретики и практики информатики пытались перенести данный подход и в разработку программного обеспечения.
Измерения помогают оценить, как продукт, так и сам процесс его разработки. В результате измерений определяется мера – количественная характеристика какого-либо свойства объекта. Некоторые измерения позволяют сразу определить свойства объекта. А остальные можно получить лишь за счет вычисления от значений опорных характеристик. Результаты подобных вычислений называют метриками. Зачастую понятие мера и метрика рассматривают как равноценные определения.
Цель этой деятельности – сформировать предварительные оценки, которые позволят:
- предъявить заказчику корректные требования по стоимости и затратам на разработку программного продукта;
- составить план программного проекта.
Размерно-ориентированные метрики прямо измеряют программный продукт и процесс его разработки. Основываются размерно-ориентированные метрики на LOC-оценках (Lines Of Code). LOC-оценка – это количество строк в программном продукте.
Достоинства размерно-ориентированных метрик:
- широко распространены;
- просты и легко вычисляются.
Недостатки размерно-ориентированных метрик:
- зависимы от языка программирования;
- требуют исходных данных, которые трудно получить на начальной стадии проекта;
- не приспособлены к непроцедурным языкам программирования.
Функционально-ориентированные метрики косвенно измеряют программный продукт и процесс его разработки. Вместо подсчета LOC – оценки при этом рассматривается не размер, а функциональность или полезность продукта.
Используется 5 информационных характеристик:
- количество внешних вводов. Подсчитываются все вводы пользователя, по которым поступают разные прикладные данные. Вводы должны быть отделены от запросов, которые подсчитываются отдельно;
- количество внешних выводов. Подсчитываются все выводы, по которым к пользователю поступают результаты, вычисленные программным приложением. В этом контексте выводы означают отчеты, экраны, распечатки, сообщения об ошибках. Индивидуальные единицы данных отчета отдельно не подсчитываются;
- количество внешних запросов. Под запросами понимают диалоговый ввод, который приводит к немедленному программному ответу в форме диалогового вывода. При этом диалоговый ввод в приложении не сохраняется, а диалоговый вывод не требует вычислений. Подсчитываются все запросы – каждый учитывается отдельно;
- количество внутренних логических файлов. Подсчитываются все логические файлы (т.е. логические группы данных, которые могут быть частью базы данных или отдельным файлом);
- количество внешних интерфейсных файлов. Подсчитываются все логические файлы, на которые ссылается данное приложение.
Каждой из выявленных характеристик ставится в соответствие сложность. Для этого характеристике назначается низкий, средний или высокий ранг, а затем формируется числовая оценка ранга.
Достоинства функционально-ориентированных метрик:
- не зависят от языка программирования;
- вычисляются на любой стадии проекта;
- FP – оценки легко пересчитать в LOC-оценки.
Недостатком функционально-ориентированных метрик является то, что результаты основаны на субъективных данных, используются не прямые, а косвенные измерения. Определение рангов сложности для внешних вводов, выводов, запросов и логических файлов приведены в таблице 1.1.
количество внутренних логических файлов;
| Транзакции: Внешние вводы | ||||||
| Название ввода | Поля ввода и элементы данных | Кол-во элементов данных | Ссылки на файлы | Ранг | Кол-во вводов | Общая сложность (общ. ранг) |
| Авторизация | Кнопки: Вход; Поле ввода: Фамилия, Номер зачетной книжки
| 3 | 0-1 | Средний = 4 | 3 | 3*4=12 |
| Добавление заметки | Кнопка: Добавить; Поля: Файл, Заголовок, Текст | 3 | 0-1 | Средний = 4 | 3 | 3*4=12
|
| Расписание очников | Поле: ListView1 Кнопки: Календарь, Сегодня | 3 | 0-1 | Средний= 5 | 3 | 5*3=15 |
| Расписание заочников | Поле: ListView1 Кнопки: Календарь, Сегодня
| 3 | 0-1 | Средний= 5 | 3 | 5*3=15 |
| Расписание преподавателей | Поле: ListView1 Кнопки: Календарь, Сегодня
| 3 | 0-1 | Средний=5 | 3 | 5*3=15 |
| Результаты тестирования | Поле: ListView1 Выборка: По семестрам
| 2 | 0-1 | Средний=5 | 2 | 5*2=10 |
| Успеваемость | Поле: ListView1 Выборка: По семестрам
| 2 | 0-1 | Средний=5 | 2 | 5*2=10 |
| Посещаемость | Поле: ListView1 Выборка: По семестрам Кнопки: Переход к неделе | 3 | 0-1 | Средний = 5 | 3 | 3*5=15 |
| Внутренние логические файлы | ||||||
| Название файла | Поля ввода и элементы данных | Кол-во элементов данных | Кол-во элементов данных-записей | Ранг | Кол-во файлов | Общая сложность (общ. ранг) |
| Database.db | Очная форма обучения, заочная форма обучения, Пользователи, заметки, успеваемость, посещаемость, результаты тестирования | 1 | Низкий (7)
| 1 | 7*7=49 | |
Внешних интерфейсных файлов нет.
Исходные данные для расчета сводятся в табл.:
| Имя характеристики | Ранг, сложность, количество | |||
| Низкий | Средний | Высокий | Итого | |
| Внешние вводы | 0x3 = 0 | 12×2 = 24 | 0x6 = 0 | = 24 |
| Внешние выводы | 80×4 = 0 | 0x7 =0 | 0x7 = 0 | = 320 |
| Внешние запросы | 0х3 = 0 | 0x4 =0 | 0x6 =0 | = 0 |
| Внутренние логические файлы Внешние интерфейсные файлы | 49×7 = 343 0x5 = 0 | 0x 10= 0 0x7 = 0 | 0x15 = 0 0x10 =0 | = 343 = 0 |
| Общее количество S =
| 687
| |||
Исходные данные для расчета FP-метрик
Определение системных параметров приложения
| Системный параметр | Описание | Fi |
| Передача данных | F1=3 | |
| Обработка данных | F2= 3 | |
| Производительность | F3=3 | |
| Распространенность | F4= 0 | |
| Скорость транзакций | F5=5 | |
| Оперативный ввод данных | F6=5 | |
| Эффективность работы | F7=3 | |
| Оперативное обновление | F8=3 | |
| Сложность обработки | F9=0 | |
| Повторная используемость | F10=3 | |
| Легкость инсталляции | F11=2 | |
| Легкость эксплуатации | F12=3 | |
| Разнообразные условия размещения | F13=3 | |
| Простота изменений | F14=3 | |
| ∑Fi=39 |
После сбора всей необходимой информации приступаем к расчету FP-метрики.
Пересчет FP-оценок в LOC-оценки
LOC= FP×23=687*23= 15801
1.7. Расчет COCOMO-МЕТРИК
На сегодняшний день для оценки стоимости ПО используется несколько различных моделей. Одной из самых популярных, открытых и хорошо документированных моделей оценки стоимости ПО является СОСОМО (Constructive Cost Model – конструктивная модель стоимости), разработанная Барри Боэмом. Эволюция СОСОМО отражает то, каким образом эволюционировала экономика ПО последние 20 лет.
История модели СОСОМО позволяет увидеть эволюцию приоритетов экономики программного обеспечения. COCOMO состоит из иерархии трех последовательно детализируемых и уточняемых форм. Первый уровень, базовый, подходит для быстрых ранних оценок стоимости разработки ПО и обладает неточностью вследствие некоторых факторов, которые невозможно учесть на ранних стадиях разработки. Средний уровень COCOMO учитывает эти факторы, тогда как детальный уровень дополнительно учитывает влияние отдельных фаз проекта на его общую стоимость.
Общая характеристика масштабных факторов Wi приведена в таблице 1.5.
Таблица 1.5 – Характеристика масштабных факторов Wi
| Масштабный фактор (Wi) | Пояснение | Wi |
| 1 Предсказуемость , наличие прецедентов | Отражает предыдущий опыт организации в реализации проектов этого типа. Очень низкий (=5) означает отсутствие опыта. Сверхвысокий (=0) означает, что организация полностью знакома с этой прикладной областью | 5 нет опыта |
| 2 Гибкость разработки | Отражает степень гибкости процесса разработки. Очень низкий означает, что используется заданный процесс. Сверхвысокий означает, что клиент установил только общие цели | 3 среднее |
| 3 Разрешение рисков в архитектуре | Отражает степень выполняемого анализа риска. Очень низкий (=5) означает малый анализ. Сверхвысокий (=0) означает полный и сквозной анализ риска | 3 среднее |
| 4 Связность группы
| Отражает, насколько хорошо разработчики группы знают друг друга и насколько удачно они совместно работают. Очень низкий (=5) означает очень трудные взаимодействия. Сверхвысокий, (=0) означает интегрированную группу, без проблем взаимодействия | 0 – один в группе, сам студент выполняет |
| 5 Зрелость процесса | Означает зрелость процесса в организации. Вычисление этого фактора может выполняться по вопроснику СММ | 2 – низкое |
| – | ∑Wi | 13 |
Для расчета показателя степени В отражающего нелинейную зависимость затрат от размера проекта (от длины кода LOC), воспользуемся формулой:
Множитель поправки Мe зависит от набора формирователей затрат EMi, перечисленных в таблице 1.6.
Таблица 1.6 – Формирователи затрат EMi для раннего этапа проектирования
| Обозначение | Название | EMi |
| PERS | Возможности (способности) персонала | Среднее = 1 |
| RCPX | Надежность и сложность продукта | Среднее = 1 |
| RUSE | Требуемое повторное использование | Среднее = 1 |
| PDIF | Трудность (сложность) платформы | Средняя = 1 |
| PREX | Опытность персонала | Среднее = 1 |
| FСIL | Средства поддержки | Среднее = 1 |
| SCED | Сроки | Низкие= 0.5 |
Для расчета множителя поправки, зависящего от 7 формирователей затрат, характеризующих продукт, процесс и персонал, воспользуемся формулой:
Для расчета затрат на разрабатываемый продукт, воспользуемся формулой, составные части которой мы уже подсчитали:
ЗАТРАТЫ = А * Ме * РАЗМЕРв , (1.5)
где А – масштабный коэффициент, который равен 2,5;
РАЗМЕР – размер ПО выраженный в тысячах LOC.
ЗАТРАТЫ = 2,5×0,5×151,14 = 27,3
Исходя из расчетов, один человек может выполнить поставленную задачу за 27 месяцев.
1.8. Модель прецедентов
Диаграмма прецедентов (диаграмма вариантов использования) в UML – диаграмма, отражающая отношения между актёрами и прецедентами и являющаяся составной частью модели прецедентов, позволяющей описать систему на концептуальном уровне.
Прецедент – возможность моделируемой системы (часть её функциональности), благодаря которой пользователь может получить конкретный, измеримый и нужный ему результат. Прецедент соответствует отдельному сервису системы, определяет один из вариантов её использования и описывает типичный способ взаимодействия пользователя с системой. Варианты использования обычно применяются для спецификации внешних требований к системе. Основное назначение диаграммы – описание функциональности и поведения, позволяющее заказчику, конечному пользователю и разработчику совместно обсуждать проектируемую или существующую систему.
При моделировании системы с помощью диаграммы прецедентов системный аналитик стремится:
- чётко отделить систему от её окружения;
- определить действующих лиц (актёров), их взаимодействие с системой и ожидаемую функциональность системы;
- определить в глоссарии предметной области понятия, относящиеся к детальному описанию функциональности системы (то есть, прецедентов).
Развернутые описания прецедентов структурированы и содержат большое количество деталей. При итеративной и эволюционной разработке на стадии анализа требований в этом формате представляют порядка 10% жизненно важных прецедентов. Обычно такое описание формируется на первом семинаре по анализу требований, после чего сразу же начинается реализация этих прецедентов в системе.
Для развернутого описания прецедентов существуют различные шаблоны форматирования. Однако, начиная с 1990-х годов прошлого столетия, чаще всего используется шаблон, созданный автором популярной книги по моделированию на основе прецедентов Алистером Коберном (Alistair Cockburn). На основе этого стиля и представлен прецедент, расположенный ниже.
Диаграмма прецедентов, изображенная рисунке 1.2 демонстрирует основные прецеденты в рамках данной программы.
Страницы: 1 2