Cтраница 1
Границы проекта должны быть установлены так, чтобы в рамки попала подавляющая часть выбросов по проекту и внешнее влияние на пространство внутри границ было пренебрежительно малым. [1]
Оценить границы проекта, перечислив обещаемые законченные части, указать предположения и ограничения для проекта и определить ответственность группы разработки за согласование с пользователями. [2]
Рекомендуется нарисовать границы проекта в виде блок-схемы, отделив включенные в рассмотрение источники от не включенных в границы проекта. Источниками, включенными в рассмотрение, должны быть только те, которые находятся под контролем данного проекта. [3]
Даже если границы проекта были отражены в других частях документа по стратегии, этот раздел остается особо важным и требует отдельного оформления. [4]
Принцип контролируемости предполагает, что границы проекта должны быть установлены так, чтобы в них вошли все источники выбросов ПГ, контролируемые участниками проекта и в пределах разумного связанные с его реализацией. [5]
Следует отметить, что границы сценария базового уровня и собственно границы проекта не всегда совпадают. Если границы проекта не совпадают с границами определения его базового уровня, это необходимо должным образом обосновать. [6]
Рекомендуется нарисовать границы проекта в виде блок-схемы, отделив включенные в рассмотрение источники от не включенных в границы проекта. Источниками, включенными в рассмотрение, должны быть только те, которые находятся под контролем данного проекта. [7]
Следует отметить, что границы сценария базового уровня и собственно границы проекта не всегда совпадают. Если границы проекта не совпадают с границами определения его базового уровня, это необходимо должным образом обосновать. [8]
Эта книга посвящена процессу полной разработки систем, включающему как переработку старой системы, так и разработку новой системы с нуля. Часто границы проекта не совмещаются с полным процессом разработки CADM. Например, в одном проекте ( над которым продолжают работать авторы) нужно было заменить оконечную ( пользовательскую) часть существующего приложения, ориентированного на символьный вывод. [9]
Такая связь может сужать границы проекта. [10]
Подобно базовому уровню выброса определение границ проекта является важным элементом в разработке плана мониторинга. Необходимо определить одни и те же границы проекта, выделенные для базового уровня и мониторинга. Если выбросы в результате неких видов деятельности включены в подсчеты ее базового уровня, тогда эти же виды деятельности могут быть включены в план мониторинга. [11]
Для очень малых проектов фазы стратегии и анализа объединяются. Например, при формировании справочной системы для настольного компьютера необходимо только несколько страниц описания, указывающего границы проекта и оценку стоимости, стратегическую ERD и, возможно, схему потоков процессов. [12]
Мы представили жизненный цикл CADM последовательно - от одной фазы к другой. Однако мы сознаем, что разработка системы не является простым линейным процессом. Границы проекта могут изменяться в любое время. Новые требования могут поступить от пользователя в любой точке процесса, даже на фазе тестирования. Кроме того, могут потерпеть неудачу проверки качества системы. Действительность всегда вносит свои коррективы в наш чисто теоретический процесс. Поэтому в главе 21 рассматриваются действия в непредвиденных ситуациях. [13]
Запись подробностей важна в больших проектах с множеством идей, которые быстро появляются и уходят с горизонта, но могут провалить весь проект. Документ о требованиях дает возможность объяснить пользователю: Вы хотите получить следующие изменения в существующей системе. Ничто не дается просто, но аналитик должен выявить границы проекта, используя для этого информацию от пользователей. [14]
При подготовке и рассмотрении соглашения о требованиях выполняется необходимый анализ, чтобы подтвердить осуществимость проекта. Фаза анализа осуществимости проекта заканчивается утверждением соглашения о требованиях, которое дает толчок некоторым другим действиям: созданию пособий, тестов, разработке планов поддержки. Кроме того, она определяет внешнюю и внутреннюю спецификации проекта. Одобрением внешней спецификации, представляющей собой законченное и строгое изложение сведений о том, что представляет собой изделие, определяются границы проекта, на чем и заканчивается фаза конструирования. [15]