Системное тестирование (SystemTesting)

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

Можно выделить два подхода к системному тестированию:

· на базе требований (requirementsbased)

Для каждого требования пишутся тестовые случаи (testcases), проверяющие выполнение данного требования.

· на базе случаев использования (usecasebased)

На основе представления о способах использования продукта создаются случаи использования системы (UseCases). По конкретному случаю использования можно определить один или более сценариев. На проверку каждого сценария пишутся тест кейсы (testcases), которые должны быть протестированы.

Приемочное тестирование или Приемо-сдаточное испытание (AcceptanceTesting)

Формальный процесс тестирования, который проверяет соответствие системы требованиям и проводится с целью:

· определения удовлетворяет ли система приемочным критериям;

· вынесения решения заказчиком или другим уполномоченным лицом принимается приложение или нет.

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

Решение о проведении приемочного тестирования принимается, когда:

 

· продукт достиг необходимого уровня качества;

· заказчик ознакомлен с Планом Приемочных Работ (ProductAcceptancePlan) или иным документом, где описан набор действий, связанных с проведением приемочного тестирования, дата проведения, ответственные и т.д.

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

Шаблон плана приемо-сдаточных испытаний от RUP можно скачать, кликнув по ссылке: RUP ProductAcceptancePlan.

 

Управление качеством, метрики, управление проектом на основе KPI. Пример использования в курсовом проекте

Проект - это всегда:

· Структурированный, состав работ, которые:

· могут выполняться параллельно или

· должны исполняться строго последовательно

· Набор ресурсов на реализацию работ, выливающиеся в затраты, из которых складывается бюджет проекта.

Масштаб проекта

По факту, требуется переложить понятную технологию строительства/возведения чего-то в формат проектного управления. Требуемые ресурсы понятны и, в общем-то, доступны. Большинство базовых работ поддается нормированию.

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

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

В реальности в компаниях так и происходит - менеджер проекта взаимодействует с определенным количеством экспертов, каждый из которых отвечает за результативность проекта на определенном этапе. Результативность измеряется:

· Время (сроки и фактическая длительность)

· Деньги (израсходованный бюджет)

· Качество реализованных работ

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

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

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

Степень неопределенности

Неопределенности хоть отбавляй в проектах НИОКР (научно-исследовательские и опытно-конструкторские работы). К категории этих проектов можно отнести, в том числе:

· проекты, связанные с модернизацией производства

· комплексные проекты организационного развития, которые также страдают отсутствием полной определенности,

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

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

Как это выглядит:

· есть задача проекта - требования к результату, который должен быть получен на выходе. Например - некий продукт.

· есть общее понимание, что нужно делать, чтобы получить заданный результат

· есть отсутствие понимания, как мы будем реализовывать какие-то промежуточные этапы. Отсутствие понимания определяется:

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

· либо, если совсем не повезло, в середине проекта мы имеем парочку белых пятен в науке: "Создай то, чего никогда не видел, о чем негде прочитать, но работать это должно так-то и габариты иметь такие-то..."

· и есть рекомендованный (совсем не повезло - утвержденный) бюджет создания проектного чуда

Здесь нет никакого утрирования проблематики, подобные проекты лежат в основе деятельности многих компаний. И этими проектами необходимо управлять.

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

И теперь мы имеем краткое описание полной красоты:

· неопределенность процесса реализации, умноженная на

· желание верить в получение нужного результата, и все это возведено в

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

Требования к интеграции и консолидации.

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

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

то возможно реализовать, интегрировав систему управления проектами с системой управления эффективностью деятельности компании - встроив систему мониторинга реализации проектов в комплексную KPI-модель деятельности компании.

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

Понравится Вам следующая мысль или нет, но если деятельность вашей компании наполнена проектами, придется задуматься о выборе специализированной автоматизированной системы управления эффективностью бизнеса на основе kpi. Системы на рынке есть и их стоимость несопоставимо низка в сравнении с потерями, которые несут компании при понятийном управлении проектами (управлении "по понятиям")

Требование 1. К системе мониторинга реализации проектов - абсолютная интеграция с системой управления бизнесом в целом.

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

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

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

Проект переносится в систему единым неделимым объектом. И, "дабы никто ничего в нем не поломал и никого не обманул", на практике в компаниях вынуждены создавать выделенные подразделения по сбору и переносу информации о ходе исполнения работ проекта в автоматизированную систему. Есть красивое название подобным подразделениям...

20. Управление рисками проекта. Источники рисков, идентификация и оценка рисков. Стратегии по управлению рисками. Пример использования в курсовом проекте

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

В соответствии с определением американского стандарта в области управления проектами PMBOK (2004), риск проекта – это неопределенное событие или условие, которое в случае возникновения имеет позитивное или негативное воздействие, по меньшей мере, на одну из целей проекта, например, сроки, стоимость, содержание или качество.

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

Выделяются негативные риски, позитивные риски и непредвиденные обстоятельства.

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

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

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

Управление рисками – это систематический процесс снижения неопределенности и управления вероятностью событий в проекте.

Цель управления рисками проекта – повышение вероятности возникновения и воздействия благоприятных событий и снижение вероятности возникновения и воздействия неблагоприятных для проекта событий.

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

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

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

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

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

Успех проекта зависит от того, какую стратегию или стратегии реагирования на риски запланирует и реализует команда управления проектом. Запланированные операции по реагированию на риски должны:

- соответствовать серьезности риска;

- быть экономически эффективными в решении проблемы;

- быть своевременными;

- быть реалистичными в контексте проекта;

- быть согласованными со всеми участниками.