ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 29.10.2023
Просмотров: 54
Скачиваний: 2
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Далее используя готовый сетевой график (рисунок 1) и длительность работ (таблица 5) вычисляется позднее время начала работ.
Таблица 8 – Вычисление позднего времени начала работ
| № | | Раннее время начала | Длительность | | |
| 17 | - | - | - | - | 37 |
| 16 | 17 | 37 | 2 | 37-2 | 35 |
| 15 | 17 | 37 | 4 | 37-4 | 33 |
| 14 | 15 16 | 33 35 | 4 | Min(33-4; 35-4) | 29 |
| 13 | 14 | 29 | 5 | 29-5 | 24 |
| 12 | 13 | 24 | 3 | 24-3 | 21 |
| 11 | 12 | 21 | 6 | 21-6 | 15 |
| 10 | 11 | 15 | 4 | 15-4 | 11 |
| 9 | 12 | 21 | 3 | 21-3 | 18 |
| 8 | 9 | 18 | 4 | 18-4 | 14 |
| 7 | 8 10 | 14 11 | 6 | Min(14-6; 11-6) | 5 |
| 6 | 12 | 21 | 2 | 21-2 | 19 |
| 5 | 8 | 14 | 4 | 14-4 | 10 |
| 4 | 5 6 7 | 10 19 5 | 3 | Min(10-3; 19-3; 5-3) | 2 |
| 3 | 4 | 2 | 2 | 2-2 | 0 |
| 2 | 4 | 2 | 2 | 2-2 | 0 |
| 1 | 2 3 | 0 0 | 0 | Min(0-0; 0-0) | 0 |
1 2 3 4
Результаты раннего времени начала (таблица 7) и позднего (таблица 8) нужно занести в новую таблицу, где будут определены критические пути для построения нового сетевого графика (таблица 9).
Таблица 9 – Вычисление резерва времени работ
| № | Раннее время | Позднее время | Резерв времени |
| 1 | 0 | 0 | 0 |
| 2 | 0 | 0 | 0 |
| 3 | 0 | 0 | 0 |
| 4 | 2 | 2 | 0 |
| 5 | 5 | 10 | 5 |
| 6 | 5 | 19 | 14 |
| 7 | 5 | 5 | 0 |
| 8 | 10 | 14 | 4 |
| 9 | 14 | 18 | 4 |
| 10 | 11 | 11 | 0 |
| 11 | 15 | 15 | 0 |
| 12 | 21 | 21 | 0 |
| 13 | 24 | 24 | 0 |
| 14 | 29 | 29 | 0 |
| 15 | 33 | 33 | 0 |
| 16 | 33 | 35 | 2 |
| 17 | 37 | 37 | 0 |
Места, в которых результаты нулевые, являются критическими. Именно эти связи нужно показать в новой графике (рисунок 2).
Рисунок 2 – Сетевой график с критическими путями
-
Планирование рисков проекта, идентификация рисков проекта
Планирование рисков проекта – это выбор подходов и планирование деятельности по рискам проекта. Процесс может включать в себя решения по организации, кадровому обеспечению процедур управления рисками проекта, выбор предпочтительной методологии, источников данных для идентификации риска, временной интервал для анализа ситуации.
Идентификация рисков – это определение рисков, способных повлиять на проект и на его документирование. Идентификация рисков должна привлекать как можно больше людей, которые задействованы в проекте: менеджеров, заказчика, пользователей, а также специалистов. Идентификация рисков является итерационным процессом. Вначале идентификация может быть выполнена менеджерами проекта или группой аналитиков. После идентификацией может заняться основная команда менеджеров.
-
Управление проектом на фазе разработки и внедрения
Задачи планирования стадии разработки и внедрения совпадают с задачами предыдущей стадии. Дополнительной задачей является подготовка персонала к завершению проекта. Решение этой задачи включает следующие действия:
-
извещение менеджмента проекта, заказчика и персонал; -
подготовка оценки работы персонала; -
документирование результатов процесса управления персоналом
Для выполнения оценки работы персонала используют методики и процедуры, принятые компанией. Все накопленные знания, приобретенные во время проекта, должны быть документированы и могут включать в себя:
-
организационные диаграммы проекта, описания позиций и планы управления обеспечением проекта персоналом; -
методы урегулирования конфликтов и процедуры поощрения; -
специальные навыки и квалификацию определенных членов команды, обнаруженные в процессе исполнения проекта; -
проблемы и способы их решения, зафиксированные в журнале регистрации проблем проекта.
На фазе разработки и внедрения выполняется проверка результатов проекта по требованиям проекта и завершение процесса управления конфигурации. Результатом данного этапа является обеспечение готовности управления конфигурацией заказчиком. Для проверки результатов соответствия выполняется аудит ключевых результатов. В рамках этого аудита менеджер по управлению демонстрирует руководителю проекта и заказчику соответствие полученных и запланированных результатов и наличие адекватного контроля результатов. Результаты в дальнейшем используются менеджером проекта при подписании акта заказчиком о приемке ключевых результатов проекта.
Менеджер по управлению конфигурацией готовит и согласовывает требования к аудиту и ключевым результатам проекта и обеспечивает его аудита. Администратор обеспечивает подготовку отчётов о состоянии конфигурации, которые необходимы для проведения аудита.
Завершение процесса управления конфигурацией заключается в передаче заказчику ответственности за процесс конфигурации проекта, а также в подготовке и передачи архива с материалами проекта.
Менеджер проекта со стороны заказчика разрабатывает требования к завершению процесса управления конфигурацией, причем рекомендуется это принять на стадии планирования. Менеджер по управлению конфигурацией архивирует информацию по конфигурации проекта и организует процесс передачи архива.
Передача заказчику результатов процесса должна быть согласована с передачей результатов, связанных с разработкой и тестированием информационной системы. Для передачи архивных копий, рекомендуется на этапе планирования разработать и согласовать с заказчиком соответствующую процедуру.
-
Инструменты для измерения характеристик и контроля качества и безопасности кода
Использование инструментов для повышения и контроля качества кода может стать важным фактором успеха при реализации сложных программных проектов. Например, к таким инструментам относятся статические анализаторы.
Инструментов для качественного контроля и безопасности очень много. На выбор могут влиять цели проекта. В данной работе использовался SonarQube.
SonarQube – инструмент для анализа качества и безопасности. При поддержке сообщества открытого исходного кода Sonarqube в настоящее время может анализировать и создавать результаты для более чем 20 языков программирования.
Основные преимущества использования SonarQube:
-
легко интегрируется в пайпланы CD с помощью однострочной команды; -
может быть интегрирован в цикл сборки Maven и Gradle; -
проверяет почти все – качество кода, форматирование, объявления переменных, обработку исключений и многое другое; -
позволяет проверять код на уязвимости.
-
Использование метрик программного продукта
В целом метрики находятся на третьем уровне иерархии и определяют значения характеристик качества программы. В модели качества метрики используются на втором уровне иерархии и определяют значения характеристик. Есть множества различных метрик, но конкретные виды метрик применяются на определенном этапе жизненного цикла программного продукта.
Свойства метрик:
-
Надежность – связана со случайной ошибкой; метрика свободна от случайной ошибки, если случайные изменения не влияют на результаты метрики; -
Повторяемость – повторное использование метрики для того же продукта теми же специалистами, используя ту же спецификацию оценки (ту же окружающую среду), тот же тип пользователей и окружения, должно привести к тем же результатам с соответствующими допусками; соответствующие допуски должны учитывать такие компоненты, как усталость и результат накопленных познаний; -
Однотипность – применение метрики для того же продукта различными специалистами, используя ту же спецификацию оценки (включая ту же окружающую среду), тот же тип пользователей и окружения, должно привести к тем же результатам с соответствующими допусками; -
Применимость – метрика должна чётко указывать условия (например, наличие определённых атрибутов), которые ограничивают её употребление; -
Показательность – способность метрики идентифицировать элементы программы, которые должны были быть улучшены, на основании сравнения измеренных и ожидаемых результатов. -
Корректность – метрика должна обладать следующими свойствами:
-
объективность – результаты метрики и её входные данные должны быть основаны на фактах и не подвластны чувствам или мнениям специалистов по оценке или тестированию(исключая метрики удовлетворенности или привлекательности, с помощью которых измеряются чувства и мнения пользователя); -
беспристрастность – измерение не должно быть направлено на получение какого-либо специфического результата; -
адекватность точности – точность определяется при проектировании метрики, особенно при выборе описаний фактов, которые используются как основа для метрики; разработчик метрики должен описать точность и чувствительность метрики;