Д. А. Градусов а. В. Шутов теоретические вопросы разработки программного обеспечения учебное пособие



Pdf көрінісі
бет34/57
Дата29.09.2023
өлшемі2,75 Mb.
#111342
1   ...   30   31   32   33   34   35   36   37   ...   57
Вопросы к главе 4 
1.
Зачем требуется проводить тестирование программного 
обеспечения? 
2.
Дайте определение понятия тестирование ПО. 
3.
Каковы цели процесса тестирования ПО? 
4.
В чем разница между процессами отладки и тестирования? 
5.
Перечислите основные принципы тестирования. 
6.
Из каких направлений деятельности состоит процесс 
тестирования? 
7.
Как осуществляется анализ и проектирование тестов? 
8.
Перечислите уровни тестирования ПО. 
9.
Что такое компонентное тестирование? 
10.
Что такое интеграционное тестирование? 
11.
Что такое системное тестирование? 
12.
Что такое приемочное тестирование? 
13.
В чем разница между альфа- и бета- тестированием? 
14.
Что такое регрессионное тестирование? 
15.
Как обеспечивается независимость тестирования? 
16.
Как осуществляется мониторинг и контроль тестирования? 


95 
Глава 5. ОЦЕНКА В РАЗВИТИИ ПРОГРАММНОГО ПРОЕКТА 
5.1
Роль оценки в планировании проекта 
Разработка крупных информационных систем (ИС) процесс 
трудоёмкий, требующий комплексного решения проблем времени, 
бюджета, и самой функциональности разрабатываемой системы. 
Зачастую проекты завершаются не в срок, бюджет проекта 
превышает первоначально заданный и т.д. - примеров можно 
привести множество. Как представляется, причинами подобных 
негативных результатов являются: 

Недостаточно продуманный план менеджера проекта, иными 
словами неправильное управление проектом. 

Неполная или неточная спецификация на проект, а также 
требования заказчика, которые меняются в процессе разработки. 

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


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

Осознание заказчиком собственных потребностей. Иными 
словами, понимание того, что же ему на самом деле нужно. 

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

Незнание методик оценки проекта или отсутствие опыта. Это 
часто встречающаяся в IT-компаниях проблема и, наверное, самая 
существенная. 

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

Ошибка аналитиков в оценке трудоёмкости. 

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

Недостаток времени на изучение документации заказчика ПО. 


97 
На этапе планирования проекта на основе запрошенных работ 
осуществляется предварительная оценка, а именно оцениваются 
масштаб и атрибуты рабочих продуктов и задач. Для того чтобы 
установить границы планирования, строится модель жизненного 
цикла проекта. Затем производятся оценки трудозатрат и стоимости. 
Эти оценки используется в качестве основы для разработки 
проектных планов. Соблюдая рамки плана, устанавливаются бюджет 
и график проекта, выявляются проектные риски и создаются планы 
управления информацией и ресурсами, определяется потребность в 
знаниях и навыках, планируется привлечение к участию в проекте 
дополнительных участников. В заключительной стадии планирования 
существует острая необходимость привести запланированные 
ресурсы в соответствии с фактически имеющимися ресурсами. 
Обычно оценки программных проектов представляются в виде 
обычных чисел, но подобные упрощенные точечные оценки 
бессмысленны, потому что они не включают никакой информации о 
вероятности, 
связанной 
с 
точечной 
оценкой 
(рис. 
5.1). 
Подразумевается ситуация, когда возможен единственный исход – 
заданная точка. 
Сроки/ затраты/ рабочее время
В
ер
оя
тн
ос
ть
100%
Единственный возможный результат
(
вероятность 100%)
Рис. 5.1 - Оценка программных проектов в виде обычных чисел 


98 
Выраженная таким образом оценка обычно оказывается целью, 
замаскированной под оценку. 
Точные оценки учитывают, что программные проекты 
подвергаются влиянию множества факторов неопределенности (рис. 
5.2). В совокупности эти факторы означают, что результат проекта 
подчиняется вероятностному распределению – одни результаты более 
вероятны, другие менее вероятны, а наиболее вероятная группа 
результатов сосредоточена где-то в середине распределения. Можно 
было бы предположить, что распределение результатов проекта будет 
иметь вид кривой нормального распределения.
Сроки/ затраты/ рабочее время
В
ер
оя
тн
ос
ть
Номинальный результат
Рис. 5.2 - Оценка в виде распределение результатов проекта 
Здесь каждая точка кривой представляет вероятность того, что 
проект завершится точно к соответствующей дате или на него уйдет 
определенная сумма. Площадь под кривой представляет суммарную 
вероятность 100%. Вероятностное распределение такого рода 
учитывает возможный разброс результатов. Тем не менее, 
предположение о симметричном распределении результатов по 
отношению к средней величине некорректно. Качество выполнения 


99 
проекта является величиной ограниченной: это означает, что левый 
край распределения усекается вместо того, чтобы бесконечно 
убывать, как в нормальном распределении (рис. 5.3). И хотя 
«удачные» результаты проекта ограничены, возможности для 
«неудач» безграничны, поэтому вероятностная кривая уходит очень 
далеко вправо. 
Сроки/ затраты/ рабочее время
В
ер
оя
тн
ос
ть
Номинальный результат
(
оценка 50/50)
Рис. 5.3 - Несимметричная оценка
Основным назначением оценки программного проекта является 
вовсе не прогнозирование результата, а определение реалистичности 
целей проекта. 
Проблемы начинаются тогда, когда разрыв между деловыми 
целями и сроками или объемом работ, необходимыми для достижения 
целей становится слишком большим. На практике показано, что если 
этот разрыв превышает 20% в ту или иную сторону, руководитель не 
сможет довести проект до успешного завершения, внося 
незначительные изменения за счет управления функциональностью, 
сроком, численностью группы и другими параметрами. Прежде чем 
руководитель начнет управление проектом для достижения 


100 
поставленных целей, эти цели необходимо привести в соответствие с 
реальностью. 
Можно выявить ряд серьезных преимуществ, которые дает 
применение оценки программного проекта на различных стадиях:
1.
Возможность отслеживания состояния проекта. Один из 
лучших способов – сравнение запланированного прогресса с 
фактическим. Если запланированный прогресс был основан на 
точных оценках и оказался достаточно реалистичным, то становится 
вполне возможным отслеживание прогресса на предмет соответствия 
планам. 
2.
Повышение качества. Точные оценки помогают избежать 
снижения качества, обусловленного приближающимся сроком сдачи. 
Как 
показали 
исследования, 
около 
40% 
всех 
ошибок 
программирования возникает из-за стресса; этих ошибок можно было 
бы избежать за счет правильного планирования и снижения нагрузки 
на разработчиков. Также оказалось, что излишнее давление сроков 
служит основной причиной для выпуска модулей, содержащих 
ошибки, исправление которых обходится чрезвычайно дорого. 
3.
Улучшение координации с функциями, не связанными с 
программированием. Программные проекты обычно координируются 
с другими видами деятельности: тестированием, написанием 
документации, маркетинговыми кампаниями, обучением торгового 
персонала, финансовыми прогнозами. обучением службы поддержки 
и т.д. Ненадежный график проекта способен привести к сбоям 
взаимосвязанных функций. Хорошая оценка программного проекта 
предусматривает более тесную координацию всего проекта, включая 
и программные, и прочие виды деятельности. 
4.
Повышение качества бюджета. Точная оценка способствует 
выработке точного бюджета. Организация, не обеспечивающая 
точных оценок, подрывает свои возможности по прогнозированию 
стоимости проектов. 


101 
5.
Получение ранней информации о рисках. Одной из самых 
частых упущенных возможностей в области программного 
обеспечения является неправильная интерпретация исходного 
несоответствия между целями и оценками проекта. Однако данное 
несоответствие несет чрезвычайно полезную информацию о риске, 
появившейся на ранней стадии проекта, когда еще возможны 
различные корректировочные меры: переопределение объема работ, 
набор дополнительного персонала, перевод лучших сотрудников на 
проект, изменение некоторых функций и т.д. Но если оставить данное 
несоответствие без внимания, возможностей корректировки на более 
поздней стадии будет гораздо меньше, и они будут обладать гораздо 
меньшей эффективностью. Как правило в таких случаях приходится 
выбирать между нарушением сроков и бюджета и отказом от важных 
функций. 
6.
Повышение доверия к группе разработчиков. Исполнительная 
группа, которая твердо держится на своих позициях и настаивает на 
точной оценке, пользуется большим доверием в своей организации. 
5.2
Неопределенность в оценке 
Разработка программного обеспечение состоит из множества 
решений 
относительно 
вопросов 
функциональности. 
Неопределенность в оценках программного обеспечения обусловлена 
разрешением неопределенности при принятии решений. 
Исследователи обнаружили, что оценкам проектов на разных 
стадиях присущи прогнозируемые уровни неопределенности. Конус 
неопределенности на рисунке 5.4, показывает, что оценки становятся 
более точными по мере продвижения работы над проектом. 
Рассмотрим вначале конус неопределенности для последовательной 
методологии разработки. 


102 


Достарыңызбен бөлісу:
1   ...   30   31   32   33   34   35   36   37   ...   57




©emirsaba.org 2024
әкімшілігінің қараңыз

    Басты бет