Лекция: Анализ полученного расписания

Ввод и распределение ресурсов для выполнения проекта

Первоначально вводится общий список ресурсов. Выделяют 3 вида ресурсов:

1. Ресурс, т.е. исполнители. Для данного вида указывается либо почасовая стоимость, либо оклад ресурса в месяц;

2. Удельная стоимость определяет используемые материалы с указанием стоимости за единицу (шт, кг и т.д.);

3. Разовые затраты – стоимость в виде единовременной суммы.

 

Каждый введенный ресурс имеет свои параметры в зависимости от его типа. При этом основным параметром является его стоимостная оценка и доступность на основе индивидуального календаря. Распределение ресурсов производится отдельно для каждой задачи проекта с учетом доступности данного ресурса и возможного приоритета задачи.

Анализ полученного расписания

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

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

2. Если срок окончания проекта изменять нельзя, т.е. длительность задач не изменяется, а на задачу вводятся дополнительные ресурсы, т.е. увеличивается стоимость проекта.

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

 

14. Руководство проектом. Контроль за исполнением проекта.

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

При контроле в первую очередь идет анализ выполнения задач критического пути. Критический путь – это самый продолжительный путь от начала до окончания проекта. Критические задачи не имеют временных резервов, поэтому именно их задержка приводит к срыву проекта. При этом контроль за выполнением задач может быть полный или краткий. Краткий контроль предполагает, что для каждой задачи, которая в данный момент выполняется или должна быть выполнена, указывается либо 0, либо 100% выполнения. Полный контроль допускает указание любого процента выполнения в пределах 0…100%. Если задачи являются невыполнимыми согласно исходного плана, то выполняется их сдвиг за пороговую дату. При этом получается новое расписание с новыми сроками с новыми сроками и стоимостью. Данный процесс выполняется регулярно до завершения проекта (обычно раз в 2 недели).

Для получения отчетов используются специальные средства пакетов, позволяющие формировать как простые, так и перекрестные отчеты.

При работе на всех этапах используются различные графические средства, отображающие сущность проекта:

1. Расширенная диаграмма Гантта, на которой отображается список задач проекта в виде фрагмента электронной таблицы, набор столбцов в которой можно подобрать по своему усмотрению. Справа от таблицы расположена временная диаграмма, отображающая продолжительность задач в определенном временном масштабе;

2. Сетевая диаграмма, где отображаются взаимосвязи задач проекта;

3. Гистограммы загрузки ресурсов для отображения профиля загрузки конкретного ресурса;

4. Гистограмма стоимости для проекта.

 

15. Особенности ценообразования программных продуктов.

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

Экономическая ситуация – разработка ПП определяется периодом от 2 до 5 лет, поэтому получение прибыли откладывается на более поздний срок. Выход из данной ситуации – привлечение фирм для разработки ПП. Следует отметить низкую покупательную способность пользователей;

Большинство фирм-разработчиков не имеет достаточного количества высокопрофессиональных аналитиков и разработчиков;

Не накоплен опыт формализации процесса разработки и соответствующих методик оценки стоимости;

Отсутствие инфраструктуры рынка программных продуктов. То сопровождение, которое является неотъемлемой частью программного продукта, у нас достаточно низкого качества;

Отсутствие четкой и стабильной системы законов в области правовой охраны.

Ввиду того, что производство ПП имеет высокую степень неопределенности, оценка затрат производится постепенно, при этом используются подходы, аналогичные подходам к оценке любого объекта интеллектуальной собственности:

Затратный;

Рыночный;

Доходный.

 

16. Конструктивная модель стоимости: затратный подход.

Основан на расчете стоимости программного продукта в процессе его разработки. К числу основных параметров относят:

1. Число условных машинных команд;

2. Сложность ПП;

3. Степень новизны;

4. Степень использования старых модулей.

 
 

n – количество этапов разработки ПП,

m – количество этапов системы, по которым производится оценка,

t – количество видов затрат в каждом элементе системы,

Si – затраты.

Все затраты подразделяются по следующим группам:

1. Затраты на проектирование и разработку системы;

2. Затраты на эксплуатационные материалы;

3. Затраты на внедрение и освоение программного продукта;

4. Прочие расходы, связанные с корреспонденцией и различными организационными мероприятиями.

Пример модели оценки стоимости (КОМОСТ – конструктивная модель стоимости):

Данная модель представляет собой последовательный процесс с разбиением на ряд уровней. При этом каждый уровень представляет собой уточненную модель стоимости. В — основном, выделяют 3 уровня иерархии: базовая, промежуточная и детальная.

Базовая модель основана на предварительной оценке стоимости программного изделия в зависимости от числа исходных команд. При этом основными элементами являются: Человеко — Месяцы, срок разработки программного изделия.

кЧИК – кило Число Исходных Команд;

ЧМ – ЧеловекоМесяц;

ЧМ = 2,4*кЧИК1,05;

Срок разработки: СР = 2,5*чм0,38.

При этом при рассмотрении исходных команд следует учитывать количество строк исходного текста. Исходные команды не включают комментарии и библиотечные модули.

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

Детальная модель предполагает уточнение каждого из 15 атрибутов промышленной модели внесение соответствующих корректировок в стоимость.

 

17. Конструктивная модель стоимости: рыночный подход.

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

1. Производственные факторы;

2. Тенденции изменения рыночных цен;

3. Условия продаж и конкуренции;

4. Рекламные элементы;

5. Элементы правовой охраны программных продуктов;

6. Авторитет разработчика.

 

Основными критериями при расчете новой цены ПП используются тестовые критерии применительно к самому ПП, а именно:

1. Функциональная полнота ПП;

2. Надежность ПП;

3. Удобство исполнения, интерфейс;

4. Система помощи;

5. Средства обучения;

6. Документация;

7. Расходы на последующее сопровождение.

 

При рассмотрении различных критериев, по которым сравниваются ПП, определяется их вес, т.е. Значимость по отношению ко всему набору критериев.

Пример: N критериев Кi, i=1…N.

 

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

 

A — общая сумма критериев

На пересечении соответствующего столбца и соответствующей строки располагаются значения аi, которые могут иметь три значения:

2, кi>kj

аi = 1, кi=kj

0, кi<kj

 

  k1 k2 …… kn Saij ai
k1 k2:: kn a11 a12…… a1n a21 a22…… a2n:: :: :: :: :::: :: :: :: :: an1 an2…… ann ::::::  
    SS aijij =A

 

18. Конструктивная модель стоимости: доходный подход.

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

1. Выбор цели, для которой разрабатывается ПП (автоматизация собственной деятельности, выживаемость, максимизация прибыли, завоевание рынков);

2. Определение уровня спроса;

3. Оценка собственных издержек;

4. Анализ цен аналогов и конкурентов;

5. Выбор метода определения цены, например, на основании средних издержек, анализа безубыточности, объективной ценности ПП;

6. Окончательное определение цены.

 

19. Проектирование программного изделия. Основные этапы.

Проектирование системы:

— проектирование архитектуры системы;

— детальное проектирование компонент системы, в т.ч. для программного обеспечения;

Этап проектирования подразумевает разработку архитектуры, разработку данных и процедурную разработку программных средств.

Проектирование – это итерационный процесс.

Обычно в проектировании выделяют две ступени: предварительное проектирование и детальное проектирование.

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

Схема информационных связей процесса проектирования приведена на рисунке 9.2

 

 


Информационные связи процесса проектирования

 

Предварительное проектирование обеспечивает:

– идентификацию подсистем;

– определение основных принципов управления подсистемами, взаимодействия подсистем.

 

Предварительное проектирование включает три типа деятельности:

1) Структурирование системы. Система структурируется на несколько подсистем, где под подсистемой понимается независимый программный компонент. Определяются взаимодействия подсистем.

2) Моделирование управления. Определяется модель связей управления между частями системы.

3) Декомпозиция подсистем на модули. Каждая подсистема разбивается на модули. Определяются типы модулей и межмодульные соединения.

 

20. Системный анализ. Требования при разработке технического задания.

еще рефераты
Еще работы по информатике