49258 (Технологический процесс разработки программного обеспечения), страница 4
Описание файла
Документ из архива "Технологический процесс разработки программного обеспечения", который расположен в категории "". Всё это находится в предмете "информатика" из 1 семестр, которые можно найти в файловом архиве . Не смотря на прямую связь этого архива с , его также можно найти и в других разделах. Архив можно найти в разделе "курсовые/домашние работы", в предмете "информатика, программирование" в общих файлах.
Онлайн просмотр документа "49258"
Текст 4 страницы из документа "49258"
каждой оценке присваивается эквивалентный числовой коэффициент (табл.1)
Таблица 1
| Оценка | Коэффициент |
| Почти всегда | 1 |
| Часто | 0.75 |
| Иногда | 0.5 |
| Редко | 0.25 |
| Никогда | 0 |
обрабатывается один опросник для одного проекта: подсчитывается количество ответов по каждой оценке одного направления ТП (количество отметок “+” или “1” в столбце). Это количество ответов умножается на соответствующий коэффициент (см. табл.1) и вычисляется их сумма. Затем эта сумма делится на количество вопросов, касающихся данного направления (приложение 1) и умножается на 100% (для получения оценки достижимости целей направления в процентах).
Ниже приведен пример заполнения опросного листа по направлению “Управление требованиями” и оценка уровня достижимости целей по данному направлению. Соответствующий опросный лист содержит 6 вопросов. Пример заполнения опросного листа приведен в табл.2. Вычисленная оценка КРА по ответам на вопросы по данному направлению составляет.
(2*1 + 1*0.75 + 1*0.5 + 2*0) / 6 = 0.54
или в процентном отношении - 0.54*100% = 54%
Процедура повторяется по всем шести направлениям, представленным в опроснике;
3) подобным образом обрабатываются ответы на вопросы по всем проектам;
4) по завершении обработки опросных листов оценки по каждому направлению для всех проектов усредняются. Усредненная оценка направления по всем проектам вычисляется как медиана частных оценок. Например, если в результате обработки вопросов по первому направлению для пяти проектов были получены такие оценки: 54 58 75 79 80
то медианой ряда будет значение 75 и это будет средняя оценка данного направления по представленным проектам.
5) полученные суммарные оценки проектов в процентах по каждому направлению заносятся в итоговый отчет по форме, представленной в табл.3.
6) для расчета уровня зрелости Lзр организации применяется формула:
Lзр = 2/6 * {i=1 [ (КPA%i) /100] }
где КРАi - полученные суммарные оценки проектов в процентах.
Таблица 2
| Управление требованиями | Почти всегда | Часто | Иногда | Редко | Никогда | Не используется |
| 1. Используются ли системные требования, делегированные ПО, в качестве основы для выполнения разработки и управления процессом разработки? | + | |||||
| 2. Выполняется ли корректировка планов ПО, рабочих продуктов и действий при изменении системных требований, делегированных ПО? | + | |||||
| 3. Руководствуется ли проект принятой в организации политикой в части управления системными требованиями, делегированными ПО? | + | |||||
| 4. Прошли ли лица, которым поручено управление делегированными требованиями, обучение приемам управления требованиями? | + | |||||
| 5. Проводятся ли измерения с целью определения адекватности действий, выполняемых по управлению делегированными требованиями (например, есть ли учет общего числа предложенных изменений в требованиях, числа принятых предложений по изменениям, числа произведенных корректировок в базовой версии и пр)? | + | |||||
| 6. Подвергаются ли действия по управлению требованиями в проекте ревизиям с целью обеспечения качества ПО? | + |
Таблица 3 Оценка уровня зрелости по КРА
| КРА | Почти всегда >90% случаев | Часто 60-90% случаев | Почти поровну 40-60% случаев | От случая к случаю 10-40% | Крайне редко < 10% |
| Управление требованиями | |||||
| Планирование проектов ПО | |||||
| Мониторинг проектов | |||||
| Управление соисполнителями | |||||
| Обеспечение качества ПО | |||||
| Управление конфигурацией |
Следует отметить, что чем больше проектов входит в выборку, тем точнее оценка, однако исходя из общего низкого уровня зрелости отечественных организаций разработчиков и сложности сбора информации по большому количеству проектов в одной организации, на данном уровне применения методики допустимо ограничить число проектов тремя.
