Отправляет email-рассылки с помощью сервиса Sendsay

Технологии разработки ПО (курс для АСОИУ)

Подписаться Бесплатная новостная рассылка Подписчиков 14 RSS
  Февраль 2006   →
 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


За последние 60 дней ни разу не выходила


Открыта: 22-02-2006

Автор
Александр Морозов

Статистика

14 подписчиков
0 за неделю
←   Все выпуски   →

Технологии разработки ПО (курс для АСОИУ) Анализ требований. Часть первая.


Анализ требований

Краткое содержание лекций(1-2)

Дисциплина «Технология программирования» предполагает изучение методик и технологий разработки ПО.

Разработка ПО включает в себя 5 видов деятельности: анализ, проектирование, кодирование, тестирование и управление. При изучении дисциплины основное внимание будет уделено первым четырем видам деятельности.

Анализ – вид деятельности, направленный на выявление, описание и систематизацию требований к ПО.

Анализ (требований) – это процесс. Участниками процесса анализа можно считать: разработчиков, аналитиков, спонсоров, руководителей фирмы – заказчика, менеджеров по маркетингу, потенциальных пользователей разрабатываемого ПО.

Особо выделяется роль аналитика – поскольку эта роль достаточно сложна в исполнении и зачастую требует специальных навыков. В роли аналитиков могу выступать люди из компании заказчика, из сторонней компании и из компании – разработчика.

Аналитики обычно имеют одну или несколько предметных областей специализации.

Профессиональные аналитики могут предлагать и проектировать изменение бизнес-процессов на предприятии, с возможным применением ИТ-технологий.

Основными видами деятельности в процессе анализа являются: извлечение, документирование, анализ (переработка) и управление требованиями.

Извлечение требований с связанно навыками коммуникации. Учитесь общаться.

При извлечении требований к ПО важно помнить об уровнях требований.

Различают требования трех уровней: бизнес-требования, пользовательские требования, детальные функциональные требования. Первые два уровня называют C-требованиями (customer), последний D-требованиями (detail)

Бизнес-требования включают в себя бизнес-цели и общее описание границ системы.

Бизнес-требования извлекаются аналитиками совместно с руководителями предприятия заказчика или менеджерами по маркетингу.

Бизнес-требования документируются с использованием ЕЯ (естественного языка) и диаграмм.

Удобной для описания границ системы является контекстная диаграмма. Для ее изображения обычно используется нотация DFD Гейне-Сарсона.

На контекстной диаграмме четко указываются все роли пользователей работающих с системой.

Пользовательские требования вырабатываются совместно с представителями всех групп (ролей) пользователей. Представителя отдельно взятой группы пользователей также называют сторонником продукта (product champion)

Не стоит набирать слишком много сторонников. Однако от каждой группы пользователей должен быть хотя бы один представитель.

Пользователи мыслят возможностями системы (feature). Еще их называют вариантами использования (use case).

Для наглядного изображения вариантов использования применяются Use Case диаграммы.

Обычно варианты использования описываются в виде «пользовательских историй» на ЕЯ (user story), пар запрос-отклик, диаграмм взаимодействия.

Если требования разных групп пользователей начинают противоречить друг другу делайте выбор в пользу наиболее значительной части аудитории. Используйте таблицы принятия решений.

Вопрос к обсуждению

Любая деятельность требует затрат (материальных, временных и т.д.) Как по вашему сколько процентов от всех затрат на проект должно уходить на анализ требований? Попробуйте порассуждать. Письма присылайте на morginc@mail.ru

 
В избранное