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

ТЕМА 5.
Стадии проектирования
и реализации ИС
Лекция 22.
Этап рабочего проектирования.
Стадии ЖЦ
по ISO/IEC 15288:2002
 Формирование концепции
 Разработка
 Реализация
 Эксплуатация
 Поддержка
 Снятие с эксплуатации
Проектирование
Реализация
Внедрение
Анализ
требований
по ГОСТ 34.601-90
 Формирование
требований к АС
 Разработка концепции АС.
 Техническое задание.
 Эскизный проект.
 Технический проект.
 Рабочая документация.

Ввод в действие.

Сопровождение АС
Эксплуатация
2
Стадии ЖЦ по ГОСТ 34.601-90
Стадия
Этапы
4. Эскизный
проект.
4.1. Разработка предварительных проектных решений по
системе и её частям.
4.2. Разработка документации на АС и её части.
5. Технический
проект.
5.1. Разработка проектных решений по системе и её
частям.
5.2. Разработка документации на АС и её части.
5.3. Разработка и оформление документации на поставку
изделий для комплектования АС и (или) технических
требований (технических заданий) на их разработку.
5.4. Разработка заданий на проектирование в смежных
частях проекта объекта автоматизации.
6. Рабочая
документация.
6.1. Разработка рабочей документации на систему и её
части.
6.2. Разработка или адаптация программ.
3
Проектирование ИС
Эскизный проект
Результаты
анализа
предметной
области
Эскизное
проектирование
(мнемосхемы,
диаграммы процессов
верхнего уровня)
Технический проект
(системный проект в
виде комплекса
моделей работы ИС)
Техническое
проектирование
Техно-рабочее
проектирование
Рабочее
проектирование
Рабочий проект
(комплекс программ с
эксплуатационной
документацией)
Готовая к
внедрению
ИС
4
Рабочее проектирование
Рабочее проектирование – детальное
проектирование, включающее:
разработку программ ИС,
 выбор, адаптацию и /или привязку
приобретаемых программных средств,
 разработку спецификаций каждого компонента,
 разработку интерфейсов между компонентами,
 разработку требований к тестам и плана
интеграции компонентов.

5
Документация этапа рабочего
проектирования

Рабочий проект – комплекс документации,
содержащий все необходимые и достаточные
сведения для обеспечения выполнения работ по
вводу ИС в действие и её эксплуатации, а также для
поддержания уровня эксплуатационных
характеристик (качества) системы в соответствии с
принятыми проектными решениями.

Источником разработки рабочего проекта служит
технический проект.
Рабочий проект оформляется в соответствии с ГОСТ 34.20190 «Виды, комплектность и обозначение документов при
создании автоматизированных систем».
В комплекс рабочего проекта входит также программная
документация в соответствии с ГОСТ 19.701-90.


6
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. Ведомость эксплуатационных
7
документов
Связь между этапами
проектирования
Эскизное
проектирование
Информационная
модель
Бизнесаналитики,
системные
аналитики
Функциональная
модель
Техническое
проектирование
Модель данных
Схема БД
Системные
аналитики,
проектировщики
Функциональные
спецификации
Технические
спецификации
Рабочее
проектирование
База данных
Проектировщики,
программисты,
тестировщики
Программный
код
8
Разработка спецификаций
модулей ИС



разработка спецификаций, которые выражают
функциональные возможности каждого модуля в
физических категориях;
определение средств разработки для каждого
модуля (или выделенных групп модулей), если
используются несколько средств разработки в
одном проекте;
определение последовательности реализации
модулей и зависимостей модулей.
9
Предназначение спецификаций
Спецификации
Функциональная
Разрабатывается для
заказчика с целью получения
санкции на завершение
проектирования и начало
реализации.
Техническая
Создается для разработчиков модулей
и групп тестирования, содержит
описание деталей проекта, а также
ряд отчетов из репозитария CASEсредств. Основанием для разработки
служит постановка задачи.
10
Содержание технической спецификации











описание назначения формы или функции модуля;
данные навигации;
формат вызова формы (модуля);
список входных параметров и параметров по умолчанию;
список выходных параметров и правила их обработки;
описание обработки (события внутри модуля и их обработка);
список ошибок, которые генерируются в процессе обработки
и реакция на них;
ограничения доступа к форме (модулю);
вероятные блокировки (потенциальные конфликты и
обработка ожидания);
ожидаемое состояние базы данных после выполнения модуля;
способ проверки целостности данных.
11
Отсутствие спецификаций
Ошибки
Последствия
Неконтролируемый рост
объемов данных
Резкое снижение
производительности системы
Возникновение потоков
запросов с изначально высокой
вероятностью конфликта
Смешивание системных и
интерфейсных модулей,
ошибки в размещении бизнеслогики
Дублирование модулей
Зацикливание
Отсутствие или неполная
реализация требуемых
заказчиком функций системы
Увеличение сроков разработки
и конфликты с заказчиком
Создание «монолитной»,
тяжело сопровождаемой
системы
Неоправданный рост затрат
12
Разработка метрик генерации кода


Метрика генерации кода – это таблица плановой
трудоемкости по кодированию и отладке ПО.
Оценку времени разработки производят:



на основе аналитической документации (на этапе
эскизного проектирования или при разработке ТЗ);
после выполнения большей части проектирования схемы
данных и модулей (на этапе технического
проектирования).
В метрике учитываются:



трудоемкость проектирования модуля,
трудоемкость генерации кода модуля,
трудоемкость тестирования модуля.
13
Факторы оценки трудоемкости






стабильность модели данных и степень ее
изменения в течение разработки;
стабильность модели функций и степень ее
изменения в течение разработки;
уровень квалификации персонала;
среда разработки (инструменты и методы);
размер конечного продукта;
качество ИС (производительность,
надежность, адаптируемость).
14
Обмен данными

Интерфейсы обмена с внешними системами можно
разбить на следующие категории:




одноразовый импорт данных, унаследованных из старой
системы;
периодический обмен данными между компонентами
информационной системы (внутренний обмен);
периодический обмен данных с другими
информационными системами (внешний обмен).
Если обмен данными должен осуществляться в
режиме, близком к реальному времени, то это будет
задача о распределенной базе данных, а не о
простой передаче данных.
15
Алгоритм загрузки/выгрузки данных
определение перечня подсистем, которым нужен интерфейс
выгрузки/загрузки данных;
2) определение периодичности обмена данными и объема
передаваемых данных;
3) определение возможных методов транспортировки данных;
4) согласование форматов данных для обмена;
5) определение порядка выполнения операций при загрузке/выгрузке;
6) определение мероприятий в случае сбоев во время загрузки и
выгрузки данных;
7) формулировка правил определения ошибочных записей (при
загрузке);
8) определение правил регистрации операций передачи и приема
данных;
9) определение графика передачи данных;
10) составление графика разработки и тестирования собственных
утилит обмена данными;
11) составление графика разовой загрузки данных, наследуемых из
старой системы, и подготовка методики проверки корректности
этой операции.
1)
16
Тестирование
Объект
Наименование
тестирования теста
Цель проведения теста
Отдельный
модуль
Автономный
тест
1) обнаружение отказов модуля;
2) соответствие модуля спецификации.
Группа
модулей
Тесты связей
Определение взаимного влияния модулей
Тесты имитации Определение степени восстановления
отказов системы системы после сбоев
Подсистема
(система)
Тесты
наработки на
отказ
Определение степени устойчивости
системы в условиях штатной работы,
оценка времени безотказной работы
Тесты пиковой
нагрузки
Определение степени устойчивости
системы в условиях перегрузки.
Системный тест Внутренняя приемка продукта,
показывающая уровень его качества
17
Функции системы хранения ошибок






хранение сообщения об ошибке;
уведомление о появлении новых ошибок, об
изменении статуса известных в системе ошибок;
формирование отчетов об актуальных ошибках по
компонентам системы, по интервалам времени, по
разработчикам;
хранение информации об истории ошибки;
организация доступа разработчиков к ошибкам
разных категорий;
организация доступа конечного пользователя ИС
как интерфейс обмена информацией между
пользователем и службой технической
поддержки.
18
Методы оценки трудоемкости
разработки ПО
1. Алгоритмическое моделирование

Основан на анализе статистических данных о
ранее выполненных проектах, затраты
прогнозируются в зависимости от
количественного показателя
2. Экспертные оценки

Основан на опросе экспертов по технологии
разработки ПО в заданной предметной области
3. Оценка по аналогии

Основан на сравнении проекта с предыдущими,
имеющими подобные характеристики
19
Методы оценки трудоемкости
разработки ПО
4. Закон Паркинсона


Усилия, затраченные на работу, распределяются
равномерно по выделенному на проект времени.
Критерием для оценки затрат являются
человеческие ресурсы, а не целевая оценка
самого программного продукта.
5. Оценка с целью выиграть контракт

Трудоемкость проекта зависит от бюджета
заказчика, а не от функциональных
характеристик создаваемой ИС.
20
Хорошая оценка трудоемкости




создается и поддерживается коллективом
разработчиков;
основывается на подробно описанной и
обоснованной модели оценки;
основывается на данных по аналогичным
проектам;
учитывает все области риска.
21
Факторы оценки трудоемкости





Размер конечного продукта (количество строк
кода или число функциональных точек);
Особенности технологии разработки ПО;
Квалификация персонала;
Особенности среды разработки
(инструментальных средств);
Требуемое качество продукта
(функциональные возможности,
производительность, надежность).
22
Определение размера продукта
1. Количество строк кода (тыс.)
2. Количество функциональных точек


Анализ функциональных точек —
стандартный метод измерения размера
программного продукта с точки зрения
пользователей системы (Алан Альбрехт,1979)
1986 г. – сформирована Международная
Ассоциация Пользователей Функциональных
Точек (International Function Point User Group
— IFPUG)
23
Внутренние логические файлы (ILFs) — выделяемые
пользователем логически связанные группы данных или блоки
управляющей информации, которые поддерживаются внутри
продукта.
Внешние интерфейсные файлы (EIFs) — выделяемые
пользователем логически связанные группы данных или блоки
управляющей информации, на которые ссылается продукт, но
которые поддерживаются вне продукта.
24
Виды функциональных точек
1. FP, связанные с данными


DET (data element type) — неповторяемое
уникальное поле данных, например, Имя
Клиента — 1 DET; Адрес Клиента (индекс,
страна, область, район, город, улица, дом,
корпус, квартира) — 9 DET's
RET (record element type) — логическая
группа данных, например, адрес, паспорт,
телефонный номер.
25
Виды функциональных точек
2. FP, связанные с транзакциями.

EI (external inputs) — внешние входные
транзакции, элементарная операция по обработке
данных или управляющей информации,
поступающих в систему из вне.

EO (external outputs) — внешние выходные
транзакции, элементарная операция по генерации
данных или управляющей информации, которые
выходят за пределы системы. Предполагает
определенную логику обработки или вычислений
информации из одного или более ILF.

EQ (external inquiries) — внешние запросы,
элементарная операция, которая в ответ на
внешний запрос извлекает данные или
управляющую информацию из ILF или EIF.
26
Размер ПО в FP









Текстовые процессоры – 3500
Клиент-серверные приложения – 7500
ПО баз данных – 7500
Бизнес-приложения – 10000
Корпоративные приложения – 25000
Приложения в госучреждениях – 50000
Операционные системы – 75000
Системы масштаба предприятия – 150000
Крупные оборонные системы – 250000
27
Число
FP
Длительность Количество
Пример
разработчиков приложений
1
1 день
10
До 1 месяца 1
Дополнения к
готовой системе
100
До 6
месяцев
(85%)
До 1 года
1
Небольшое
приложение
10
Клиент-серверные
приложения
100
Крупные
приложения
До 1000
Операционные
системы
1000
От 1,5 до 5
лет
100000 От 3 до 8
лет
10000
1
Утилиты
28