ГОСТ Р ИСО-МЭК 12207-2010 Процессы ЖЦ ПС. Процессы жизненного цикла программных средств
 Скачать 457.34 Kb.
|
|
виды процессов с целью организовать процессы, виды деятельности и задачи, отобранные из ИСО/МЭК 12207 или ИСО/МЭК 15288, и сфокусировать их на объекте внимания способом, который охватывает весь или части жизненного цикла. В данном приложении рассматривается точка зрения на процесс, которую можно использовать для определения видов процессов в упомянутых выше примерах. Е.2 Определения Вид: представление системы как целого исходя из рассмотрения связной совокупности объектов, представляющих интерес*. _______________ * Цитировано из проекта ИСО/МЭК 42010 Системная и программная инженерия - Архитектурное описание (Systems and software engineering - Architectural description), разрабатываемого на базе IEEE P42010/D1 (примеч. переводчика). Примечание - В данном определении, но не в остальной части приложения, "система" представляет собой совокупность процессов жизненного цикла, приведенных в ИСО/МЭК 15288 и в настоящем стандарте. Точка зрения: спецификация соглашений для конструирования и применения вида. Образец или шаблон точки зрения предназначен для разработки отдельных видов посредством установления целей и аудиторий для вида, а также технических приемов его создания и анализа [ИСО/МЭК 42010]. Е.3 Понятие "вид процесса" Могут существовать случаи, когда необходимо сконцентрироваться на видах деятельности и задачах, выбранных из несоизмеримых процессов, для обеспечения видения существенных концепций или угроз, которые присутствуют в применяемых процессах в пределах жизненного цикла. Полезно посоветовать пользователям стандартов, каким образом идентифицировать и определить эти виды деятельности для их применения, даже если они не могут выделить единственный процесс для объекта своих специфических интересов. Для этой цели сформулировано понятие "вид процесса". Подобно любому процессу описание вида процесса включает в себя формулировку цели и выходов. В отличие от процесса описание вида процесса не включает в себя виды деятельности и задачи. Вместо этого описание содержит руководство, поясняющее, как выходы могут быть получены путем применения видов деятельности и задач из различных процессов, представленных в настоящем стандарте и [18]. Виды процессов могут быть сконструированы с использованием шаблона точки зрения на процесс, приведенного в Е.3.1. Е.3.1 Точка зрения на процесс Вид процесса согласуется с точкой зрения на процесс. Точка зрения на процесс, представленная здесь, может использоваться для создания видов процессов. Пример применения точки зрения на процесс приведен в Е.4. Точка зрения на процесс определяется: - правообладателями и пользователями стандарта; - объектами внимания, порождающими процессы, необходимые для отражения частных инженерных интересов; - содержанием результирующих видов процессов, в которое следует включать: наименование вида процесса, цель вида процесса, выходы вида процесса, идентификацию и описание процессов, видов деятельности и задач, реализующих вид процесса, ссылки на источники этих процессов, виды деятельности, задачи и другие стандарты. Примечание - Требования к документированию точек зрения изложены в ИСО/МЭК 42010:2007 Системная и программная инженерия. Рекомендованная практика архитектурного описания систем, широко использующих программные средства (ISO/IEC 42010:2007 "Systems and software engineering - Recommended practice for architectural description of software-intensive systems"). Приведенное описание согласуется с этими требованиями. Е.4 Вид процесса, характеризующего приспособленность к применению В данном разделе приведен пример использования точки зрения на процесс с целью привести вид процесса, ориентированного на приспособленность к применению. Пример предназначен для иллюстрации того, как в проекте можно объединить процессы, виды деятельности и задачи из настоящего стандарта для концентрации внимания на достижении приспособленности продукта к применению по назначению. В этом примере представлен кластер интересов, называемых обычно "приспособленностью, удобством применения", "ориентированным на пользователя проектированием" или "ориентированным на человека проектированием", как описано в [7], что дает возможность оптимизировать поддержку и обучение, обеспечить рост производительности и качества работы, улучшить условия работы людей и снизить шансы непринятия системы пользователями. Наименование: вид процесса, характеризующего приспособленность к применению. Цель: целью вида процесса для приспособленности к применению является гарантия рассмотрения интересов и потребностей правообладателей для предоставления возможности оптимизации поддержки и обучения, роста производительности и качества работы, улучшения условий работы и снижения шансов непринятия системы пользователем. В результате успешной реализации вида процесса, ориентированного на приспособленность к применению: 1) система удовлетворяет потребности пользователей, учитывает способности людей и ограничения по навыкам; 2) человеческий фактор, эргономические знания и технические приемы учитываются в системном проекте; 3) идентифицируется и выполняется деятельность по проектированию, ориентированная на человека; 4) при проектировании системы учитываются возможные негативные воздействия системы на здоровье, безопасность и рабочие характеристики людей; 5) системы будут обладать улучшенными показателями результативности, эффективности и удовлетворенности пользователей. Примечание - Хотя совершенствование пользователей является принципом ориентированного на человека проектирования, но в результате может оказаться, что желаемые характеристики не могут быть непосредственно измерены, а вместо этого могут быть обсуждены и выведены характеристики, основанные на других продуктах или процессах, которые могут быть измерены. Процессы, виды деятельности и задачи Рассматриваемый вид процесса может быть реализован с использованием следующих процессов, видов деятельности и задач, представленных в настоящем стандарте: h) процесс менеджмента портфеля проектов (см. 6.2.3), в частности процесс инициации процессов (см. 6.2.3.3.1), предусматривает установление и обслуживание направления на проблемы пользователя в подразделениях организации, имеющей дело с рынками, концепцией, разработкой и поддержкой, обеспечивающего ориентированный на человека подход; i) процесс менеджмента инфраструктуры (см. 6.2.2) представляет спецификацию того, каким образом деятельность, ориентированная на человека при проектировании, соответствует процессу жизненного цикла всей системы и организации; j) процесс планирования проекта (см. 6.3.1) используется для: выбора методов и технических приемов, ориентированных на человека, планирования совершенствования пользователей и правообладателей, планирования ориентированной на человека деятельности при проектировании; k) процесс оценки и управления проектом (см. 6.3.2) используется для мониторинга степени достижения требований и доведения результатов до правообладателей и менеджеров, гарантируя ориентированный на человека подход в проектной команде. Соответствующие задачи включают в себя 6.3.2.3.3.1 и 6.3.2.3.3.2; I) процесс определения требований правообладателя (см. 6.4.1) используется для идентификации и документирования содержания применения и взаимодействия между пользователями и системой, принимая в расчет способности человека и ограничения по навыкам, а также спецификации по вопросам здоровья, безопасности, защищенности, окружающей среды, обученности, поддержки и других требований и функций правообладателей, направленных на предотвращение возможных негативных воздействий системы на здоровье и безопасность человека. Примечание - Там, где возможно, используются общепризнанные профессиональные достижения практики (см., например, [7] и [12]); m) процесс анализа системных требований (см. 6.4.2) используется для спецификации и оценки содержания использования, требований к приспособленности к применению и проектных требований, ориентированных на человека; n) процесс архитектурного проектирования системы (см. 6.4.3) используется для включения критериев проектирования, нацеленных на задание требований к приспособленности к работе и эргономике; о) процесс комплексирования системы (см. 6.4.5) применяется для планирования работ по комплектованию, включая рассмотрение вопросов обучения пользователей и обеспечения гарантий проверки и регистрации выполнения заданий для требований к приспособленности и эргономике; р) процесс менеджмента информации (см. 6.3.6) применяется в общем случае для спецификации, разработки и сопровождения артефактов при документировании и обмене сведениями о степени достижений. Применительно к приспособленности к применению этот процесс детализируется в [30] и связанных с ним будущих стандартах той же серии; q) процесс измерений (см. 6.3.7) применяется в общем случае для определения подхода, который соотносит единицы и показатели измерений с желаемыми характеристиками. Применительно к программным средствам эти вопросы детально изложены в ИСО/МЭК 25020 Программная инженерия. Требования и оценка качества программных продуктов. Эталонная модель измерений и руководство (ISO/IEC 25020 "Software engineering - Software product Quality Requirements and Evaluation (SQuaRE) - Measurement reference model and guide"); r) процесс анализа требований к программным средствам (см. 7.1.2) используется для спецификации требований к приспособленности и эргономике программных средств. Соответствующая задача представлена в 7.1.2.3.1.1, перечисление f и примечание 3; s) процесс функционирования программных средств (см. 6.4.9) предназначен для использования системы. Для гарантии достижения требования к приспособленности к применению используется мониторинг функционирования системы. Соответствующие задачи включают в себя 6.4.9.3.3.1, примечание 2, 6.4.9.3.4.1 и 6.4.9.3.5.1; t) процесс сопровождения программных средств (см. 6.4.10) поддерживает возможности системы, включая в себя свойства ее приспособленности, и может быть использован полностью. Приложение F (справочное). Некоторые примеры описания процессов Приложение F (справочное) В настоящем приложении представлены примеры процессов, которые считаются весьма полезными для некоторых пользователей настоящего стандарта. Эти процессы могли бы учитываться в документации, описывающей организационные процессы пользователей. F.1 Процесс организационной настройки F.1.1 Цель Цель организационной настройки заключается в том, чтобы реализовать процессы программных средств, необходимые для поставки продуктов и услуг в соответствии с целями деловой деятельности организации. F.1.2 Выходы В результате успешного осуществления процесса организационной настройки: 1) идентифицируются конечные цели деловой деятельности организации; 2) идентифицируется и определяется структура работы, которая включает в себя совокупность программных процессов, необходимых для достижения деловых целей организации; 3) формируется стратегия определения, выполнения и совершенствования процессов; 4) обеспечивается поддержка реализации этой стратегии; 5) до сведения всего штатного персонала доводится назначение, базовые ценности, перспективы, текущие и конечные цели организации; 6) сотрудники организации разделяют общее видение, культуру и понимание целей деловой деятельности, что позволяет им эффективно выполнять свои функции; 7) каждый сотрудник организации понимает свою роль в достижении конечных целей деловой деятельности и способен выполнить эту роль. F.2 Процесс менеджмента организации F.2.1 Цель Цель менеджмента организации заключается в установлении и выполнении практических приемов менеджмента программных средств в ходе реализации процессов, необходимых для обеспечения программных продуктов и услуг согласно деловым целям организации. Примечание - Хотя организационные действия в общем случае имеют намного более обширную область применения, чем для программных процессов, программные процессы выполняются в контексте деловой деятельности и, чтобы быть эффективными, требуют соответствующей организационной среды. F.2.2 Выходы В результате успешного осуществления менеджмента организации: 1) организация будет осуществлять инвестиции в соответствующую инфраструктуру менеджмента; 2) идентифицируются лучшие достижения практики для поддержки выполнения эффективного менеджмента организации и проектов; 3) обеспечивается базис для оценки достижения деловых целей организации, основанный на этих лучших достижениях практики. F.3 Процесс менеджмента изменений в контракте F.3.1 Цель Цель процесса менеджмента изменений в контракте заключается в разработке нового текста контракта по обоюдному согласию приобретающей стороны и поставщика, когда предлагается заявка на изменение, оказывающая влияние на согласованное содержание контракта. Этот процесс начинается с предложения заявки на изменение приобретающей стороной либо поставщиком и оканчивается заключением, приемлемым для обеих сторон, отклонением или принятием в целом (частично) заявки на изменение. F.3.2 Выходы В результате успешного осуществления процесса менеджмента изменений в контракте: a) открыто и официально предлагается запрос на изменение контракта; b) устанавливаются роли и обязанности как приобретающей стороны, так и поставщика для менеджмента изменений в контракте; c) оценивается воздействие заявки на изменение в контракте на проектные планы, затраты, выгоду, качество и графики работ; d) предпринимаются действия по заявке на изменения для получения согласия и удовлетворения как приобретающей стороны, так и поставщика; e) результат каждой заявки на изменение становится известным всем участвующим сторонам. F.3.3 Виды деятельности и задачи Приобретающая сторона и поставщик должны осуществлять следующие виды деятельности в соответствии с применяемыми в организации политиками и процедурами в отношении процесса менеджмента изменений в контракте. F.3.3.1 Подготовка процесса Данный вид деятельности состоит из решения следующих задач: F.3.3.1.1 Приобретающая сторона и поставщик должны согласиться вести переговоры по поводу любых изменений в контракте в консультативном органе и отразить этот порядок в контракте. Они должны учредить консультативный орган прежде, чем начнутся основные работы. F.3.3.1.2 Приобретающая сторона и поставщик должны определить и документировать процедуру осуществления менеджмента изменений в контракте. F.3.3.2 Заявка на изменение в контракте Данный вид деятельности состоит из решения следующей задачи: F.3.3.2.1 В требовании на изменения в контракте, относящемся к составной части базовой линии, приобретающая сторона или поставщик должны документировать спецификации, причины и исходные данные и давать пояснения другим заинтересованным сторонам. В процессе изменения контракта поставщик доложен документировать и давать пояснения приобретающей стороне по вопросам, оказывающим влияние на проектные планы, затраты, выгоду, качество и графики работ. F.3.3.3 Исследование и анализ влияния изменений Данный вид деятельности состоит из решения следующей задачи: F.3.3.3.1 В случае заявки приобретающей стороны на изменение в контракте поставщик должен исследовать влияние этого изменения на проектные планы, затраты, выгоду, качество и графики работ, а затем документировать полученные результаты и дать соответствующие пояснения приобретающей стороне. В пояснении поставщику следует представить четкие обоснования. F.3.3.4 Переговоры и соглашения Данный вид деятельности состоит из решения следующих задач: F.3.3.4.1 При ведении переговоров приобретающая сторона и поставщик должны приходить к наиболее приемлемым заключениям через рассмотрение содержания изменений, их причин и исходных данных так же, как и их воздействий на проектные планы, затраты, выгоду, качество и графики работ. F.3.3.4.2 Приобретающая сторона и поставщик, особенно при согласовании затрат, должны выносить проблему на более высокий уровень руководства для соответствующего соглашения или решения. F.3.3.5 Модификация контракта Данный вид деятельности состоит из решения следующих задач: F.3.3.5.1 Приобретающая сторона и поставщик должны документировать взаимное соглашение и подтверждать его. Приобретающая сторона и поставщик должны немедленно модифицировать оригинал контракта и заключить пересмотренный контракт, если такая модификация необходима. После этого приобретающая сторона и поставщик должны осуществлять менеджмент содержания контракта как части управления изменениями. F.3.3.5.2 При любой модификации контракта составные части конфигурации, на которые она оказала воздействие, должны быть зафиксированы в базовой линии. Эта процедура должна выполняться, используя процесс менеджмента конфигурации. F.3.3.5.3 Результат модификации контракта должен отражаться в проектных планах и доводиться до сведения всех участвующих сторон. Приложение G (справочное). Взаимосвязи с другими стандартами IEEE Приложение G (справочное) _______________ * IEEE - Институт инженеров по электротехнике и электронике США, разрабатывающий стандарты, признанные во всем мире. В частности, настоящий стандарт, идентичный IEEE Std 12207, был принят в качестве |