ТЕМА 5. Стадии проектирования и реализации ИС Лекция 24. Оценка трудоемкости разработки ИС.

Основные причины неудач проектов разработки ИС 2 Плохое управление проектом Плохое управление проектом «Плывущие» требования «Плывущие» требования Неправильная оценка проекта, связанная с Неправильная оценка проекта, связанная с отсутствием опыта или методики оценки проекта; отсутствием опыта или методики оценки проекта; непредвиденными проблемами в используемых средствах и компонентах; непредвиденными проблемами в используемых средствах и компонентах; непониманием ключевых технических проблем проекта. непониманием ключевых технических проблем проекта.

Единица измерения проекта Наиболее популярные единицы измерения – время и функции системы. Наиболее популярные единицы измерения – время и функции системы. зависит от сложности проекта и позволяет изменять оценку размера проекта с изменением требований; зависит от сложности проекта и позволяет изменять оценку размера проекта с изменением требований; применима на всех стадиях жизненного цикла системы, причем на различных этапах жизненного цикла проекта его эффективность определяется заново, с различной глубиной проработки; применима на всех стадиях жизненного цикла системы, причем на различных этапах жизненного цикла проекта его эффективность определяется заново, с различной глубиной проработки; дает независимые оценки времени выполнения проекта и его трудоемкости; дает независимые оценки времени выполнения проекта и его трудоемкости; позволяет распределить риски между всеми участниками проекта. позволяет распределить риски между всеми участниками проекта. 3

4 Методы оценки трудоемкости разработки ПО ИС 1.Алгоритмическое моделирование Основан на анализе статистических данных о ранее выполненных проектах, затраты прогнозируются в зависимости от количественного показателя Основан на анализе статистических данных о ранее выполненных проектах, затраты прогнозируются в зависимости от количественного показателя 2.Экспертные оценки Основан на опросе экспертов по технологии разработки ПО в заданной предметной области Основан на опросе экспертов по технологии разработки ПО в заданной предметной области 3.Оценка по аналогии Основан на сравнении проекта с предыдущими, имеющими подобные характеристики Основан на сравнении проекта с предыдущими, имеющими подобные характеристики

5 Факторы оценки трудоемкости Размер конечного продукта (количество строк кода или количество функциональных точек); Размер конечного продукта (количество строк кода или количество функциональных точек); Особенности технологии разработки ПО; Особенности технологии разработки ПО; Квалификация персонала; Квалификация персонала; Особенности среды разработки (инструментальных средств); Особенности среды разработки (инструментальных средств); Требуемое качество продукта (функциональные возможности, производительность, надежность). Требуемое качество продукта (функциональные возможности, производительность, надежность).

6 Недостатки метода определения размера продукта через количество строк кода 1.Не применяется на ранних стадиях разработки. 2.Строки исходного кода зависят от типа языков программирования, методов проектирования, стиля и квалификации программиста. 3.Разработка ПО связана с большими затратами, напрямую не зависящими от размера программного кода. 4.Генераторы кода продуцируют чрезмерный объем кода, в результате чего искажаются показатели трудоемкости.

Показатель (по стадиям ЖЦ) Команда 1 (низкоуровневый ЯП) Команда 2 (высокоуровневый ЯП) Изучение требований к ПО 1 мес. Внешнее и концептуальное проектирование 2 мес. Кодирование 9 мес.2 мес. Тестирование 4 мес.2 мес. Подготовка комплекта документации 3 мес.2 мес. ИТОГО по времени 19 мес.9 мес. Число строк кода Затраты у.е у.е. Цена строки кода 5 у.е.18 у.е. Производительность труда 1500 строк/мес.500 строк/мес. 7

8 Методы определения размера продукта 1.Количество строк кода - точка зрения разработчика. 2.Количество функциональных точек – точка зрения пользователей. Разработчик метода Алан Альбрехт (IBM),1979 Разработчик метода Алан Альбрехт (IBM),1979 Основная идея метода - максимальный отказ от деталей реализации ПО и перенос оценки в область функциональности, наблюдаемой пользователем. Основная идея метода - максимальный отказ от деталей реализации ПО и перенос оценки в область функциональности, наблюдаемой пользователем г. – сформирована Международная Ассоциация Пользователей Функциональных Точек (International Function Point User Group IFPUG) 1986 г. – сформирована Международная Ассоциация Пользователей Функциональных Точек (International Function Point User Group IFPUG)

9 Алгоритм метода функциональных точек

1. Определение типа оценки. 2. Определение области оценки и границ продукта. 3. Подсчет функциональных точек, связанных с данными. 4. Подсчет функциональных точек, связанных с транзакциями. 5. Определение суммарного количества не выровненных функциональных точек (UFP). 6. Определение значения фактора выравнивания (FAV). 7. Расчет количества выровненных функциональных точек (AFP).

Тип оценкиОбласть оценки Проект разработки Оценивается количество функциональности, поставляемой пользователям в первом релизе продукта. Все разрабатываемые функции Проект развития (поддержки) Оценивается проект доработки: добавление, изменение и удаление функционала. Все добавляемые, изменяемые и удаляемые функции Готовый продукт Оценивается объем уже существующего и установленного продукта. Только функции, реально используемые 11

Границы продукта Что является «внешним» по отношению к продукту. Что является «внешним» по отношению к продукту. Где располагается «граница системы», через которую проходят транзакции, передаваемые или принимаемые приложением, с точки зрения пользователя. Где располагается «граница системы», через которую проходят транзакции, передаваемые или принимаемые приложением, с точки зрения пользователя. Какие данные поддерживаются приложением, а какие внешние. Какие данные поддерживаются приложением, а какие внешние. 12

13 Функциональные точки, связанные с данными DET (data element type) неповторяемое уникальное поле данных, например, Имя Клиента 1 DET; Адрес Клиента (индекс, страна, область, район, город, улица, дом, корпус, квартира) 9 DET's DET (data element type) неповторяемое уникальное поле данных, например, Имя Клиента 1 DET; Адрес Клиента (индекс, страна, область, район, город, улица, дом, корпус, квартира) 9 DET's RET (record element type) логическая группа данных, например, адрес, паспорт, ФИО. RET (record element type) логическая группа данных, например, адрес, паспорт, ФИО. Объект данных «Клиент»

Матрица сложности данных 1-19 DET20-50 DET50+ DET 1 RETНизкая Средняя 2-5 RETНизкаяСредняяВысокая 6+ RETСредняяВысокая 14 Оценка в функциональных точках объекта данных «Клиент»

15 FP, связанные с транзакциями Виды FPНазначениеПример EI (external inputs) внешние входные транзакции, элементарная операция по обработке данных или управляющей информации, поступающих в систему из вне. Поле ввода, кнопка EO (external outputs) внешние выходные транзакции, элементарная операция по генерации данных или управляющей информации, которые выходят за пределы системы. Предполагает определенную логику обработки или вычислений информации из одного или более ILF. Поле данных отчета, сообщение об ошибке EQ (external inquiries) внешние запросы, элементарная операция, которая в ответ на внешний запрос извлекает данные или управляющую информацию из ILF или EIF. Поле ввода для поиска, поле вывода результата поиска

Оценка сложности транзакций Матрица сложности внешних входных транзакций (EI) 1-4 DET5-15 DET 16+ DET 0-1 FTRНизкая Средняя 2 FTRНизкаяСредняяВысокая 3+ FTRСредняяВысокая Матрица сложности внешних выходных транзакций и внешних запросов (EO & EQ) 1-5 DET6-19 DET 20+ DET 0-1 FTRНизкая Средняя 2-3 FTRНизкаяСредняяВысокая 4+ FTRСредняяВысокая 16 Сложность EI Количество FP (EI) EO Количество FP (EO) EQ Количество FP (EQ) Низкая343 Средняя454 Высокая676 Оценка в функциональных точках сложности транзакций FTR (file type referenced) позволяет подсчитать количество различных файлов типа ILF и/или EIF, модифицируемых или считываемых в транзакции.

17 Пример оценки сложности транзакции 1 DET 1 FTR 17 DET, 1 FTR Средняя сложность 4 UFP

Определение суммарного количества не выровненных функциональных точек Общий объем продукта в не выровненных функциональных точках (UFP) определяется путем суммирования по всем информационным объектам (ILF, EIF) и элементарным операциям (транзакциям EI, EO, EQ). Общий объем продукта в не выровненных функциональных точках (UFP) определяется путем суммирования по всем информационным объектам (ILF, EIF) и элементарным операциям (транзакциям EI, EO, EQ). 18

Расчет количества выровненных функциональных точек Учет общесистемных требований осуществляется путем применения фактора выравнивания (VAF – Value Adjustment Factor). Учет общесистемных требований осуществляется путем применения фактора выравнивания (VAF – Value Adjustment Factor). Значение фактора выравнивания зависит от 14 параметров (DI - degree of influence), каждый из которых оценивается по 5-балльной шкале. Значение фактора выравнивания зависит от 14 параметров (DI - degree of influence), каждый из которых оценивается по 5-балльной шкале. TDI = DI – суммарный эффект параметров TDI = DI – суммарный эффект параметров VAF = (TDI *0.01) VAF = (TDI *0.01) AFP = UFP * VAF AFP = UFP * VAF

Общесистемные параметры 1. Обмен данными 0 продукт представляет собой автономное приложение; 0 продукт представляет собой автономное приложение; 5 продукт обменивается данными по более, чем одному телекоммуникационному протоколу. 5 продукт обменивается данными по более, чем одному телекоммуникационному протоколу. 2. Распределенная обработка данных. 0 продукт не перемещает данные; 0 продукт не перемещает данные; 5 распределенная обработка данных выполняется несколькими компонентами системы. 5 распределенная обработка данных выполняется несколькими компонентами системы. 3. Производительность. 0 пользовательские требования по производительности не установлены; 0 пользовательские требования по производительности не установлены; 5 время отклика критично для всех бизнес-операций, для удовлетворения требованиям необходимы специальные проектные решения и инструменты анализа. 5 время отклика критично для всех бизнес-операций, для удовлетворения требованиям необходимы специальные проектные решения и инструменты анализа. 4. Ограничения по аппаратным ресурсам 0 нет ограничений; 0 нет ограничений; 5 продукт целиком должен функционировать на определенном процессоре и не может быть распределен. 5 продукт целиком должен функционировать на определенном процессоре и не может быть распределен. 5. Транзакционная нагрузка. 0 транзакций не много, без пиков; 0 транзакций не много, без пиков; 5 число транзакций велико и неравномерно, требуются специальные решения и инструменты. 5 число транзакций велико и неравномерно, требуются специальные решения и инструменты.

Общесистемные параметры 6. Интенсивность взаимодействия с пользователем. 0 все транзакции обрабатываются в пакетном режиме; 0 все транзакции обрабатываются в пакетном режиме; 5 более 30% транзакций - интерактивные. 5 более 30% транзакций - интерактивные. 7. Эргономика 0 нет специальных требований; 0 нет специальных требований; 5 требования по эффективности очень жесткие. 5 требования по эффективности очень жесткие. 8. Интенсивность изменения данных пользователями. 0 не требуются; 0 не требуются; 5 изменения интенсивные, жесткие требования по восстановлению 5 изменения интенсивные, жесткие требования по восстановлению 9. Сложность обработки 0 обработка минимальна; 0 обработка минимальна; 5 требования безопасности, логическая и математическая сложность 5 требования безопасности, логическая и математическая сложность 10. Повторное использование 0 не требуется; 0 не требуется; 5 продукт разрабатывается как стандартный многоразовый компонент 5 продукт разрабатывается как стандартный многоразовый компонент

Общесистемные параметры 11. Удобство инсталляции. 0 нет требований; 0 нет требований; 5 установка и обновление ПО производится автоматически 5 установка и обновление ПО производится автоматически 12. Удобство администрирования 0 не требуется; 0 не требуется; 5 система автоматически самовосстанавливается 5 система автоматически самовосстанавливается 13. Портируемость 0 продукт имеет только 1 инсталляцию на единственном процессоре; 0 продукт имеет только 1 инсталляцию на единственном процессоре; 5 система является распределенной и предполагает установку на различные ТО и ОС 5 система является распределенной и предполагает установку на различные ТО и ОС 14. Гибкость 0 не требуется; 0 не требуется; 5 гибкая система запросов и построение произвольных отчетов, модель данных изменяется пользователем в интерактивном режиме 5 гибкая система запросов и построение произвольных отчетов, модель данных изменяется пользователем в интерактивном режиме

23 Размер ПО в функциональных точках Текстовые процессоры – 3500 Текстовые процессоры – 3500 Клиент-серверные приложения – 7500 Клиент-серверные приложения – 7500 ПО баз данных – 7500 ПО баз данных – 7500 Бизнес-приложения – Бизнес-приложения – Корпоративные приложения – Корпоративные приложения – Приложения в госучреждениях – Приложения в госучреждениях – Операционные системы – Операционные системы – Системы масштаба предприятия – Системы масштаба предприятия – Крупные оборонные системы – Крупные оборонные системы –

Количество строк кода на одну функциональную точку Язык (средство) программирования Оценка количества строк кода на 1 FP Наиболее вероятная Оптимис- тическая Пессимис- тическая Assembler JavaScript C Visual Basic

25 Число FP Длительность Количество разработчиков Пример приложений 1 1 день 1Утилиты 10 До 1 месяца 1 Дополнения к готовой системе 100 До 6 месяцев (85%) 1 Небольшое приложение 1000 До 1 года 10 Клиент-серверные приложения От 1,5 до 5 лет 100 Крупные приложения От 3 до 8 лет До 1000 Операционные системы

Статистическая модель оценки трудоемкости Модель COCOMO (COnstructive COst MOdel) – конструктивная модель стоимости (1985, Барри Боэм, данные о 63 проектах). Модель COCOMO (COnstructive COst MOdel) – конструктивная модель стоимости (1985, Барри Боэм, данные о 63 проектах). Модель COCOMO II (1997, Центр по разработке ПО Южно-Калифорнийского университета, данные о 161 проекте). Модель COCOMO II (1997, Центр по разработке ПО Южно-Калифорнийского университета, данные о 161 проекте). В модели используется формула регрессии с параметрами, определяемыми на основе отраслевых данных и характеристик конкретного проекта. В модели используется формула регрессии с параметрами, определяемыми на основе отраслевых данных и характеристик конкретного проекта.

Допущения модели COCOMO Исходный код конечного продукта включает в себя все строки кода, кроме комментариев. Исходный код конечного продукта включает в себя все строки кода, кроме комментариев. Начало цикла разработки совпадает с началом стадии реализации продукта. Начало цикла разработки совпадает с началом стадии реализации продукта. Окончание цикла разработки совпадает с окончанием приемочного тестирования. Окончание цикла разработки совпадает с окончанием приемочного тестирования. Виды деятельности включают в себя только работы, непосредственно направленные на выполнение проекта. Виды деятельности включают в себя только работы, непосредственно направленные на выполнение проекта. Человеко-месяц состоит из 152 часов. Человеко-месяц состоит из 152 часов. Проект управляется надлежащим образом. Проект управляется надлежащим образом. Требования стабильны. Требования стабильны. 27

Оценка трудоемкости проекта PM – трудоемкость в чел./мес. PM – трудоемкость в чел./мес. SIZE размер продукта в тыс. строк исходного кода SIZE размер продукта в тыс. строк исходного кода EM i множители трудоемкости EM i множители трудоемкости SF j факторы масштаба SF j факторы масштаба n=7 для предварительной оценки n=7 для предварительной оценки n=17 для детальной оценки n=17 для детальной оценки

Оценка длительности проекта С = 3,67; D = 0,28; TDEV – продолжительность проекта PM NS трудоемкость проекта без учета множителя SCED, определяющего сжатие расписания.

Факторы масштаба в COCOMO Фактор Низкий уровень Балл Высокий уровень Балл Прецедентност ь опыт в продукте и платформе отсутствует 6,2 продукт и платформа полностью знакомы 0 Гибкость процесса разработки процесс строго детерминирован 5,07 определены только общие цели 0 Архитектура и разрешение рисков риски неизвестны/не проанализированы 7,07 риски определены на 100% 0 Сработанность команды формальные взаимодействия 5,48 полное доверие, взаимозаменяемость и взаимопомощь 0 Зрелость процессов CMM Уровень 1 7,8 CMM Уровень 5 0

Множители трудоемкости Множители EM i отражают совместное влияние многих параметров. Множители EM i отражают совместное влияние многих параметров. Позволяют характеризовать и нормировать среду разработки по параметрам, содержащимся в БД проектов модели COCOMO II. Позволяют характеризовать и нормировать среду разработки по параметрам, содержащимся в БД проектов модели COCOMO II. Для конкретного проекта каждый множитель оценивается с помощью лингвистической переменной – очень низкий, низкий, номинальный, высокий, очень высокий. Для конкретного проекта каждый множитель оценивается с помощью лингвистической переменной – очень низкий, низкий, номинальный, высокий, очень высокий.

Множители трудоемкости для предварительной оценки 1. Квалификация персонала (PERS) Low аналитики и программисты имеют низшую квалификацию, текучесть больше 45%; Low аналитики и программисты имеют низшую квалификацию, текучесть больше 45%; High аналитики и программисты имеют высшую квалификацию, текучесть меньше 4% High аналитики и программисты имеют высшую квалификацию, текучесть меньше 4% 2. Сложность и надежность продукта (RCPX) Low продукт простой, специальных требований по надежности нет, БД маленькая, документация не требуется; Low продукт простой, специальных требований по надежности нет, БД маленькая, документация не требуется; High продукт очень сложный, требования по надежности жесткие, БД сверхбольшая, документация требуется в полном объеме High продукт очень сложный, требования по надежности жесткие, БД сверхбольшая, документация требуется в полном объеме 3. Сложность платформы разработки (PDIF) Low специальные ограничения по памяти и быстродействию отсутствуют, платформа стабильна; Low специальные ограничения по памяти и быстродействию отсутствуют, платформа стабильна; High жесткие ограничения по памяти и быстродействию, платформа нестабильна High жесткие ограничения по памяти и быстродействию, платформа нестабильна

Множители трудоемкости для предварительной оценки 4. Опыт персонала (PREX) Low новое приложение, инструменты и платформа; Low новое приложение, инструменты и платформа; High приложение, инструменты и платформа хорошо известны High приложение, инструменты и платформа хорошо известны 5. Оборудование (FCIL) Low инструменты простейшие, коммуникации затруднены; Low инструменты простейшие, коммуникации затруднены; High интегрированные средства поддержки жизненного цикла, интерактивные мультимедиа коммуникации High интегрированные средства поддержки жизненного цикла, интерактивные мультимедиа коммуникации 6. Сжатие расписания (SCED) Low 75% от номинальной длительности; Low 75% от номинальной длительности; High 160% от номинальной длительности High 160% от номинальной длительности 7. Разработка для повторного использования (RUSE) Low не требуется; Low не требуется; High требуется многократное использование в других продуктах High требуется многократное использование в других продуктах

Множители трудоемкости Идент. Описание множителя Диапазон 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 Способность программиста 1,34 – 0,76 APEX Знание приложений 1,22 – 0,81 PLEX Знание платформы 1,19 – 0,85 PCON Преемственность персонала 1,29 – 0,81 LTEX Знание языка/инструментальных средств 1,20 – 0,84 TOOL Использование инструментальных средств 1,17 – 0,78 SCED Требуемые сроки разработки 1,43 – 1,0 SITE Распределенность команды разработчиков 1,22 – 0,8

Пример определения TOOL Элементы множителя Уровни рейтинга Значение Редакторы кода, отладчики Очень низкий 1,17 Простые CASE-средства с минимальной интеграцией Низкий1,09 Средства поддержки основных процессов ЖЦ, средняя степень интеграции Номинальный1,0 Развитые средства поддержки ЖЦ, средняя степень интеграции Высокий0,9 Мощные средства поддержки ЖЦ, хорошо интегрированные Очень высокий 0,78

37 Методы оценки трудоемкости разработки ТД ГОСТ Р ИСО/МЭК « Информационная технология. Процесс создания документации пользователя программного средства» ГОСТ Р ИСО/МЭК « Информационная технология. Процесс создания документации пользователя программного средства» Метод нисходящего проектирования Метод нисходящего проектирования Поминутно-почасовой метод Поминутно-почасовой метод Справочник базовых цен на разработку технической документации на автоматизированные системы управления технологическими процессами (АСУТП) Справочник базовых цен на разработку технической документации на автоматизированные системы управления технологическими процессами (АСУТП)

38 Метод нисходящего проектирования Число страниц оценивается: Число страниц оценивается: автор может за месяц подготовить 22 страницы нового текста; автор может за месяц подготовить 22 страницы нового текста; автор может за месяц подготовить 44 страницы текста с изменениями. автор может за месяц подготовить 44 страницы текста с изменениями. 15 % - планирование; 15 % - планирование; 50 % - написание первой редакции; 50 % - написание первой редакции; 25 % - написание второй редакции; 25 % - написание второй редакции; 10 % - подготовка фотошаблонов (скриншотов). 10 % - подготовка фотошаблонов (скриншотов).

39 Поминутно-почасовой метод 1)Определение номенклатуры поставки 2)Исследование содержания документации 3)Написание плана документирования 4)Проектирование структуры документа и правил оформления его страниц 5)Написание первой редакции (документации) 6)Разработка графических материалов 7)Объединение текстовых и графических материалов 8)Проверка первой редакции (эксперт) 9)Корректировка первой редакции и графики 10)Внесение замечаний пользователя 11)Грамматическое редактирование 12)Подготовка второй редакции (документации) 13)Проверка второй редакции (эксперт) 14)Окончательная корректировка документации 15)Нормоконтроль документации 16)Изготовление фотошаблонов 17)Печать и переплетение оригиналов 18)Печать и брошюровка копий 19)Рассылка 16 ч на проект 24 ч на проект 48 ч на проект 8 ч на том 1 ч на страницу 5 ч на материал 30 мин на страницу 15 мин на страницу 10 мин на страницу 15 мин на страницу 3 сут. 5 сут. 10 сут. 1 сут.

40

41 Метрики документирования Метрики проекта Метрики пользовательской перспективы Метрики данных Метрики интерфейса пользователя Объем доступной документации; Объем доступной документации; Количество экспертов Количество экспертов Количество рецензентов Количество рецензентов Количество функциональных ролей; Количество функциональных ролей; Количество пользовательских задач; Количество пользовательских задач; Количество функций программы; Количество функций программы; Количество реакций пользователя на сообщения программы Количество реакций пользователя на сообщения программы Количество сущностей; Количество сущностей; Количество атрибутов объектов; Количество атрибутов объектов; Количество поддерживаемых форматов данных Количество поддерживаемых форматов данных Количество главных окон и рабочих областей; Количество главных окон и рабочих областей; Количество крупных экранных форм; Количество крупных экранных форм; Количество команд главного меню; Количество команд главного меню; Количество сообщений об ошибках Количество сообщений об ошибках

42 Последовательность разработки эксплуатационной документации Изучение продукта Чтение документации; Интервью; Работа на стенде Составление плана документирования Анализ требований к документу; Составление структуры документа; Составление и согласование плана документирования Написание текста Изложение структурной информации; Изложение процедурной информации; Изложение справочной информации; Подготовка рисунков Согласование текста Обсуждение замечаний; Внесение исправлений Оформление текста Авторская разметка; Расстановка перекрестных ссылок; Разметка указателя

43 Для решаемой задачи измеряются значения каждого показателя из списка метрик. Для каждого вида работ рассчитывается трудоемкость по формуле: Трудоемкость i = Метрика 1 *T i1 + Метрика 2 *T i2 +…+ Метрика N *T iN.

44 Расчет стоимости работ по созданию ТД Базовая цена разработки ТД определяется в зависимости от количества баллов, подсчитанных по основным факторам трудоемкости, соответствующего ценностного множителя и общего поправочного коэффициента: Базовая цена разработки ТД определяется в зависимости от количества баллов, подсчитанных по основным факторам трудоемкости, соответствующего ценностного множителя и общего поправочного коэффициента: Ц баз = S x Б x К Цены установлены отдельно на разработку каждой из следующих частей проектной документации на АСУТП: Цены установлены отдельно на разработку каждой из следующих частей проектной документации на АСУТП: общесистемные решения (ОР); общесистемные решения (ОР); организационное обеспечение (ОО); организационное обеспечение (ОО); информационное обеспечение (ИО); информационное обеспечение (ИО); техническое обеспечение (ТО). техническое обеспечение (ТО). математическое обеспечение (МО). математическое обеспечение (МО). программное обеспечение (ПО). программное обеспечение (ПО).

45 Факторы трудоемкости разработки проектной документации на АСУТП 1.Характер протекания управляемого технологического процесса во времени (непрерывный, циклический, дискретный) 2.Количество технологических операций, контролируемых или управляемых АСУТП 3.Степень развитости информационных функций АСУТП (I-IV) 4.Степень развитости управляющих функций АСУТП (I-VII) 5.Режим выполнения управляющих функции АСУТП (автоматизированный/автоматический, всего 5 режимов) 6.Количество переменных, измеряемых, контролируемых и регистрируемых АСУТП 7.Количество управляющих воздействий, вырабатываемых АСУТП

46 Ориентировочное распределение базовой цены двухстадийной разработки ТД Части ТД ТПРД Общесистемные решения 70-80%20-30% Организационное обеспечение 30-40%60-70% Информационное обеспечение 40-50%50-60% Техническое обеспечение 40-50%50-60% Математическое обеспечение 80-90%10-20% Программное обеспечение 10-20%80-90%

47 Пример определения цены разработки проектной документации на АСУТП Исходные данные по факторам трудоемкости: 1. Характер протекания управляемого технологического процесса во времени – полунепрерывный технологический процесс; 2. Количество технологических операций, контролируемых или управляемых АСУТП – 36; 3. Степень развитости информационных функций АСУТП - III степень (косвенное измерение (вычисление) отдельных комплексных показателей функционирования ТОУ); 4. Степень развитости управляющих функций АСУТП - IV степень (оптимальное управление установившимися режимами (в статике)); 5. Режим выполнения управляющих функции АСУТП – автоматизированный режим "советчика"; 6. Количество переменных, измеряемых, контролируемых и регистрируемых АСУТП – 365; 7. Количество управляющих воздействий, вырабатываемых АСУТП – 130

48 Пример определения цены разработки проектной документации на АСУТП Исходные данные для поправочных коэффициентов: создаваемая АСУТП является впервые разрабатываемой и подлежит эксплуатации в России; создаваемая АСУТП является впервые разрабатываемой и подлежит эксплуатации в России; АСУТП создается с использованием зарубежных технических средств (К6); АСУТП создается с использованием зарубежных технических средств (К6); АСУТП подлежит эксплуатации в условиях взрывоопасного производства (К10.1); АСУТП подлежит эксплуатации в условиях взрывоопасного производства (К10.1); АСУТП создается на вновь проектируемом технологическом объекте управления; АСУТП создается на вновь проектируемом технологическом объекте управления; разработка документации выполняется в две стадии. разработка документации выполняется в две стадии.

49 Определение базовой цены для ОР = 29 для ОР = 29 для ОО = 18 для ОО = 18 для ИО = 37 для ИО = 37 для ТО = 32 для ТО = 32 для МО = 37 для МО = 37 для ПО = 37 для ПО = 37 Сумма баллов для каждого вида документации Повышающий коэффициент К6 = 1,1; К10.1 = 1,3.

50 Определение баллов для факторов трудоемкости Пример для фактора 7 (количество управляющих воздействий, вырабатываемых АСУТП = 130) Пример для фактора 7 (количество управляющих воздействий, вырабатываемых АСУТП = 130) Части ТД ЗначениефактораОРООИОТОМОПО

51 Базовая цена двухстадийной разработки проектной документации на АСУТП Части документации Ценностный множитель ОР2,04 ОО1,24 ИО1,83 ТО4,38 МО4,92 ПО6,00

52 Экспертиза технической документации Экспертиза документации определяет согласованность документов, разработанных на разных стадиях создания ИС. Экспертиза документации определяет согласованность документов, разработанных на разных стадиях создания ИС. Согласованность – главное требование к выражающееся в непротиворечивости сведений, излагаемых в отдельных документах, входящих в состав комплекта технической документации. Согласованность – главное требование к технической документации, выражающееся в непротиворечивости сведений, излагаемых в отдельных документах, входящих в состав комплекта технической документации.

53 Цели и задачи экспертизы ТД ЦЕЛИ: снижение финансовых рисков заказчика и исполнителя при создании ИС; снижение финансовых рисков заказчика и исполнителя при создании ИС; сокращение сроков ввода ИС в действие. сокращение сроков ввода ИС в действие.ЗАДАЧИ: проверка технической документации на комплектность; проверка технической документации на комплектность; проверка структуры разделов технической документации на соответствие требованиям стандартов, нормативных документов и актов; проверка структуры разделов технической документации на соответствие требованиям стандартов, нормативных документов и актов; проверка соответствия содержательной части технической документации требованиям НТД и техническим требованиям организации-эксперта. проверка соответствия содержательной части технической документации требованиям НТД и техническим требованиям организации-эксперта.

54 Техническая документация, подлежащая экспертизе Техническое задание на создание автоматизированной системы; Техническое задание на создание автоматизированной системы; Технический или технорабочий проект; Технический или технорабочий проект; Документы, разрабатываемые на стадии «Рабочая документация»; Документы, разрабатываемые на стадии «Рабочая документация»; Эксплуатационная документация; Эксплуатационная документация; Программа и методики испытаний. Программа и методики испытаний.

55 Взаимосвязь технической документации Техническое задание Пояснительная записка к техническому проекту Общее описание системы (рабочий проект) Требования Решения Стадия анализа предметной области Сведения о системе Проектная стадия Стадия реализации (разработки)

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

57