4.3 Определение технической сложности проекта
Техническая сложность проекта (TCF – Technical Complexity Factor) вычисляется с учетом показателей технической сложности (табл.6). Каждому показателю присваивается значение Ti в диапазоне от 0 до 5 (0 означает отсутствие значимости показателя для данного проекта, 5 – высокую значимость). Значение TCF вычисляется по формуле
TCF = 0,6 + (0,01 (ΣTi Весi))
Вычислим TCF для системы регистрации (табл.).
TCF = 0,6 + (0,01 44) = 1,04
Таблица 4.5 «Показатели технической сложности проекта TCF».
| Показатель | Описание | Вес |
| Т1 | Распределенная система | 2 |
| Т2 | Высокая производительность | 1 |
| Т3 | Работа конечных пользователей в режиме онлайн | 1 |
| Т4 | Сложная обработка данных | 1 |
| Т5 | Повторное использование кода | 1 |
| Т6 | Простота установки | 0,5 |
| Т7 | Простота использования | 0,5 |
| Т8 | Переносимость | 2 |
| Т9 | Простота внесения изменений | 1 |
| Т10 | Параллелизм | 1 |
| Т11 | Специальные требования к безопасности | 1 |
| Т12 | Непосредственный доступ к системе со стороны внешних пользователей | 1 |
| Т13 | Спец. требования к обучению пользователей | 1 |
Таблица 4.6 «Показатели технической сложности системы регистрации».
| Показатель | Вес | Значение | Значение с учетом веса |
| Т1 | 2 | 3 | 6 |
| Т2 | 1 | 4 | 4 |
| Т3 | 1 | 4 | 4 |
| Т4 | 1 | 3 | 3 |
| Т5 | 1 | 3 | 3 |
| Т6 | 0,5 | 5 | 2,5 |
| Т7 | 0,5 | 5 | 2,5 |
| Т8 | 2 | 1 | 2 |
| Т9 | 1 | 5 | 5 |
| Т10 | 1 | 5 | 5 |
| Т11 | 1 | 4 | 4 |
| Т12 | 1 | 2 | 2 |
| Т13 | 1 | 1 | 1 |
| ∑ | 44 |
4.4 Определение уровня квалификации разработчиков
Уровень квалификации разработчиков (EF – Environmental Factor) вычисляется с учетом следующих показателей (таблица 4.7).
Таблица 4.7 «Показатели уровня квалификации разработчиков».
| Показатель | Описание | Вес |
| F1 | Знакомство с технологией | 1,5 |
| F2 | Опыт разработки приложений | 0,5 |
| F3 | Опыт использования объектно-ориентированного подхода | 1 |
| F4 | Наличие ведущего аналитика | 0,5 |
| F5 | Мотивация | 1 |
| Показатель | Описание | Вес |
| F6 | Стабильность требований | 2 |
| F7 | Частичная занятость | -1 |
| F8 | Сложные языки программирования | -1 |
Каждому показателю присваивается значение в диапазоне от 0 до 5. Для показателей F1-F4 0 означает отсутствие, 3 – средний уровень, 5 – высокий уровень. Для показателя F5 0 означает отсутствие мотивации, 3 – средний уровень, 5 – высокий уровень мотивации. Для F6 0 означает высокую нестабильность требований, 3 – среднюю, 5 – стабильные требования. Для F7 0 означает отсутствие специалистов с частичной занятостью, 3 – средний уровень, 5 – все специалисты с частичной занятостью. Для показателя F8 0 означает простой язык программирования, 3 – среднюю сложность, 5 – высокую сложность. Значение EF вычисляется по формуле
EF = 1,4 + ( -0,03 (ΣFi Весi))
Вычислим EF для системы «безопасность» (таблица 4.8).
Таблица 4.8 Показатели уровня квалификации разработчиков системы
| Показатель | Вес | Значение | Значение с учетом веса |
| F1 | 1,5 | 2 | 3 |
| F2 | 0,5 | 4 | 2 |
| F3 | 1 | 2 | 2 |
| F4 | 0,5 | 4 | 2 |
| F5 | 1 | 5 | 5 |
| F6 | 2 | 3 | 6 |
| F7 | -1 | 0 | 0 |
| F8 | -1 | 0 | 0 |
| ∑ | 20 |
EF = 1,4 + (-0,03 ∙ 20) = 0.8
В результате получаем окончательное значение UCP (Use Case Points):
UCP = UUCP TCF EF = 83 1,04 0.8 = 69,01
4.5 Оценка трудоемкости проекта
В качестве начального значения предлагается использовать 20 чел.-ч на одну UCP. Эта величина может уточняться с учетом опыта разработчиков.
Приведем пример возможного уточнения.
Рассмотрим показатели F1-F8 и определим, сколько показателей F1-F6 имеют значение меньше 3 и сколько показателей F7-F8 имеют значение больше 3. Если общее количество меньше или равно 2, следует использовать 20 чел.-ч на одну UCP, если 3 или 4 – 28. Если общее количество равно 5 или более, следует внести изменения в сам проект, в противном случае риск провала слишком высок.
Для системы «безопасность» получаем 28 чел.-ч на одну UCP, таким образом, общее количество человеко-часов на весь проект равно 69,01*28=1932,28, что составляет 48 недель при 40-часовой рабочей неделе. Допустим, что команда разработчиков состоит из трех человек, и добавим 3 недели на различные непредвиденные ситуации, тогда в итоге получим 17 недель на весь проект.
Заключение
На первом этапе выполнения курсовой работы ознакомлены с задачами и обязанностями, выполняемыми для обеспечения безопасности. На основании этого во второй части работы была разработана спецификация требований к информационной системе «безопасность». В курсовом проекте для сбора требований использовались методики от Rational Unified Process (RUP). Для разработки функциональных требований RUP – модель вариантов использования (ВИ), которая состоит из диаграммы ВИ и подробно описанных потоков событий (сценариев) для каждого ВИ. Также была освоена работа в Rational RequisitePro и построены матрица функциональных, нефункциональных требований, матрица трассировки и матрица вариантов использования. Так же работа включает глоссарий – устанавливает общую терминологию для всех моделей и описаний требований к системе.
В третьей части курсовой сформированы требования к составу выполняемых функций, организации входных и выходных данных и включает: диаграмму последовательности действий, диаграмму состояний объекта «пользователь», диаграмму деятельности, диаграмму внедрения. Проектный раздел содержит проектные предложения о путях и методах решения сформулированной в начале проекта задачи. Проектная часть описывает процедуру разработки проекта и включает: диаграмму классов, схему и описание информационной базы данных, прототипы экранных форм (пользовательский интерфейс). Пятая часть работы содержит оценку трудоемкости проекта. Сделан вывод, что для разработки системы «безопасность» при условии, что команда разработчиков состоит из трех человек, и добавлено 3 недели на различные непредвиденные ситуации, требуется 23 недели на весь проект. В результате всех проведенных действий был разработан проект информационной системы управления безопасностью под названием «безопасность». В ходе выполнения курсовой работы сделаны выводы, что внедрение информационных систем может способствовать:
· Увеличению качества работоспособности системы;
· Увеличению скорости работоспособности системы;
· Полному контролю над всеми действиями персонала;
· Проведению многокритериального анализа и прогнозированию результатов деятельности;
· Освобождению работников от рутинной работы за счет ее автоматизации.
В ходе эксплуатации данной информационной системы, ее можно усложнять, совершенствовать, добавляя новые функциональные возможности.
Список литературы
1. Вендров А.М. Практикум по проектированию программного обеспечения экономических информационных систем: Учеб. пособие.— 2-е изд., перераб. и доп. — М.: Финансы и статистика, 2006. - 192 с: ил.
2. Вендров А.М. Проектирование программного обеспечения экономических информационных систем: Учебник. — М.: Финансы и статистика, 2002. - 352 с : ил.
0 комментариев