Общий процесс разработки требований

Глава 2 - Общий процесс разработки требований - описывает общий подход к разработке требований, применяющийся на всех этапах разработки системы. Хотя этот подход и поможет читателям получить хорошее понимание сущности процесса разработки требований, он, тем не менее, остается достаточно абстрактным. В главах 5 и 6 общий процесс описан более детально, с помощью примеров, применительно к пользовательским и системным требованиям.  [c.23]


Глава 2 - Общий процесс разработки требований  [c.24]

Общий процесс разработки требований  [c.25]

Описанный процесс разработки также показывает, что разработка системы происходит на разных уровнях, и что на каждом из них выполняются различные действия. Так рис. 2.1 демонстрирует, что процесс разработки на каждом уровне поддерживается моделями (модель использования, абстрактная модель, архитектурные модели), но природа моделей на каждом из уровней существенно отличается. Это пример распространенного подхода -на каждом уровне разработки используется своя модель. Последующие разделы данной главы описывают другие общие идеи, на которых базируется общий процесс разработки требований.  [c.28]

Информационная модель общего процесса разработки требований  [c.35]

В этой главе мы рассмотрели общий процесс разработки требований, который одновременно применяется на каждом уровне разработки системы. Основным преимуществом общего процесса является то, что он определяет общие действия, характерные для каждого уровня  [c.48]


После того, как выше мы определили все ключевые моменты, у нас появляется возможность проиллюстрировать основной (общий) процесс разработки требований из области проблем.  [c.105]

В книге уделяется особое внимание тому, как писать хорошие требования. Как основа для более глубокого понимания сути процесса разработки требований, в книге вводиться понятие общего процесса разработки требований. Применение общего процесса рассматривается затем отдельно для области проблем и для области решений.  [c.234]

Этот вопрос будет рассмотрен подробнее в Главе 2 по ходу введения в общий процесс разработки. Рис. 1.3 демонстрирует цель работы с требованиями на каждом уровне.  [c.9]

На рис. 2.2. представлен иной взгляд на процесс разработки требований. Диаграмма демонстрирует, что один и тот же процесс - процесс разработки требований -применяется на каждом уровне, хотя ранее были описаны различия в работе на разных уровнях процесса разработки системы. Такой странный, на первый взгляд, подход описания процесса разработки всего лишь говорит о том факте, что существует много общего в работе, выполняемой на разных уровнях.  [c.28]

И хоть целью данной главы является описание таких вот общих аспектов и представление общего подхода к процессу разработки требований, тем не менее, описание процессов будет включать и различия в них, что даст более широкие возможности использования полученных знаний.  [c.28]

Прежде чем перейти к рассмотрению процессов, протекающих в рамках основного процесса разработки требований, было бы полезно рассмотреть общую информационную модель, которая поддерживает этот основной процесс.  [c.35]

В данной главе были рассмотрены общие свойства области решений и охарактеризован процесс разработки требований, используемый в этой области.  [c.153]


В заключительном разделе главы сформулированы некоторые общие подходы к управлению процессом разработки требований.  [c.183]

На мой взгляд, авторам удалось невероятно элегантно скомпоновать материал книги. В первой и второй главах излагаются основные идеи, которые развиваются на протяжении последующих глав. Нигде ранее я не встречал попыток выделить общие методы и подходы, применимые для разных этапов разработки систем. Введение в общий процесс разработки является краеугольным камнем книги, а метод расширенных связей выводит разработку требований на совершенно иной качественный уровень.  [c.232]

Процесс разработки и постановки целей, как и сам процесс управления в целом, в каждой компании организуется и реализуется по-разному. Вместе с тем имеются и общие требования к технологии целеполагания влияние установленных целей на рациональное поведение в организации взаимосвязи ценностей, целей и управленческих решений и др. Ценностные предпосылки являются предположениями о том, какие цели наиболее предпочтительны. Чем точнее и специфичнее обозначены ценностные предпосылки, тем эффективнее их воздействие на управленческие решения.  [c.61]

Технологический процессе создания АС (вторая часть общего процесса) частично должен выполняться в специализированных организациях, а в основном — в НТО, переходящей в условия функционирования АС. Участие специализированных в области создания АС организаций в данной части технологического процесса должно сводиться к исследованию возможности применения различных КСА для построения конкретных АС и выработке рекомендаций по структуре и составу работ, предшествующих началу функционирования АС, т. е. они формируют проект создания АС в конкретной НТО, используя имеющийся в этой области опыт и учитывая конкретные требования данной НТО. Разработка проекта и его сопровождение в конкретной АС могут рассматриваться как услуги специализированной организации и оцениваться по соответствующим прейскурантам.  [c.40]

Все крупные многоотраслевые корпорации обладают мощной сетью кооперационных связей с субпоставщиками. Например, в автомобилестроении Японии головные фирмы имеют прямые связи примерно с 200 подрядными фирмами, которые, в свою очередь, через систему последовательных субподрядов вовлекают в производственный процесс головной компании до 30 тыс. и более фирм разного размера. Общая тенденция - ужесточение требований корпораций к качеству продукции и техническому уровню производства субпоставщиков. Крупные корпорации нередко начинают подключать своих партнеров по связям не только к производству новой продукции, но и к участию в ее разработке. Характерно также, что головные корпорации стали поощрять развитие связей своих поставщиков с "третьими" компаниями, рассчитывая таким образом заставить их внимательнее следить за изменением требований рынка и более активно повышать конкурентоспособность своей продукции.  [c.171]

Качество УР — это степень соответствия УР внутренним требованиям (стандартам) организации. При разработке и реализации УР руководитель должен уделять внимание каждому этапу процесса разработки и реализации УР. Качество каждого этапа вносит существенный вклад в общую оценку качества всего УР. Качество измеряется в относительных единицах от 0 до 1. Низшему качеству УР присваивается значение 0, а высшему — 1. Общее качество УР вычисляется как произведение значений качеств всех составляющих этапов, стадий и операций, выполняющихся последовательно. Допустим, при разработке УР было выполнено 10 операций со следующими значениями качеств 0,8 0,9 0,7 0,8 0,7 0,8 0,8 0,9 0,7 и 0,8. Значение качества каждой операции само по себе хорошее, но общее качество УР будет равно 0,091 Это очень низкий уровень. Поэтому только при профессиональном отношении ко всем составляющим процесса разработки и реализации УР можно обеспечить приемлемое качество всего УР.  [c.236]

В данном разделе мы дали краткое описание программного пакета DOORS, предназначенного для управления требованиями. Примеры, приводимые в данной главе, демонстрировали нам использование тех принципов, которые ранее излагались в этой книге общий процесс разработки требований и метод расширенных связей.  [c.224]

При разработке содержания операций следует руководствоваться такими стандартами ГОСТ 14.301—73 Общие правила разработки технологических процессов и выбора средств технологического оснащения ГОСТ 14.303—73 Правила разработки и применения типовых технологических процессов ГОСТ 3.1104—74 ЕСТД Общие требования к документам ГОСТ 2.105—68 ЕСКД Общие требования к текстовым документам .. Как правило, в картах все допуски нужно проставлять в открытой форме. Закрытые допуски рекомендуется указывать только при условии обеспечения контроля размеров измерительными инструментами, на которых обозначен соответствующий символ закрытого допуска.  [c.77]

Внедрение международных стандартов финансовой отчетности в России началось еще в 1992 году. Тогда была принята Государственная программа перехода России на систему учета и статистики в соответствии с требованиями развития рыночной экономики. Изменение системы общественных отношений, а также гражданско-правовой среды предопределяет необходимость адекватной трансформации бухгалтерского учета. Однако процесс реформирования отечественной системы бухгалтерского учета отстает от общего процесса экономических реформ в России. Именно в целях изменения такого положения дел разработана Программа реформирования бухгалтерского учета в соответствии с международными стандартами финансовой отчетности. Программа реформирования бухгалтерского учета в соответствии с международными стандартами финансовой отчетности была утверждена постановлением Правительства РФ от б марта 1998 г. № 283. Основным направлением данной программы стало принятие Правительственной программы реформирования бухгалтерского учета в соответствии с МСФО и в разработке концепции бухгалтерского учета в рыночной экономике России. Все это стало важным шагом на пути совершенствования бухгалтерского учета в России.  [c.6]

Разработка По достаточно сложный процесс и его поэтапное выполнение не всегда возможно. Появление новых требований в процессе разработки учитывается при планировании проекта в несколько итераций с использованием языка моделирования UML (Unified Modeling Language —унифицированный язык моделирования). Это визуальный язык моделирования общего назначения, который используется для спецификации, визуализации, конструирования и документирования программных систем. При этом проходится 4 фазы проекта начальная фаза, уточнение, конструирование и ввод в действие.  [c.37]

Смотреть страницы где упоминается термин Общий процесс разработки требований

: [c.105]