10.Методы организации проведения обследования предметной области ис и сбора материалов.

5) В зависимости от категории участников предпроектного обследования:

              5.1) Методы сбора информации, выполняемого проектировщиком АИС.

              5.2) Методы сбора информации, выполняемого специалистами предметной области.

К методам сбора информации, выполняемого силами проектировщика АИС, относятся:  опросные методы (анкетирование, интервьюирование), метод проведения бесед и консультаций, метод наблюдения, метод фотографии рабочего дня, метод хронометража рабочего времени, расчетный метод определения объемов, трудоемкости и стоимости работ, метод анализа процессов, операций, задач.

Методы сбора информации, выполняемого специалистами предметной области, включают: метод самофотографии рабочего дня, метод ведения тетрадей (дневников) осуществляемых работ, инвентаризация документов, используемых на  рабочем месте.

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

11.Понятие масштаба и границ проекта. Группы функций системы, выделяемые в методе MoSCoW.

Масштаб – это то, что руководитель проекта решает выполнить в начале существования проекта. Он устанавливается во время фазы анализа требований проекта. Работая в тесном контакте с заказчиком и пользователями, руководитель проекта выявляет, что нужно осуществить в качестве целей проекта. Масштаб фиксируется в проектной документации и согласуется со всеми затронутыми лицами.

Масштаб формирует границы проекта. Если вы не определите, что есть что, то велика вероятность того, что проект будет расти - и вскоре ваш небольшой проект вырастет до незапланированных масштабов большого проекта.

M — должен сделать это (англ. — «MUST have this.»)

S — должен сделать это, если это вообще возможно (англ. — «SHOULD have this if at all possible.»)

C — мог бы сделать это, если это не повлияет отрицательно на что-то другое (англ. — «COULD have this if it does not affect anything else.»)

W — не будет достаточно времени на это, но в будущем хотелось бы. Или хочу. (англ. — «WON’T have this time but WOULD like in the future. Alternatively WANT.»)

Буквы «о» добавлены в акроним MoSCoW для удобства произношения. Часто их оставляют строчными, чтобы показать, что они ничего не означают. Некоторые считают, что акроним должен выглядеть так: MuSCoW, чтобы точнее отображать слова из которых он состоит. Но MoSCoW предпочтительнее, так как легче запоминается из-за созвучности со столицей Российской Федерации.

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

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

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

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

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

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

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

Вряд ли удастся (но хотелось бы)

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