СОВРЕМЕННЫЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПО Лекция 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 • StarUML http://staruml.sourceforge.net/en/ • ArgoUML http://argouml.tigris.org/ • Подробный курс по UML на INTUIT: • http://www.intuit.ru/studies/courses/32/32/info • Дополнение по Robustness Diagram (англ.): • http://www.agilemodeling.com/artifacts/robustnessDia gram.htm • Mind Maps: • XMind http://www.xmind.net/ 42