1-software_engineering_requirements (1133541), страница 4

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 4)

В большинстве случаев, процесс определения, работы с требованиямивыделен в самостоятельный набор и описан как последовательность (сценарии) действий,8Copyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ruОсновы программной инженерии (по SWEBOK)Программная инженерия. Программные требования.связанных с ними ролей и непосредственных результатов (их часто называют “артефактами”,например, в RUP – Rational Unified Process), в рамках конкретных методологий разработкипрограммного обеспечения.2.2 Участники процессов (Process Actors)В этой теме вводится понятие “роли” и дается понимание “ролей” для людей, которые участвуют впроцессе работы с требованиями (чувствуете отличие между “определением” требований и“работой” с ними?). Таких людей также называют “заинтересованными лицами” (в данном контексте software stakeholders).

Заинтересованное лицо – некто, имеющий возможность (в том числе,материальную) повлиять на реализацию проекта/продукта.Типичные примеры ролей:Пользователи (Users): группа, охватывающая тех людей, кто будет непосредственноиспользовать программное обеспечение; пользователи могут описать задачи, которые онирешают (планируют решать) с использованием программной системы, а также ожидания поотношению к атрибутам качества, отображаемые в пользовательских требованиях.Заказчики (Customers): те, кто отвечают за заказ программного обеспечения или, в общемслучае, являются целевой аудиторией на рынке программного обеспечения (образуютцелевой рынок ПО);Стандарт 12207 (его обзор будет приведен в другой главе) определяет более суженноепонятие “заказчика” (обратите внимание – acquirer, а не customer, хотя часто оба терминапереводятся на русский язык одинаково) как организацию, которая приобретает или получаетсистему, программный продукт или программную услугу от поставщика. Здесь возможноиспользовать такое общее определение: заказчик – лицо или организация, получающиепрямую или косвенную выгоду от использования продукта.

Клиентами считают техзаинтересованных лиц, кто требует, оплачивает, выбирает, использует или получаетрезультаты работы программного обеспечения. В этом плане, “заказчик” в пониманиистандарта 12207 скорее ближе к “клиенту” в такой интерпретации.Аналитики (Market analysts): продукты массового рынка программного обеспечения (как идругих массовых рынков, например, бытовой техники) не обладают “заказчиками” впонимании персонификации тех, кто “заказывает разработку. В то же самое время, лица,отвечающие за маркетинг, нуждаются в идентификации потребностей и обращению к тем,кто может играть роль <квалифицированных> “представителей” потребителей;Регуляторы (Regulators): многие области применения (“домены”) являются регулируемыми,например, телекоммуникации или банковский сектор.

Программное обеспечение для рядацелевых рынков (в первую очередь, корпоративного сектора) требует соответствияруководящим документам и прохождения процедур, определяемых уполномоченнымиорганами.Инженеры по программному обеспечению, иженеры-программисты (Software Enginner):лица, обладающие обоснованным интересом к разработке программного обеспечения,например, повторному использованию тех или иных компонент, библиотек, средств иинструментов. Именно инженеры ответственны за техническую оценку путей решенияпоставленных задач и последующую реализацию требований заказчиков.SWEBOK особо подчеркивает, что если невозможно в точности (в оригинале – “perfectly”)удовлетворить требования каждого заинтересованного лица, именно работа инженера включаетпроведение переговоров и поиск компромисса, приемлемого для ключевых заинтересованных лиц(“стейкхолдеров”) и удовлетворяющего бюджетным, техническим, временным и другимограничениям проекта.

Необходимо понимать, что такая деятельность практически навернякаприведет к изменениям в требованиях, как минимум, на уровне соответствующих приоритетовтребований и, следовательно, работ по их реализации.2.3 Управление и поддержка процессов (Process Support and Management)Copyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru9Основы программной инженерии (по SWEBOK)Программная инженерия. Программные требования.Эта тема затрагивает вопросы распределения ресурсов, необходимых для осуществленияпроектной деятельности, устанавливая контекст для первой секции “Инициация и определениесодержания” (Initiation and Scope Definition) области знаний “Управление в программной инженерии”(Software Engineering Management). Основная цель данной темы – обеспечение связи междупроцессами и деятельностью, определенными в 2.1 “модели процесса определения требований” ивопросами использования проектных ресурсов – стоимостью, человеческими ресурсами,инструментами и т.п.2.4 Качество и улучшение процессов (Process Quality and Improvement)Эта тема связана с оценкой качества процессов работы с программными требованиями иулучшением этих процессов.

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

Т.е. нет смысла заниматься улучшением ради улучшения,нужно четко понимать какая в настоящее время есть проблема в работе с требованиями, инасколько эта проблема значима, и только потом приступать к ее устранению, в частности черезулучшение процессов. Реальная отечественная практика многих организаций, занимающихсяразработкой ПО, показывает, что очень немногие имеют действительно четкое представление о том,каким образом организация работы с требованиям может повлиять на успех компании в целом.Обычно, отечественные компании, в лучшем случае просто документируют требования, выпускаядокументы, например, Техническое задание по ГОСТ.

Но действительно ли в этом документе можноувидеть требования – увы. Следуя только рекомендациям, которые есть в ГОСТ можно толькосоответствующим образом оформить разделы, что практически никак не влияет на качество иинформативность документа. Вопросы совершенствования процессов – process improvement будутрассматриваться как в главах, посвященных CMMI, так и в других частях этой книги.Данная тема тесно связана с областями знаний “Качество программного обеспечения” (SoftwareQuality) и “Процесс программной инженерии” (Software Engineering Process). В этом контексте,фокусы обсуждаемой темы – определение атрибутов и метрик качества, а также определениесоответствующих процессов в применении к программным требованиям, которые можно свести в тригруппы практик: Покрытие процессов работы с требованиями с точки зрения стандартов и моделейулучшения процессов, в целом; Измерение и количественная оценка (benchmarking) процессов работы с требованиями; Планирование и реализация процесса улучшения, как такового.3.

Извлечение требований (Requirements Elicitation)Данная секция освещает вопросы сбора требований как с точки зрения организации процесса, так иопределения источников, откуда поступают требования. Это первая стадия построения виденияавтоматизируемой проблемной области. Идентификация заинтересованных лиц, их взаимодействия,выполняемых ими бизнес-процессов – все это является ключевыми вопросами, без четкого иоднозначного ответа на которые даже не стоит думать об успешности проекта (кстати, не толькопрограммного...).Один из ключевых принципов программной инженерии заключается в обеспечении взаимодействиямежду пользователями и инженерами. Прежде, чем начинается разработка программногообеспечения, именно специалисты “по требованиям” – аналитики перекидывают тот самый “мостик”между заказчиками и исполнителями, который задает тот уровень коммуникаций и взаимопониманиямежду ними, который необходим для решения задач проекта.Copyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru10Основы программной инженерии (по SWEBOK)Программная инженерия.

Программные требования.3.1 Источники требований (Requirement Sources)Необходимо идентифицировать все возможные источники требований, значимые для решения задачпроекта. Только после этого можно определить их влияние на проект. Данная тема касаетсявопросов понимания информированности источников требований и их значимости.Данная тема фокусируется на: Целях Знании предметной области Заинтересованных лицах Операционном окружении Организационной средеВыделение приоритетов, однозначность требований, передаваемых инженерам, связь междутребованиями и их взаимное влияние друг на друга – все это является следствием четкого иоднозначного понимания источников требований.3.2 Техники извлечения требований (Elicitation Techniques)Идентифицировав источники требований мы не должны “покоится на лаврах”.

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

Характеристики

Список файлов книги