Заглавная страница Избранные статьи Случайная статья Познавательные статьи Новые добавления Обратная связь КАТЕГОРИИ: АрхеологияБиология Генетика География Информатика История Логика Маркетинг Математика Менеджмент Механика Педагогика Религия Социология Технологии Физика Философия Финансы Химия Экология ТОП 10 на сайте Приготовление дезинфицирующих растворов различной концентрацииТехника нижней прямой подачи мяча. Франко-прусская война (причины и последствия) Организация работы процедурного кабинета Смысловое и механическое запоминание, их место и роль в усвоении знаний Коммуникативные барьеры и пути их преодоления Обработка изделий медицинского назначения многократного применения Образцы текста публицистического стиля Четыре типа изменения баланса Задачи с ответами для Всероссийской олимпиады по праву Мы поможем в написании ваших работ! ЗНАЕТЕ ЛИ ВЫ?
Влияние общества на человека
Приготовление дезинфицирующих растворов различной концентрации Практические работы по географии для 6 класса Организация работы процедурного кабинета Изменения в неживой природе осенью Уборка процедурного кабинета Сольфеджио. Все правила по сольфеджио Балочные системы. Определение реакций опор и моментов защемления |
Эмпирические оценочные моделиОценочная модель для программных изделий использует формулу для получения оценочных данных. Для вывода формулы используются опытные данные, полученные в предыдущих разработках. Обычно выделяются классы программных продуктов, и для каждого класса используется своя формула, т.е. универсальных моделей, пригодных для любых проектов, нет. Модели, которые позволяют предсказать усилия на разработку изделия (в человеко-месяцах) и длительность проектирования (в хронологических месяцах или годах), получили название ресурсных моделей и обычно состоят из одной или нескольких эмпирически выведенных формул. Разработано несколько классов моделей. Одной из наиболее распространенных и используемых на практике является Конструктивная модель стоимости — СОСОМО (Constructive Cost Model). Эта модель применима к трем типам программных систем: 1. Изолированный тип — относительно небольшие программные проекты, в разработке которых участвуют небольшие коллективы с хорошим прикладным опытом работы. Требования к программному изделию при этом не очень жесткие. 2. Полуизолированный тип — промежуточные по размеру и сложности проекты, в разработке которых участвуют группы специалистов с разным уровнем опыта и квалификации. Отдельные требования к программному изделию или базе данных могут быть весьма жесткими. 3. Встроенный тип — когда проект разрабатывается внутри очень строгих ограничений и требований. Конструктивная модель стоимости представлена иерархией моделей: 1. Базовая модель — основная — это статическая модель с одной переменной. Модель позволяет рассчитать усилия и стоимость разработки программного изделия. Параметром модели служит размер изделия в тысячах строк кода (KLOC). Базовая модель дает возможность получить не только интегральные оценки показателей трудозатрат в целом по всему проекту, но и определить трудозатраты и сроки выполнения работ как по фазам ЖЦПИ, так и по основным видам деятельности. 2. Промежуточная модель представляет собой развитие базовой модели и дает более точные оценки трудозатрат. Отличие модели заключается в использовании совокупности стоимостных атрибутов, или коэффициентов изменения трудоемкости, характеризующих особенности конкретного проекта и условия его разработки. 3. Детальная модель предназначена для более подробного учета деталей проекта и обеспечивает более точные оценки трудозатрат, сроков и стоимости разработки программного изделия. Основная особенность детальной модели — трехуровневая иерархическая декомпозиция программного изделия: система — подсистема — модуль. Другое отличие от промежуточной модели состоит в том, что коэффициенты изменения трудоемкости определяются индивидуально для каждой фазы ЖЦПИ. Для оценки стоимости и затрат усилий на разработку используются следующие уравнения базовой модели СОСОМО: Е = а • (KLOC) • ехр (Ь); D = с - (Е) • exp (d), где Е — требуемые усилия (в человеко-месяцах); D — хронологическое время разработки (в месяцах); а, Ь, с, d — коэффициенты, представленные в табл. 11.1. Таблица 11.1
Базовая модель расширяется и превращается в промежуточную при условии учета совокупности атрибутов, оказывающих влияние на стоимость разработки. Обычно атрибуты группируются в четыре основные категории. 1. Атрибуты программного продукта: • требуемая надежность; • размер прикладной базы данных; • сложность программного продукта. 2. Атрибуты технических средств: • ограничения на время прогона программы; • ограничения на объем памяти; • требуемое время цикла обработки. 3. Атрибуты персонала разработчиков: • квалификация системного аналитика; • опыт в данной прикладной области; • опыт работы с принятой в проекте средой разработки. 4. Атрибуты среды проектирования: • применение современных методов программотехники; • использование специальных инструментальных средств для разработки программного обеспечения. Каждый из перечисленных атрибутов располагается в пределах шкалы значений, диапазон которой изменяется от "очень низкий" до "чрезвычайно высокий". На основе специально составленной таблицы, основанной на опыте разработки подобных проектов, определяется множитель корректировки усилий. Типичные значения этих множителей лежат в пределах от 0,9 до 1,4. Управление рисками При планировании разработки программного изделия необходимо учитывать имеющиеся многочисленные источники и угрозы рисков в проекте. Риск касается как будущего, так и выбора, причем любому выбору присуща неопределенность. Важным моментом при планировании является анализ риска. Примерами областей возможного риска служат: • качество и стабильность требований пользователя; • стабильность и полнота описания внешних интерфейсов; • опыт и квалификация кадров; • техническая новизна проекта и т.п. Анализ риска включает четыре разных вида деятельности: 1. Идентификация риска. 2. Описание риска. 3. Оценка риска. 4. Управление риском. Прежде всего необходимо идентифицировать все возможные риски и систематизировать их по категориям. На самом верхнем уровне можно выделить следующие группы: • риск проектирования; • технический риск; • бизнес-риск (деловой риск). Риски проектирования включают риски, связанные с неопределенностью в финансировании проекта, в квалификации персонала, непостоянством требований заказчика, несвоевременными поставками технических и программных средств и т.д. Кроме того, как уже отмечалось, факторами риска являются сложность и размер программного изделия. Технический риск появляется в результате того, что разработчик на первых этапах не может предвидеть всех сложностей, которые проявятся на этапах разработки, т.е. проблема всегда сложнее, чем она оценивается вначале. Наиболее коварный — деловой риск. Например, создан прекрасный продукт, который еще не соответствует требованиям рынка, либо созданный продукт не соответствует стратегической линии компании, либо прекращено бюджетное финансирование и т.п. После составления подробного перечня возможных рисков делается попытка описать каждый из выявленных рисков с точки зрения вероятности его проявления и с точки зрения тех последствий, которые с ним связаны. С этой целью устанавливается шкала, отражающая вероятность риска с точки зрения управленца и проектировщика, оценивается влияние риска на проектирование и на продукт. Три фактора определяют степень влияния риска: природа риска, область его действия и время действия. Природа риска показывает, с какими проблемами столкнется разработчик и управленец, когда событие произойдет. Область действия (влияния) риска показывает, что будет затронуто в проекте и скольким пользователям будет причинен ущерб и т.д. Временной фактор риска характеризует, когда и как долго будет ощущаться его влияние. В результате анализа каждый риск характеризуется вероятностью его появления и степенью влияния. При этом важно установить приоритеты рисков, которые для большинства проектов рассматриваются с точки зрения возможного нарушения графика работ, превышения выделенных ассигнований и нарушений требований пользователя. Уже на этапе описания рисков необходимо думать о путях предотвращения наиболее из них опасных, т.е. об управлении рисками. Для больших проектов обычно выделяется от тридцати до сорока основных рисков, и для каждого из них намечаются шаги по их предотвращению. Вся эта информация сводится в план управления рисками. Примером риска может быть текучесть кадров. Предположим, что на основе предыдущих разработок известна ее вероятность, а влияние текучести оценивается процентом повышения длительности разработки проекта. Тогда для управления этим риском необходимо: • определить причины текучести (оплата, условия работы); • наметить действия, смягчающие эти причины; • постоянно контролировать ситуацию; • подготовить дублеров по критическим специальностям; • организовать рабочие бригады и т.д. Очевидно, что эти действия увеличивают первоначальную стоимость проекта, поэтому планировщик работ должен провести анализ затрат-выгод, чтобы либо обосновать проведение работ, либо отказаться от них. При анализе всей совокупности рисков целесообразно воспользоваться правилом Парето, так как опыт показывает, что двадцать процентов рисков являются причиной восьмидесяти процентов возможных нарушений в разработке проекта. Задача состоит в определении этих двадцати. Решения о приоритетах принимаются после анализа рисков. Планирование разработки программного изделия Ключевым моментом при планировании деятельности по созданию программного изделия является оценка временнЫх интервалов, необходимых для выполнения отдельных работ, и оценка потребных ресурсов. Основной подход к составлению подробного плана разработки — анализ проекта с целью выделения отдельных небольших задач, стоимость и время выполнения которых можно оценить достаточно просто и точно. В результате объединения этих частных позадачных оценок можно получить сводные оценки общего времени разработки и ресурсов, необходимых для выполнения всего проекта. Каждая задача должна быть связана с соответствующей частью или компонентой, которая должна быть реализована для рассматриваемой фазы. Например, для фазы разработки требований к программному изделию задача может относится к отдельному требованию или их группе, а на фазе архитектурного проектирования — к отдельной компоненте. Оценки для детального проекта традиционно связаны с числом строк кода. Для планирования проектной деятельности широко используется метод нисходящего разделения работ, позволяющий составить иерархию задач, которые должны быть выполнены в процессе проектирования. Эти задачи объединяются в пакеты. Описание пакета определяет задачи с такой степенью детализации, которая позволяет отдельным работникам или небольшим группам работать независимо. При этом устанавливают даты начала и окончания работ, и интервал должен быть таким, чтобы сохранить обозримость процесса разработки. Такие процедурно-ориентированные пакеты могут распространяться на весь процесс проектирования и включаться в сводный график выполняемых работ с распределением людских, финансовых и технических ресурсов. Точность составления графика выполнения работ иногда оказывается более важной, чем точность в оценке стоимости. На графике работ приводятся ре-перные точки, отражающие ключевые события в проекте и связанные с хронологическими датами выполнения проекта. Документом, в соответствии с которым осуществляется проектирование, является План управления проектированием программного изделия. Этот план определяет технические и управляющие функции, виды деятельности и задачи, выполнение которых необходимо для удовлетворения требований к программному изделию. Он обновляется и совершенствуется на протяжении жизненного цикла изделия. Эффективным средством для контроля за ходом выполнения плана служит сетевой график, который отражает последовательность и продолжительность отдельных работ в виде графа. Узлы графа представляют собой события-работы, которые должны быть выполнены, а дуги графа — последовательность выполнения работ с указанием требуемого времени выполнения. На основе сетевого графика с использованием специальных программных пакетов появляется возможность не только отслеживать процесс выполнения плана, но и постоянно проводить уточнение оценок времени выполнения работ и определять критический путь в графике работ.
|
||||||||||||
Последнее изменение этой страницы: 2017-02-07; просмотров: 161; Нарушение авторского права страницы; Мы поможем в написании вашей работы! infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 35.153.106.141 (0.004 с.) |