Модель вариантов использования системы состоит из всех актантов системы и различных вариантов использования, посредством которых актанты взаимодействуют с системой, тем самым, описывая многообразие ее функционального поведения. Она также показывает связи между вариантами использования, что углубляет наше понимание системы.
Первый шаг моделирования вариантов использования состоит в создании системной диаграммы, описывающей границы системы и определяющей ее актанты. Это позволяет параллельно осуществить этапы 3 и 4, в которых требуется выявить заинтересованных лиц системы и определить ее границы.
Второй шаг описывает системное поведение, т.е. то, как пользователи взаимодействуют с системой, осуществляя некоторые последовательности действий, для достижения определенных целей (Рис. 3 .52). Следующий шаг состоит в уточнении деталей функционального поведения каждого варианта использования.
Мастер-класс по сбору и анализу требований
Спецификации вариантов использования состоят из текстовых и графических описаний каждого варианта использования, написанных с позиции пользователя. Рис. 3.52 Диаграмма вариантов использования
Спецификация вариантов использования Определение потока событий
- Клиентами, которые одобряют результат;
- Пользователями, которые будут работать с системой;
- Разработчиками вариантов использования, которые заинтересованы в точном описании желаемого поведения системы;
- Рецензентами, которые составляют непредвзятое мнение о системе;
- Проектировщиками, которые анализируют варианты использования в поисках классов, объектов и т.п.;
- Тестерами, которым нужно создать тестовые примеры;
- Менеджером проекта, которому необходимо понимать весь проект в целом;
- Составителем технической документации, которому нужно документировать функции системы так, чтобы было понятно пользователю;
- Людьми, из отдела маркетинга и продаж, которым необходимо понимать функции продукта и объяснять его достоинства остальным.
04.06.2015 535.4 Кб 6 Учебный план.rtf
Ограничение
Для продолжения скачивания необходимо пройти капчу:
Источник: studfile.net
Лекция 5: Управление требованиями
Разделим требования на две большие группы – функциональные и нефункциональные.
Функциональные требования являются детальным описанием поведения и сервисов системы, ее функционала. Они определяют то, что система должна уметь делать.
Нефункциональные требования не являются описанием функций системы. Этот вид требований описывает такие характеристики системы, как надежность, особенности поставки (наличие инсталлятора, документации), определенный уровень качества. Сюда же могут относиться требования на средства и процесс разработки системы, требования к переносимости, соответствию стандартам и т.д. Требования этого вида часто относятся ко всей системе в целом.
Техника интервьюрирования в бизнес-анализе
Сформулируем ряд важных свойств требований.
— Ясность, недвусмысленность — однозначность понимания требований заказчиком и разработчиками.
Часто этого трудно достичь, поскольку конечная формализация требований, выполненная с точки зрения потребностей дальнейшей разработки, трудна для восприятия заказчиком или специалистом предметной области, которые должны проинспектировать правильность формализации.
— Полнота и непротиворечивость.
— Необходимый уровень детализации.
Требования должны обладать ясно осознаваемым уровнем детализации, стилем описания, способом формализации: либо это описание свойств предметной области, для которой предназначается ПО, либо это техническое задание, которое прилагается к контракту, либо это проектная спецификация, которая должна быть уточнена в дальнейшем, при детальном проектировании.
Важно также ясно видеть и понимать тех, для кого данное описание требований предназначено, иначе не избежать недопонимания и последующих за этим трудностей. Ведь в разработке ПО задействовано много различных специалистов – инженеров, программистов, тестировщиков, представителей заказчика, возможно, будущих пользователей – и все они имеют разное образование, профессиональные навыки и специализацию, часто говорят на разных языках. Здесь также важно, чтобы требования были максимально абстрактны и независимы от реализации.
— Прослеживаемость — важно видеть то или иное требование в различных моделях, документах, наконец, в коде системы. А то часто возникают вопросы типа – «Кто знает, почему мы решили, что такой-то модуль должен работать следующим образом ….?».
Прослеживаемость функциональных требований достигается путем их дробления на отдельные, элементарные требования, присвоение им идентификаторов и создание трассировочной модели, которая в идеале должна протягиваться до программного кода. Хочется например, знать, где нужно изменить код, если данное требование изменилось.
На практике полная формальная прослеживаемость труднодостижима, поскольку логика и структура реализации системы могут сильно не совпадать с таковыми для модели требований. В итоге одно требование оказывается сильно «размазано» по коду, а тот или иной участок кода может влиять на много требований. Но стремиться к прослеживаемости необходимо, разумно совмещая формальные и неформальные подходы.
— Тестируемость и проверяемость — необходимо, чтобы существовали способы оттестировать и проверить данное требование. Причем, важны оба аспекта, поскольку часто проверить-то заказчик может, а вот тестировать данное требование очень трудно или невозможно в виду ограниченности доступа (например, по соображениям безопасности) к окружению системы для команды разработчика. Итак, необходимы процедуры проверки –выполнение тестов, проведение инспекций, проведение формальной верификации части требований и пр. Нужно также определять «планку» качества (чем выше качество, тем оно дороже стоит!), а также критерии полноты проверок, чтобы выполняющие их и руководители проекта четко осознавали, что именно проверено, а что еще нет.
— Модифицируемость. Определяет процедуры внесения изменений в требования.
Варианты формализации требований:
В реальной практике они всегда существуют в виде какого-то представления – документа, модели, формальной спецификации, списка и т.д.
Каждое представление требований выполняет определенную задачу, например, служит «мостом», фиксацией соглашения между разными группами специалистов, или используется для оперативного управления проектом (отслеживается, в какой фазе реализации находится то или иное требование, кто за него отвечает и пр.), или используется для верификации и модельно-ориентированного тестирования. И в первом, и во втором, и в третьем примере мы имеем дело с требованиями, но формализованы они будут по-разному.
Формализация требований в проекте может быть очень разной – это зависит от его величины, принятого процесса разработки, используемых инструментальных средств, а также тех задач, которые решают формализованные требования. Более того, может существовать параллельно несколько формализаций, решающих различные задачи:
— Неформальная постановка требований в переписке по электронной почте.
Хорошо работает в небольших проектах, при вовлеченности заказчика в разработку.
Хорошо также при таком стиле, когда есть взаимопонимание между заказчиком и командой, то есть лишние формальности не требуются.
Однако, электронные письма в такой ситуации часто оказываются важными документами – важно уметь вести деловую переписку, подводить итоги, хранить важные письма и пользоваться ими при разногласиях. Важно также вовремя понять, когда такой способ перестает работать и необходимы более формальные подходы.
— Требования в виде документа – описание предметной области и ее свойств, техническое задание как приложение к контракту, функциональная спецификация для разработчиков и т.д.
— Требования в виде графа с зависимостями в одном из средств поддержки требований.
Такое представление удобно при частом изменении требований, при отслеживании выполнения требований, при организации «привязки» к требованиям задач, людей, тестов, кода.
Важно также, чтобы была возможность легко создавать такие графы из текстовых документов, и наоборот, создавать презентационные документы по таким графам.
— Формальная модель требований для верификации, модельно-ориентированного тестирования и т.д.
Итак, каждый способ представления требований должен отвечать на следующие вопросы: кто потребитель, пользователь этого представления, как именно, с какой целью это представление используется.
Некоторые ошибки при документировании требований:
Перечислим ряд ошибок, встречающихся при составлении технических заданий и иных документов с требованиями:
— Описание возможных решений вместо требований.
— Нечеткие требования, которые не допускают однозначную проверку, оставляют недосказанности, имеют оттенок советов, обсуждений, рекомендаций: «Возможно, что имеет смысл реализовать также…..», «и т.д.».
— Игнорирование аудитории, для которой предназначено представление требований.
Например, если спецификацию составляет инженер заказчика, то часто встречается переизбыток информации об оборудовании, с которым должна работать программная система, отсутствует глоссарий терминов и определений основных понятий, используются многочисленные синонимы и т.д. Или допущен слишком большой уклон в сторону программирования, что делает данную спецификацию непонятной всем непрограммистам.
— Пропуск важных аспектов, связанных с нефункциональными требованиями, в частности, информации об окружении системы, о сроках готовности других систем, с которыми должна взаимодействовать данная.
Последнее случается, например, когда данная программная система является частью более крупного проекта. Типичны проблемы при создании программно-аппаратных систем, когда аппаратура не успевает вовремя и ПО невозможно тестировать, а в сроках и требованиях это не предусмотрено….
Цикл работы с требованиями:
Выделение требований (requirementselicitation), нацеленное на выявление всех возможных источников требований и ограничений на работу системы и извлечение требований из этих источников.
Анализ требований (requirementsanalysis), целью которого является обнаружение и устранение противоречий и неоднозначностей в требованиях, их уточнение и систематизация.
Описание требований (requirementsspecification). В результате этой деятельности требования должны быть оформлены в виде структурированного набора документов и моделей, который может систематически анализироваться, оцениваться с разных позиций и в итоге должен быть утвержден как официальная формулировка требований к системе.
Валидация требований (requirementsvalidation), которая решает задачу оценки понятности сформулированных требований и их характеристик, необходимых, чтобы разрабатывать ПО на их основе, в первую очередь, непротиворечивости и полноты, а также соответствия корпоративным стандартам на техническую документацию.
Источник: megaobuchalka.ru
Жесткий формализм в команде: за и против
Многие быстроразвивающиеся компании испытывают потребность в стандартизации рабочих процессов, и это не удивительно. Но как сделать так, чтобы формализация не перешла в банальный бюрократизм и не отразилась негативно на деятельности сотрудников и компании в целом?
http://delivery.gettyimages.com/xc/200428538-001.jpg?v=1k=2/>Однажды руководитель молодой быстроразвивающейся компании обратился к специалистам нашего агентства с запросом оценить состояние организации в связи со смутными опасениями, что люди не готовы к изменениям, которые происходят на фоне гиперроста компании. До последнего времени в ней сохранялась «семейная» обстановка: плоская организационная структура, где каждый сотрудник мог зайти в кабинет руководителя и сказать, что думает.
Однако компания развивалась очень быстрыми темпами, количество персонала за короткий срок выросло примерно в десять раз. Руководитель (он же учредитель) был более не в состоянии поддерживать тесные отношения со всеми сотрудниками, так как ему просто не хватало времени, да еще близилось открытие нового офиса. Возможности интересоваться делами всего коллектива или хотя бы «старых» сотрудников больше не было. В то же время не хотелось вводить должностные инструкции, иерархическую структуру и прочие атрибуты совкового прошлого, которые воспринимались руководителем этой компании как угроза сложившемуся демократическому климату.
В отношении описанной ситуации вопрос можно было сформулировать так: «Можно ли в быстрорастущей компании избежать формализации и сохранить прежнюю неформальную атмосферу?»
В данном случае вопрос о формализации возник в связи с развитием компании. И действительно, в жизни организаций существует этап, когда особенно активно вводятся формализованные процедуры, правила и стандарты. Это необходимо, когда на фоне интенсивного развития актуальными становятся такие цели, как внутренняя стабилизация и охват новых рынков.
Этот этап развития (который, собственно, и называется этапом формализации) требует от руководителей делегирования полномочий и введения некоторых формальных систем контроля, иначе по мере дальнейшего роста компания может стать неуправляемой. Таким образом, рост формализации — неизбежное следствие развития компании. В дальнейшем альтернативой чрезмерной бюрократизации становятся мероприятия по улучшению командного взаимодействия и совершенствование системы управления.
Ответ на поставленный руководителем вопрос, можно ли избежать формализации в данном случае, дали в интервью сами сотрудники компании: «Не всегда знаешь, к кому обратиться с вопросом. Необходима формализация, однако не до абсурда, когда правило стоит выше логики».
Сопротивление изменениям
Формализация, с одной стороны, направлена на упорядочивание производственных отношений и тем самым должна вести к повышению эффективности производства. С другой, независимо от того, насколько это нововведение разумно, оно часто встречает сопротивление, причем как со стороны руководства, так и со стороны подчиненных. Если же необходимость формализации тех или иных процедур, введения стандартов, разработки критериев очевидна, но вызывает сопротивление, есть смысл привлечь сам персонал к работе над составлением инструкций и алгоритмов. Следовать правилам, разработанным самим собой, гораздо проще и приятнее, чем тем, которые навязываются кем-то, особенно если этот кто-то имеет смутное представление о специфике деятельности конкретного человека или подразделения.
Чаще всего об уровне формализации принято судить по объемам бумаги, сопровождающей рабочий процесс, где отражены, например, структурная схема организации, положения о подразделениях, должностные инструкции и прочее. Чрезмерное количество такой бумаги вносит путаницу, а ее дефицит может вызвать неопределенность.
Например, сотрудник готовится к встрече с руководителем, чтобы просить о повышении заработной платы. При этом в компании или в конкретном подразделении нет должностных инструкций.
Вполне возможен такой сценарий беседы:
Сотрудник: «Объем выполняемой мной работы значительно расширился за последнее время».
Руководитель: «Наконец-то вы стали справляться со своими обязанностями».
Как видим, сотрудник не может аргументировать свою просьбу о повышении оплаты труда, так как отсутствие четко зафиксированного перечня должностных обязанностей не позволяет понять, что и в каком объеме следует делать, чтобы считать свою работу выполненной. Неизвестна грань между выполнением обязанностей и проявлением инициативы, следовательно, сотрудники не могут полностью понять, что нужно сделать в компании, каких показателей достичь, какие знания приобрести, чтобы увеличить размер оплаты своего труда, и возможно ли это вообще. Большинство людей хотят понимать пределы своих финансовых возможностей в компании и планировать доходы.
Если выйти за рамки приведенной иллюстрации, то можно увидеть, к чему ведет отсутствие четко зафиксированного перечня обязанностей по каждой конкретной должности.
Распределение ответственности в подразделении и в компании в целом происходит случайным образом и во многом определяется межличностными отношениями, а не производственной необходимостью. Как следствие в подобных обстоятельствах часты явления фаворитизма.
Отсутствие фиксированного перечня должностных обязанностей не позволяет адекватно оценивать работу персонала и делает невозможным построение эффективной системы материального стимулирования. В такой ситуации неизвестно, как формируется размер бонуса и что означает сама сумма, высоко оценена работа или нет, честно ли распределен доход внутри подразделений и между ними.
Мотивация персонала при такой системе материального стимулирования обычно ниже, чем при обычной фиксированной оплате труда, поскольку связь между затраченными усилиями и размером вознаграждения неясна. Подобная неопределенность (в обязанностях, критериях оценки работы, системе материального стимулирования) может вызывать у сотрудников напряжение и демотивировать.
Формализация и этика
Формализация во многом призвана обеспечивать контроль над сотрудниками компании, а поэтому она содержит в себе и этический компонент. Иногда можно видеть, как в организации пытаются контролировать поведение людей, выходя далеко за рамки корпоративных интересов. Пусть некорректным считается обсуждать романы на работе, однако это происходит и объясняется тем, что близкие отношения между сотрудниками могут задевать интересы самой организации или попросту быть разрушительными для нее. Казалось бы, что времена, когда любовные связи выносились на обсуждение коллектива на партийных собраниях, позади, однако и сейчас в некоторых компаниях считают, что никакие личные интересы людей не могут быть реализованы в рабочее время.
Роберт Уолкер, начальник информационного отдела Hewlett-Packard, когда-то сказал: «Мы рассматриваем электронную почту и, вероятно, все остальное не как чье-то частное дело, а как составной элемент работы компании. Мы не считаем, и я не думаю, что людям следует считать, что то, чем они занимаются, должно носить приватный характер в рамках компании Hewlett-Pack-ard» (Дж. Линд «Индустриально-организационная психология»). Это высказывание очень хорошо иллюстрирует одну из точек зрения на описываемую проблему.
Наивно думать, что формализация может абсолютно вытеснить неформальные отношения и устранить личные интересы из рабочего времени. Подобное отношение компании к собственным сотрудникам, вероятнее всего, будет встречать постоянный протест и в целом ухудшать организационный климат.
Политика открытых дверей
Еще один наглядный пример позволяет увидеть следствия бюрократизации в крупных компаниях. На одном из торжеств компании Форда чествовали механика, проработавшего 25 лет. После поздравлений Генри Форда и вручения подарков механик сказал: «Все двадцать пять лет ты использовал мои руки. Но если бы ты спрашивал меня о том, что я думаю, все двадцать пять лет ты мог бы использовать и мои мозги!»
Высокая степень формализации, пусть и обоснованная (в данном случае большим размером организации и рутинным характером работы на конвейере), препятствует проявлению инициативы, снижает информационный поток снизу вверх и тем самым ведет к потере ценной информации. В то же время при пониженной формализации неупорядоченная коммуникация может вести к информационной перегрузке и вносить путаницу в работу (например, несогласованная отправка сообщений руководителями).
Высокий уровень бюрократии часто снижает конфиденциальность коммуникации, как это происходит при прохождении документов по различным инстанциям (в большинстве западных исследований до одной трети респондентов признаются, что отслеживают электронную почту и компьютерные файлы других работников), и делает связь односторонней, когда реакция адресата остается неизвестной. При этом руководители могут питать иллюзии, считая, что «любой может зайти ко мне в кабинет и сказать обо всем, что его не устраивает. А если не заходит — значит, не хочет».
Исследования показывают, что политики открытых дверей явно недостаточно и управленцы должны проявлять дополнительную активность, чтобы получать полезную информацию снизу, иначе множество сообщений, которые могли бы оказаться полезными, если бы они поступили наверх, уходят в горизонтальном направлении, к коллегам. Здесь могут пригодиться специальные формализованные процедуры обратной связи, позволяющие обеспечить двухстороннюю коммуникацию.
Рассмотренные примеры показывают, что формализация в компании — важный процесс. Регламентация отношений между подчиненным и руководителем выполняет функцию стабилизации производственных отношений и обеспечивает безопасность сотрудника, в частности его защиту от эксплуатации. Регулируя отношения между владельцем бизнеса, руководителями и специалистами, формализация проявляется в коммуникации, а потому влияет и на другие процессы в компании: власть, руководство и принятие решений. Очевидно, что вопрос не в том, быть ли формализации, а в том, каков ее оптимальный уровень.
Достигаем оптимума
Оптимальный уровень формализации достигается посредством учета многих факторов.
Первый фактор, который необходимо принимать во внимание, — нынешний этап развития компании. Развивающаяся компания так или иначе сталкивается с необходимостью формализации. Ее уровень по ходу развития обычно возрастает. Однако если в компании наблюдается организационный кризис, излишняя формализация может быть очень нежелательна, поскольку замедляет процесс принятия решений, которые в этот период должны отличаться особой оперативностью.
Вторым фактором является размер компании: чем она больше, тем больше она нуждается в бюрократических мерах. Так, традиционная для небольших организаций форма поддержания неформальных отношений руководства с персоналом на пикниках, вечеринках или за пивом по мере роста компании становится практически неприемлемой.
Характеристики выполняемой работы каждого подразделения или отдельного сотрудника — третий фактор, который должен учитываться в поиске оптимального уровня формализации рабочих процессов. Чем выше сложность и необходимость творческого подхода, чем больше неопределенность условий конкретной деятельности, тем меньше необходима стандартизация работы. И наоборот, чем более рутинна деятельность человека (в сборочном цеху, в деловой переписке), тем большей формализации она требует.
Важно заметить, что оптимальный уровень может, а часто и должен, различаться в зависимости от специфики деятельности каждого конкретного подразделения или сотрудника. Например, креативная работа в рекламном агентстве должна быть гораздо менее формализована, нежели деятельность менеджеров, общающихся с клиентами.
При высокой степени формализации компания может позволить себе некоторую децентрализацию власти, но только при условии, что действующая система мотивации эффективна, а уровень профессионализма и ответственности специалистов высок. Следует также отметить, что указанные характеристики персонала, а также положение сотрудника или подразделения в иерархической структуре компании обратно пропорциональны степени бюрократизации.
Хорошо прописанные правила вносят определенность в отношения отдельных людей и целых подразделений, снимают двусмысленность и создают структуру, в которой возможна осмысленная работа. Вместе с тем те же стандартизированные процедуры имеют принудительный характер, поскольку заставляют людей подстраиваться под определенные правила.
Формализация может способствовать повышению или снижению ответственности и мотивации, обеспечивать стабильность внутриорганизационных процессов или лишать компанию способности гибко реагировать на внешние изменения. По уровню формализации можно судить о кадровой политике и благополучии организационного климата. Таким образом, формализация не является каким-то обособленным процессом в организации, а тесно переплетается с вопросами управления, мотивации, ответственности, доверия и свободы
Справка
Причины сопротивления
Формализация может встречать сопротивление и со стороны руководства, и со стороны подчиненных в силу нескольких причин:
— нежелание руководства и сотрудников терять комфортную, «домашнюю» обстановку, открытые и доверительные отношения, которые были прежде;
— опасность того, что соблюдение формальностей станет самоцелью. Если это происходит, то неизбежно снижается инициативность и в целом мотивация персонала;
— специалист высокого уровня воспринимает детализированное, пошаговое инструктирование как проявление недоверия, чувствует, что его квалификацию считают недостаточной для принятия самостоятельных решений;
— некоторые виды работ не могут быть жестко формализованы в связи с высокой сложностью. Работа, характеризующаяся значительной степенью неопределенности, требующая высокой креативности или быстрого принятия решений, зачастую интуитивных, не допускает излишней формализованности, иначе снижается творческий потенциал, уровень ответственности и скорость реагирования на изменения.
Источник: bishelp.ru