Курсовая

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

Работа добавлена на сайт bukvasha.net: 2014-12-09

Поможем написать учебную работу

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

Предоплата всего

от 25%

Подписываем

договор

Выберите тип работы:

Скидка 25% при заказе до 23.11.2024


ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ
СТАВРОПОЛЬСКИЙ ГОСУДАРСТВЕННЫЙ АГРАРНЫЙ УНИВЕРСИТЕТ
КУРСОВАЯ РАБОТА
на тему: «Выполнение оценки в ходе руководства проектом разработки программного обеспечения концерна “Суперавто”»
По дисциплине «Разработка и стандартизация программных средств и информационных технологий»
Выполнила студентка 4 курса, 7 группы
Специальность: Прикладная информатика
(в области экономики)
Тарасова Анастасия Сергеевна
Проверил: д.т.н., доц. кафедры
Прикладной информатики
Канивец В.Ю.
Ставрополь, 2006

Введение
Известно, что основной задачей первых трех десятилетий компьютерной эры являлось развитие аппаратных компьютерных средств. Современный персональный компьютер теперь имеет производительность большой ЭВМ 80-х годов. Сняты практически все аппаратные ограничения на решение задач. Оставшиеся ограничения приходятся на долю ПО.
Чрезвычайно актуальными стали следующие проблемы:
1.     аппаратная сложность опережает наше умение строить ПО, использующее потенциальные возможности аппаратуры;
2.     наше умение строить новые программы отстает от требований к новым программам;
3.     нашим возможностям эксплуатировать существующие программы угрожает низкое качество их разработки.
Ключом к решению этих проблем является грамотная организация процесса создания ПО, реализация технологических принципов промышленного конструирования программных систем (ПС).
Компьютерные науки вообще и программная инженерия в частности — очень популярные и стремительно развивающиеся области знаний. Обоснование простое: человеческое общество XXI века — информационное общество. Об этом говорят цифры: в ведущих странах занятость населения в информационной сфере составляет 60%, а в сфере материального производства — 40%. Именно поэтому специальности направления «Компьютерные науки и информационные технологии» гарантируют приобретение наиболее престижных, дефицитных и высокооплачиваемых профессий. Так считают во всех развитых странах мира. Ведь не зря утверждают: «Кто владеет информацией — тот владеет миром!»
Поэтому понятно то пристальное внимание, которое уделяет компьютерному образованию мировое сообщество, понятно стремление унифицировать и упорядочить знания, необходимые специалисту этого направления. Одними из результатов такой работы являются международный стандарт по компьютерному образованию Computing Curricula 2001 — Computer Science и международный стандарт по программной инженерии IEEE/ACM Software Engineering Body of Knowledge SWEBOK 2001.
Для проведения успешного проекта нужно понять объем предстоящих работ, возможный риск, требуемые ресурсы, предстоящие задачи, прокладываемые вехи, необходимые усилия (стоимость), план работ, которому желательно следовать. Руководство программным проектом обеспечивает такое понимание. Оно начинается перед технической работой, продолжается по мере развития ПО от идеи к реальности и достигает наивысшего уровня к концу работ.
Перед планированием проекта следует:
1.     установить цели и проблемную область проекта;
2.     обсудить альтернативные решения;
3.     выявить технические и управленческие ограничения.
При планировании программного проекта надо оценить людские ресурсы (в человеко-месяцах), продолжительность (в календарных датах), стоимость (в тысячах долларов). Обычно исходят из прошлого опыта. Если новый проект по размеру и функциям похож на предыдущий проект, вполне вероятно, что потребуются такие же ресурсы, время и деньги.
В данной работе используются размерно-ориентированные метрики за-трат. Размерно-ориентированные метрики прямо измеряют программный продукт и процесс его разработки. Основываются размерно-ориентированные метрики на LOC-оценках (Lines Of Code). LOC-оценка — это количество строк в программном продукте. Цель этой деятельности — сформировать предварительные оценки, которые позволят:
•предъявить заказчику корректные требования по стоимости и затратам на разработку программного продукта;
•составить план программного проекта.
В курсовой работе для оценивания затрат используется также модель COCOMO II. Автор оригинальной модели — Барри Боэм. СОСОМО II — авторитетная и многоплановая модель, позволяющая решать самые разнообразные задачи управления программным проектом. Факторы затрат оказывают существенное влияние на выходные параметры программного проекта.
В курсовой работе для оценки программного продукта используется модель этапа постархитектуры, являющаяся подмоделью СОСОМО II. Модель этапа постархитектуры используется в период, когда уже сформирована архитектура и выполняется дальнейшая разработка программного продукта.
Далее приведена предварительная оценка программного проекта на основе LOC-метрик; расчеты затрат на разработку ПО, стоимости проекта, длительности его разработки на основе модели этапа постархитектуры конструктивной модели стоимости СОСОМО II.

Задание № 1
Выполнить предварительную оценку программного проекта на основе LOC – метрик.
Поступил заказ на разработку ПО от концерна «Суперавто». Следует создать ПО для рабочей станции дизайнера автомобиля. Выполняя предварительную оценку программного проекта на основе LOC – метрик, будем исходить из начальных данных оценки проекта (табл.1) и данных из метрического базиса фирмы (табл.2).
Таблица1 – Начальные оценки проекта
Функция
Лучшая
Вероятная
Худшая
Ожидаемая
Уд.ст-сть
Ст-сть
Производительность
Затраты
(LOC)
(LOC)
(LOC)
(LOC)
($/LOC)
($)
(LOC/чел.-мес.)
(чел.-мес.)
СУПИ
700
1500
2650
А2Г
2900
3200
7400
А3Г
3000
5100
8600
УБД
2800
3800
4100
КДГ
4050
5900
6500
УП
2000
2250
3100
МПА
5900
8500
9100
Итого:
Таблица 2 – Данные из метрического базиса фирмы
Функция
Аналогов.
Аналоговая
Аналоговая
(LOC)
уд.ст-сть
производительность
($/LOC)
(LOC/чел.-мес.)
СУПИ
615
18
1240
А_Г
2050
22
460
УБД
1121
16
800
КДГ
2300
24
310
УП
230
26
1400
МПА
1400
16
2050

Исходные формулы для расчета показателей:
 QUOTE    (1)
 QUOTE    (2)
 QUOTE    (3)
 QUOTE    (4)
Теперь мы имеем все необходимые данные для завершения расчетов. Заполним до конца таблицу оценки нашего проекта (табл.3).
Таблица 3 – Предварительная оценка программного проекта
Функция
Лучшая (LOC)
Вероятная
(LOC)
Худшая (LOC)
Ожидаемая
 (LOC)
Уд. Ст-ть
($/LOC)
Ст-ть($)
Приозводи
тельность
(LOC/чел.-мес.)
Затраты (чел.-мес.)
СУПИ
700
1500
2650
1558
18
28050
489
3
А2Г
2900
3200
7400
3850
22
84700
245
16
А3Г
300
5100
8600
4883
22
107433
193
25
УБД
2800
3800
4100
3683
16
58933
243
15
КДГ
4050
5900
6500
5692
24
136600
125
45
УП
2000
2250
3100
2350
26
61100
137
17
МПА
5900
8500
9100
8167
16
130667
351
23
Итого:
30183
607483
145
Из табл. 3 видно, что наибольшую удельную стоимость имеет строка функции управления периферией (требуются специфические и конкретные знания по разнообразным периферийным устройствам), наименьшую удельную стоимость — строка функции управления пользовательским интерфейсом (применяются широко известные решения). Также следует заметить, что, несмотря на то, что функция управления пользовательским интерфейсом имеет самую низкую стоимость, она же обладает самой высокой производительностью. Совершенно противоположными свойствами обладает функция управления периферией.
Предварительная оценка программного продукта дает нам следующие результаты: ожидаемое количество строк программного продукта составило
30183 LOC, стоимость продукта составит 607483 $, а затраты – 145 чел. – мес.
Задание № 2
Используя модель этапа пост – архитектуры конструктивной модели COCOMO II определить:
·                   затраты на разработку ПО;
·                   стоимость проекта;
·                   длительность разработки проекта.
Поступил заказ на разработку ПО от концерна «Суперавто». Следует создать ПО для станции дизайнера автомобиля.
Автоматическая генерация кода и повторное использование компонентов не предусматриваются.
Средняя заработная плата в команде предусматривается 6200 $ в месяц. Также известны оценка масштабных факторов (табл.4) и оценка пост – архитектурных факторов затрат (табл.5).
Таблица 4 – оценка масштабных факторов
Масштабный фактор Wi
Значения
PREC
3
FLEX
1
RESEL
4
TEAM
3
PMAT
1
В
1,13
Зная оценку пост – архитектурных факторов затрат для проекта, в табл. 5 внесем значения множителей формирователей затрат для каждой функции. В табл. 5 также укажем множитель поправки ( ), который определяется по формуле:

где:
EMi – формирователь затрат.
Таблица 5 – Оценка пост – архитектурных факторов затрат
Фактор
Описание
Оценка
Множитель
RELY
Требуемая надежность ПО 
Номинальная
1
DATA
Размер базы данных 
Низкая
0.93
CPLX
Сложность продукта 
Очень высокая
1.3
RUSE
Требуемая повторная используемость
Низкая 
0.91
DOCU
Документирование жизненного цикла 
Номинальная
1
TIME
Ограничения времени выполнения 
Высокая
1.1
STOR
Ограничения оперативной памяти 
Высокая
1.06
PVOL
Изменчивость платформы
Номинальная
1
ACAP
Возможности аналитика 
Низкая 
1.22
PCAP
Возможности программиста 
Низкая 
1.16
AEXP
Опыт работы с приложением 
Номинальная
1
PEXP
Опыт работы с платформой 
Низкая 
1.12
LTEX
Опыт работы с языком и утилитами 
Номинальная
1
PCON
Непрерывность персонала 
Высокая
0.92
TOOL
Активное использование программных утилит
Высокая
0.86
SITE
Мультисетевая разработка
Низкая 
1.1
SCED
Требуемый график разработки
Номинальная
1
Множитель поправки Мр
1.77

Используя модель этапа пост-архитектуры конструктивной модели стоимости СОСОМО II, определим:
- затраты на разработку ПО;
- стоимость проекта;
- длительность разработки проекта.
Произведем расчет затрат на разработку ПО, применяя формулу (6):
, (6)
где:
А=2,5(const)
B – показатель степени;
 (7)
где:
 - масштабный фактор, указанный в табл. 4;
: PREC (предсказуемость) – отражает опыт организации в реализации проектов данного типа;
* : FLEX (гибкость разработки) – отражает степень гибкости процесса разработки;
: RESL (риск) – отражает степень выполняемого анализа риска;
: TEAM (связанность группы) – отражает, насколько хорошо разработчики группы знают друг друга и насколько удачно вместе работают;
: PMAT (зрелость процесса) – означает зрелость процесса в организации;
 - коэффициент, учитывающий возможные изменения требований;

, (8)
где BRAK – процент кода, отброшенного (модифицированного) из-за изменения требований;
, (9)
где:
 – размер нового, создаваемого программного кода;
; (10)
, (11)
где:
KASLOC – количество строк повторно используемого кода, который должен быть модифицирован;
AT – процент автоматически генерируемого кода;
АА – фактор, отражающий решение о том, может ли программное обеспечение быть повторно используемым;
SU – фактор, основанный на стоимости добавляемого программного обеспечения;
DМ – процент модифицируемых проектных модулей;
СМ – процент модифицируемого программного кода;
IM – процент затрат, требуемых для подключения повторно используемого программного обеспечения;
Мp – множитель поправки, указанный в табл. 5;
ЗАТРАТЫauto – затраты на автоматическую генерацию кода;

, (12)
где ATPROD – производительность автоматической генерации кода.
Исходя из того, что автоматическая генерация кода и повторное использование его компонентов не предусматриваются, имеем:  = 0 и . Расчет затрат приведен в табл. 6:
Таблица 6 – Расчет затрат программного проекта
A
2,5
Размер new= KLOC ожид
30,183
Размер reuse
0
Размер (KLOC)
30,183
РазмерВ (KLOC)
47,00
B
1,13
Мр
1,77
Brak
5
K req
1,05
Затраты auto
0
Затраты (чел/мес.)
218
Произведем расчет стоимости разработки программного проекта, воспользовавшись формулой (13). Результаты вычислений стоимости сведем в табл. 7.
Стоимость = , (13)
где - средняя заработная плата в команде.
Таблица 7 – Расчет стоимости программного проекта
Затраты (чел./мес.)
218
Рабочий коэффициент
6700
Стоимость, $
1460600

Длительность выполнения разработки ПО рассчитывается по формуле (14):
, (14)
где SCEDтребуемый график разработки.
Результаты вычислений длительности внесем в табл. 8.
Таблица 8 – Расчет длительности программного проекта
Затраты (чел.-мес.)
218,00
Требуемый график разработки (SCED)
1,00
В
1,13
Затраты0,33+0,2*(B-1,01)
6,73
Длительность (чел.-мес.)
0,20
Таким образом, можно сделать вывод, что затраты на разработку ПО составляют 218,00 (чел.-мес.), стоимость проекта равна 1460600 $, а длительность разработки данного проекта составила 0,20 (мес.), то есть 6 дней. Таковы стартовые условия программного проекта.
Задание № 3
Определение выигрыша (проигрыша) в стоимости проекта на разработку программного обеспечения концерна “Суперавто” с помощью модели СОСОМО II и с учетом изменения зарплаты и возможностей сотрудников. Заказчик решил повысить зарплату разработчиков. Причина - повышение квалификации аналитика и программиста. В итоге зарплата сотрудников повышается до 7000 $. Оценки их возможнотей становятся номинальными, то есть EMACAP=EMPCAP=1. Требуется определить выигрыш (проигрыш) в стоимости проекта.
Учитывая изменения оценки возможностей аналитика и программиста, произведем расчет множителя поправки (формула 5). Полученные данные внесем в табл. 9.
Таблица 9 – Оценка пост-архитектурных факторов затрат с учетом изменений возможностей аналитика и программиста
Фактор
Описание
Оценка
Множитель
RELY
Требуемая надежность ПО
Номинальная
1
DATA
Размер базы данных
Низкая
0.93
CPLX
Сложность продукта
Очень высокая
1.3
RUSE
Требуемая повторная используемость
Низкая
0.91
DOCU
Документирование жизненного цикла
Номинальная
1
TIME
Ограничения времени выполнения
Высокая
1.1
STOR
Ограничения оперативной памяти
Высокая
1.06
PVOL
Изменчивость платформы
Номинальная
1
ACAP
Возможности аналитика
Номинальная
1
PCAP
Возможности программиста
Номинальная
1
AEXP
Опыт работы с приложением
Номинальная
1
PEXP
Опыт работы с платформой
Низкая
1.12
LTEX
Опыт работы с языком и утилитами
Номинальная
1
PCON
Непрерывность персонала
Высокая
0.92
TOOL
Активное использование программных утилит
Высокая
0.86
SITE
Мультисетевая разработка
Низкая
1.1
SCED
Требуемый график разработки
Номинальная
1
Множитель поправки Мр
1.25
Пользуясь формулами (5-13), аналогично производим расчет затрат и стоимости программного продукта, с измененным сценарием разработки. Следствием такого решения является изменение множителя поправки Мр=1,25, а также затрат и стоимости:
ЗАТРАТЫ = 154 чел.-мес.;
СТОИМОСТЬ = 1078000 $;
Полученные значения затрат отражены в табл. 10.

Таблица 10 – Расчет затрат программного проекта с учетом изменений возможностей аналитика и программиста
A
2,5
Размер new= KLOC ожид
30,183
Размер reuse
0
Размер (KLOC)
30,183
РазмерВ (KLOC)
47,00
B
1,13
Мр
1,25
Brak
5
K req
1,05
Затраты auto
0
Затраты
154
Полученные значения стоимости, а также изменения в стоимости в связи с учетом изменения ограничения оперативной памяти (выигрыш в стоимости = 1078000 – 1460600 = -382600 ($)) отражены в табл. 11.
Таблица 11 – Расчет стоимости разработки проекта и изменений в стоимости с учетом изменений возможностей аналитика и программиста
Затраты (чел./месс.)
154
Рабочий коэффициент
7000
Стоимость,$
1078000
Соимость1- Стоимость,$
-382600
Таким образом, заказчик, повышая заработную плату разработчиков проекта до 7000 $, получает стоимость проекта 1078000 $, эта стоимость на много ниже стоимости, которая была получена при первоначальной заработной плате 6700 $. Резкое снижение стоимости проекта происходит за счет уменьшения значений множителей возможностей аналитика и программиста. Следствием такого решения является снижение множителя поправки Мр=1,25, а также затрат и, следовательно, стоимости. То есть заказчик с таким сценарием разработки остается в выигрыше.

Задание № 4
Определение выигрыша (проигрыша) в стоимости проекта на разработку программного обеспечения концерна “Суперавто” с помощью модели СОСОМО II и с учетом изменения ограничения памяти ОЗУ. Разработчик предложил нарастить память – купить за 1100 $ чип ОЗУ емкостью 96 Кбайт (вместо 64 Кбайт). Это меняет ограничение памяти. В результате фактор STOR становится номинальным. Нужно определить выигрыш либо проигрыш в стоимости проекта. Таким образом, EMSTOR=1. Учитывая изменения оценки в ограничения оперативной памяти, произведем расчет множителя поправки (формула 5). Полученные данные внесем в таблицу 12.
Таблица 12 – Оценка пост-архитектурных факторов затрат с учетом изменения оценки ограничения оперативной памяти
Фактор
Описание
Оценка
Множитель
RELY
Требуемая надежность ПО
Номинальная
1
DATA
Размер базы данных
Низкая
0,93
CPLX
Сложность продукта
Очень высокая
1,3
RUSE
Требуемая повторная используемость
Низкая
0,91
DOCU
Документирование жизненного цикла
Номинальная
1
TIME
Ограничения времени выполнения
Высокая
1,1
STOR
Ограничения оперативной памяти
Номинальная
1
PVOL
Изменчивость платформы
Номинальная
1
ACAP
Возможности аналитика
Низкая
1,22
PCAP
Возможности программиста 
Низкая
1,16
AEXP
Опыт работы с приложением
Номинальная
1
PEXP
Опыт работы с платформой
Низкая
1,12
LTEX
Опыт работы с языком и утилитами
Номинальная
1
PCON
Непрерывность персонала
Высокая
0,92
TOOL
Активное использование программных утилит
Высокая
0,86
SITE
Мультисетевая разработка
Низкая
1,1
SCED
Требуемый график разработки
Номинальная
1
Множитель поправки Мр
1,67

Пользуясь формулами (5-10), аналогично производим расчет затрат и стоимости программного продукта, с измененным сценарием разработки. Следствием такого решения является снижение множителя поправки Mp=1,67, а также затрат и стоимости:
ЗАТРАТЫ = 206 чел.-мес.;
СТОИМОСТЬ 2 =1380200 $;
Таблица 13 – Расчет затрат программного проекта с учетом изменения ограничения оперативной памяти
A
2,5
Размер new= KLOC ожид
30,183
Размер reuse
0
Размер (KLOC)
30,183
РазмерВ (KLOC)
47,00
B
1,13
Мр
1,67
Brak
5
K req
1,05
Затраты auto
0
Затраты(чел.-мес.)
206
Полученные значения стоимости, а также изменения в стоимости в связи с учетом изменения ограничения оперативной памяти (выигрыш в стоимости = 1380200– 1460600 = -80400 ($)) отражены в таблице 14.
Таблица 14 – Расчет стоимости разработки проекта и изменений в стоимости с учетом изменения ограничения оперативной памяти
Затраты
206
Рабочий коэффициент
6700
Стоимость,$
1380200
Соимость2- Стоимость,$
-80400
Таким образом, разработчик, предлагая нарастить память ОЗУ до 96 Кбайт вместо 64 Кбайт, провоцирует уменьшение стоимости проекта. Такое снижение стоимости проекта происходит за счет уменьшения значения множителя ограничения оперативной памяти. Следствием такого решения является уменьшение множителя поправки Мр=1,67, а также затрат и, следовательно, стоимости. То есть заказчик, приняв предложение разработчика с таким сценарием разработки, сможет сэкономить 80400 $.
Задание № 5
Определение выигрыша (проигрыша) в стоимости проекта на разработку программного обеспечения концерна “Суперавто” с помощью модели СОСОМО II и с учетом изменения опыта работы с языком и утилитам, а также изменения активного использования программных утилит. Заказчик предложил использовать новый, более дешевый микропроцессор (дешевле на 1000 $).
При этом опыт работы с языком и утилитами, а также активное использование программных утилит снижается до очень низкого. Необходимо определить выигрыш либо проигрыш в стоимости проекта. Опыт работы с его языком и утилитами понижается до очень низкого и EMLTEX = 1,22, а разработанные для него утилиты (компиляторы, ассемблеры и отладчики) примитивны и ненадежны (в результате фактор TOOL понижается от высокого до очень низкого и EMТООL= 1,24).
Рассчитаем множитель поправки (формула 5).
Таблица 15 – Оценка пост – архитектурных факторов затрат с учетом изменений опыта работы с утилитами и языком, а также изменений активного использования программных утилит
Фактор
Описание
Оценка
Множитель
RELY
Требуемая надежность ПО
Номинальная
1
DATA
Размер базы данных
Низкая
0.93
CPLX
Сложность продукта
Очень высокая
1.3
RUSE
Требуемая повторная используемость
Низкая
0.91
DOCU
Документирование жизненного цикла
Номинальная
1
TIME
Ограничения времени выполнения
Высокая
1.1
STOR
Ограничения оперативной памяти
Высокая
1.06
PVOL
Изменчивость платформы
Номинальная
1
ACAP
Возможности аналитика
Низкая
1.22
PCAP
Возможности программиста
Низкая
1.16
AEXP
Опыт работы с приложением
Номинальная
1
PEXP
Опыт работы с платформой
Низкая
1.12
LTEX
Опыт работы с языком и утилитами
Очень низкая
1.22
PCON
Непрерывность персонала
Высокая
0.92
TOOL
Активное использование программных утилит
Очень низкая
1.24
SITE
Мультисетевая разработка
Низкая
1.1
SCED
Требуемый график разработки
Номинальная
1
Множитель поправки Мр
3.11
Пользуясь формулами (5-10), аналогично производим расчет затрат и стоимости программного продукта, с измененным сценарием разработки.
Следствием такого решения является возрастание множителя поправки Мр=3,11, а также затрат и стоимости:
ЗАТРАТЫ = 384 чел.-мес.;
СТОИМОСТЬ 3 = 2572800 $;
Полученные значения стоимости, а также изменения в стоимости в связи с учетом изменения ограничения оперативной памяти (проигрыш в стоимости = 2572800 – 1460600 = 1112200 ($)) отражены в таблице 16.
Таблица 16 – Расчет изменений в стоимости с учетом изменений опыта работы с утилитами и языком, а также изменений активного использования программных утилит
Стоимость 3 ($)
Стоимость ($)
Изменение стоимости($)
2572800
1460600
1112200
Таким образом, заказчик, предложив заменить микропроцессор более дешевым (на 1000 $), повлек увеличение стоимости проекта на 1112200 $.
Такой подъем стоимости проекта происходит за счет увеличения значений множителей LTEX и TOOL.
Следовательно, увеличение множителя поправки Мр=3,11 повлекло рост также затрат и, следовательно, стоимости. Такой сценарий разработки приводит заказчика к проигрышу.

Заключение
Современная программная инженерия (Software Engineering) — молодая и быстро развивающаяся область знаний и практик. Она ориентирована на комплексное решение задач, связанных с разработкой особой разновидности сложных систем — программных систем.
Программные системы — самые необычные и удивительные создания рук человеческих. Они не имеют физических тел, их нельзя потрогать, ощутить одним из человеческих чувств. Они не подвергаются физическому износу, их нельзя изготовить в обычном инженерном смысле, как автомобиль на заводе. И вместе с тем разработка программных систем является самой сложной из задач, которые приходилось когда-либо решать человеку-инженеру.
Современное общество впадает во все большую зависимость от программных технологий. Программные инженеры стали более востребованными.
Базис современной программной инженерии образуют следующие составляющие:
q     процессы конструирования ПО;
q     метрический аппарат, обеспечивающий измерения процессов и продуктов;
q     аппарат формирования исходных требований к разработкам;
q     аппарат анализа и проектирования ПО;
q     аппарат визуального моделирования ПО;
q     аппарат тестирования программных продуктов.
В данном курсовом проекте нашел применение процесс планирования проекта, в составе которого выполнение предварительной оценки проекта на основе LOC-метрик.
Для оценивания затрат в курсовом проекте используется наиболее популярная модель — СОСОМО II.
На основании выполненных выше оценок, модно сделать выводы:
1) факторы затрат оказывают существенное влияние на выходные параметры программного проекта;
2) модель СОСОМО II предлагает широкий спектр факторов затрат, учитывающих большинство реальных ситуаций в «жизни» программного проекта;
3) модель СОСОМО II обеспечивает перевод качественного обоснования решения менеджера на количественные “рельсы”, тем самым повышая объективность принимаемого решения.
Следуя выводу 1, при выборе сценария разработки программного обеспечения, необходимо учитывать анализ чувствительности программного проекта, произведенный в 3, 4, и 5 разделах курсового проекта, а именно:
- используя сценарий понижения заработной платы разработчиков проекта, заказчик рискует, так как использует труд рабочих низшей квалификации, рабочая сила которых оказывается дешевле, но скорость и качество выполнения проекта тормозится, то есть от процесса разработки ПО появляется отрицательный эффект, проявляющийся в удорожании стоимости данного проекта;
- следуя наращивания оперативной памяти, заказчик оказывается в выигрышной ситуации, так как ограничение памяти ОЗУ снижается, высвобождаются свободные килобайты, которые могут пригодится в выполнении еще нескольких задач при разработке проекта;
- используя вариант удешевления стоимости микропроцессора, заказчик тем самым прокладывает путь к понижению столь активного использования программных утилит, сколь хотелось бы квалифицированным разработчикам, при этом уменьшается опыт работы с языком и утилитами, а уже следствием всего этого является увеличение стоимости всего проекта в целом.

Список используемой литературы
1.     Технологии разработки программного обеспечения: Учебник/ С. Орлов. — СПб.: Питер, 2002. — 464 с.
2.     Боэм Б.У. Инженерное проектирование программного обеспечения. М.: Радио и связь, 1985. 511 с.
3.     Липаев В.В. Отладка сложных программ: Методы, средства, технология. М.: Энергоатомиздат, 1993. 384 с.
4.     Майерс Г. Искусство тестирования программ. М.: Финансы и статистика, 1982. 176с.
5.     Орлов С.А. Принципы объектно-ориентированного и параллельного программирования на языке Ada 95. Рига: TSI, 2001. 327 с.
6.     Чеппел Д. Технологии ActiveX и OLE. M.: Русская редакция, 1997. 320 с.

1. Краткое содержание Білий кінь Шептало
2. Реферат на тему Population Essay Research Paper Brandon CoxPopulation FactsSome
3. Контрольная работа на тему Характеристика Уральского региона
4. Реферат Общее понятие индексов
5. Курсовая на тему Синергетика как естественная наука о структурных преобразованиях в
6. Реферат Квадривиум
7. Реферат Криминология методы и система
8. Реферат Хлопковое волокно его свойства и классификация
9. Сочинение на тему Горький м. - По пьесе м. горького
10. Реферат Теория языков программирования и методы трансляций