Тема 4 Требования при разработке ПС
реклама
Формирование требований при разработке ПО Содержание Проблемы современных проектов разработки ПО Немного о системном подходе Какие бывают требования Управление требованиями Выявление проблемы Формирование требований Работа с требованиями Литература Вопросы 1. В чем основные проблемы программных проектов? Версии зала... Проблемы современных проектов ПО Увеличение сроков Аннулирование Превышение бюджета Оценка стоимости ошибок Вопросы 1. Вспомним причины неудач программных проектов. Версии зала... Причины неудач Нечеткая и неполная формулировка требований к ПО Недостаточное вовлечение пользователей в работу над проектом Отсутствие необходимых ресурсов Неудовлетворительное планирование и отсутствие грамотного управления проектом Причины неудач Частое изменение требований и спецификаций Новизна и несовершенство используемой технологии Недостаточная поддержка со стороны высшего руководства Недостаточно высокая квалификация разработчиков, отсутствие необходимого опыта Ошибки требований и стоимость переделок Ошибки в требованиях – самые дорогостоящие ошибки Ошибки в требованиях – самые распространенные ошибки Переделка продукта занимает 40-50% бюджета проекта Ошибки в требованиях отнимают наибольшую часть стоимости переделки продукта (>70%) Ошибки в требованиях отнимают 3040% общей стоимости бюджета проекта Вопросы 1. Какова основная фундаментальная идея программной инженерии? Версии зала... Разработка ПО Фундаментальная идея программной инженерии – проектирование ПО является формальным процессом, который можно изучать и совершенствовать. Разработка ПО Методологическую основу разработки ПО составляет системный подход Система – это совокупность взаимодействующих компонентов и взаимосвязей между ними Системный подход это методология исследования объекта любой природы как системы, которая ориентирована на • раскрытие целостности объекта и обеспечивающих его механизмов; • выявление многообразных типов связей объекта; • сведение этих связей в единую картину. Системный подход реализует представление сложного объекта в виде иерархической системы взаимосвязанных моделей, позволяющих фиксировать целостные свойства объекта, его структуру и динамику. Системный подход Программное обеспечение (ПО), как система, в свою очередь является подсистемой некоторой информационной системы Разработка ПО Проект ПО – это совокупность спецификаций (включающих модели и предпроектную документацию), обеспечивающих создание ПО в конкретной программно-технической среде Разработка ПО Технологический цикл разработки ПС включает три процесса Анализ Синтез Сопровождение Информационные потоки разработки ПС Этап выработки требований Модель анализа •Информационная •Функциональная •Поведенческая Этап проектирования Процедурная Разработка разработка архитектуры Разработка данных Этап кодирования Программные модули Этап тестирования Проверенное ПС Вначале было слово... Требование - свойство программного обеспечения, необходимое пользователю для решения некоторой проблемы при достижении поставленной цели Требования к ПО Требование – это условие, которому должна удовлетворять система, или свойство, которым она должна обладать, чтобы удовлетворить потребность пользователя в решении некоторой задачи и удовлетворить требования контракта, стандарта или спецификации. Требования – это жизнь проекта... Требования – это четкие формулировки цели Правильно сформулированные требования помогут вам сосредоточить ваши усилия на самых важных задачах Требования, как навигационные карты, определяют направление движения и необходимые остановки для проверки Требования дают вам средства и механизм управления, помогающие достичь выбранной цели Требования к ПО Функциональные – определяют действия, которые должна выполнять система, без учета ограничений, связанных с ее использованием •Функции (feature) – предоставляемая системой услуга для удовлетворения одной или нескольких потребностей заинтересованных лиц. Типы нефункциональных требований Нефункциональные – описывают атрибуты системы или атрибуты системного окружения к к к к к к применению; производительности; реализации; надежности; интерфейсу; эксплуатации. Нефункциональные требования Требования к применению – качество пользовательского интерфейса, документации и учебных курсов; Требования к производительности – ограничения на функциональные требования (эффективность использования ресурсов, пропускная способность и время реакции); Требования к реализации – стандарты, языки программирования, операционная среда и др.; Требования к надежности – допустимая частота воздействие сбоев, возможности восстановления; Требования к интерфейсу – внешние сущности, с которыми может взаимодействовать система, и регламент этого взаимодействия. Эксплуатационные требования правильность; универсальность; надежность; проверяемость; точность результата; защищенность; программная совместимость; аппаратная совместимость эффективность; адаптируемость; повторная входимость; рентабельность. Требование – ответ на вопрос «Что», а не «Как» Требование не должно быть проектным решением. Способ реализации требования будет определен при проектировании системы; Если требование является проектным решением, то оно должно быть отмечено как ограничение; К требованиям не относятся способы управления проектом, планы, тестовые процедуры и т.д. Роль требований Основа взаимодействия всех заинтересованных лиц; Формальное соглашение сторон (контракт); База для ссылок менеджеров; Исходные данные для проектирования; Исходные данные для тестирования и обеспечения качества; Контроль процесса развития системы. Роль требований Требования - свойство программного обеспечения, которым должна обладать система или ее компонент, чтобы удовлетворить требование контракта или спецификации. Спецификация требований к ПО является основным документом, который играет определяющую роль по отношению к другим элементам плана разработки Требования возникают отовсюду... Требования заказчика Функциональные требования A B C Требования рынка D E F Дальнейшее сопровождение G H I C D A H I G B E F Системные требования D1 D2 A1 H1 H2 G1 C1 I1 I2 B1 E1 F1 F2 Архитектурный дизайн Software D1 A1 H2 C1 B1 Hardware D2 G1 I1 E1 F2 Manuals H1 I2 F1 Проблемы при работе с требованиями требования не очевидны, приходят из разных источников, их трудно сформулировать словами из-за внутренней неоднозначности языка; требования разнообразны по типам и деятельности, могут достигать огромного количества, которое трудно контролировать требования связаны между собой и другими проектными данными, изменяются в ЖЦ ПО Эффект домино… Неправильная работа с требованиями приводит к эффекту домино, который может сказаться на любом из этапов жизненного цикла Пропуск (неучет) требования пользователя ведет к пропуску системного требования, которое – в свою очередь - приводит к отсутствию элемента дизайна, отсутствию функциональности и, фактически, к провалу проекта • Около 60%-70% общего числа всех IT-проектов заканчиваются плачевным результатом только из-за неудовлетворительной комплектации требований, их анализа, управления и контроля Управление требованиями Это систематический подход к выявлению, организации и документированию требований к системе, а также процесс, в ходе которого вырабатывается и обеспечивается соглашение между заказчиком и выполняющей проект группой по поводу меняющихся требований к системе. Управление требованиями Позволяет получить ответ на вопросы: Кто из участников проекта отвечает за требование Х и кому из них разрешено вносить в него изменения или вообще удалить его? Если в требование Х вносятся изменения, на какие другие требования это повлияет? Как удовлетвориться в том, что для выполнения требований Х уже написан код, и какие тесты предназначены для проверки того, что данное требование действительно выполнено? Качество и требования Качество: полное соответствие результата первоначальным требованиям Цель управления требованиями: поставка качественного продукта в соответствии с графиком, отвечающего исходной спецификации, с уверенностью, что все первичные требования учтены и реализованы Почему управление проектами и управление требованиями тесно взаимосвязаны? И там, и там цели едины: Обеспечение оценки и контроля содержания проекта Обеспечение предсказуемости проекта Обеспечение успешного получения промежуточного и конечного продукта Они зависят друг от друга: Нужны ресурсы для разработки требований Нужны ресурсы для удовлетворения требований Изменение требований приводит к изменению графика и загрузки ресурсов Изменение графика и загрузки ресурсов приводит к изменению требований Анализ проблемы Проблема – это разница между желаемым и воспринимаемым (Gause, Weinberg. Exploring Requirements: Quality Before Design, 1989) Цель анализа- добиться лучшего понимания проблемы до начала разработки При выработке требований при анализе проблемы необходимо Достигнуть соглашение об определении проблемы. Выделить основные причины – вопросы, стоящие за проблемой. Выявить заинтересованных лиц и пользователей Определить границу системы решения. Выявить ограничения, которые необходимо наложить на решение. Этап1. Достижение соглашения об определении проблемы Элемент Описание Проблема Описание проблемы Воздействие на что(кого) и результат чего является Указание лиц, на которых оказывает влияние данная проблема. Описание воздействия данной проблемы на заинтересованных лиц и бизнес-деятельность Выигрыш от решения может состояться в следующем Указание предлагаемого решения. Список основных предоставляемых решением преимуществ. Этап 2.Выявление основных причин – вопросов, стоящих за проблемой Проблема- простой ИС Этап 3.Выявление заинтересованных лиц и пользователей Кто является пользователем системы? Кто является заказчиком системы? На кого еще окажут влияние результаты работы системы? Кто будет оценивать и принимать систему? Существуют ли другие пользователи системы чьи потребности стоит учесть? Кто будет сопровождать новую систему? Не забыли ли мы кого-нибудь? Этап 4. Определение границы системы Кто будет управлять системой? Кто будет осуществлять сопровождение системы? Откуда система получает информацию? Какие внешние системы будут взаимодействовать с системой? Этап 5. Выявление ограничений, налагаемых на решение Экономические Финансы, бюджет, себестоимость, ценообразование, лицензирование Политические Политические вопросы, взаимоотношения между подразделениями Технические Технологии, платформа, ПО Системные Существующие системы, совместимость, поддержка ОС и сред. Эксплуатационные Информационные, правовые, юридические, безопасность, стандарты Графики и ресурсы Ресурсы, штат, привлечение работников. Этапы работы с требованиями Определение типов требований и групп участников проекта, работающих с ними; Первичный сбор требований, их классификация и занесение в базу данных требований; Использование базы данных требований для управления проектом. Атрибуты требований Приоритет (высокий, средний, низкий); Статус (предложено, одобрено, утверждено, реализовано, верифицировано); Стоимость (высокая, средняя, низкая или числовое значение); Сложность реализации (высокая, средняя, низкая); Стабильность (высокая, средняя, низкая); Исполнитель Методы выявления требований Интервьюирование и анкетирование; Совещания; Мозговой штурм и отбор идей; Раскадровки; Прецеденты; Обыгрывание ролей; Создание прототипов. Собеседование Преимущества • • Опрашиваемое лицо может свободно и отрыто отвечать на вопросы и почувствовать себя участником проекта Лицо, проводящее собеседование, может наблюдать за поведением опрашиваемого лица, изменять ход опроса, переформулировать или иначе построить вопросы во время собеседования Недостатки • • Метод трудоемкий и дорогой, поэтому может оказаться не практичным Успех собеседования зависит от навыков общения лица, проводящего собеседование, и от желания опрашиваемых лиц участвовать в интервью Некоторые правила проведения интервью Малая длительность (от 1 до 2 часов) Не перед обедом и не поздно вечером (перед концом рабочего дня) Четко представлять цель интервью Объяснить свою роль сотруднику подразделения перед началом интервью Включать в интервью ограниченное количество вопросов Все вопросы должны быть подготовлены и продуманны заранее Перед проведением интервью желательно познакомиться с документацией и рассматриваемым вопросам Что нужно сказать сотруднику подразделения в начале интервью Почему проводится это интервью От кого получено разрешение его проводить Кто еще будет проинтервьюирован По какому принципу и кто выбирал интервьюируемых Как будет использована полученная информация Будет ли интервью анонимным Будет ли интервью отражено в отчете Какова будет обратная связь по итогам обработки результатов интервью Почему важно получить детальную и точную информацию в процессе интервью Некоторые правила проведения интервью Hе отвлекаться на посторонние комментарии по проблемам, связанным с обсуждаемым предметом Не пытаться завязать дружеские отношения Не указывать интервьюируемому на его затруднения при описании предметной области Давать интервьюируемому время подумать Отделить «мнения O..> от фактов Не иронизировать Концентрироваться на наиболее сложных аспекта предметной области Не пытаться показывать свои звания (эксперт не вы, а интервьюируемый) Не увеличивать длительность проведения интервью Обработка полученной информации Перенос полученной информации в электронную форму (некоторые руководители требуют полностью документировать результаты интервью) Проверка информации на корректность: Событие, завершающее выполнение функции, в одном отделе, должно быть инициирующим в другом отделе Названия функций должны совпадать с официальными названиями, утвержденными в Положении об отделах Не должно быть разночтений в названиях функций. Анкетирование Преимущества: Люди могут заполнять и возвращать анкеты в удобное для них время Люди склонны сообщать в ответах действительные факты, если анкетирование анонимное Анкетирование – относительно недорогой способ сбора данных с участием большого числа людей Недостатки: Не все могут согласиться ответить на вопросы, анкеты могут возвращаться незаполненными Нет возможности пояснить или переформулировать не правильно понятые вопросы, наблюдать и анализировать реакцию респондента на отдельные вопросы Предложения, стоящие за вопросами, оказывают влияние на ответы Совещания Достоинства: Все заинтересованные лица могут высказывать свое мнение Формируется соглашение между заинтересованными лицами и разработчиками Разрешаются политические вопросы, влияющие на успех проекта Результат становится известным немедленно Недостатки: Необходимость управления временем Доминирующие позиции отдельных участков Недостатки предложений от участников Негативные комментарии, мелочное поведение и скрытая враждебность Мозговой штурм и отбор идей Достоинства: Поддерживает участие всех присутствующих Позволяет участникам развивать идеи друг друга Как правило, в результате получается множество возможных решений Способствует свободному мышлению, не ограниченному обычными рамками Проблемы: те же, что и для Типы раскадровок Пассивные: Экранные копни Выходные документы (отчеты) Активные Демонстрация слайдов Анимация Имитация Интерактивные «Живая» демонстрационная версия Интерактивная презентация Управление требованиями Требования к проекту ПО могут быть представлены в виде модели. Под моделью ПО понимают формализованное описание системы ПО на определенном уровне абстракции. Управление требованиями Требования могут быть смоделированы с помощью различного вида диаграмм Работа с требованиями Этапы работы с требованиями Определение типов требований и групп участников проекта, работающих с ними Первичный сбор требований, их классификация и занесение в базу данных требований Использование базы данных требований Возможные типы требований Требовании пользователей (UR-User Requirements Требования к функциям (FR- Feature Requirements) Требования к программному обеспечению (SR- Software Requirements) Тестовые требования (TR - Test Requirements) Требовании на внесение изменении (CRChange Requirements) Требования на исправление ошибок (ER Error Requirements) Уровни требований Атрибуты требований Приоритет (высокий, средний, низкий) Статус (предложено, одобрено, реализовано, верифицировано) Стоимость реализации (высокая, средняя, низкая — или числовое значение) Сложность реализации (высокая, средняя, низкая) Стабильность (высокая, средняя, низкая) Показатели качества требований Корректность – набор требований является корректным тогда и только тогда, когда каждое его требование представляет собой нечто, реально требуемое от создаваемой системы Недвусмысленность – однозначность интерпретации Полнота – учет всех важных требований, интересующих пользователя Непротиворечивость Упорядоченность по важности и стабильности Проверяемость – верифицируемость и тестируемость Модифицируемость Трассируемость Понятность Организация процесса управления требованиями Обучение Организация инфраструктуры Персонал Инструментальные средства Средства взаимодействия (интранет/интернет, электронная почта) Определение источников возникновения и механизмов выявления требований Определение процедуры обсуждения требований и правил принятия решений по ним Определение механизмов регистрации и обработки изменений требований и принятия решений по ним Управление изменениями: Обязательность стандартного процесса Все запросы на изменения должны проходить через установленный процесс утверждения Управление изменениями: Трассировка зависимости требований Трассировка требований Трассировка требований (tracing) это установка связей требований с другими требованиями и проектными данными Цель трассировки требований: Убедиться, что все требования к системе выполнены в процессе реализации Убедиться, что приложение делает только то, что предполагалось Облегчить управление изменениями Трассировка требований Отражает связь между двумя требованиями Между двумя любыми требованиями может существовать только одна связь трассировки Связь должна устанавливаться в одном направлении и может Управление требованиями Вести обсуждения между участниками проекта (модуль “Discussions”). Работать с требованиями непосредственно в базе данных проекта (RequisitePro Views). Работать с документами и требованиями в этих документах с помощью Microsoft Word, который автоматически запускается из-под RequisitePro при открытии любого документа проекта Просмотр трассировки требований Traceability Matrix - Матрица трассировки. Показывает связь двух заданных типов требований Traceability Tree (Traced out of...)- Дерево трассировки (трассировка от). Древовидное представление зависимости требований всех типов требований одного заданного типа Traceability Tree (Traced in to ...)-Дерево трассировки (трассировка к). Древовидное представление зависимости требований одного заданного типа от всех типов требований Матрица трассировки (RequisitePro) Матрица трассировки (RequsitePro) «Подозрительные» связи (Suspect links) После изменения текста требования все его связи с другими требованиями (в обоих направлениях) помечаются как «подозрительные» Следует рассмотреть все такие связи, внести необходимые изменения в другие требования (что может привести к появлению новых «подозрительных» связей), затем снять статус «подозрительности» «Подозрительные» связи устава вливаются автоматически, могут устанавливаться пользователем вручную и должны удаляться вручную Матрица трассировки (RequsitePro) Информационные потоки синтеза ПС Этап выработки требований Модель анализа •Информационная •Функциональная •Поведенческая Этап проектирования Процедурная Разработка разработка архитектуры Разработка данных Этап кодирования Программные модули Этап тестирования Проверенное ПС Модель анализа Информационная модель описывает информацию, которую должна обрабатывать система Функциональная модель определяет перечень функций обработки Поведенческая модель фиксирует желаемую динамику системы (режимы ее работы) Модель анализа Техническое задание Системные требования Соответствие Стандарты Соответствие Системные тесты Тесты Тесты Тесты Приемочные тесты Проект Общие и блочные тесты 78 Почему так получается? Литература к лекции 1) Вендров А.М. Пректирование программного обеспечения экономических информационных систем – М: Финансы и статистика, 2005 2) Гусятников В.Н., Безруков А.И. Стандартизация и разработка программных систем. - М: Финансы и статистика, 2010. 3) И. Соммервиль. Инженерия программного обеспечения, 6 изд. – И.д. "Вильямс", 2002.
