Шпаргалка по "Информатике"

организации прогр системы;

выбора структур элементов, составляющих систему, и их интерфейсов;поведения  этих элементов, пецифицированного  в кооперациях с др элемен;составл из этих структурных и поведенческих элем все более и более крупных подсистем;архитект стиля, направляющего и определ всю организацию системы: статические и динам элементы, их интерфейсы, кооперации и способ их объединения.Архитектура прогр системы охватывает не только ее структурные и поведенческие аспекты, но и использование, функциональн, производительность, гибкость, возможности повторного примен, полноту, экономич и технолог огранич и компромис, а также эстетические вопросы.архитектура прогр системы наиболее оптимально может быть описана с помощью пяти взаимосвязан видов или представлений, каждый из которых явл одной из возможных проекций организации и структуры системы и заостряет внимание на определ аспекте ее функционирования.Вид с точки зрения прецедентов (Use case view) охватывает прецеденты, которые описыв поведение системы, наблюдаемое конечными пользов, аналитиками и тестировщ. Этот вид специфицирует не истинную организацию прогр системы, а те движущие силы, от которых зависит формирование системной архитектуры. В языке UML статические аспекты этого вида передаются диагр прецедентов, а динамич диагр взаимодействия, состояний и действий.Вид с точки зрения проектир (Design view) охватывает классы, интерфейсы и кооперации, формирующие словарь задачи и ее решения. Этот вид поддерживает прежде всего функциональные требов, предъявляемые к системе, т.е. услуги, которые она должна предоставлять конечным пользов. С помощью языка UML статические аспекты этого вида можно передавать диагр классов и объектов, а динам диагр взаимоде, состояний и действий.

11. Управление  риском

Влияние риска вычисл по выраж:RE = P(UO) x L(UO), где: RE — показатель риска; P(UO) — вероятн неудовлетвор результата; L(UO) — потеря при неудовлетвор результ. При разработке програм продукта неудовлетворит результ может быть: превышение бюджета, низкая надежность, неправил функциониров и т. д. Управл риском включ 6 действий: *Идентификация риска — выявлен элем риска в проекте. Анализ риска — оценка вероятнос и величины потери по каждому элем риска. Ранжирование риска — упорядочение элем риска по степени их влияния. Планиров управления риском — подготов к работе с каждым элем риска. Разрешение риска — устранен или разрешение элем риска. Наблюдение риска — отслежив динамики элемен риска, выполн корректирующих действий. Первые три действия относят к этапу оценивания риска, последние три действия — к этапу контроля риска. Идентиф риска В результате идентиф формир список элемен риска, специфичных для данного проекта. Выдел 3 категории источн риска: проектн, техничес, коммерч. Источн проект риска явл: выбор бюджета, плана, человеч ресурсов програм проекта; формиров требов к програм продукту;сложность, размер и структура програм проекта; методика взаимодейст с заказчик. К источн технич риска относят: трудности проектир, реализации, формиров интерф, тестиров и сопровождения; неточность спецификаций; техническая неопределенность или отсталость принятого решения. Главная причина технич риска — реальная сложность проблем выше предполагаемой сложности. Источн коммерчес риска вкл: создание продукта, не требующ на рынке; создание продукта, опережающего требов рынка; потерю финансирования. Лучший способ идентификац использове проверочных списков риска, которые помогают выявить возможный риск. После идентификации элем риска следует колич-вено оценить их влияние на програм проект, решить вопросы о возможных потерях. Эти вопросы решаются на шаге анализа риска  В ходе оценив вероятн возникнов Р_i и величина потери L_i для каждого выявленного i-го элем риска. В результате вычисл влияние RE_i i-го элемен риска на проект. Вероятности определяются с помощью экспертных оценок или на основе статистики, накопленной за предыдущие разработки. Ранжиров заключ в назначении каждому элем риска приоритета, который пропорционален влиянию элем на проект. Это позволяет выделить категории элемен риска и определить наиболее важные из них.  Планир управления риском Цель сформир набор функций управления каждым элемен риска. Основанием для разрешения и наблюд явл план управл риск. Работы по разрешению и наблюдению производятся с начала и до конца процесса разработки. Разрешение риска состоит в плановом применен действий по уменьш риска. Наблюд риска гарантирует: цикличность процесса слежения за риском; вызов необходимых корректирующих воздействий. Для управл риск  использ эффективная методика «Отслеживание 10 верхних элементов риска». Эта методика концентрирует внимание на факторах повышен риска, экономит много времени, минимизирует «сюрпризы» разработки.

20.Диаграммы  Use Case определ поведение системы с точки зрения пользов. Диагр Use Case рассматрив как главное ср-во для первичного моделир динамики системы, использ для выяснения требов к разрабатываемой системе, фиксации этих треб в форме, которая позволит проводить дальнейшую разработку. Use Case часто называют диагр прецедентов, или диагр вариант использов. В состав Use Case входят элем Use Case, актеры, а также отношения зависимости, обобщения и ассоциации. диагр Use Case могут включать примечания и ограничения. Use Case могут содержать пакеты, использ для группир элем модели в крупные фрагменты.

Актеры и элементы Use Case Вершинами в диагр Use Case явл актеры и элементы Use Case. Актеры представ внешн мир, нуждающийся в работе системы. Элем Use Case представ действия, выполняемые системой в интересах актеров.

Актер это роль объекта вне системы, который прямо взаимодейс с ее частью конкрет элем. Различают актеров и пользов. Пользов это физич объект, который использ систему. Он может играть несколько ролей и поэтому может моделироваться несколькими актерами. Справедливо и обратное актером могут быть разные пользов. Элемент Use Case это описание последовательности действий, которые выполн системой и производят для отдельного актера видимый результат. Один актер может использ несколько элем Use Case, и наоборот, один элемент Use Case может иметь несколько актеров, использ его. Каждый элем Use Case задает определ путь использования системы. Набор всех элем Use Case определяет полные функциональные возможности системы.

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

Между актерами допустимо отношение обобщения, означаю, что экземпляр потомка может взаимод с такими же разновидн экземпляров элем Use Case, что и экземпляр родителя.

Между элем Use Case определены отношение обобщения и две разновид отношения зависимости включ и расширения. Отношение обобщения фиксирует, что потомок наследует поведение родителя. потомок может дополнить или переопределить поведение родителя. Элем Use Case, являющ потомком, может замещать элем Use Case, являющ родителем, в любом месте диагр.

Отнош включен между элем Use Case означает, что базовый элем Use Case явно включ поведение др элема Use Case в точке, которая определена в базе. Включ элемент Use Case никогда не использ самостоят его конкретизация может быть только частью др, большего элем Use Case. Отнош расширения между элем Use Case означает, что базовый элем Use Case неявно включает поведение др элем Use Case в точке, которая определ косвенно расширяющим элем Use Case. Базовый элем Use Case может быть автономен, но при определ условиях его поведение может расширяться поведением из др элем Use Case. Базовый элем Use Case может расширяться только в определ точках точках расширения. Отнош расширения примен для моделирования выбираемого поведения системы. Таким способом можно отделить обязател поведение от необязател поведения. Работа с элементами Use Case

Элемт Use Case описывает, что должна делать система, но не опред, как она должна это делать. При моделировании это позволяет отделять внешнее представ системы от ее внутрен представления. Поведение элем Use Case описывается потоком событий. Начальное описание выполн в текст форме, прозрачной для польз системы. В потоке событий выделяют: основной поток и альтернат потоки поведения; как и когда стартует и заканчив элем Use Case; когда элем Use Case взаимод с актерами; какими данными обменив актер и система. Для уточнения и формализации потоков событий использ диагр последовательн. Обычно одна диагр последоват опред главный поток в элем Use Case, а др диагр потоки исключ. В общем случае один элем Use Case описывает набор последоват, в котором каждая последоват представляет возможный поток событий. Каждая последоват назывя сценарием. Сценарий конкрет последовател действий, которая иллюстрирует поведение. Сценарии явл для элем Use Case почти тем же, чем явл экземпляры для класса. Спецификация элементов Use Case основ источ инфор для выполн анализа и проектир системы. Очень важно, чтобы содержание спецификации было представлено в полной и конструктивной форме. В общем случае спецификация включает главный поток, под потоки и альтернативные потоки поведения.

1.Организация процесса конструирования

Технология конструирования по (ТКПО) система инженерных принципов для создания экономич ПО, которое надежно и эффективно работает в реальных компьютерах. Различ методы, ср-ва и процедуры ТКПО. Методы обеспеч решение след задач: планиров оценка проекта; анализ системных и прогр требов; проектир алгоритмов, структур данных и прогр структур; кодирование; тестир; сопровожд. Ср-ва (утилиты) ТКПО обеспеч автоматизир или автоматич поддержку методов. В целях совместного применения утилиты могут объед в системы автоматизир конструирования ПО. Такие системы принято называть CASE-системами. Процедуры явл «клеем», который соединяет методы и утилиты так, что они обеспеч непрерывную технологическ цепочку разработки. Процедуры опред: порядок применения методов и утилит; формир отчет, форм по соответствующим требов; контроль, который помогает обеспеч качество и координировать изменения; формир «вех», по которым руководители оценивают прогресс. Процесс конструиров по  состоит из последовател шагов, использ методы, утилиты и процедуры. Классический жц  каскадной или водопадной моделью, подчеркивая, что разработка рассматривается как последовательность этапов, причем переход на следующий, иерархически нижний этап происходит только после полного завершения работ на текущем этапе подразумева, что разработка начинается на системном уровне и проходит через анализ, проектир, кодирование, тестир и сопровожд. При этом моделируются действия стандартного инженерного цикла. Системный анализ задает роль каждого элемента в компьют системе, взаимодействие элем др с др. Поскольку ПО явл лишь частью большой системы, то анализ начинается с определения требов ко всем системным элем и назначения подмножества этих требов программному «элементу». Необходимость системного подхода явно проявляется, когда формируется интерфейс ПО с др элем. На этом же этапе начин решение задачи планиров проекта ПО. В ходе планиров проекта определ объем проектных работ и их риск, необходимые трудозатраты, формируются рабочие задачи и план-график работ. Анализ требований относится к програм элементу по. Уточняют и детализируются его функции, характер и интерфейс. Все определ документируются в спецификации анализа. Здесь же заверш решение задачи планиров проекта.

Проектир состоит в создании представле: архитект ПО; модульной структуры ПО; алгоритмич структуры ПО; структуры данных; входного и выходного интерф. Исходные данные для проектир содержатся в спецификации анализа, т.е.в ходе проектир выполн трансляция требов к ПО во множество проектных представлений. При решении задач проектир основное внимание уделяется качеству будущего програм продукта. Кодирование состоит в переводе результ проектир в текст на языке программир. Тестир выполнение программы для выявления дефектов в функциях, логике и форме реализации прогр продукта. Сопровождение это внесение изменений в эксплуатируемое ПО. Цели изменений: исправление ошибок; адаптация к изменениям внешней для ПО среды; усовершенств ПО по требов заказчика. Достоин классич жц: дает план и временной график по всем этапам проекта, упорядочивает ход конструирования. Недост классич жц: реальные проекты часто требуют отклонения от стандартной последоват шагов; цикл основан на точной формулировке исходных требований к ПО; результаты проекта доступны заказчику только в конце работы. Макетирован цель снять неопределен в требованиях заказчка. Макетирование это процесс создания модели требуемого прогр продукта. Модель может принимать одну из 3 форм: бумажный макет или макет на основе ПК (изображает или рисует человеко-машинный диалог); работающий макет (выполняет некоторую часть требуемых функций); существующая программа (характер которой затем должны быть улучшены). макетирование основыв на многократном повторении итераций, в которых участвуют заказчик и разработчик.

Макетир начинается со сбора  и уточнения требов к создаваем ПО Разработ и заказчик встречаются и опред все цели ПО, устанавл, какие требов известны, а какие предстоит доопределить. Затем выполн быстрое проектир. В нем внимание сосредоточив на тех характер ПО, которые должны быть видимы польз. Быстрое проектир приводит к построению макета. Макет оценивается заказч и использ для уточн требов к ПО. Итерации повтор до тех пор, пока макет не выявит все требов заказчика и, тем самым, не даст возможность разработчику понять, что должно быть сделано. Достоин макетир: обеспеч определение полных требов к ПО. Недоста макетир: заказч может принять макет за продукт; разработ может принять макет за продукт.

Сущест 3 страт конструир ПО: однократный проход (водопадная стратегия) линейная последоват этапов конструирования;инкрементная стратегия. В начале процесса определ все пользоват и системные требов, оставшаяся часть конструирования выполняется в виде последовательности версий. Первая версия реализует часть запланиров возможн, след версия реализует дополнит возможн и т. д., пока не будет получена полная система; эволюционная стратегия. строится в виде последоват версий, но в начале процесса определены не все требов. Требов уточня в результате разработки версий. Характер стратегий конструирования ПО в соответ с требов стандарта IEEE/EIA 12207.2

2. Модели качества процессов  конструиров.

Инкрем модель явл  классич примером инкрементной стратегии  конструир. Каждая линейная последоват здесь вырабатывает поставляемый инкремент  ПО. Напри, ПО для обраб слов в 1-м  инкрем реализует функции базовой обраб файлов, функции редактир и документир; во 2-м инкрем более сложные возможн редактир и документир; в 3-м инкрем проверку орфографии и грамматики; в 4-м инкрем возможн компоновки страницы.

1-инкрем приводит к  получению базового продукта, реализ  базовые требования. 2 инкрем предусматр модификацию базового продукта, обеспечив дополнит характер и функционал. инкремен процесс итеративен, но, в отличие от макетирования, инкрементная модель обеспеч на каждом инкременте работающий продукт.

Модель быстрой разработки приложений 2 пример применения инкрементной стратегии конструирования. RAD-модель обеспеч экстремально короткий цикл разработки. RAD  высокоскор адаптация линейной последоват модели, в которой быстрая разработка достигается за счет использов компонентно-ориентиров конструиров. Если требов полностью определены, а проектная обл ограничена, RAD-процесс позволяет группе создать полностью функционал систему за очень короткое время. RAD-подход ориентир на разработку ис и выделяет след этапы: бизнес-моделирование. Моделир информац поток между бизнес-функциями. моделиров данных. Информац поток, определенный на этапе бизнес-моделирования, отображается в набор объектов данных, которые треб для поддержки бизнеса. моделиров обработки Определ преобразования объектов данных, обеспечив реализацию бизнес-функций. Создаются описания обработки для добавления, модификации, удаления или нахождения объектов данных; генерация приложения Предполаг использ методов, ориентиров на языки программир 4-го поколения. Для обеспечения конструиров использ утилиты автоматизации; тестирование и объединение. применяются повторно использу компоненты, многие програм элемен уже протестированы. Это уменьшает время тестирования.

Примене RAD возможно в том случае, когда каждая главная функция может быть завершена за 3 месяца. Каждая главная функция адресуется отдельной группе разработчиков, а затем интегрируется в целую систему. Применение RAD имеет- и свои недостатки, и ограничения: Для больших проектов в RAD треб существенные людские ресурсы; RAD применима только для таких прилож, которые могут декомпозиров на отдельные модули и в которых производител не явл критическ величиной; RAD не применима в условиях высоких технич рисков. Спиральная модель классич пример примен эволюционной стратегии конструиров.

1.Планиров определение целей, вариантов и ограничений. 2. Анализ риска- анализ вариантов и распознаван/выбор риска. 3.Конструиров- разработ продукта следующего уровня. 4. Оценивание-оценка заказчик текущих результ конструиров. Интегрирующий аспект спирал модели очевиден при учете радиального измерения спирали. С каждой итерацией по спирали (продвижением от центра к периферии) строятся все более полные версии ПО. В первом витке спирали определ начальн цели, варианты и огранич, распознается и анализируется риск. Если анализ риска показывает неопределенность треб, на помощь разработч и заказч приходит макетирование. Для дальнейшего определ проблемных и уточненных требов может быть использ моделирование. Заказчик оценивает инженерную работу и вносит предложения по модификации. След фаза планиров и анализа риска базируется на предложениях заказчика. В каждом цикле по спирали результаты анализа риска формируют в виде «продолжать, не продолжать». Если риск слишком велик, проект может быть остановлен. В большинстве случаев движение по спирали продолж, с каждым шагом продвигая разработч к более общей модели системы. В каждом цикле по спирали требуется конструиров, которое может быть реализовано классич жц или макетированием. Заметим, что кол-во действий по разработке возрастает по мере продвижения от центра спирали. Достоин спирал мод: наиболее реально (в виде эволюции) отображает разработку по; позволяет явно учитывать риск на каждом витке эволюции разработки; включ шаг системного подхода в итерационную структуру разработки; испол моделиров для уменьш риска и совершенствов програм изделия. Недостат спирал мод: новизна; повышенные требов к заказч; трудности контроля и управл временем разработки.