СОВРЕМЕННЫЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПО Лекция 3 1 Сбор

СОВРЕМЕННЫЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПО Лекция 3. 1: Сбор и анализ требований. Функциональные спецификации.

Техническое задание

Техническое задание • ТЗ – базовый документ • • • общее назначение продукта технические характеристики требования показатели качества процесс выполнения проекта и приёмки • Главная цель • максимально полно отразить требования • сформулировать задачу • обосновать потребность в её решении 3

Стандарты • ГОСТ 19. 201 -78 Техническое задание. Требования к содержанию и оформлению. • ГОСТ 34. 602 -89 Техническое задание на создание автоматизированной системы. 4

Основные разделы ТЗ • Общие сведения о системе (программе) • Назначение, цели и задачи системы (программы) • Требования к системе • функциональные требования • пользовательские требования • требования к системе в целом и тд. • • Требования к видам обеспечения Требования к документированию Стадии и этапы разработки Порядок контроля и приемки системы (программы) 5

Общие сведения • Полное и сокращённое наименование системы • Реквизиты сторон • Ссылки на документы, на основании которых ведётся разработка (в т. ч. , правовая основа) • Сроки и финансирование • Словарь терминов и сокращений 6

Назначение, цели и задачи системы Мотивация создания системы: • какую потребность закрываем • какие подзадачи возникают • возможности, предоставляемые пользователям - сервисы оптимизация бизнес-процессов безопасность централизация обработки и хранения данных 7

Требования к системе • Основные функциональные требования • Декомпозиция задач: • действующие лица • сценарии использования • результаты • В составе этого раздела или в приложении – примеры пользовательского интерфейса 8

Требования к системе • требования к функциональным характеристикам • требования к надежности • условия эксплуатации • требования к составу и параметрам технических средств • требования к информационной и программной совместимости • требования к маркировке и упаковке • требования к транспортированию и хранению • специальные требования 9

Требования к видам обеспечения Требования к: • математическому • информационному • лингвистическому • программному • техническому • и другим видам обеспечения 10

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

Стадии и этапы разработки • Перечисляются этапы работ • сроки • описание • результаты этапа 12

Порядок контроля и приёмки • Указывается документ, на основании которого проводятся приёмо-сдаточные испытания. 13

Общее содержание ТЗ • ТЗ может по необходимости дополняться другими разделами: • внедрение • наполнение контентом (в случае сайта) • и прочие работы, не подпадающие под основные разделы • а также может быть сокращено. 14

Функциональные спецификации

Зачем? • Итак, ТЗ – это: • декларируемый набор функций - описывает, что система должна делать • если нужно – юридический документ • требования ТЗ – для планирования работы • Функциональная спецификация – это: • надо больше программистам • хотя и не только • описывает, как система работает - сценарии работы пользователей с системой - модули и их взаимодействие • помогает понимать систему: - а значит, разрабатывать её и поддерживать 16

Зачем описывать поведение? • При создании продукта • лучше представлять замысел - прежде чем строить здание, хорошо бы продумать, где будут окна-двери, и понадобится ли второй лифт; - ведь чем позже вносятся изменения – тем они дороже, - если вообще возможны. • стремление к одинаковому видению проекта у команды • С прицелом на поддержку/развитие • Проще смотреть картинки и читать линейный текст, чем изучать код 17

Содержимое ФС • Множество стандартов и нестандартов • (в чём несколько отличается от ТЗ) • крупные методологии предписывают определённую структуру ФС • но структура вовсе не обязательно строгая • Выбор (очень) зависит от контекста • главная цель – описать систему 18

Общая схема • Примерное содержимое ФС: • Варианты использования - ключевые сценарии • Описание процессов и процедур - детализация сценариев, компоненты • Сложное поведение компонент • Внутренняя структура - детализация структуры компонент - отношения между компонентами - схемы БД и размещения компонент 19

Вариации • Детали внутреннего устройства могут выноситься в отдельный документ • Детальная архитектура • Также ФС может содержать: • Чёткое разграничение целей и «антицелей» проекта • Списки открытых вопросов • Специальные примечания - маркетинговый контекст, комментарии экспертов в предметной области • И другое, полезное в конкретной ситуации 20

Варианты использования • Первый шаг – отразить пользовательские сценарии • выделить и перечислить ключевые взаимодействия с системой, дающие значимый результат • для описания подойдут - чтобы проникнуться: пользовательские истории, диаграммы связей (mind maps) - чтобы быстро понять круг задач: диаграммы прецедентов (вариантов использования) UML 21

Пользовательские истории • User stories – рассказы о том, как пользователи работают с программой • Лучше писать живо и с юмором, чем сухо © Dilbert. com 22

Mind maps 23

Mind maps 24

Диаграммы прецедентов 25

Описание процессов и процедур • Расписываются сценарии: • какие элементы взаимодействуют • что друг у друга запрашивают • Инструменты: • псевдокод • диаграммы UML: робастности, сотрудничества, последовательности действий, деятельности • диаграммы Data Flow 26

Диаграмма робастности Actors – действующие лица Boundary objects – элементы интерфейса Control elements – управляющие процессы Entity objects – элементы модели предметной области Use cases (опционально) – варианты использования © http: //iconixprocess. com/iconix-process/analysis-and-preliminary-design/robustness-analysis/ 27

Диаграмма робастности 28 © http: //iconixprocess. com/iconix-process/analysis-and-preliminary-design/robustness-analysis/

Диаграмма сотрудничества 29

Диаграмма последовательности действий 30

Диаграмма деятельности 31

Диаграмма потоков данных (Data Flow) 32

Сложное поведение компонент • Сложные алгоритмы и процедуры • диаграммы деятельности, блок-схемы и псевдокод • Автоматы: смена состояний • диаграммы состояний (UML) 33

Диаграмма состояний 34

Внутренняя структура • Детальное описание элементов системы: • • классы (ООП) – диаграмма классов диаграммы отношений таблицы баз данных схемы размещения компонент: диаграмма развертывания (UML) 35

Диаграмма классов 36

Отношения на диаграмме классов 37

Таблицы баз данных 38

Диаграмма развёртывания 39

Итоги • Инструментов для создания спецификаций много • лекция покрыла только несколько • Критерии выбора инструментов: • стандартные (предписаны процессом) • удобные (хорошо описывают) • «компактные» (небольшое подмножество) 40

Ссылки • ГОСТ 19. 201 -78, Техническое задание. Требования к содержанию и оформлению • ГОСТ 34. 602 -89 Техническое задание на создание автоматизированной системы • Сравнение обоих ГОСТов: общее содержание ТЗ • Неплохие материалы с разбором процесса написания ТЗ на сайт: • http: //habrahabr. ru/post/140574/ и • http: //habrahabr. ru/post/138749/ 41

Ссылки • Инструменты для UML • Visual Paradigm (community edition – некоммерческая) http: //www. visualparadigm. com/download/vpuml. jsp? edition=ce • Star. UML http: //staruml. sourceforge. net/en/ • Argo. UML http: //argouml. tigris. org/ • Подробный курс по UML на INTUIT: • http: //www. intuit. ru/studies/courses/32/32/info • Дополнение по Robustness Diagram (англ. ): • http: //www. agilemodeling. com/artifacts/robustness. Dia gram. htm • Mind Maps: • XMind http: //www. xmind. net/ 42