Технологии внедрения информационных систем ТЕМА 4. Лекция 17.

ТЕМА 4.
Технологии внедрения
информационных систем
Лекция 17.
Стадия реализации ИС.
Оценка трудоемкости разработки ИС.
Рабочее проектирование
Рабочее проектирование – детальное
проектирование, включающее:
разработку программ ИС,
 выбор и адаптацию приобретаемых
программных средств,
 разработку спецификаций каждого компонента,
 разработку интерфейсов между компонентами,
 разработку требований к тестам,
 разработку плана интеграции компонентов.

2
Связь между этапами
проектирования
Эскизное
проектирование
Информационная
модель
Бизнесаналитики,
системные
аналитики
Функциональная
модель
Техническое
проектирование
Модель данных
Схема БД
Системные
аналитики,
проектировщики
Функциональные
спецификации
Технические
спецификации
Рабочее
проектирование
База данных
Проектировщики,
программисты,
тестировщики
Программный
код
3
Документация этапа рабочего
проектирования




Рабочий проект – комплекс документации, содержащий все
необходимые и достаточные сведения для обеспечения
выполнения работ по вводу ИС в действие и её эксплуатации,
а также для поддержания уровня эксплуатационных
характеристик (качества) системы в соответствии с
принятыми проектными решениями.
Источником разработки рабочего проекта служит
технический проект.
Рабочий проект оформляется в соответствии с ГОСТ 34.20190 «Виды, комплектность и обозначение документов при
создании автоматизированных систем».
В комплекс рабочего проекта входит также программная
документация в соответствии с ГОСТ 19.701-90.
4
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
Каталог базы данных
Состав выходных данных
(сообщений)
Инструкция по формированию и
ведению базы данных
Чертеж формы документа
(видеокадра)
Ведомость машинных носителей
информации
Массив входных данных
Методика (технология)
автоматизированного
проектирования
Технологическая инструкция
Руководство пользователя
Описание технологического
процесса обработки данных
Инструкция по эксплуатации
КТС
Схема соединений внешних
проводок
Схема подключения внешних
проводок
Таблица соединений и
подключений
15. Схема деления системы
(структурная)
16. Чертеж общего вида
17. Чертеж установки технических
средств
18. Схема принципиальная
19. Схема структурная комплекса
технических средств
20. План расположения
оборудования и проводок
21. Спецификация оборудования
22. Ведомость потребности в
материалах
23. Локальная смета
24. Общее описание системы
25. Программа и методика
испытаний (компонентов,
комплексов средств
автоматизации, подсистемы,
систем)
26. Проектная оценка надежности
системы
27. Ведомость держателей
подлинников
28. Ведомость эксплуатационных
5
документов
Разработка спецификаций
модулей ИС



разработка спецификаций, которые выражают
функциональные возможности каждого модуля в
физических категориях;
определение средств разработки для каждого
модуля (или выделенных групп модулей), если
используются несколько средств разработки в
одном проекте;
определение последовательности реализации
модулей и зависимостей модулей.
6
Предназначение спецификаций
Спецификации
Функциональная
Разрабатывается для
заказчика с целью получения
санкции на завершение
проектирования и начало
реализации.
Техническая
Создается для разработчиков модулей
и групп тестирования, содержит
описание деталей проекта, а также
ряд отчетов из репозитария CASEсредств. Основанием для разработки
служит постановка задачи.
7
Содержание технической спецификации











описание назначения формы или функции модуля;
данные навигации;
формат вызова формы (модуля);
список входных параметров и параметров по умолчанию;
список выходных параметров и правила их обработки;
описание обработки (события внутри модуля и их обработка);
список ошибок, которые генерируются в процессе обработки
и реакция на них;
ограничения доступа к форме (модулю);
вероятные блокировки (потенциальные конфликты и
обработка ожидания);
ожидаемое состояние базы данных после выполнения модуля;
способ проверки целостности данных.
8
Отсутствие спецификаций
Ошибки
Последствия
Неконтролируемый рост
объемов данных
Резкое снижение
производительности системы
Возникновение потоков
запросов с изначально высокой
вероятностью конфликта
Смешивание системных и
интерфейсных модулей,
ошибки в размещении бизнеслогики
Дублирование модулей
Зацикливание
Отсутствие или неполная
реализация требуемых
заказчиком функций системы
Увеличение сроков разработки
и конфликты с заказчиком
Создание «монолитной»,
тяжело сопровождаемой
системы
Неоправданный рост затрат
9
Разработка метрик генерации кода


Метрика генерации кода – это таблица плановой
трудоемкости по кодированию и отладке ПО.
Оценку времени разработки производят:



на основе аналитической документации (на этапе
эскизного проектирования или при разработке ТЗ);
после выполнения большей части проектирования схемы
данных и модулей (на этапе технического
проектирования).
В метрике учитываются:



трудоемкость проектирования модуля,
трудоемкость генерации кода модуля,
трудоемкость тестирования модуля.
10
Тестирование
Объект
Наименование
тестирования теста
Цель проведения теста
Отдельный
модуль
Автономный
тест
1) обнаружение отказов модуля;
2) соответствие модуля спецификации.
Группа
модулей
Тесты связей
Определение взаимного влияния модулей
Тесты имитации Определение степени восстановления
отказов системы системы после сбоев
Подсистема
(система)
Тесты
наработки на
отказ
Определение степени устойчивости
системы в условиях штатной работы,
оценка времени безотказной работы
Тесты пиковой
нагрузки
Определение степени устойчивости
системы в условиях перегрузки.
Системный тест Внутренняя приемка продукта,
показывающая уровень его качества
11
Основные причины неудач проектов
разработки ИС



Плохое управление проектом
«Плывущие» требования
Неправильная оценка проекта, связанная с
отсутствием опыта или методики оценки
проекта;
 непредвиденными проблемами в используемых
средствах и компонентах;
 непониманием ключевых технических проблем
проекта.

12
Единица измерения проекта





Наиболее популярные единицы измерения – время и
функции системы.
зависит от сложности проекта и позволяет изменять
оценку размера проекта с изменением требований;
применима на всех стадиях жизненного цикла
системы, причем на различных этапах жизненного
цикла проекта его эффективность определяется
заново, с различной глубиной проработки;
дает независимые оценки времени выполнения
проекта и его трудоемкости;
позволяет распределить риски между всеми
участниками проекта.
13
Методы оценки трудоемкости
разработки ПО ИС
1. Алгоритмическое моделирование

Основан на анализе статистических данных о
ранее выполненных проектах, затраты
прогнозируются в зависимости от
количественного показателя
2. Экспертные оценки

Основан на опросе экспертов по технологии
разработки ПО в заданной предметной области
3. Оценка по аналогии

Основан на сравнении проекта с предыдущими,
имеющими подобные характеристики
14
Хорошая оценка трудоемкости




создается и поддерживается коллективом
разработчиков;
основывается на подробно описанной и
обоснованной модели оценки;
основывается на данных по аналогичным
проектам;
учитывает все области риска.
15
Факторы оценки трудоемкости





Размер конечного продукта (количество строк
кода или количество функциональных точек);
Особенности технологии разработки ПО;
Квалификация персонала;
Особенности среды разработки
(инструментальных средств);
Требуемое качество продукта
(функциональные возможности,
производительность, надежность).
16
Недостатки метода определения размера
продукта через количество строк кода
1. Не применяется на ранних стадиях разработки.
2. Строки исходного кода зависят от типа языков
программирования, методов проектирования,
стиля и квалификации программиста.
3. Разработка ПО связана с большими затратами,
напрямую не зависящими от размера
программного кода.
4. Генераторы кода продуцируют чрезмерный
объем кода, в результате чего искажаются
показатели трудоемкости.
17
Показатель (по стадиям
ЖЦ)
Команда №1
Команда №2
(низкоуровневый ЯП) (высокоуровневый ЯП)
Изучение требований к ПО
1 мес.
1 мес.
Внешнее и концептуальное
проектирование
2 мес.
2 мес.
Кодирование
9 мес.
2 мес.
Тестирование
4 мес.
2 мес.
Подготовка комплекта
документации
3 мес.
2 мес.
ИТОГО по времени
19 мес.
9 мес.
Число строк кода
30000
5000
Затраты
150000 у.е.
90000 у.е.
Цена строки кода
5 у.е.
18 у.е.
Производительность труда
1500 строк/мес.
500 строк/мес.
18
Методы определения размера продукта
1. Количество строк кода - точка зрения
разработчика.
2. Количество функциональных точек – точка зрения
пользователей.
 Разработчик метода Алан Альбрехт (IBM),1979
 Основная идея метода - максимальный отказ от
деталей реализации ПО и перенос оценки в область
функциональности, наблюдаемой пользователем.
 1986 г. – сформирована Международная
Ассоциация Пользователей Функциональных
Точек (International Function Point User Group —
IFPUG)
19
Алгоритм метода функциональных
точек
20
Алгоритм метода функциональных
точек
1.
2.
3.
4.
5.
6.
7.
Определение типа оценки.
Определение области оценки и границ продукта.
Подсчет функциональных точек, связанных с
данными.
Подсчет функциональных точек, связанных с
транзакциями.
Определение суммарного количества не
выровненных функциональных точек (UFP).
Определение значения фактора выравнивания
(FAV).
Расчет количества выровненных функциональных
точек (AFP).
Тип оценки
Проект
разработки
Область оценки
Оценивается количество
Все разрабатываемые
функциональности,
функции
поставляемой пользователям
в первом релизе продукта.
Оценивается проект
Проект
доработки: добавление,
развития
(поддержки) изменение и удаление
Все добавляемые,
изменяемые и
удаляемые функции
функционала.
Готовый
продукт
Оценивается объем уже
существующего и
установленного продукта.
Только функции,
реально используемые
22
Границы продукта



Что является «внешним» по отношению к продукту.
Где располагается «граница системы», через которую
проходят транзакции, передаваемые или принимаемые
приложением, с точки зрения пользователя.
Какие данные поддерживаются приложением, а какие —
внешние.
23
Внутренние логические файлы (ILFs) — выделяемые
пользователем логически связанные группы данных или блоки
управляющей информации, которые поддерживаются внутри
продукта.
Внешние интерфейсные файлы (EIFs) — выделяемые
пользователем логически связанные группы данных или блоки
управляющей информации, на которые ссылается продукт, но
которые поддерживаются вне продукта.
24
Функциональные точки, связанные с
данными


DET (data element type) — неповторяемое уникальное поле
данных, например, Имя Клиента — 1 DET; Адрес Клиента
(индекс, страна, область, район, город, улица, дом, корпус,
квартира) — 9 DET's
RET (record element type) — логическая группа данных,
например, адрес, паспорт, ФИО.
Объект данных «Клиент»
25
Матрица сложности данных
1-19 DET
1 RET
Низкая
2-5 RET Низкая
6+ RET Средняя
20-50 DET
Низкая
Средняя
Высокая
50+ DET
Средняя
Высокая
Высокая
Оценка в функциональных точках
объекта данных «Клиент»
26
FP, связанные с транзакциями
Виды FP Назначение
EI
(external
inputs)
внешние входные транзакции, элементарная
операция по обработке данных или управляющей
информации, поступающих в систему из вне.
EO
(external
outputs)
внешние выходные транзакции, элементарная
операция по генерации данных или управляющей
информации, которые выходят за пределы системы.
Предполагает определенную логику обработки или
вычислений информации из одного или более ILF.
EQ
(external
inquiries)
внешние запросы, элементарная операция, которая в
ответ на внешний запрос извлекает данные или
управляющую информацию из внутренних
логических файлов (ILF) или внешних
интерфейсных файлов (EIF).
27
Основные отличия между типами
транзакций
Функция
EI
EO
Изменяет
поведение
системы
Поддержка ILF
Основная
Дополнительная Не применяется
Основная
Дополнительная Не применяется
Представление
информации
пользователю
Дополнительная
Основная
EQ
Основная
28
Характеристики транзакций


FTR (file type referenced) — позволяет
подсчитать количество различных файлов
типа ILF и/или EIF, модифицируемых или
считываемых в транзакции.
DET (data element type) – неповторяемое
уникальное поле данных:
EI – поле ввода, кнопка;
 EO – поле данных отчета, сообщение об ошибке;
 EQ – поле ввода для поиска, поле вывода
результатов поиска.

29
Оценка сложности транзакций
Матрица сложности внешних
входных транзакций (EI)
1-4 DET
5-15
DET
16+ DET
0-1 FTR
Низкая
Низкая
Средняя
2 FTR
Низкая
Средняя
3+ FTR
Средняя
Высокая
Матрица сложности внешних
выходных транзакций и
внешних запросов (EO & EQ)
1-5 DET
6-19
DET
20+
DET
0-1 FTR
Низкая
Низкая
Средняя
Высокая
2-3 FTR
Низкая
Средняя
Высокая
Высокая
4+ FTR
Средняя
Высокая Высокая
Оценка в функциональных точках сложности транзакций
Сложность
транзакции
Количество UFP (EI)
Количество UFP (EO) Количество UFP (EQ)
Низкая
3
4
3
Средняя
4
5
4
Высокая
6
7
6
30
1 DET
1 DET
1 DET
Пример оценки
сложности
управляющей
транзакции
(EI)
17 DET, 1 FTR
Средняя
сложность
1 FTR
4 UFP
31
Определение суммарного количества не
выровненных функциональных точек

Общий объем продукта в не выровненных
функциональных точках (UFP)
определяется путем суммирования по всем
информационным объектам (ILF, EIF) и
элементарным операциям (транзакциям EI,
EO, EQ).
32
Расчет количества выровненных
функциональных точек





Учет общесистемных требований осуществляется
путем применения фактора выравнивания (VAF –
Value Adjustment Factor) .
Значение фактора выравнивания зависит от 14
параметров (DI - degree of influence), каждый из
которых оценивается по 5-балльной шкале.
TDI = ∑ DI – суммарный эффект параметров
VAF = (TDI *0.01) + 0.65
AFP = UFP * VAF
Общесистемные параметры
Обмен данными
1.


0 — продукт представляет собой автономное приложение;
5 — продукт обменивается данными по более, чем одному
телекоммуникационному протоколу.
Распределенная обработка данных.
2.


0 — продукт не перемещает данные;
5 — распределенная обработка данных выполняется несколькими
компонентами системы.
Производительность.
3.


0 — пользовательские требования по производительности не установлены;
5 — время отклика критично для всех бизнес-операций, для удовлетворения
требованиям необходимы специальные проектные решения и инструменты
анализа.
Ограничения по аппаратным ресурсам
4.


0 — нет ограничений;
5 — продукт целиком должен функционировать на определенном
процессоре и не может быть распределен.
Транзакционная нагрузка.
5.


0 — транзакций не много, без пиков;
5 — число транзакций велико и неравномерно, требуются специальные
решения и инструменты.
Общесистемные параметры
Интенсивность взаимодействия с пользователем.
6.


0 — все транзакции обрабатываются в пакетном режиме;
5 — более 30% транзакций - интерактивные.
Эргономика
7.


0 — нет специальных требований;
5 — требования по эффективности очень жесткие.
Интенсивность изменения данных пользователями.
8.


0 — не требуются;
5 — изменения интенсивные, жесткие требования по
восстановлению
Сложность обработки
9.


0 — обработка минимальна;
5 — требования безопасности, логическая и математическая
сложность
Повторное использование
10.


0 — не требуется;
5 — продукт разрабатывается как стандартный многоразовый
компонент
Общесистемные параметры
Удобство инсталляции.
11.


0 — нет требований;
5 — установка и обновление ПО производится автоматически
Удобство администрирования
12.


0 — не требуется;
5 — система автоматически самовосстанавливается
Портируемость
13.


0 — продукт имеет только 1 инсталляцию на единственном
процессоре;
5 — система является распределенной и предполагает установку
на различные ТО и ОС
Гибкость
14.


0 — не требуется;
5 — гибкая система запросов и построение произвольных
отчетов, модель данных изменяется пользователем в
интерактивном режиме
Размер ПО в функциональных точках









Текстовые процессоры – 3500
Клиент-серверные приложения – 7500
ПО баз данных – 7500
Бизнес-приложения – 10000
Корпоративные приложения – 25000
Приложения в госучреждениях – 50000
Операционные системы – 75000
Системы масштаба предприятия – 150000
Крупные оборонные системы – 250000
37
Количество строк кода на одну
функциональную точку
Язык (средство)
программирования
Оценка количества строк кода на
1 UFP
Наиболее
Оптимис- Пессимисвероятная
тическая
тическая
Assembler
JavaScript
C++
Visual Basic
SQL
172
56
60
50
46
86
44
29
14
14
320
65
178
276
110
38
Число
FP
Длительность Количество
Пример
разработчиков приложений
1
1 день
10
До 1 месяца 1
Дополнения к
готовой системе
100
До 6
месяцев
(85%)
До 1 года
1
Небольшое
приложение
10
Клиент-серверные
приложения
100
Крупные
приложения
До 1000
Операционные
системы
1000
От 1,5 до 5
лет
100000 От 3 до 8
лет
10000
1
Утилиты
39
Статистическая модель оценки
трудоемкости



Модель COCOMO (COnstructive COst MOdel) –
конструктивная модель стоимости (1985, Барри
Боэм, данные о 63 проектах).
Модель COCOMO II (1997, Центр по разработке
ПО Южно-Калифорнийского университета,
данные о 161 проекте).
В модели используется формула регрессии с
параметрами, определяемыми на основе
отраслевых данных и характеристик конкретного
проекта.
Допущения модели COCOMO







Исходный код конечного продукта включает в себя
все строки кода, кроме комментариев.
Начало цикла разработки совпадает с началом
стадии реализации продукта.
Окончание цикла разработки совпадает с
окончанием приемочного тестирования.
Виды деятельности включают в себя только работы,
непосредственно направленные на выполнение
проекта.
Человеко-месяц состоит из 152 часов.
Проект управляется надлежащим образом.
Требования стабильны.
41
Оценка трудоемкости проекта






PM – трудоемкость в
чел./мес.
SIZE — размер
продукта в тыс. строк
исходного кода
EMi — множители
трудоемкости
SFj — факторы
масштаба
n=7 — для
предварительной
оценки
n=17 — для
детальной оценки
Оценка длительности проекта



С = 3,67; D = 0,28;
TDEV – продолжительность проекта
PMNS — трудоемкость проекта без учета
множителя SCED, определяющего сжатие
расписания.
Факторы масштаба в COCOMO
Фактор
Очень низкий Балл Сверх высокий
уровень
уровень
Балл
Прецедентность
(наличие опыта
аналогичных
разработок) PREC
опыт в продукте и 6,2
платформе
отсутствует
продукт и
платформа
полностью знакомы
0
5,07
определены только
общие цели
0
Архитектура и
риски неизвестны 7,07
разрешение рисков или не
RESL
анализировались
риски определены
на 100%
0
Сработанность
команды
TEAM
формальные
взаимодействия
5,48
полное доверие,
0
взаимозаменяемость
и взаимопомощь
Зрелость
процессов PMAT
CMM Уровень 1
7,8
CMM Уровень 5
Гибкость процесса процесс строго
разработки FLEX детерминирован
0
Значение фактора масштаба
в зависимости от оценки его уровня
Фактор PREC
Уровень
FLEX RESL
TEAM
PMAT
Очень низкий
6,2
5,07
7,07
5,48
7,8
Низкий
4,96
4,05
5,65
4,38
6,24
Номинальный 3,72
3,04
4,24
3,29
4,68
Высокий
2,48
2,03
2,83
2,19
3,12
Очень
высокий
Сверх
высокий
1,24
1,01
1,41
1,10
1,56
0
0
0
0
0
Множители трудоемкости



Множители EMi отражают совместное
влияние многих параметров.
Позволяют характеризовать и нормировать
среду разработки по параметрам,
содержащимся в БД проектов модели
COCOMO II.
Для конкретного проекта каждый
множитель оценивается с помощью
лингвистической переменной – очень
низкий, низкий, номинальный, высокий,
очень высокий.
Множители трудоемкости для
предварительной оценки
Квалификация персонала (PERS)
1.


Low — аналитики и программисты имеют низшую
квалификацию, текучесть больше 45%;
High — аналитики и программисты имеют высшую
квалификацию, текучесть меньше 4%
Сложность и надежность продукта (RCPX)
2.


Low — продукт простой;
High — продукт очень сложный
Разработка для повторного использования
(RUSE)
3.


Low — не требуется;
High — требуется многократное использование в
других продуктах
Множители трудоемкости для
предварительной оценки
Сложность платформы разработки (PDIF)
4.


Low — специальные ограничения по памяти и
быстродействию отсутствуют, платформа стабильна;
High — жесткие ограничения по памяти и
быстродействию, платформа нестабильна
Опыт персонала (PREX)
5.


Low — новое приложение, инструменты и платформа;
High — приложение, инструменты и платформа хорошо
известны
Оборудование (FCIL)
6.


Low — инструменты простейшие, коммуникации затруднены;
High — интегрированные средства поддержки жизненного
цикла, интерактивные мультимедиа коммуникации
Сжатие расписания (SCED)
7.


Low — 75% от номинальной длительности;
High — 160% от номинальной длительности
Значение множителя трудоемкости
в зависимости от оценки его уровня
Множитель PERS
Уровень
RCPX RUSE
PDIF
PREX
FCIL
SCED
Сверх низкий
2,12
0,49
-
-
1,59
1,43
-
Очень низкий
1,62
0,6
-
-
1,33
1,3
1,43
Низкий
1,26
0,83
0,95
0,87
1,22
1,1
1,14
Номинальный
1
1
1
1
1
1
1
Высокий
0,83
1,33
1,07
1,29
0,87
0,87
1
Очень высокий 0,63
1,91
1,15
1,81
0,74
0,73
1
Сверх высокий 0,5
2,72
1,24
2,61
0,62
0,62
-
Множители трудоемкости для
окончательной оценки
Идент. Описание множителя
Диапазон
RELY
Требуемая надежность
0,82 – 1,26
DATA
Размер базы данных
0,9 – 1,28
CLPX
Сложность продукта
0,73 – 1,74
RUSE
Требуемый уровень повторного
использования
0,95 – 1,24
DOCU Соответствие документации требованиям
ЖЦ
0,81 – 1,23
TIME
Ограничение времени выполнения
1,0 – 1,63
STOR
Ограничение по объему основной памяти
1,0 – 1,46
PVOL Изменчивость платформы
0,87 – 1,30
Множители трудоемкости для
окончательной оценки
Идент. Описание множителя
Диапазон
ACAP Способность аналитика
1,42 – 0,71
PCAP
Способность программиста
APEX Знание приложений
1,34 – 0,76
1,22 – 0,81
Знание платформы
1,19 – 0,85
PCON Преемственность персонала
1,29 – 0,81
PLEX
LTEX
Знание языка/инструментальных средств
TOOL Использование инструментальных средств
1,20 – 0,84
1,17 – 0,78
SCED
Требуемые сроки разработки
1,43 – 1,0
SITE
Распределенность команды разработчиков
1,22 – 0,8
Пример определения TOOL
Элементы множителя
Уровни
рейтинга
Значение
Редакторы кода, отладчики
Очень низкий 1,17
Простые CASE-средства с
минимальной интеграцией
Низкий
Средства поддержки основных
процессов ЖЦ, средняя степень
интеграции
Номинальный 1,0
Развитые средства поддержки ЖЦ,
средняя степень интеграции
Высокий
0,9
Мощные средства поддержки ЖЦ,
хорошо интегрированные
Очень
высокий
0,78
1,09