русс | укр

Языки программирования

ПаскальСиАссемблерJavaMatlabPhpHtmlJavaScriptCSSC#DelphiТурбо Пролог

Компьютерные сетиСистемное программное обеспечениеИнформационные технологииПрограммирование

Все о программировании


Linux Unix Алгоритмические языки Аналоговые и гибридные вычислительные устройства Архитектура микроконтроллеров Введение в разработку распределенных информационных систем Введение в численные методы Дискретная математика Информационное обслуживание пользователей Информация и моделирование в управлении производством Компьютерная графика Математическое и компьютерное моделирование Моделирование Нейрокомпьютеры Проектирование программ диагностики компьютерных систем и сетей Проектирование системных программ Системы счисления Теория статистики Теория оптимизации Уроки AutoCAD 3D Уроки базы данных Access Уроки Orcad Цифровые автоматы Шпаргалки по компьютеру Шпаргалки по программированию Экспертные системы Элементы теории информации

Синицын И.В., Терновсков В.Б. 2 страница


Дата добавления: 2013-12-23; просмотров: 1001; Нарушение авторских прав


• Системные требования (System Requirements) - иногда классифицируются как составная часть группы функциональных требований (не путайте с как таковыми “функциональными требованиями”). Описывают высокоуровневые требования к программному обеспечению, содержащему несколько или много взаимосвязанных подсистем и приложений. При этом, система может быть как целиком программной, так и состоять из программной и аппаратной частей. В общем случае, частью системы может быть персонал, выполняющий определенные функции системы, например, авторизация выполнения определенных операций с использованием программно-аппаратных подсистем.

Необходимо сделать несколько важных замечаний по бизнес-правилам. Бизнес правила, как таковые, являются предметом пристального изучения различных специалистов в области как бизнес-моделирования, так и программной инженерии в целом. Практика разработки программных требований включает идентификацию и описание бизнес-правил как самостоятельных артефактов. Например, методология RUP выделяет отдельный артефакт Business Rule в рамках дисциплины Business Modeling. Все бизнес-правила, в рамках данной дисциплины, идентифицируются и описываются в документе Business Rules Document. При разработке требований, в сценариях Use Cases обычно включается ссылка на уже описанное бизнес-правило. Скотт Амблер (см. www.agilemodeling.com/artifacts/) так же выделяет бизнес-правило как один из артефактов, который используют в семействе Agile методологий.

В настоящее время разработаны методы и подходы формального представления бизнес-правил, вплоть до формальных языков описания (использование OCL - Object Constraint Language, BRML - Business Rules Markup Language).

Бизнес-правила могут быть не только использованы при определении требований к разрабатываемому По, но и могут отдельно оформляться в дизайне ПО (класс или группа классов), отражаясь в конечном итоге в программном коде на определенном языке программирования. Существуют специализированные инструментальные средства и библиотеки, позволяющие разрабатывать и поддерживать приложения, интенсивно использующие бизнес-правила.



Рассматривая бизнес-правила, как артефакты относящиеся к области программных требований можно отметить, вернее дать одно из пояснений, почему БП относят к нефункциональным требованиям: Например, при написании определенного шага в сценарии use case, используется ссылка на бизнес правило: «... система производит расчет стоимости в соответствии с бизнес- правилом BP41 ...». В свою очередь данное бизнес-правило может определять алгоритм расчета стоимости. Т.е. налицо «с соблюдением каких условий система делает расчет».

Одним из наиболее известных специалистов по BR является Рональд Росс, автор книги «Principles of the Business Rule Approach» (Ronald G. Ross. «Principles of the Business Rule Approach», 2003).

Наравне с представленной классификацией требований, могут использоваться и другие подходы. Даже в рамках этой классификации, существуют и различные взгляды на ее интерпретацию и детализацию. Например, как результат определения целевой аудитории и в рамках маркетинговой стратегии продвижения тиражируемого решения, возможно определять высокоуровневые возможности (ключевые характеристики, особенности) - “фичи” (features) разрабатываемого продукта. Иногда, такие возможности детализируются в смысле функциональных требований в некоторых agile-техниках, например, FDD - Feature-Driven Development (как вы видите вплоть до самого названия целого комплекса практик, метода разработки).

Вигерс, описывает feature как “множество логически связанных функциональных требований, которые предоставляют определенные возможности для пользователя и удовлетворяют бизнес-целям <организации>". С точки зрения маркетинга программного обеспечения, как отмечает Вигерс, feature это «группа требований, узнаваемая заинтересованными лицами, которые вовлечены в процесс принятия решения по приобретению ПО - это список <отличительных особенностей или возможностей, характеристику присутствующий в описании продукта». В то же время, Леффингвелл и Видриг (D.Leffingwell, D. Widrig, Managing Software Requirements: A Use Case Approach, Second Edition, 2003) определяют feature как “сервисы, которые оказывает система для удовлетворения одной или более потребностей заинтересованных лиц (stakeholders needs)”. Ими же отмечается, что в реальных проектах могут быть не определены stakeholders needs (а их часто выделяют, особенно если у проекта/продукта есть много заинтересованных лиц со своими потребностями, и эти потребности могут носить взаимоисключающий характер), но существовать features могут и самостоятельно (как и stakeholder needs), и конечно же возможно существование и stakeholder needs и features со взаимной трассировкой.

Развивая тему features -- Kurt Bittner & Ian Spence в своей книге “Use Case Modeling” (Kurt Bittner, Ian Spence. Use Case Modeling, 2002), дают схожее, хотя и более формальное определение features.

Они отмечают, что features могут быть как относящимся к функциональным, так и к нефункциональным требованиям. И могут изменяться от версии к версии продукта.

Анализируя различные источники на предмет работы с features, следует отметить следующее:

С точки зрения инженерии требований, features являются самостоятельным артефактом, который может быть соотнесен как с функциональными требованиями, так и с нефункциональными (в т.ч. с ограничениями проектирования или атрибутами качества).

Необходимо также отметить, что Features обладают определенным дуализмом в своей интерпретации, зависимым от контекста конкретного продукта - с одной стороны это может быть «тот самый список характеристик, указанный на коробке продукта» в случае создания «коробочного ПО», с другой стороны это может список высокоуровневых возможностей системы, например при заказной разработке ПО автоматизации бизнес-процессов конкретной организации.

Features могут быть разного уровня детализации - от выражения высокоуровневых возможностей системы (например, «Расчет заработной платы ...»), до достаточно конкретных требований (например, «Автоматическое уведомление Клиента по e-mail о резервировании товара на складе»)

1.4 Независимые свойства (Emergent Properties) - эти свойства обозначают требования, которые адресованы к системе в целом, и не могут быть соотнесены с отдельнымы ее элементами. Т.е. данные требования относятся к тому синергетическому эффекту, которым может обладать такая система («целое больше, чем сумма его частей»). Примером может служить требования к «пропускной способности» коллцентра, которая будут зависеть от того, каким образом будут взаимодействовать коммуникационное оборудование, оператор и программное обеспечение в конкретных условиях.

1.5 Требования с количественной оценкой (Quantifiable Requirements) - требования, поддающиеся количественному определению/измерению, например, система должна обеспечить пропускную способность “столько-то запросов в секунду”; в то же самое время, крайне важно понимать, что постановка вопроса (то есть формулирование требования) в форме “система должна обеспечить рост пропускной способности” без указания конкретных количественных характеристик является просто некорректно определенным требованием.

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

- системного администратора, привыкшего работать в kshell (популярной командной оболочке Unix/Linux), объясняющего свои потребности аналитику, фиксирующему запросы пользователя и привыкшего оперировать Microsoft Office ;) Может ли такое требование быть переформулировано и/или детализировано для адекватности интерпретации? Да. Например, так - средний показатель ошибок оператора не должен превышать 2% от объема вводимой информации и 85% пользователей должны дать положительную оценку прототипу пользовательского интерфейса на этапе опытной эксплуатации.

Такие требования должны однозначно отвечать на вопросы, предполагающие ответы с численными величинами - как часто? насколько быстро? в каком количестве? и т.п.

Большинство требований с количественной оценкой относится к атрибутам качества.

В качестве примера можно привести реальное требование, присутствующее в реальном проекте по электронному документообороту: “Система должна производить поиск документов <определенного вида> за время, не превышающее 5 секунд”. Это типичное требование с количественной оценкой, в котором определена верхняя граница диапазона времени, за которое должен быть осуществлен поиск документов. Несомненно, этот атрибут качества системы существует в контексте

определенного функционального требования о возможности поиска документов по определенным критериям. И этот контекст или связь должна быть определена либо явно, в рамках иерархии требований, либо посредством трассировки, между требованиями разных видов (функционального и атрибута качества). Примечательно, что Вигерс в своей книге выделяет требования по производительности системы в отдельный вид требований, тем не менее входящих в понятие нефункциональных требований или атрибутов качества.

1.6 Системные требования и программные требования (System Requirements and Software Requirements) - данное разделение базируется на определении “системы”, данном INCOSE (International Council on Systems Engineering) “комбинация взаимодействующих элементов <созданная> для достижения определенных целей; может включать аппаратные средства, программное обеспечение, встроенное ПО, другие средства, людей, информацию, техники (подходы), службы и другие поддерживающие элементы”; таким образом, подразумевается, что система является более ёмким понятием, чем программное обеспечения и включает окружение, в котором функционирует ПО, как таковое; отсюда, естественным образом, вытекают требования к системе в целом и программному обеспечению (или программной системе), в частности. Часто в литературе по управлению требованиями встречается описание системных требований как “пользовательских требований” (user requirements), SWEBOK ограничивает применение понятия “пользовательское требование” требованиями к системе конечных пользователей/заказчиков. Системные требования по SWEBOK, в свою очередь, окружают пользовательские требования (или требования других заинтересованных лиц - stakeholders, например, регулирование полномочий) без указания идентифицируемого источника-человека.

2. Процесс работы с требованиями (Requirements Process)

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

Цель данной темы, в соответствии с SWEBOK, дать понимание того, что такое процесс работы с требованиями, как таковой. В русском языке также устойчиво используется его название как “процесс определения требований”. мы его будем использовать взаимозаменяемым образом, подразумевая весь процесс работы с требованиями по SWEBOK.

Что ж, рассмотрим структуру декомпозиции тем процесса работы с требованиями:

2.1 Модель процесса определения требований:

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

• Идентифицирует программные требования как элементы конфигурации (в терминах конфигурационного обеспечения) и контролирует их с использованием тех же практик конфигурационного управления, что и для других активов программных проектов (например, файлов или запросов на изменения).

• Требует адаптации к проектному и/или организационному контексту, в рамках которого ведется соответствующий программный проект.

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

связанных с ними ролей и непосредственных результатов (их часто называют “артефактами”, например, в 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)

Эта тема затрагивает вопросы распределения ресурсов, необходимых для осуществления проектной деятельности, устанавливая контекст для первой секции “Инициация и определение содержания” (Initiation and Scope Definition) области знаний “Управление в программной инженерии” (Software Engineering Management). Основная цель данной темы - обеспечение связи между процессами и деятельностью, определенными в 2.1 “модели процесса определения требований” и вопросами использования проектных ресурсов - стоимостью, человеческими ресурсами, инструментами и т.п.

2.4 Качество и улучшение процессов (Process Quality and Improvement)

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

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

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

Данная тема тесно связана с областями знаний “Качество программного обеспечения” (Software Quality) и “Процесс программной инженерии” (Software Engineering Process). В этом контексте, фокусы обсуждаемой темы - определение атрибутов и метрик качества, а также определение соответствующих процессов в применении к программным требованиям, которые можно свести в три группы практик:

• Покрытие процессов работы с требованиями с точки зрения стандартов и моделей улучшения процессов, в целом;

• Измерение и количественная оценка (benchmarking) процессов работы с требованиями;

• Планирование и реализация процесса улучшения, как такового.

3. Извлечение требований (Requirements Elicitation)

Данная секция освещает вопросы сбора требований как с точки зрения организации процесса, так и определения источников, откуда поступают требования. Это первая стадия построения видения автоматизируемой проблемной области. Идентификация заинтересованных лиц, их взаимодействия, выполняемых ими бизнес-процессов - все это является ключевыми вопросами, без четкого и однозначного ответа на которые даже не стоит думать об успешности проекта (кстати, не только программного...).

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

3.1 Источники требований (Requirement Sources)

Необходимо идентифицировать все возможные источники требований, значимые для решения задач проекта. Только после этого можно определить их влияние на проект. Данная тема касается вопросов понимания информированности источников требований и их значимости.

Данная тема фокусируется на:

• Целях

• Знании предметной области

• Заинтересованных лицах

• Операционном окружении

• Организационной среде

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

3.2 Техники извлечения требований (Elicitation Techniques)

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

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

• Интервьюрирование - традиционный подход извлечения требований; не стоит забывать, что получение информации от пользователя “не равно” получению требований; информация должна быть проанализирована и трансформирована в требования, таким образом, информация от пользователя является “входом” в процессы сбора требований, а сами требования - “выходом” этих процессов;

• Сценарии - контекст для сбора пользовательских требований, определяющий ответы на вопросы “что если” и “как это делается” в отношении бизнес-процессов, реализуемых пользователями;

• Прототипы - отличный инструмент для уточнения и/или детализации требований; существуют разные подходы к прототипированию - от “бумажных” моделей до пилотных подсистем, реализуемых как самостоятельные (в терминах управления ресурсами) проекты или бета-версии продуктов; часто прототипы постепенно трансформируются в результаты проекта и используются для проверки и утверждения требований;


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

• Наблюдение (observation) - подразумевает непосредственное присутствие аналитиков и инженеров рядом с пользователем в процессе выполнения последним его работ по обеспечению функционирования бизнес-процессов: в определенной степени можно провести аналогию с практикой присутствия представителя заказчика в проектной группе исполнителя ( типовая практика в eXtreme Programming “on-site customer” - “присутствующий заказчик”); данная техника является достаточно затратной, но, в то же время, очень эффективной, а иногда - просто незаменимой, особенно, если речь идет о достаточно сложных и взаимосвязанных бизнес-процессах;

Существуют и другие, достаточно эффективные практики, описание которых можно найти в литературе и которые вы, наверняка, сами используете в своей работе (например, Requirements Workshop, Role Playing, Storyobarding и т.п.). Некоторые из них будут также упоминаться в контексте конкретных методологий.

4. Анализ требований (Requirements Analysis)

Эта секция посвящена процессам анализа требований, то есть трансформации информации, полученной от пользователей (и других заинтересованных лиц) в четко и однозначно определенные требования, передаваемые инженерам для реализации в программном коде.

Анализ требований включает:

• Обнаружение и разрешение конфликтов между требованиями;

• Определение границ задачи, решаемой создаваемым программным обеспечением; в общем случае - определение “scope” (или “bounds”), границ и содержания программного проекта;

• Детализация системных требований для установления программных требований;

Практически всегда, хотя это явно и не отмечено в описании анализа требований как секции SWEBOK, на практике выделяется и детализация бизнес-требований для установления программных требований. Например, пресловутый режим работы 2 4x7, сформулированный в виде бизнес-требования, накладывает достаточно жесткие рамки на выбор технологической платформы и архитектурных решений как технических требований к разрабатываемой программной системе..

SWEBOK отмечает, что традиционный взгляд на анализ требований часто сфокусирован или уменьшен до вопросов концептуального моделирования с использованием соответствующих аналитических методов, одним из которых является SADT - Structured Analysis and Design Technique (методология структурного анализа и техники проектирования), знакомый многим по нотациям IDEF0 (функциональное моделирование - стандарт IEEE 1320.1), IDEF1X (информационное моделирование - стандарт IEEE 1320.2, известный также как IDEFObject), часто применяемым как для моделирования бизнес-процессов, так и структур данных, в частности - реляционных баз данных.

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

4.1 Классификация требований (Requirements Classification)

Требования могут классифицироваться по целому ряду параметров, например:

• Функциональные и нефункциональные требования

• Внутренние (с другими требованиями) или внешние зависимости

• Требования к процессу или продукту


• Приоритет требований

• Содержание требований в отношении конкретных подсистем создаваемого программного обеспечения

• Изменяемость/стабильность требований

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

4.2 Концептуальное моделирование (Conceptual Modeling)

Разработка модели проблемы реального мира - ключевой элемент анализа требований. Цель моделирования - понимание проблемы, задачи и методов их решения до того, как начнется решение проблемы.

Часто приходится слышать, что прагматичность подхода в отношении программных проектов заключается в “пропуске” этапа (или стадии, фазы) моделирования. В свою очередь, часто ставят знак равенства между моделированием и “этими красивыми квадратиками со стрелочками”. Ни то, ни другое утверждение неверны. Например, в XP и в других гибких (Agile) практиках существуют и истории пользователей, и карточки задач, и процедуры анализа (в частности, связанных с ними “мозговых штурмов”, как запланированных, так и, к сожалению, не очень) , в результате которого мы сформулировали задачи, высокоуровневые возможности - “фичи” продукта (feature - особенность), а также необходимые модели (см. [Амблер, 2002]). Объем моделей, их детализация и средства представления могут быть различны. Их выбор базируется и/или диктуется конкретным культурным контекстом организаций, вовлеченных в проект, и практик, применяемых проектной группой. Именно не форма, но сама идея моделирования как попытка упростить и однозначно интерпретировать на концептуальном уровне проблематику деятельности в реальном мире - обязательная составляющая как управления требованиями, так и программной инженерии, в целом.



<== предыдущая лекция | следующая лекция ==>
Синицын И.В., Терновсков В.Б. 1 страница | Синицын И.В., Терновсков В.Б. 3 страница


Карта сайта Карта сайта укр


Уроки php mysql Программирование

Онлайн система счисления Калькулятор онлайн обычный Инженерный калькулятор онлайн Замена русских букв на английские для вебмастеров Замена русских букв на английские

Аппаратное и программное обеспечение Графика и компьютерная сфера Интегрированная геоинформационная система Интернет Компьютер Комплектующие компьютера Лекции Методы и средства измерений неэлектрических величин Обслуживание компьютерных и периферийных устройств Операционные системы Параллельное программирование Проектирование электронных средств Периферийные устройства Полезные ресурсы для программистов Программы для программистов Статьи для программистов Cтруктура и организация данных


 


Не нашли то, что искали? Google вам в помощь!

 
 

© life-prog.ru При использовании материалов прямая ссылка на сайт обязательна.

Генерация страницы за: 0.009 сек.