Ниже представлен исходный код, сравнивающий два целых числа. Соберем его в исполняемый файл и проведем набор тестов состоящий из:
1 Подача на вход ПО заведомо правильных значений.
2 Подача на вход заведомо неверных значений.
3 Подача на вход данных неподдерживаемого типа (строки).
Результаты тестов представлены на скриншотах.
Задания для самостоятельного выполнения
Скомпилируйте представленную программу, сделайте вывод по каждому тесту.
Содержание отчета
1 Тема и цель работы
2 Описание выполнения практического задания
3 Вывод о проделанной работе
5 Контрольные вопросы
1 Что такое тестирование методом черного ящика?
2 Что такое тестирование белым ящиком?
3 Как выполняется тестирование логики программы?
4 Как выполняется тестирование данных в программе?
ЛАБОРАТОРНАЯ РАБОТА №7
Быстродействие программных продуктов
Цель работы: изучение методологии управления проектами. Получение навыков по применению данных методологий для планирования проекта.
Методические указания
Лабораторная работа направлена на ознакомление с основными понятиями методологии управления проектами, получение навыков по применению данных понятий при построении плана проекта, построения графика работ, распределения исполнителей, управления рисками.
Требования к результатам выполнения лабораторного практикума:
Построить модель управления проектом, включающую:
определение всех этапов проекта, зависимых этапов, определение длительности этапов;
построение на основе полученных данных сетевой и временной диаграмм;
построение диаграммы распределения работников по этапам;
при определении этапа указывается его название – отражающее суть этапа (например, определение пользовательских требований, проектирование интерфейса и т.д.);
этапов должно быть не менее 7, срок реализации проекта – с 1.01 по 31.12;
в проекте задействовано 3 человек персонала (группа разработчиков).
Теоретический материал
Основные понятия
Проблемы управления программными проектами впервые проявились в 60-х — начале 70-х годов. Руководители программных проектов выполняют такую же работу, что и руководители технических проектов. Вместе с тем процесс разработки ПО существенно отличается от процессов реализации технических проектов, что порождает определенные сложности в управлении программными проектами. Ниже приведён краткий список этих отличий.
- Программный продукт нематериален. Менеджер технического проекта видит результаты выполнения своего проекта. Если реализация проекта отстает от графика, это также видно воочию. В противоположность этому программное обеспечение нематериально. Его нельзя увидеть или потрогать. Менеджер программного проекта не видит процесс роста разрабатываемого ПО. Он может полагаться только на документацию, которая фиксирует процесс разработки программного продукта.
- Не существует стандартных процессов разработки ПО. На сегодняшний день не существует четкой зависимости между процессом создания ПО и типом создаваемого программного продукта. Другие технические дисциплины имеют длительную историю, процессы разработки технических изделий многократно опробованы и проверены. Процессы создания большинства технических систем хорошо изучены. Изучением же процессов создания ПО специалисты занимаются только несколько последних лет. Поэтому пока нельзя точно предсказать, на каком этапе процесса разработки ПО могут возникнуть проблемы, угрожающие всему программному проекту.
- Большие программные проекты — это часто одноразовые проекты. Большие программные проекты, как правило, значительно отличаются от проектов, реализованных ранее. Поэтому, чтобы уменьшить неопределенность в планировании проекта, руководители проектов должны обладать очень большим практическим опытом. Но постоянные технологические изменения в компьютерной технике и коммуникационном оборудовании обесценивают предыдущий опыт. Знания и навыки, накопленные опытом, могут не востребоваться в новом проекте.
Перечисленное выше может привести к тому, что реализация проекта выйдет из временного графика или превысит бюджетные ассигнования. Программные системы зачастую оказываются новинками как в идеологическом, так и в техническом плане. Технические проекты, которые являются инновационными (например, новая транспортная система), также часто нарушают временные графики работ. Поэтому, предвидя возможные проблемы в реализации программного проекта, следует всегда помнить, что многим из них свойственно выходить за рамки временных и бюджетных ограничений.
Планирование проекта
Эффективное управление программным проектом напрямую зависит от правильного планирования работ, необходимых для его выполнения. План помогает менеджеру предвидеть проблемы, которые могут возникнуть на каких-либо этапах создания ПО, и разработать превентивные меры для их предупреждения или решения. План, разработанный на начальном этапе проекта, рассматривается всеми его участниками как руководящий документ, выполнение которого должно привести к успешному завершению проекта. Этот первоначальный план должен максимально подробно описывать все этапы реализации проекта.
Кроме разработки плана проекта, на менеджера ложится обязанность разработки других видов планов. Эти виды планов кратко описаны в табл. 1.
Таблица 1 — Виды планов
| План | Описание |
| План качества | Описывает стандарты и мероприятия по поддержке качества разрабатываемого ПО |
| План аттестации | Описывает способы, ресурсы и перечень работ, необходимых для аттестации программной системы |
| План управления конфигурацией | Описывает структуру и процессы управления конфигурацией |
| План сопровождения ПО | Предлагает план мероприятий, требующихся для сопровождения ПО в процессе его эксплуатации, а также расчет стоимости сопровождения и необходимые для этого ресурсы |
| План по управлению персоналом | Описывает мероприятия, направленные на повышение квалификации членов команды разработчиков |
В листинге 1 показан процесс планирования создания ПО в виде псевдокода. Здесь сделан акцент на том, что планирование — это итерационный процесс. Поскольку в процессе выполнения проекта постоянно поступает новая информация, план должен регулярно пересматриваться. Важными факторами, которые должны учитываться при разработке плана, являются финансовые и деловые обязательства организации. Если они изменяются, эти изменения также должны найти отражение в плане работ.
Листинг 1. Процесс планирования проекта
Определение проектных ограничений
Первоначальная оценка параметров проекта
Определение этапов выполнения проекта и контрольных отметок
while пока проект не завершится или не будет остановлен loop
Составление графика работ
Начало выполнения работ
Ожидание окончания очередного этапа работ
Отслеживание хода выполнения работ
Пересмотр оценок параметров проекта
Изменение графика работ
Пересмотр проектных ограничений
if (возникла проблема) then
Пересмотр технических или организационных параметров проекта
End if
End loop
Процесс планирования начинается с определения проектных ограничений (временные ограничения, возможности наличного персонала, бюджетные ограничения и т.д.). Эти ограничения должны определяться параллельно с оцениванием проектных параметров, таких как структура и размер проекта, а также распределением функций среди исполнителей. Затем определяются этапы разработки и то, какие результаты документация, прототипы, подсистемы или версии программного продукта) должны быть получены по окончании этих этапов. Далее начинается циклическая часть планирования. Сначала разрабатывается график работ по выполнению проекта или дается разрешение на продолжение использования ранее созданного графика. После этого (обычно через 2-3 недели) проводится контроль выполнения работ и отмечаются расхождения между реальным и плановым ходом работ.
Далее, по мере поступления новой информации о ходе выполнения проекта, возможен пересмотр первоначальных оценок параметров проекта. Это, в свою очередь, может привести к изменению графика работ. Если в результате этих изменений нарушаются сроки завершения проекта, должны быть пересмотрены (и согласованы с заказчиком ПО) проектные ограничения.
Конечно, большинство менеджеров проектов не думают, что реализация их проектов пройдет гладко, без всяких проблем. Желательно описать возможные проблемы еще до того, как они проявят себя в ходе выполнения проекта. Поэтому лучше составлять пессимистические графики работ, чем оптимистические. Но, конечно, невозможно построить план, учитывающий все, в том числе случайные, проблемы и задержки выполнения проекта, поэтому и возникает необходимость периодического пересмотра проектных ограничений и этапов создания программного продукта.
План проекта
План проекта должен четко показать ресурсы, необходимые для реализации проекта, разделение работ на этапы и временной график выполнения этих этапов. В некоторых организациях план проекта составляется как единый документ, содержащий все виды планов, описанных выше. В других случаях план проекта описывает только технологический процесс создания ПО. В таком плане обязательно присутствуют ссылки на планы других видов, но они разрабатываются отдельно от плана проекта.
План, представленны ниже, принадлежит именно к последнему типу планов. Детализация планов проектов очень разнится в зависимости от типа разрабатываемого программного продукта и организации-разработчика. Но в любом случае большинство планов содержат следующие разделы.
- Введение. Краткое описание целей проекта и проектных ограничений (бюджетных, временных и т.д.), которые важны для управления проектом.
- Организация выполнения проекта. Описание способа подбора команды разработчиков и распределение обязанностей между членами команды.
- Анализ рисков. Описание возможных проектных рисков, вероятности их проявления и стратегий, направленных на их уменьшение. Тема управления рисками рассмотрена ниже.
- Аппаратные и программные ресурсы, необходимые для реализации проекта. Перечень аппаратных средств и программного обеспечения, необходимого для разработки программного продукта. Если аппаратные средства требуется закупать, приводится их стоимость совместно с графиком закупки и поставки.
- Разбиение работ на этапы. Процесс реализации проекта разбивается на отдельные процессы, определяются этапы выполнения проекта, приводится описание результатов (выходов) каждого этапа и контрольные отметки. Эта тема представлена ниже.
- График работ. В этом графике отображаются зависимости между отдельными процессами (этапами) разработки ПО, оценки времени их выполнения и распределение членов команды разработчиков по отдельным этапам.
- Механизмы мониторинга и контроля за ходом выполнения проекта. Описываются предоставляемые менеджером отчеты о ходе выполнения работ, сроки их предоставления, а также механизмы мониторинга всего проекта.
План должен регулярно пересматриваться в процессе реализации проекта. Одни части плана, например график работ, изменяются часто, другие более стабильны. Для внесения изменений в план требуется специальная организация документопотока, позволяющая отслеживать эти изменения.
