1. Технология создания по. Методы средства процедуры

Скачать 466.5 Kb. Название 1. Технология создания по. Методы средства процедуры Анкор opias_shpory1.doc Дата 03.05.2017 Размер 466.5 Kb. Формат файла Имя файла opias_shpory1.doc Тип Документы #6598 страница 1 из 4

1   2   3   4 1.Технология создания ПО. Методы средства процедуры. При разработке программных систем для того чтобы обеспечить качество программного продукта необходимо выполнить определенную последовательность шагов которые называются технологией разработкой ИАС. В состав технологий так же входят методы, средства и процедуры. Методы позволяют решать след задачи: 1.планирование и оценка проекта. 2.анализ требований. 3. проектирование алгоритмов, структур данных и программных структур. 4. кодирование. 5. тестирование. 6.сопровождение. Средства (утилиты) – они обеспечивают автоматизированную поддержку методов. Процедуры – они соединяют методы и средства, чтобы образовалась непрерывная технологическая цепочка разработки программного обеспечения. Процедуры определяют порядок применения методов и утилит – разработка отчетов и обеспечивают контроль процесса разработки. 2. Распределение обязанностей в команде разработчиков В составе команды разработчиков каждого мини-проекта должны быть выделены следующие роли: лидер мини-проекта отвечает за проект в целом, осуществляет распределение работ среди участников проекта и контролирует их выполнение; главный разработчик отвечает за создание технического задания по мини-проекту, выполнение высокоуровневого проектирования (состав/содержание/план/структура конспекта и презентации); главный тестер отвечает за планирование качества и тестирование конспекта и презентации (проверка соответствия зафиксированной структуре, отслеживание выполнения принятых правил оформления); технический писатель выполняет поиск и накопление материалов, отвечает за реализацию (написание) компонентов конспекта и презентации (разделов, частей); тестер выполняет тестирование компонентов конспекта и презентации (разделов, частей). Замечание: каждый участник мини-проекта может выполнять несколько ролей одновременно 3. Стратегии конструирования ПО. Инкрементная модель Существуют 3 стратегии конструирования ПО: · однократный проход (водопадная стратегия) - линейная последовательность этапов конструирования; · инкрементная стратегия. В начале процесса определяются все пользовательские и системные требования, оставшаяся часть конструирования выполняется в виде последовательности версий. Первая версия реализует часть запланированных возможностей, следующая версия реализует дополнительные возможности и т. д., пока не будет получена полная система; · эволюционная стратегия. Система также строится в виде последовательности версий, но в начале процесса определены не все требования. Требования уточняются в результате разработки версий. Характеристики стратегий конструирования Стратегия конструирования В начале процесса определены все требования? Множество циклов конструирования? Промежуточное ПО распространяется? Однократный проход Инкрементная (запланированное улучшение продукта) Эволюционная Да Нет Нет Да Да Может быть Нет Да Да Инкрементная модель является классическим примером инкрементной стратегии конструирования. Она объединяет элементы последовательной водопадной модели с итерационной философией макетирования. Каждая линейная последовательность здесь вырабатывает поставляемый инкремент ПО. Например, ПО для обработки слов в 1-м инкременте реализует функции базовой обработки файлов, функции редактирования и документирования; во 2-м инкременте - более сложные возможности редактирования и документирования; в 3-м инкременте - проверку орфографии и грамматики; в 4-м инкременте - возможности компоновки страницы. Первый инкремент приводит к получению базового продукта, реализующего базовые требования (правда, многие вспомогательные требования остаются нереализованными). План следующего инкремента предусматривает модификацию базового продукта, обеспечивающую дополнительные характеристики и функциональность. По своей природе инкрементный процесс итеративен, но, в отличие от макетирования, инкрементная модель обеспечивает на каждом инкременте работающий продукт. 4. Стратегии конструирования ПО. Спиральная модель Существуют 3 стратегии конструирования ПО: · однократный проход (водопадная стратегия) - линейная последовательность этапов конструирования; · инкрементная стратегия. В начале процесса определяются все пользовательские и системные требования, оставшаяся часть конструирования выполняется в виде последовательности версий. Первая версия реализует часть запланированных возможностей, следующая версия реализует дополнительные возможности и т. д., пока не будет получена полная система; · эволюционная стратегия. Система также строится в виде последовательности версий, но в начале процесса определены не все требования. Требования уточняются в результате разработки версий. Характеристики стратегий конструирования Стратегия конструирования В начале процесса определены все требования? Множество циклов конструирования? Промежуточное ПО распространяется? Однократный проход Инкрементная (запланированное улучшение продукта) Эволюционная Да Нет Нет Да Да Может быть Нет Да Да Спиральная модель процесса создания программного обеспечения была впервые предложена в статье и в настоящее время получила широкую известность и популярность. В отличие от рассмотренных ранее моделей, где процесс создания ПО представлен в виде последовательности отдельных процессов с возможном обратной связью между ними, здесь процесс разработки представлен в виде спирали. Каждый виток спирали соответствует одной стадии (итерации) процесса создания ПО. Так, самый внутренний виток спирали соответствует стадии принятия решения о создании ПО, на сле­дующем витке определяются системные требования, далее следует стадия (виток спирали) проектирования системы и т.д. Каждый виток спирали разбит на четыре сектора. 1. Определение целей. Определяются цели каждой итерации проекта. Кроме того, устанавливаются ограничения на процесс создания ПО и на сам программный продукт, уточняются планы производства компонентов. Определяются проектные риски (например, риск превышения сроков или риск превышения стоимости проекта). В зависимости от "проявленных" рисков, могут планироваться альтернативные стратегии разработки ПО. 2. Оценка и разрешение рисков. Для каждого определенного проектного риска проводится его детальный анализ. Планируются мероприятия для уменьшения (разрешения) рисков. Например, если существует риск, что системные требования определены неверно, планируется разработать прототип системы. 3. Разработка и тестирование. После оценки рисков выбирается модель процесса солдаты системы. Например» если доминируют риски, связанные с разработкой интерфейсов, наиболее подходящей будет эволюционная модель разработки ПО с прототипированием. Если основные риски связаны с соответствием системы и спецификации, скорее всего, следует применить модель формальных преобразований. Каскадная модель может быть применена в том случае, если основные риски определены как ошибки, которые могут проявиться на этапе сборки системы. 4. Планирование. Здесь пересматривается проект и принимается решение о том, начинать ли следующий виток спирали. Если принимается решение о продолжении проекта, разрабатывается план на следующую стадию проекта. Существенное отличие спиральной модели от других моделей процесса создания ПО заключается в точном определении и оценивании рисков.. В спиральной модели нет фиксированных этапов, таких как разработка спецификации или проектирование. Эта модель может включать в себя любые другие модели разработки систем. 7. Оценка программного проекта. Размерно-ориентированные метрики Метрика качества программ - система измерений качества программ. Эти измерения могут проводиться на уровне критериев качества программ или на уровне отдельных характеристик качества. В первом случае система измерений позволяет непосредственно сравнивать программы по качеству. При этом сами измерения не могут быть проведены без субъективных оценок свойств программ. Во втором случае измерения характеристик можно выполнить объективно и достоверно, но оценка качества ПО в целом будет связана с субъективной интерпретацией получаемых оценок. Размерно-ориентированные метрики прямо измеряют программный продукт и процесс его разработки. Основываются такие метрики на LOC-оценках (Lines Of Code). LOC-оценка - это количество строк в программном продукте. Принято регистрировать следующие показатели: - общие затраты (в человеко-месяцах - чел.-мес); - объем программного изделия (в тысячах строк исходного кода -KLOC); - стоимость разработки (в тыс.рублей или в долларах $); - объем документации (в страницах документов -СД); - ошибки, обнаруженные в течение первого года эксплуатации (число ошибок - ЧО); - число людей, работавших над изделием (человек); - срок разработки (в календарных месяцах). На основе перечисленных показателей вычисляются размерно-ориентированные метрики производительности и качества (для каждого проекта): Достоинства размерно-ориентированных метрик: 1) широко распространены; 2) просты и легко вычисляются. Недостатки размерно-ориентированных метрик: 1) зависимы от языка программирования; 2) требуют исходных данных, которые трудно получить на начальной стадии проекта; 3) не приспособлены к непроцедурным языкам программирования. 8. Оценка программного проекта. Функционально-ориентированные метрики Функционально-ориентированные метрики косвенно измеряют программный продукт и процесс его разработки. Вместо подсчета LOC-оценки при этом рассматривается не размер, а функциональность или полезность продукта. Используется 5 информационных характеристик. 1. Количество внешних вводов. Подсчитываются все вводы пользователя, по которым поступают разные прикладные данные. Вводы должны быть отделены от запросов, которые подсчитываются отдельно. 2. Количество внешних выводов. Подсчитываются все выводы, по которым к пользователю поступают результаты, вычисленные программным приложением. В этом контексте выводы означают отчеты, экраны, распечатки, сообщения об ошибках. Индивидуальные единицы данных внутри отчета отдельно не подсчитываются. 3. Количество внешних запросов. Под запросом понимается диалоговый ввод, который приводит к немедленному программному ответу в форме диалогового вывода. При этом диалоговый ввод в приложении не сохраняется, а диалоговый вывод не требует выполнения вычислений. Подсчитываются все запросы - каждый учитывается отдельно. 4. Количество внутренних логических файлов. Подсчитываются все логические файлы (то есть логические группы данных, которые могут быть частью базы данных или отдельным файлом). 5. Количество внешних интерфейсных файлов. Подсчитываются все логические файлы из других приложений, на которые ссылается данное приложение. 9. Оценка программного проекта. Метод функциональных указателей Количество функциональных указателей вычисляется по формуле FP = Общее количество х (0,65+ 0,01 x), (2.1) где Fр — коэффициенты регулировки сложности. Каждый коэффициент может принимать следующие значения: 0 — нет влияния, 1 — случайное, 2 — небольшое, 3 — среднее, 4 — важное, 5 — основное. Область применения метода функциональных указателей - коммерческие информационные системы. Для продуктов с высокой алгоритмической сложностью используются метрики указателей свойств (Features Points). Они применимы к системному и инженерному ПО. ПО реального времени и встроенному ПО. Для вычисления указателя свойств добавляется одна характеристика - количество алгоритмов. Алгоритм здесь определяется как ограниченная подпрограмма вычислений, которая включается в общую компьютерную программу. Примеры алгоритмов: обработка прерываний, инвертирование матрицы, расшифровка битовой строки Область применения метода функциональных указателей — коммерческие информационные системы. Для продуктов с высокой алгоритмической сложностью используются метрики указателей свойств (Features Points). Они применимы к системному и инженерному ПО, ПО реального времени и встроенному ПО. Для вычисления указателя свойств добавляется одна характеристика — количество алгоритмов. Алгоритм здесь определяется как ограниченная подпрограмма вычислений, которая включается в общую компьютерную программу. Примеры алгоритмов: обработка прерываний, инвертирование матрицы, расшифровка битовой строки. 10. Конструктивная модель оценки стоимости. Модель композиции приложения Модель композиции используется на ранней стадии конструирования ПО, когда: рассматривается макетирование пользовательских интерфейсов; обсуждается взаимодействие ПО и компьютерной системы; оценивается производительность; определяется степень зрелости технологии. Модель композиции приложения ориентирована на применение объектных указателей. Объектный указатель — средство косвенного измерения ПО, для его расчета определяется количество экранов (как элементов пользовательского интерфейса), отчетов и компонентов, требуемых для построения приложения. После определения сложности количество экранов, отчетов и компонентов взвешивается. Количество объектных указателей определяется перемножением исходного числа объектных экземпляров на весовые коэффициенты и последующим суммированием промежуточных результатов. Для учета реальных условий разработки вычисляется процент повторного использования программных компонентов %REUSE и определяется количество новых объектных указателей NOP: NOP = (Объектные указатели) х [(100 - %REUSE) /100]. Для оценки затрат, основанной на величине NOP, надо знать скорость разработки продукта PROD. Эту скорость определяют по табл. 2.18, учитывающей уровень опытности разработчиков и зрелость среды разработки. Проектные затраты оцениваются по формуле ЗАТРАТЫ = NOP /PROD [чел.-мес], где PROD — производительность разработки, выраженная в терминах объектных указателей. В более развитых моделях дополнительно учитывается множество масштабных факторов, формирователей затрат, процедур поправок. 11. Модель раннего этапа проектирования Модель раннего этапа проектирования используется в период, когда стабилизируются требования и определяется базисная программная архитектура. Основное уравнение этой модели имеет следующий вид: ЗАТРАТЫ = А х РАЗМЕРв х Ме + ЗАТРАТЫаuto[чел.-мес], где: масштабный коэффициент А = 2,5; показатель В отражает нелинейную зависимость затрат от размера проекта (размер системы РАЗМЕР выражается в тысячах LOC); множитель поправки Мe зависит от 7 формирователей затрат, характеризующих продукт, процесс и персонал; слагаемое 3ATPATЫauto отражает затраты на автоматически генерируемый программный код. Значение показателя степени В изменяется в диапазоне 1,01... 1,26, зависит от пяти масштабных факторов Wi и вычисляется по формуле Общая характеристика масштабных факторов позволяет определить оценки этих факторов. Оценки принимают 6 значений: от очень низкой (5) до сверхвысокой (0). 12. Модель этапа постархитектуры Модель этапа постархитектуры используется в период, когда уже сформирована архитектура и выполняется дальнейшая разработка программного продукта. Основное уравнение постархитектурной модели является развитием уравнения предыдущей модели и имеет следующий вид: ЗАТРАТЫ = А х К˜req х РАЗМЕРB х Мр +3ATPATЫauto [чел.-мес], где коэффициент К˜req учитывает возможные изменения в требованиях; показатель В отражает нелинейную зависимость затрат от размера проекта (размер выражается в KLOC), вычисляется так же, как и в предыдущей модели; в размере проекта различают две составляющие — новый код и повторно используемый код; множитель поправки Мр зависит от 17 факторов затрат, характеризующих продукт, аппаратуру, персонал и проект. Изменчивость требований приводит к повторной работе, требуемой для учета предлагаемых изменений, оценка их влияния выполняется по формуле К˜req =l + (BRAK/100), где BRAK — процент кода, отброшенного (модифицированного) из-за изменения требований. Размер проекта и продукта определяют по выражению РАЗМЕР = PA3MEPnew + PA3MEPreuse [KLOC], где PA3MEPnew — размер нового (создаваемого) программного кода; PA3MEPreuse — размер повторно используемого программного кода. Формула для расчета размера повторно используемого кода записывается следующим образом: PA3MEPreuse =KASLOC x ((100 - AT)/ 100) x (AA + SU + 0,4 DM + 0,3 CM + 0,3 IM) /100, Где KASLOC — количество строк повторно используемого кода, который должен быть модифицирован (в тысячах строк);AT — процент автоматически генерируемого кода; DM — процент модифицируемых проектных моделей; CM — процент модифицируемого программного кода;IM — процент затрат на интеграцию, требуемых для подключения повторно используемого ПО;SU — фактор, основанный на стоимости понимания добавляемого ПО; изменяется от 50 (для сложного неструктурированного кода) до 10 (для хорошо написанного объектно-ориентированного кода);АА — фактор, который отражает стоимость решения о том, может ли ПО быть повторно используемым; зависит от размера требуемого тестирования и оценивания (величина изменяется от 0 до 8). Правила выбора этих параметров приведены в руководстве по СОСОМО II. Для определения множителя поправки Мр основного уравнения используют 17 факторов затрат, которые могут быть разбиты на 4 категории. Перечислим факторы затрат, сгруппировав их по категориям. Факторы продукта: 1) требуемая надежность ПО — RELY; 2) размер базы данных — DATA; 3) сложность продукта — CPLX; 4) требуемая повторная используемость — RUSE; 5) документирование требований жизненного цикла — DOCU. Факторы платформы (виртуальной машины): 6) ограничения времени выполнения — TIME; 7) ограничения оперативной памяти — STOR; 8) изменчивость платформы — PVOL. Факторы персонала: 9) возможности аналитика — АСАР; 10) возможности программиста — РСАР; 11) опыт работы с приложением — АЕХР; 12) опыт работы с платформой — РЕХР; 13) опыт работы с языком и утилитами — LTEX; 14) непрерывность персонала — PCON. Факторы проекта: 15) использование программных утилит — TOOL; 16) мультисетевая разработка — SITE; 17) требуемый график разработки — SCED. Значение Мр отражает реальные условия выполнения программного проекта и позволяет троекратно увеличить (уменьшить) начальную оценку затрат. От оценки затрат легко перейти к стоимости проекта. Переход выполняют по формуле: СТОИМОСТЬ = ЗАТРАТЫ х РАБ_ КОЭФ, где среднее значение рабочего коэффициента составляет $15 000 за человеко-месяц. После определения затрат и стоимости можно оценить длительность разработки. Модель СОСОМО II содержит уравнение для оценки календарного времени TDEV, требуемого для выполнения проекта. Для моделей всех уровней справедливо: Длительность (TDEV) = [3,0 х (ЗАТРАТЫ)(0,33+0,2(B-1,01))] х SCEDPercentage/100 [мес], где В — ранее рассчитанный показатель степени; SCEDPercentage — процент увеличения (уменьшения) номинального графика. Если нужно определить номинальный график, то принимается SCEDPercentage =100 и правый сомножитель в уравнении обращается в единицу. Следует отметить, что СОСОМО II ограничивает диапазон уплотнения/растягивания графика (от 75 до 160%). Причина проста — если планируемый график существенно отличается от номинального, это означает внесение в проект высокого риска. Рассмотрим пример. Положим, что затраты на проект равны 20 человеко-месяцев. Примем, что все масштабные факторы номинальны (имеют значения 3), поэтому, в соответствии с табл. 2.20, показатель степени 5=1,16. Отсюда следует, что номинальная длительность проекта равна TDEV = 3, Ox (20)0,36 = 8,8 мес. Отметим, что зависимость между затратами и количеством разработчиков носит характер, существенно отличающийся от линейного. Очень часто увеличение количества разработчиков приводит к возрастанию затрат. В чем причина? Ответ прост: увеличивается время на взаимодействие и обучение сотрудников, согласование совместных решений; возрастает время на определение интерфейсов между частями программной системы. Удвоение разработчиков не приводит к двукратному сокращению длительности проекта. Модель СОСОМО II явно утверждает, что длительность проекта является функцией требуемых затрат, прямой зависимости от количества сотрудников нет. Другими словами, она устраняет миф нерадивых менеджеров в том, что добавление людей поможет ликвидировать отставание в проекте. СОСОМО II предостерегает от определения потребного количества сотрудников путем деления затрат на длительность проекта. Такой упрощенный подход часто приводит к срыву работ. Реальная картина имеет другой характер. Количество людей, требуемых на этапе планирования и формирования требований, достаточно мало. На этапах проектирования и кодирования потребность в увеличении команды возрастает, после окончания кодирования и тестирования численность необходимых сотрудников достигает минимума. 14. Модели жизненного цикла проектирования ПО. Модель жизненного цикла отражает различные состояния системы, начиная с момента возникновения необходимости в данной ИС и заканчивая моментом ее полного выхода из употребления. Модель жизненного цикла - структура, содержащая процессы, действия и задачи, которые осуществляются в ходе разработки, функционирования и сопровождения программного продукта в течение всей жизни системы, от определения требований до завершения ее использования. В настоящее время известны и используются следующие модели жизненного цикла: Каскадная модель (рис. 1) предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе. Поэтапная модель с промежуточным контролем (рис. 2). Разработка ИС ведется итерациями с циклами обратной связи между этапами. Межэтапные корректировки позволяют учитывать реально существующее взаимовлияние результатов разработки на различных этапах; время жизни каждого из этапов растягивается на весь период разработки. Спиральная модель (рис. 3) На каждом витке спирали выполняется создание очередной версии продукта, уточняются требования проекта, определяется его качество и планируются работы следующего витка. Особое внимание уделяется начальным этапам разработки - анализу и проектированию, где реализуемость тех или иных технических решений проверяется и обосновывается посредством создания прототипов (макетирования). Рис. 1 Каскадная модель ЖЦ ИС Рис. 2 Поэтапная модель с промежуточным контролем В ранних проектах достаточно простых ИС каждое приложение представляло собой единый, функционально и информационно независимый блок. Для разработки такого типа приложений эффективным оказался каскадный способ. Каждый этап завершался после полного выполнения и документального оформления всех предусмотренных работ. Рис. 3 Спиральная модель ЖЦ ИС 15. Унифицированный процесс разработки, его структура В свою очередь, каждый этап процесса разделяется на итерации. Итерация - это полный цикл разработки, вырабатывающий промежуточный продукт. По мере перехода от итерации к итерации промежуточный продукт инкрементно усложняется, постепенно превращаясь в конечную систему. В состав каждой итерации входят все рабочие потоки - от сбора требований до тестирования. От итерации к итерации меняется лишь удельный вес каждого рабочего потока - он зависит от этапа. На этапе Начало основное внимание уделяется сбору требований, на этапе Развитие - анализу и проектированию, на этапе Конструирование - реализации, на этапе Переход - тестированию. Каждый этап и итерация уменьшают некоторый риск и завершается контрольной вехой. К вехе привязывается техническая проверка степени достижения ключевых целей. По результатам проверки возможна модификация дальнейших действий.Структура Унифицированного процесса Унифицированный процесс как процесс разработки программного обеспечения представляет собой методологию, содержащую детальное описание работ по созданию и внедрению ПО. Она отвечает «на вопросы когда, как, кто, что и с помощью чего реализуется проект» [30], а именно содержит описание: · технологических процессов (когда) – последовательности видов деятельности (работ), дающих ощутимый результат. Технологический процесс, как правило, представляется в виде диаграммы, отображающей состав работ и их последовательность на той или иной стадии разработки ПО;· видов деятельности (как) – работ, осуществляемых исполнителями; · исполнителей (кто) – заинтересованных в реализации проекта отдельных лиц или групп. Исполнитель характеризуется строго определенным поведением и обязанностями (ролью). Поведение выражается через виды деятельности, осуществляемые исполнителем, а обязанности – через результаты, получаемые в процессе выполнения работ; · артефактов (что) – информации, создаваемой, изменяемой или используемой исполнителями в проекте. Другими словами, артефакт – это не только то, что создается в результате деятельности (технические артефакты – модели системы, исходные коды программ, готовый программный продукт, документация к нему и т. д.), но и то, что направляет эту деятельность (артефакты управления – календарный план, техническое задание, инструкции и т. д.) · используемых утилит (с помощью чего) – программных продуктов, рекомендуемых при выполнении работ. 16. унифицированный процесс разработки. Рабочие потоки процесса Рабочие потоки процесса имеют следующее содержание: - Сбор требований — описание того, что система должна делать; - Анализ — преобразование требований к системе в классы и объекты, выявляемые в предметной области; - Проектирование — создание статического и динамического представления системы, выполняющего выявленные требования и являющегося эскизом реализации; - Реализация — производство программного кода, который превращается в исполняемую систему; - Тестирование — проверка всей системы в целом. Каждый рабочий поток определяет набор связанных артефактов и действий. Артефакт — это документ, отчет или выполняемый элемент. Артефакт может вырабатываться, обрабатываться или потребляться. Действие описывает задачи — шаги обдумывания, шаги исполнения и шаги проверки. Шаги выполняются участниками процесса (для создания или модификации артефактов). Между артефактами потоков существуют зависимости. Например, модель Use Case, генерируемая в ходе сбора требований, уточняется моделью анализа из процесса анализа, обеспечивается проектной моделью из процесса проектирования, реализуется моделью реализации из процесса реализации и проверяется тестовой моделью из процесса тестирования. Модели Модель — наиболее важная разновидность артефакта. Модель упрощает реальность, создается для лучшего понимания разрабатываемой системы. Предусмотрены девять моделей, вместе они покрывают все решения по визуализации, спецификации, конструированию и документированию программных систем: - бизнес-модель. Определяет абстракцию организации, для которой создается система; - модель области определения. Фиксирует контекстное окружение системы; - модель Use Case. Определяет функциональные требования к системе; - модель анализа. Интерпретирует требования к системе в терминах проектной модели; - проектная модель. Определяет словарь проблемы и ее решение; - модель размещения. Определяет аппаратную топологию, в которой исполняется система; - модель реализации. Определяет части, которые используются для сборки и реализации физической системы; - тестовая модель. Определяет тестовые варианты для проверки системы; - модель процессов. Определяет параллелизм в системе и механизмы синхронизации. 17. унифицированный процесс разработки. Этап НАЧАЛО (Inception) Главное назначение этапа - запустить проект. Цели этапа НАЧАЛО: - определить область применения проектируемой системы (ее предназначение, границы, интерфейсы с внешней средой, критерий признания - приемки); - определить элементы Use Case, критические для системы (основные сценарии поведения, задающие ее функциональность и покрывающие главные проектные решения); - определить общие черты архитектуры, обеспечивающей основные сценарии, создать демонстрационный макет; - определить общую стоимость и план всего проекта и обеспечить детализированные оценки для этапа развития; - идентифицировать основные элементы риска. Основные действия этапа НАЧАЛО: - формулировка области применения проекта - выявление требований и ограничений, рассматриваемых как критерий признания конечного продукта; - планирование и подготовка бизнес-варианта и альтернатив развития для управления риском, определение персонала, проектного плана, а также выявление зависимостей между стоимостью, планированием и полезностью; - синтезирование предварительной архитектуры, развитие компромиссных решений проектирования; определение решений разработки, покупки и повторного использования, для которых можно оценить стоимость, планирование и ресурсы. В итоге этапа НАЧАЛО создаются следующие артефакты:   1   2   3   4