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

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

Програм компон, созданные в реализованных прогр проектах, хранятся в библиот. В новом програм проекте, исходя из требов заказч, выявля кандидаты в компоненты. Далее проверяется наличие этих кандидатов в библиот. Если они найдены, то компон извлек из библиот и использ повторно. В противном случае создаются новые компон, они примен в проекте и включаются в библиот. Достоин компон ориентир модели: уменьшает на 30% время разработки програм продукта; уменьшает стоимость програм разработки до 70%; увелич в1,5 раза производит разработки.

3.Процесс  руководства проектом

Руководство програм  проектом- первый слой процесса конструир  ПО. Термин «слой» подчерк, что руковод опред сущность процесса разработ от его начала до конца.

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

4.Планирование  проектных задач

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

Результаты анализа  сводятся в спецификацию требований к програм продукту. задачи по проектиров и планиров тестов могут быть распараллелены. Благодаря модульной природе ПО для каждого модуля можно предусмотреть параллельный путь для детального проектир, кодиров и тестиров. После получения всех модулей ПО решается задача тестир интеграции объединения элем в единое целое. Далее проводится тестиров правильности, которое обеспеч проверку соответствия ПО требов заказч. Ромбиками обознач вехи- процедуры контроля промежуточ результ. Вехи распростран и на документац как на один из результ успешн решения задачи. параллельные задачи выполн асинхронно, планировщик должен опред межзадачные зависимости. Это гарантир «непрерывность движения к объединению». руководит проекта должен знать задачи, лежащие на критическом пути. Для того чтобы весь проект был выполнен в срок, необход выполнять в срок все критич задачи. Основн рычаг в планирующих методах вычисление границ времени выполн задачи. использ след оценки: 1. Раннее время начала решения задачи (при условии, что все предыдущие задачи решены в кратчайшее время).2. Позднее время начала решения задачи (еще не вызывает общую задержку проекта). Раннее время конца решения задачи . . 4. Позднее время конца решения задачи . . 5. Общий резерв-кол-во избытков и потерь планиров задач во времени, не приводящих к увелич длительн критическ пути Т_к.п. Все эти значения позволяют руководит кол-венно оценить успех в планиров, выполнении задач. Рекоменд правило распределения затрат проекта -40-20-40: на анализ и проектирование приходится 40% затрат (из них на планиров и системный анализ-5%); на кодирование-20%;

на тестирование и  отладку-40%.