ТЕМА 5. Стадии проектирования и реализации ИС

1. ТЕМА 5.Стадии проектирования и реализации ИС Лекция 23. Этап рабочего проектирования.

2. по ISO/IEC 15288:2002 Формирование концепции Разработка Реализация Эксплуатация Поддержка Снятие с эксплуатации по ГОСТ 34.601-90 Формирование требований к АС Разработка концепции АС. Техническое задание. Эскизный проект. Технический проект. Рабочая документация. Ввод в действие. Сопровождение АС Анализ требований Стадии ЖЦ Проектирование Реализация Внедрение Эксплуатация

3. Стадии ЖЦ по ГОСТ 34.601-90

4. Проектирование ИС Эскизный проект (мнемосхемы, диаграммы процессов верхнего уровня) Эскизное проектирование Результаты анализа предметной области Технический проект (системный проект в виде комплекса моделей работы ИС) Техническое проектирование Рабочий проект (комплекс программ с эксплуатационной документацией) Техно-рабочее проектирование Рабочее проектирование Готовая к внедрению ИС

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

6. Связь между этапами проектирования

7. Документация этапа рабочего проектирования • Рабочий проект – комплекс документации, содержащий все необходимые и достаточные сведения для обеспечения выполнения работ по вводу ИС в действие и её эксплуатации, а также для поддержания уровня эксплуатационных характеристик (качества) системы в соответствии с принятыми проектными решениями. • Источником разработки рабочего проекта служит технический проект. • Рабочий проект оформляется в соответствии с ГОСТ 34.201-90 «Виды, комплектность и обозначение документов при создании автоматизированных систем». • В комплекс рабочего проекта входит также программная документация в соответствии с ГОСТ 19.701-90.

9. Разработка спецификаций модулей ИС • разработка спецификаций, которые выражают функциональные возможности каждого модуля в физических категориях; • определение средств разработки для каждого модуля (или выделенных групп модулей), если используются несколько средств разработки в одном проекте; • определение последовательности реализации модулей и зависимостей модулей.

10. Предназначение спецификаций Разрабатывается для заказчика с целью получения санкции на завершение проектирования и начало реализации. Создается для разработчиков модулей и групп тестирования, содержит описание деталей проекта, а также ряд отчетов из репозитарияCASE-средств. Основанием для разработки служит постановка задачи.

11. Содержание технической спецификации • описание назначения формы или функции модуля; • данные навигации; • формат вызова формы (модуля); • список входных параметров и параметров по умолчанию; • список выходных параметров и правила их обработки; • описание обработки (события внутри модуля и их обработка); • список ошибок, которые генерируются в процессе обработки и реакция на них; • ограничения доступа к форме (модулю); • вероятные блокировки (потенциальные конфликты и обработка ожидания); • ожидаемое состояние базы данных после выполнения модуля; • способ проверки целостности данных.

12. Отсутствие спецификаций

13. Разработка метрик генерации кода • Метрика генерации кода – это таблица плановой трудоемкости по кодированию и отладке ПО. • Оценку времени разработки производят: • на основе аналитической документации (на этапе эскизного проектирования или при разработке ТЗ); • после выполнения большей части проектирования схемы данных и модулей (на этапе технического проектирования). • В метрике учитываются: • трудоемкость проектирования модуля, • трудоемкость генерации кода модуля, • трудоемкость тестирования модуля.

14. Факторы оценки трудоемкости • стабильность модели данных и степень ее изменения в течение разработки; • стабильность модели функций и степень ее изменения в течение разработки; • уровень квалификации персонала; • среда разработки (инструменты и методы, использование автоматических генераторов кода); • размер конечного продукта; • качество ИС (производительность, надежность, адаптируемость).

15. Обмен данными • Интерфейсы обмена с внешними системами можно разбить на следующие категории: • одноразовый импорт данных, унаследованных из старой системы; • периодический обмен данными между компонентами информационной системы (внутренний обмен); • периодический обмен данных с другими информационными системами (внешний обмен). • Если обмен данными должен осуществляться в режиме, близком к реальному времени, то это будет задача о распределенной базе данных, а не о простой передаче данных.

16. Алгоритм загрузки/выгрузки данных • определение перечня подсистем, которым нужен интерфейс выгрузки/загрузки данных; • определение периодичности обмена данными и объема передаваемых данных; • определение возможных методов транспортировки данных; • согласование форматов данных для обмена; • определение порядка выполнения операций при загрузке/выгрузке; • определение мероприятий в случае сбоев во время загрузки и выгрузки данных; • формулировка правил определения ошибочных записей (при загрузке); • определение правил регистрации операций передачи и приема данных; • определение графика передачи данных; • составление графика разработки и тестирования собственных утилит обмена данными; • составление графика разовой загрузки данных, наследуемых из старой системы, и подготовка методики проверки корректности этой операции.

17. Тестирование

18. Функции системы хранения ошибок • хранение сообщения об ошибке; • уведомление о появлении новых ошибок, об изменении статуса известных в системе ошибок; • формирование отчетов об актуальных ошибках по компонентам системы, по интервалам времени, по разработчикам; • хранение информации об истории ошибки; • организация доступа разработчиков к ошибкам разных категорий; • организация доступа конечного пользователя ИС как интерфейс обмена информацией между пользователем и службой технической поддержки.

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

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

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

22. Методы оценки трудоемкости разработки ПО • Закон Паркинсона • Усилия, затраченные на работу, распределяются равномерно по выделенному на проект времени. • Критерием для оценки затрат являются человеческие ресурсы, а не целевая оценка самого программного продукта. • Оценка с целью выиграть контракт • Трудоемкость проекта зависит от бюджета заказчика, а не от функциональных характеристик создаваемой ИС.

23. Хорошая оценка трудоемкости • создается и поддерживается коллективом разработчиков; • основывается на подробно описанной и обоснованной модели оценки; • основывается на данных по аналогичным проектам; • учитывает все области риска.

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

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

27. Методы определения размера продукта • Количество строк кода - точка зрения разработчика. • Количество функциональных точек – точка зрения пользователей. • Разработчик метода Алан Альбрехт (IBM),1979 • Основная идея метода - максимальный отказ от деталей реализации ПО и перенос оценки в область функциональности, наблюдаемой пользователем. • 1986 г. – сформирована Международная Ассоциация Пользователей Функциональных Точек (InternationalFunctionPointUserGroup — IFPUG)

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

29. Алгоритм метода функциональных точек • Определение типа оценки. • Определение области оценки и границ продукта. • Подсчет функциональных точек, связанных с данными. • Подсчет функциональных точек, связанных с транзакциями. • Определение суммарного количества не выровненных функциональных точек (UFP). • Определение значения фактора выравнивания (FAV). • Расчет количества выровненных функциональных точек (AFP).

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

32. Внутренние логические файлы (ILFs) — выделяемые пользователем логически связанные группы данных или блоки управляющей информации, которые поддерживаются внутри продукта. Внешние интерфейсные файлы (EIFs) — выделяемые пользователем логически связанные группы данных или блоки управляющей информации, на которые ссылается продукт, но которые поддерживаются вне продукта.

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

34. Матрица сложности данных Оценка в функциональных точках объекта данных «Клиент»

35. FP, связанные с транзакциями

36. Оценка сложности транзакций Матрица сложности внешних входных транзакций (EI) Матрица сложности внешних выходных транзакций и внешних запросов (EO & EQ) FTR (file type referenced) — позволяет подсчитать количество различных файлов типа ILF и/или EIF, модифицируемых или считываемых в транзакции. Оценка в функциональных точкахсложности транзакций

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

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

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

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

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

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

43. Размер ПО в функциональных точках • Текстовые процессоры – 3500 • Клиент-серверные приложения – 7500 • ПО баз данных – 7500 • Бизнес-приложения – 10000 • Корпоративные приложения – 25000 • Приложения в госучреждениях – 50000 • Операционные системы – 75000 • Системы масштаба предприятия – 150000 • Крупные оборонные системы – 250000

44. Количество строк кода на одну функциональную точку

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

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

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

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

50. Факторы масштаба в COCOMO