Понятие масштаба и границ проекта. Группы функций системы, выделяемые в методе 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 неоднозначность в плане ее сравнения с приоритетностью других категорий.
Принципы структурного анализа системы.
Анализ требований разрабатываемой системы является важнейшим среди всех этапов ЖЦ. Он оказывает существенное влияние на все последующие этапы, являясь в то же время наименее изученным и понятным процессом. На этом этапе, во-первых, необходимо понять, что предполагается сделать, а во-вторых, задокументировать это, т.к. если требования не зафиксированы и не сделаны доступными для участников проекта, то они вроде бы и не существуют. При этом язык, на котором формулируются требования, должен быть достаточно прост и понятен заказчику.
|
|
|
Структурным анализом принято называть метод исследования системы, которое начинается с ее общего обзора и затем детализируется, приобретая иерархическую структуру со все большим числом уровней. Для таких методов характерно разбиение на уровни абстракции с ограничением числа элементов на каждом из уровней (обычно от 3 до 6-7); ограниченный контекст, включающий лишь существенные на каждом уровне детали; дуальность данных и операций над ними; использование строгих формальных правил записи; последовательное приближение к конечному результату.
Все методологии структурного анализа базируются на ряде общих принципов, часть из которых регламентирует организацию работ на начальных этапах ЖЦ, а часть используется при выработке рекомендаций по организации работ. В качестве двух базовых принципов используются следующие: принцип "разделяй и властвуй" и принцип иерархического упорядочивания. Первый является принципом решения трудных проблем путем разбиения их на множество меньших независимых задач, легких для понимания и решения. Второй принцип в дополнение к тому, что легче понимать проблему если она разбита на части, декларирует, что устройство этих частей также существенно для понимания. Понимание проблемы резко облегчается при организации ее частей в древовидные иерархические структуры, т.е. система может быть понята и построена по уровням, каждый из которых добавляет новые детали.
|
|
|
Выделение двух базовых принципов инженерии программного обеспечения вовсе не означает, что остальные принципы являются второстепенными, игнорирование любого из них может привести к непредсказуемым последствиям (в том числе и к неуспеху всего проекта). Отметим основные из таких принципов.
Принцип абстрагирования - заключается в выделении существенных с некоторых позиций аспектов системы и отвлечение от несущественных с целью представления проблемы в простом общем виде.
Принцип формализации - заключается в необходимости строгого методического подхода к решению проблемы.
Принцип упрятывания - заключается в упрятывании несущественной на конкретном этапе информации: каждая часть "знает" только необходимую ей информацию.
Принцип концептуальной общности - заключается в следовании единой философии на всех этапах ЖЦ (структурный анализ - структурное проектирование - структурное программирование - структурное тестирование).
Принцип полноты - заключается в контроле на присутствие лишних элементов.
Принцип непротиворечивости - заключается в обоснованности и согласованности элементов.
Принцип логической независимости - заключается в концентрации внимания на логическом проектировании для обеспечения независимости от физического проектирования.
Принцип независимости данных - заключается в том, что модели данных должны быть проанализированы и спроектированы независимо от процессов их логической обработки, а также от их физической структуры и распределения.
Принцип структурирования данных - заключается в том, что данные должны быть структурированы и иерархически организованы.
Принцип доступа конечного пользователя - заключается в том, что пользователь должен иметь средства доступа к базе данных, которые он может использовать непосредственно (без программирования).
Дата добавления: 2018-02-15; просмотров: 544; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!