Семя – орган полового размножения и расселения растений: наружи у семян имеется плотный покров – кожура...
Археология об основании Рима: Новые раскопки проясняют и такой острый дискуссионный вопрос, как дата самого возникновения Рима...
Топ:
Определение места расположения распределительного центра: Фирма реализует продукцию на рынках сбыта и имеет постоянных поставщиков в разных регионах. Увеличение объема продаж...
Выпускная квалификационная работа: Основная часть ВКР, как правило, состоит из двух-трех глав, каждая из которых, в свою очередь...
Характеристика АТП и сварочно-жестяницкого участка: Транспорт в настоящее время является одной из важнейших отраслей народного...
Интересное:
Принципы управления денежными потоками: одним из методов контроля за состоянием денежной наличности является...
Финансовый рынок и его значение в управлении денежными потоками на современном этапе: любому предприятию для расширения производства и увеличения прибыли нужны...
Берегоукрепление оползневых склонов: На прибрежных склонах основной причиной развития оползневых процессов является подмыв водами рек естественных склонов...
Дисциплины:
2017-11-22 | 296 |
5.00
из
|
Заказать работу |
|
|
Стилевая гибкость – возможность использовать различные интерфейсы с одним и тем же приложением, на практике реализуется в виде набора “skins”, для web-интерфейсов – с помощью таблицы стилей, в том числе возможность в выборе пользователем собственных установок ПИ (цвет, иконы, подсказки и пр.).
Совместное наращивание функциональности – возможность развивать приложение без разрушения (т.е. оставаясь в рамках) существующего интерфейса.
Масштабируемость – возможность легко настраивать и расширять как интерфейс, так и само приложение при увеличении числа пользователей, рабочих мест, объема и характеристик данных.
Адаптивность к действиям пользователя – приложение должно допускать возможность ввода данных и команд множеством разных способов (клавиатура, мышь, другие устройства) и многовариативность доступа к прикладным функциям (иконы, «горячие клавиши», меню …), кроме того программа должна учитывать возможность перехода и возврат от окна к окну, от режима к режиму, и правильно обрабатывать такие ситуации.
Независимость в ресурсах – для создания пользовательского интерфейса должны предоставляться отдельные ресурсы, направленные на хранение и обработку данных, необходимых для поддержки пользователя (пользовательские словари, контекстно-зависимые списки, наборы данных по умолчанию или по последнему запросу, истории запросов и пр.)
Переносимость – при переходе на другую аппаратную (программную) платформу, должен осуществляется автоматически перенос и пользовательского интерфейса, и конечного приложения.
Вопросы
1) Что такое понятие Usability?
2) Какие проблемы возникают при разработки ПО?
3) С чем связана удовлетворенность пользователя от работы?
|
4) Какие существуют принципы реализации пользовательского интерфейса?
5) Что отражает функциональная полнота?
Дополнительная информация
1)http://www.usability.ru/Articles/software-ergonomics.htm
2)http://www.cntd.ru/assets/files/upload/250713/55241.1-2012.pdf
3) http://psychlib.ru/mgppu/MZE-2001/MEC-001.HTM
Лекция №8. Управление требованиями к программному продукту. CASE-средство RequisitePro.
План лекции
- Внедрение системы управления требованиями.
- Определение принципов создания хранилищ и политики доступа к ним.
- Фиксация инструментария, рабочей среды, средств разработки и внешних интерфейсов.
- Определение идентификации требований.
- Определение трассировки требований.
- Определение группы, видов, атрибутов требований.
- Определение метрик и отчетов.
- Определение принципов управления требованиями, формирование группы управления изменениями.
- Определение контрольных точек проекта.
- Внедрение разработанной системы УТ на проекте.
- Подсистема управления требованиями на основе IBM RationalRequisitePro.
Введение
В последние годы большинство специалистов, связанных с областью производства программного обеспечения (ПО), наверняка много слышали о средствах организации процесса разработки, поставляемых компанией Rational. В линейке продуктов этой компании важное место занимает RationalRequisitePro, основная цель которого – автоматизация процесса управления требованиями.
Цель данного документа - продемонстрировать общую последовательность действий, которые обычно выполняются при работе с RequisitePro, и рассказать о некоторых его технических особенностях. Здесь не описываются назначение и все возможности продукта. Также не раскрывается смысл многих терминов, что достаточно подробно выполнено в RationalUnifiedProcess (рубрика “Glossary”)
Нормативная основа
В качестве нормативной основы при разработке лекции использован стандарт:
IEEE Std 830-1993 «IEEE Recommended Practice for Software Requirements Specifications».
В таблице 5 приведены основные термины и определения.
|
Таблица 5 – Термины, сокращения и определения
Сокращение, термин | Расшифровка сокращения или термина | Категория на английском языке |
ГОК | Группа обеспечения качества | Quality Assurance Group |
ГТР | Группа технологии разработки | Engineering Process Group |
Заказчик | Организация, в интересах которой разрабатывается программный продукт, имеющая полномочия утверждать требования к программному продукту и принимать результат разработок. В качестве заказчика может выступать сторонняя фирма, департамент компании, руководитель комплексного проекта, группа маркетинга и пр. В контексте настоящего Положения под Заказчиком понимаются ответственные сотрудники, имеющие полномочия согласовывать и утверждать технические и организационные документы проекта от имени Заказчика. | Customer |
Ключевая роль | Роль, которая должна быть заполнена в течение всего жизненного цикла проекта, причем, как правило, одним и тем же специалистом. Если роль в проекте заполнена несколькими специалистами, ключевую роль будет играть специалист, назначенный ведущим за данное направление. | Кеуrole |
Аналитик | Ключевая роль в рабочей группе проекта разработки программного обеспечения, отвечающая за управление требованиями | Analyst |
Менеджерпроекта | Ключевая роль в рабочей группе проекта разработки программного обеспечения, отвечающая за организацию работ и координацию действий участников проекта | ProjectManager |
Нетехническое требование | Требование, относящееся к организации разработки продукта | Non technical Requirement |
Нефункциональное требование | Техническое требование, описывающее условие или ограничение, которому должен удовлетворять программный продукт | Non functional requirement |
ПО | Программное Обеспечение | Software |
Проект | Ограниченная во времени деятельность, направленная на разработку уникального продукта | Project |
Проектировщик | Ключевая роль в рабочей группе проекта разработки программного обеспечения, отвечающая за разработку технического проекта | Designer |
Разработчик | Ключевая роль в рабочей группе проекта разработки программного обеспечения, отвечающая за кодирование и отладку ПО | Developer |
Роль | Множество обязанностей, которое возлагается на сотрудника на время выполнения проекта. Один сотрудник может совмещать несколько ролей в проекте. Одну роль в проекте могут выполнять несколько специалистов. В последнем случае группа специалистов, выполняющая одну роль, должна быть структурирована с выделением ведущего члена рабочей группы, ответственного за организацию работ по данному направлению. | Role |
Тестировщик | Ключевая роль в рабочей группе проекта разработки программного обеспечения, отвечающая за тестирование разрабатываемого программного продукта | Tester |
Технический проект | Документ с описанием технических решений, положенных в основу разработки, архитектуры разрабатываемой программной системы и методики разработки. | Design |
Техническое требование | Требование, относящееся к характеристикам разрабатываемого продукта | Technical Requirement |
ТЗ | ТехническоеЗадание | Requirement Specification |
ТЗПО | Техническое Задание на Программное Обеспечение | Software Requirement Specification |
Требование | Описание способности или ограничения | Requirement |
Функциональное требование | Техническое требование, описывающее способность выполнения программным продуктом определенной функции | Functional Requirement |
Основные положения
|
8.2.1 Цели управления требованиями
Целями управления требованиями являются:
1) Обеспечение контроля над процессами управления требованиями с целью обеспечения разработки программного продукта в точном соответствии с требованиями заказчика;
2) Поддержание соответствия, на протяжении всего жизненного цикла проекта, между действующими требованиями к разрабатываемому программному обеспечению, с одной стороны, с планами, результатами работ и выполняемыми действиями – с другой.
8.2.2 Участники управления требованиями
Для описания процессов управления требованиями выделяются следующие ключевые роли, должности и группы[17]:
1. Менеджер проекта – ключевая роль рабочей группы, несет ответственность за организацию управления требованиями в проекте в соответствии с данным положением.
2. Аналитик – ключевая роль рабочей группы, несет ответственность за выполнение процедур управления требованиями в проекте.
4. Разработчик – ключевая роль рабочей группы, несет ответственность за кодирование и отладку программного продукта в соответствии с утвержденными требованиями.
|
5. Тестировщик – ключевая роль рабочей группы, несет ответственность за тестирование разрабатываемого продукта в соответствии с утвержденными требованиями.
6. Проектировщик - ключевая роль рабочей группы, несет ответственность за разработку технического проекта в соответствии с утвержденными требованиями.
6. ГОК – группа обеспечения качества. Специалисты группы в соответствии с планом работы группы осуществляют необходимые проверки и аудит процессов управления требований.
7. ГТР – группа технологии разработки. Группа несет ответственность за поддержку и совершенствование процессов управления требованиями в проектах разработки программного обеспечения.
8. Заказчик – организация, имеющая полномочия утверждать требования и вести приемку разработанного программного продукта.
8.2.3 Политика в области управления требованиями
В данном разделе приведены принципы, которые положены в основу управления требованиями в компании.
1. Координация работ по управлению требованиями в проекте возлагается на одного члена рабочей группы – Аналитика, на протяжении всего жизненного цикла проекта.
2. Требования к разрабатываемому программному обеспечению должны быть документированы.
3. Документ, содержащий требования к разрабатываемому продукту, должен быть письменно утвержден Заказчиком[1]. После утверждения требований Заказчиком технические риски, связанные с формулировкой требований принимает на себя Заказчик.
4. Требования должны быть утверждены Руководством компании. После утверждения требований технические риски, связанные с удовлетворением сформулированных требований принимает на себя разработчик.
5. Требования должны быть согласованы со всеми ключевыми членами рабочей группы проекта.
6. Перед согласованием и утверждением требования должны пройти формальную проверку на наличие рисков, связанных с требованиями. Отчет о результатах проверки с выводами о наличии и размерах рисков доводится до сведения всех ключевых членов рабочей группы и руководства компании и помещается в составе необходимой внутренней документации в дело проекта.
7. Информация о рисках, связанных с требованиями, в обязательном порядке доводится до сведения заказчика, если планы компенсации рисков требуют привлечения ресурсов, выходящих за рамки утвержденных для проекта лимитов и ограничений.
8. Действия по разработке программного обеспечения могут быть начаты только после утверждения требований Заказчиком и руководством компании. При необходимости начать работы до утверждения требований официальным Заказчиком, в роли Заказчика может выступить должностное лицо компании, имеющее полномочия и ресурсы принять риски, связанные с формулировкой требований.
|
9. В процессе выполнения проекта по инициативе Заказчика, ключевых членов рабочей группы или в соответствии с планом проекта требования могут быть изменены. Изменение требований должно быть выполнено в соответствии с процедурой контроля изменений. Документ, содержащий изменения или дополнения требований либо новая версия документа, согласовывается и утверждается в порядке, предусмотренном для основного документа.
10. При изменении требований выполняются процедуры каскадной корректировки разработанных материалов проекта. Обеспечение соответствия утвержденных требований - остальным материалам проекта является сферой ответственности рабочей группы проекта.
11. Документ, описывающий требования к ПО – Техническое Задание должен находиться под конфигурационным контролем.
12. Группа обеспечения качества в соответствии со своим планом проводит проверки и аудит процедур управления требований.
8.3 Обеспечение процессов управления требований
|
|
Эмиссия газов от очистных сооружений канализации: В последние годы внимание мирового сообщества сосредоточено на экологических проблемах...
Типы сооружений для обработки осадков: Септиками называются сооружения, в которых одновременно происходят осветление сточной жидкости...
История развития хранилищ для нефти: Первые склады нефти появились в XVII веке. Они представляли собой землянные ямы-амбара глубиной 4…5 м...
Археология об основании Рима: Новые раскопки проясняют и такой острый дискуссионный вопрос, как дата самого возникновения Рима...
© cyberpedia.su 2017-2024 - Не является автором материалов. Исключительное право сохранено за автором текста.
Если вы не хотите, чтобы данный материал был у нас на сайте, перейдите по ссылке: Нарушение авторских прав. Мы поможем в написании вашей работы!