Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Пересмотры выделения ресурсов, пересмотры, и контрольные точки в жизненном цикле.

Вновь и вновь поднимается вопрос, что такое "пересмотры выделения ресурсов" -- текста самого ISO 15288 и поясняющих материалов явно не хватает для ответа на этот вопрос. Вот фрагмент из INCOSE SE Handbook v3.1 (кстати, следующая версия этого руководства выходит в феврале 2010, сейчас заканчивается проект по адаптации текста к ISO 15288:2008 -- и мы планируем затем перевод на русский. Так что нижеприведенный текст -- отнюдь не окончательный, но дорога ложка к обеду).
3.2.2 Decision Gates 3.2.2. Пересмотры выделения ресурсов 
 Decision gates, also known as control gates, are often called “Milestones” or “Reviews.” All decision gates are both reviews and milestones; however, not all reviews and milestones are decision gates. Decision gates address the following questions:
Пересмотры выделения ресурсов, также известные как контрольные пересмотры, часто называются "контрольными точками" или "пересмотрами". Все пересмотры выделения ресурсов являются одновременно пересмотрами и контрольными точками, хотя не все пересмотры и контрольные точки являются пересмотрами выделения ресурсов. Пересмотры выделения ресурсов отвечают на следующие вопросы:
• Does the project deliverable still satisfy the business case?
• Is it affordable?
• Can it be delivered when needed?
• Комплект поставки все еще соответствует организационной ситуации?
• Стоимость его приемлема?
• Может ли он быть поставлен тогда, когда он нужен?
Decision gates represent major decision points in the system life cycle. They ensure that new activities are not pursued until the previously scheduled activities, on which new ones depend, are satisfactorily completed and placed under coniguration control. Пересмотры выделения ресурсов представляют главные точки принятия решения в жизненном цикле системы. Они обеспечивают, что новые мероприятия не делаются, пока ранее запланированные мероприятия, от которых зависят новые, не будут удовлетворительно закончены и поставлены под управление конфигурацией.
The primary objectives of decision gates are to:Главные задачи пересмотров выделения ресурсов:
• Ensure that the elaboration of the business and technical baselines are acceptable and will lead to satisfactory verification and validation.
• Ensure that the risk of proceeding to the next step is acceptable.
• Continue to foster buyer and seller teamwork.
• Обеспечить, что последующая доработка организационных и технических базисов приемлема и приведет к удовлетворительной верификации валидации.
• Обеспечить, что риск перехода на следующую стадию приемлем.
• Продолижть стимулирование командной работы поставщика и заказчика.
Decision gate approval follows review by qualiied experts and involved stakeholders and is based on hard evidence of compliance to the criteria of the review. Detailed information about the decision gate activity is provided in chapter 7.1.Утверждение [решений] пересмотра выделения ресурсов следует за [техническим] пересмотром квалифицированными экспертами и вовлеченными [в проект] заинтересованными лицами, и основывается на строгом доказательстве соответствия критериям пересмотра. Детальная информация по мероприятиям пересмотра выделения ресурсов дается в главе 7.1
There are at least two decision gates in any project: authority to proceed and initial acceptance of the project deliverable. The project team needs to decide which life cycle stages are appropriate for their project and which decision gates beyond the basic two are needed. Each decision must have a beneficial purpose; “pro-forma” reviews waste everyone’s time. Even in agile development frequent interaction with the customer may minimize, but not eliminate, the need for decision gates. The consequences of conducting a superficial review, omitting a critical discipline, or skipping a decision gate altogether are usually long-term and costly.Существует как минимум два пересмотра выделения ресурсов в любом проекте: полномочия выполнять проект и начальная приемка комплекта поставки проекта. Команде проекта нужно решение, какие стадии жизненного цикла подходят для их проекта, и какие нужны пересмотры выделения ресурсов, кроме базовых двух. Каждое решение должно иметь выгодное назначение; "формальный" пересмотр -- это просто трата времени каждого [участника]. Проведение поверхностного пересмотра, опускающего необходимые дисциплины, или вообще пропуск пересмотра выделения ресурсов обычно ведет к долгосрочным и дорогостоящим последствиям.
......
7.1.1. Decision Gates7.1.1. Пересмотры выделения ресурсов
A decision gate is an approval event in the project cycle, suficiently important to be defined and included in the schedule by the project manager, executive management, or the customer. Entry and exit criteria are established for each gate at the time they are included into the project management baseline. Decision gates ensure that new activities are not pursued until the previously scheduled activities, on which new ones depend, are satisfactorily completed. Proceeding beyond the Decision Gate before the project is ready entails risk, as comically illustrated in Figure 7-1. The project manager may decide to accept that risk, as is done, for instance, with long-lead item procurement.Пересмотр выделения ресурсов -- это утверждающее событие в ходе проекта, достаточно важное, чтобы быть определенным и включенным в график менеджером проекта, менеджером организации или заказчиком. Для каждого пересмотра выделения ресурсов в момент их включения в базис проектного управления устанавливаются входные и выходные критерии. Пересмотры выделения ресурсов обеспечивают, что новые мероприятия не предпринимаются пока предыдущие мероприятия, от которых они зависят, не закончатся успешно. Продолжение работ после пересмотра выделения ресурсов до того, как проект будет готов, связано с риском, как иллюстрировано в комиксе на рис.7-1 [в комиксе менеджер требует от инженера приступать к проектированию до того, как будут известны требования, чтобы никто не подумал, что ничего не предпринимается. Инженер вместо проектирования начинает читать газету, и замечает, что ему особенно нравятся проекты, заранее обреченные на неудачу]. Менеджер проекта может решить принять этот риск, как это делается, например, с заказом длинноциклового оборудования.
The project business case issues of market demand, affordability, and realistic schedules are important decision criteria inluencing concept selection, and they should be updated and evaluated at every decision gate. Inadequate checks along the way can set up subsequent failures – usually a major factor in cost over-runs and delays. At each gate the decision options are:Такие вопросы организационной ситуации проекта, как рыночный спрос, приемлемость цены и реалистичные графики являются важными критериями принятия решения, влиящими на выбор концепции, и они должны обновляться и оцениваться во время каждого пересмотра выделения ресурсов. Неадекватные проверки в ходе работ могут заложить последующие провалы -- [они] обычно важный фактор в перерасходе средств и задержках. В каждом пересмотре выделения ресурсов выборы таковы: 
Acceptable: Proceed with the next stage of the project;
Or Acceptable with reservations: Proceed and respond to action items;
Unacceptable: Do not proceed; continue this stage and repeat the review when ready;
Unacceptable: Return to a preceding stage;
Unacceptable: Put a hold on project activity;
Unsalvageable: Terminate the project.

Приемлемо: переходить к следующей стадии проекта;
   Или Приемлемо с оговорками: переходить и выполнить затребованные действия;
Неприемлемо: не переходить; продолжать эту стадию и повторить пересмотр, когда будет готовность;
Неприемлемо: Вернуться на предыдущую стадию;
Неприемлемо: заморозить мероприятия проекта;
Невосстановимо: закрыть проект.

Upon successful completion of a decision gate, some artifacts (documents, models, or other products of a project cycle stage) have been approved as the basis upon which future work must build. If the project is large or long enough, or entails high risk, these artifacts are placed under coniguration management.После успешного завершения пересмотра выделения ресурсов в качестве базиса, на котором должна строиться будущая работа утверждаются некоторые артефакты (документы, модели, или другие продукты стадии жизненного цикла). Если проект большой, или достаточно долгий, или подразумевает высокий риск, эти артефакты подлежат управлению конфигурацией.
Decision gate descriptions should identify the:
• Purpose of the decision gate
• Host and chairperson
• Attendees
• Location
• Agenda and how the decision gate is to be conducted
• Evidence to be evaluated
• Actions
• Method of closing the review
Описания пересмотра выделения ресурсов должны определять:
• Назначение пересмотра выделения ресурсов
• Организатора и личность руководителя
• Участников
• Место
• Повестку дня и как будет этот пересмотр выделения ресурсов проводиться
• Доказательства, которые будут оценены
• Действия
• Способ завершения пересмотра
Decision gate approval must involve the necessary disciplines and stakeholders and must be based on hard evidence of compliance. One of the underlying principles for the agile development and extreme programming movements is to substantially reduce (but not eliminate) the frequency and elaborate (and they would claim pro-forma) content of decision gates for software development. Balancing the formality and frequency of decision gates is seen as a critical success factor for all systems engineering process areas. On large or lengthy projects, decisions and their rationale are maintained using an information management process.Утверждение пересмотра выделения ресурсов должно включать необходимые дисциплины и заинтересованные стороны и должно быть основано на строгом доказательстве соответствия. Один из фундаментальных принципов движения гибкой разработки и экстремального программирования -- это существенно уменьшить (но не исключить совсем) частоту и проработанность (и они могут заявлять формальность) содержания пересмотра выделения ресурсов для разработки программных средств. Балансирование формальности и частоты пересмотров выделения ресурсов рассматривается как критический фактор успеха во всех областях практики системной инженерии. В больших или долгих проектах решения и их обоснования ведутся с использованием практики управления информацией.

Современный способ, каким происходит доказательство в момент пересмотра выделения ресурсов -- "оценочное дело" (ISO 15026, assurance case), но я от.

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

Осталось разобраться с пересмотрами и контрольными точками.

Контрольная точка -- понятие управления проектами (менеджерское понятие). Вот определения из словаря системной инженерии (http://pascal.computer.org/sev_display/index.action):

milestoneконтрольная точка
(1) a significant point or event in the project (A Guide to the Project Management Body of Knowledge (PMBOK® Guide) -- Fourth Edition)(1) Существенная точка или событие в проекте (Руководство к набору знаний по проектному управлению (Рукодвоство PMBOK®) --четвертое издание)
(2) a scheduled event used to measure progress. (IEEE 1058-1998 IEEE Standard for Software Project Management Plans, 3.3) Example: Major milestones for software projects may include an acquirer or managerial sign-off, baselining of a specification, completion of system integration, and product delivery. Minor milestones might include baselining of a software module or completion of a chapter of the user manual. (2) запланированное событие, используемое для измерения продвижения (IEEE 1058-1998 IEEE стандарт по планам управления проектами, 3.3)
Пример: Большие контрольные точки для проектов по разработке программных средств могут включать одобрения заказчика или менеджера, утверждение базиса спецификации, завершение интеграции системы и поставку продукта. Малые контрольные точки могут включать утверждение базиса программного модуля или завершение главы пользовательского руководства.
Видно, что в контрольных точках принимаются менеджерские решения, но не происходит технических пересмотров. Большие контрольные точки затрагивают весь проект, а маленькие -- только его часть.

review пересмотр 
 (1) a process or meeting during which a work product, or set of work products, is presented to project personnel, managers, users, customers, or other interested parties for comment or approval (ISO/IEC 24765:2009 Systems and software engineering vocabulary) (1) процесс или заседание, в ходе которого продукт работы или набор продуктов работы показывается персоналу проекта, менеджерам, пользователям, заказчикам или другим заинтересованным сторонам для комментирования или утверждения. (ISO/IEC 24765:2009 Словарь системной и программной инженерии)
 (2) a process or meeting during which a software product is presented to project personnel, managers, users, customers, user representatives, or other interested parties for comment or approval. (IEEE 1028-2008 IEEE Standard for Software Reviews and Audits, 3.5)  (2) (1) процесс или заседание, в ходе которого программный продукт показывается персоналу проекта, менеджерам, представителям пользователя или другим заинтересованным сторонам для комментирования или утверждения. (IEEE 1028-2008 IEEE Стандарт по пересмотрам и аудитам программного обеспечения)


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

Тем самым пересмотр выделения ресурсов -- это принятие менеджерских (т.е. выделение ресурсов!) решений по проекту в целом итогам технического пересмотра проекта в целом (и чаще всего этот технический пересмотр делается в формате "оценочного дела").
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 10 comments