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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

25. Виды функциональных точек • FP, связанные с данными • DET (data element type) — неповторяемое уникальное поле данных, например, Имя Клиента — 1 DET; Адрес Клиента (индекс, страна, область, район, город, улица, дом, корпус, квартира) — 9 DET's • RET (record element type) — логическая группа данных, например, адрес, паспорт, телефонный номер.

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

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