Интернет магазин китайских планшетных компьютеров

Компьютеры - Метод MoSCoW - Основа

Такое использование метода MoSCoW было впервые разработано Даем Клегом из Oracle UK Consulting; при ускорении метода CASE: подход RAD; хотя позже он передал права интеллектуальной собственности консорциуму методов разработки с помощью динамических систем).

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

Объяснение

Все требования важны, но среди них производят расстановку приоритетов для отбора тех, которые в наименьший срок принесут наибольшие выгоды. Сначала, разработчики попытаются выполнить требования M, S и C, но если временная шкала не соответствует темпам выполнения задачи, то наиболее приоритетным становится выполнение требований S и C. Назначение слов, из которых состоит акроним MoSCoW состоит в том, чтобы объяснить тем, кто использует этот метод, как надо расставлять приоритеты не так, как это делают обычно, например, деля задачи на высокий, средний и низкий уровни приоритета.

Должен сделать

требования обозначенный так должны быть включены в текущее расписание для того, чтобы задача была успешно выполнена. Если хотя бы одно требование этой категории не включено, проект можно считать проваленным. MUST может, также, рассматриваться, как сокращение слов: Minimum Usable SubseT, то есть минимальный набор параметров, позволяющий пользоваться сделанным.

Должен сделать это, если возможно

требования этой категории также критичны в выполнении для успешного исхода проекта, но не являются необходимыми для соблюдения текущего расписания. Требования SHOULD также важны как требования MUST, но чаще всего время их выполнения не является критичным параметром, или их можно удовлетворить обходными путями так, что их можно перенести в следующий пункт расписания.

Мог бы сделать, если не повлияет отрицательно на что-то другое

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

Вряд ли удастся

такие требования и не обязательны и от них меньше всего отдачи, или просто не нужны в данный момент. В итоге, эти требования не вносятся в расписание для выполнения. Они откладываются до рассмотрения их возможного включения в последующие пункты расписания. Это, тем не менее, не делает их менее значимыми. Часто про них можно сказать: «Хотелось бы иметь» в будущем. Это вкладывает в категорию WON’T неоднозначность в плане ее сравнения с приоритетностью других категорий.