Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Categories:

Практики и процессы

Начал большой апдейт PraxOS (http://praxos.ru/index.php/Служебная:Recentchanges).

Гланвя проблема сегодняшнего дня -- это различие между практиками и процессами.

Практики (технологии) -- это нормы действий, для которых результаты проверяемы, но не подразумевается передача этих результатов практик как материала для работы других процессов. Обычно ничего нельзя сказать про последовательность выполнения практик, и последовательность действий внутри самой практики -- они обычно "по потребности". Примеры: практики парного программирования в XP, расставления буферов в CCPM, управления качеством путем описания практик и процессов.

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

У практики обычно нет экземпляра, у процесса этот экземпляр=проект (который чаще всего указывается путем указания конкретной системы, идущей по "конвейеру" процесса -- "подписание договора номер 34", "сборка холодильника 567", "выдача справки 768") есть.

При моделировании практики с помощью формального языка возникают непреодолимые трудности. При моделировании процесса -- это элементарно, Ватсон.

Так вот: большинство "процессных стандартов" -- это описание практик, в которое подмешано очень небольшое количество процессов. И мне кажется, что "внедрить практики системной инженерии" много понятней и точней, чем "внедрить процессы системной инженерии". Если там и есть какие процессы, то это прежде всего процесс прохождения системы по стадиям жизненного цикла. Каждая реализация такого процесса для конкретной системы -- проект, в полном соответствии со стандартом. А вот сами life cycle processes из стандарта -- это как раз жизненноцикловые практики.

Стандарт, кстати, существенно путает "шаблон проекта" (т.е. процесс) и конкретный проект -- слово project там обозначает то одно, то другое (отходная их позиция понятна: ежели чего они процесс обзовут одним проектом, а границы интересующей системы определят как "система-совокупность всех систем").
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 1 comment