впвв. Практическая работа по теме_ «разработка сценария внедрения и со. Практическая работа по теме разработка сценария внедрения и сопровождения программного продукта для рабочего места

Название	Практическая работа по теме разработка сценария внедрения и сопровождения программного продукта для рабочего места
Дата	25.09.2022
Размер	0.67 Mb.
Формат файла
Имя файла	Практическая работа по теме_ «разработка сценария внедрения и со.docx
Тип	Практическая работа #694566

ПРАКТИЧЕСКАЯ РАБОТА ПО ТЕМЕ:

«РАЗРАБОТКА СЦЕНАРИЯ ВНЕДРЕНИЯ И СОПРОВОЖДЕНИЯ ПРОГРАММНОГО ПРОДУКТА ДЛЯ РАБОЧЕГО МЕСТА»

ЦЕЛЬ РАБОТЫ: изучить основы разработки, сценарии внедрения программного продукта для рабочего места, составление плана сопровождения и отчета о дефектах, актов ввода и приемки программного продукта.

ОБОРУДОВАНИЕ: ПК, MS Word.

ВРЕМЯ ВЫПОЛНЕНИЯ: 90 минут
КРАТКАЯ ТЕОРИЯ И МЕТОДИЧЕСКИЕ РЕКОМЕНДАЦИИ:

Бизнес-цель - это описание фактора, побуждающего к выполнению проекта. Ее формирование производится на стратегическом уровне, то есть бизнес-цель выступает в качестве связующего звена между глобальными задачами, стоящими перед организациями, и планируемым к реализации проектом. При отходе от стратегического видения происходит смещение бизнес-цели в сторону тактических и даже операционных задач, на уровне которых целью проекта видится «просто выдать продукт», а не достичь какой-либотактической цели, поддерживающей стратегические цели организации. Этого нельзя допускать: бизнес-цель проекта должна всегда носить тактический или стратегический характер, но в то же время быть предельно точной и ясной (очень редко удается применить широко известный метод SMART к построению бизнес-цели проекта.Так, например, бизнес-целью проекта по приобретению и установке нового производственного оборудования является не покупка и установка оборудования, а устранение узкого места в производственном процессе и обеспечение надлежащих объемов выпуска, гарантирующих удовлетворение спроса и завоевание определенной доли рынка. Аналогично, проект внедрения информационной системы имеет своей бизнес-целью не разворачивание технических средств, а создание информационно-технологического фундамента для поддержки принятия руководством компании своевременных управленческих решений, направленных на обеспечение ее развития и роста.

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

 функцию постановки задачи;

 функцию согласования;

 авторизационную функцию;

 функцию повышения дисциплины;

 консолидационную функцию;

 интеграционную функцию.

Разработка устава проекта начинается после издания приказа о запуске.

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

1. Обоснование выполнения уникальной задачи развития.

2. Цели, задачи и результаты.

3. Имя и фамилию PM, границы его ответственности и полномочия.

4. Определение и структуру продукта.

5. Интересы и ожидания участников.

6. Критерии успеха.

7. Принципы организации и управления проектом

«Окружение проекта: внешнее и внутреннее; влияние окружения на управление проектом»

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

Внешнее окружение:

 Если проект внутри организации

Из ближнего окружения факторами влияния на проект являются:

 Руководитель

 Сфера финансов

 Сфера сбыта,

 Сфера производства

 Материальное обеспечение

 Инфраструктура

 Очистка и утилизация отходов.

Дальнее окружение:

 Политические и экономические факторы

 Социальные

 Научно-технические

 Природные, экологические факторы

Внутреннее окружение.

На проект влияние оказывает внутренняя среда самого проекта:

 Распределение прав, ответственности

 Психологический климат

 Стиль руководства

 Методы и средства коммуникаций

 Социальные условия проекта (з/п, техника безопасности, стандартные условия деятельности, социальное обеспечение)

«Участники проекта»

Роли и ответственности участников типового проекта разработки ПО можно

условно разделить на пять групп:

1. Анализ. Извлечение, документирование и сопровождение требований к продукту.

2. Управление. Определение и управление производственными процессами.

3. Производство. Проектирование и разработка ПО.

4. Тестирование. Тестирование ПО.

5. Обеспечение. Производство дополнительных продуктов и услуг.

Группа анализа включает в себя следующие роли:

• Бизнес-аналитик. Построение модели предметной области (онтологии).

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

• Системный аналитик. Отвечает за перевод требований к продукту в функциональные требования к ПО.

• Специапист по требованиям. Документирование и сопровождение требований к продукту.

• Менеджер продукта (функциональный заказчик). Представляет в проекте интересы пользователей продукта.

Группа управления состоит из следующих ролей:

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

• Куратор проекта. Оценка планов и исполнения проекта. Выделение ресурсов.

• Системный архитектор. Разработка технической концепции системы. Принятие ключевых проектных решений относительно внутреннего устройства программной системы и её технических интерфейсов.

• Руководитель группы тестирования. Определение целей и стратегии тестирования, управление тестированием.

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

В производственную группу входят:

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

• Проектировщик базы данных.

• Проектировщик интерфейса пользователя.

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

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

Группа тестирования в проекте состоит из следующих ролей:

• Проектировщик тестов. Разработка тестовых сценариев.

• Разработчик автоматизированных тестов.

• Тестировщик. Тестирование продукта. Анализ и документирование результатов.

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

• Технический писатель.

• Переводчик.

• Дизайнер графического интерфейса.

• Разработчик учебных курсов, тренер.

• Участник рецензирования.

• Продажи и маркетинг.

• Системный администратор.

• Технолог.

• Специалист по инструментапьным средствам.

• Другие.

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

• Руководитель проекта + системный аналитик (+ системный архитектор)

• Системный архитектор + разработчик

• Системный аналитик + проектировщик тестов технический писатель)

• Системный аналитик + проектировщик интерфейса пользователя

• Ответственный за управление конфигурациями + ответственный за сборку и поставку (+ разработчик)

Крайне нежелательно совмещать следующие роли:

• Разработчик + руководитель проекта

• Разработчик + системный аналитик.

• Разработчик + проектировщик интерфейсов пользователя.

• Разработчик + тестировщик

«Сопровождение проекта»

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

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

— причины необходимости сопровождения;

— состав исполнителей работ по сопровождению;

— роли и обязанности каждого субъекта, вовлеченного в сопровождение;

— как должны быть выполнены основные процессы и работы;

— какие имеются и необходимы ресурсы для сопровождения;

— методы и средства организации работ по управлению, выпуску продукта и синхронизации работ;

— перечень всех проектных результатов и продуктов, подлежащих поставке заказчику;

— критерии завершения соответствующей деятельности, работ и задач;

— состав отчетных материалов по этапам, затратам и графикам проведения работ;

— периодичность и способы выдачи отчетных материалов;

— состав отчетных материалов по проблемам и устраненным дефектам;

— время начала и длительность сопровождения.

Рекомендуется сопроводителям формализовать конкретный план сопровождения ПС из представленного общего состава процессов ЖЦ, который уточнить и адаптировать с учетом объема и особенностей проекта, содержащий разделы:

— описание сопровождаемой системы, в которую входит ПС;

— концепция сопровождения комплекса программ; описание уровня сопровождения системы и ПС; установление длительности процессов сопровождения; адаптация стандартизированных процессов сопровождения;

— организационные работы по сопровождению, роли и обязанности специалистов;

— ресурсы: состав специалистов; инструментальные средства; технические средства; документы и планы;

— процессы — как должна быть выполнена конкретная деятельность;

— определение уровня обучения, необходимого для сопроводителей и для пользователей;

— протоколы и отчеты по сопровождению; контрольные данные,

собранные при работах по сопровождению.

Анализ дефектов и модификаций в стандарте ISO 14764 рекомендуется реализовать в следующем порядке:

— анализируются предложения о модификации и отчеты о дефектах;

— дублируется или проверяется реальность каждого дефекта;

— разрабатываются варианты реализации изменения;

— документально оформляются: предложения о модификации и отчеты о дефектах, результаты их рассмотрения и варианты реализации изменений;

— проводится согласование выбранного варианта реализации изменения с заказчиком.

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

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

разработка силами программистов предприятия; ·

заказ разработки у специализированного предприятия; ·

приобретение готового программного обеспечения.

Варианты внедрения программного обеспечения

Вариант

Преимущества

Недостатки

Внедрение полностью собственными силами

Меньшие финансовые затраты

Знание бизнес-процессов

Независимость на этапе эксплуатации

Требуются специалисты с хорошим знанием программного продукта

Требуются программисты

Требуется разработка методологии управления проектом и четкое следование ей

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

Реализация проекта (или его этапов) «под ключ» силами внешней компании-консультанта

Опыт управления проектами

Разработанная и «обкатанная» методология внедрения

Опыт внедрения системы на нескольких предприятиях

Владение современными методами построения систем управления

Штат опытных программистов

Большие финансовые затраты

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

Проблема поддержания системы на этапе эксплуатации

Привлечение руководителя проекта от внешней компании-консультанта

Меньшие финансовые затраты

Опыт управления проектами

Опыт внедрения системы на нескольких предприятиях

Владение современными методами построения систем управления

Независимость на этапе эксплуатации

Требуется разработка методологии управления проектом и четкое следование ей

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

Требуются программисты

Привлечение экспертов по продукту от внешней компании-консультанта

Меньшие финансовые затраты

Знание программного продукта

Требуется разработка методологии управления проектом и четкое следование ей

Необходимость решения вопроса занятости сотрудников

ЗАДАНИЕ 1

ТЕХНИЧЕСКОЕ ЗАДАНИЕ ИС
ПРИМЕР:

В качестве предметной области выбрана тема «Отдел информационных технологий. Учет компьютеров на предприятии».

1. Этап разработки раздела «Общие сведения»:

 Полное наименование ИС: «Отдел информационных технологий. Учет компьютеров на предприятии».

 Шифр темы: 00001.

 Предприятие-разработчик системы: Лаборатория баз данных “БД”, ул. 50 лет Октября, 86, тел. 32-12-02.

 Предприятие-заказчик системы: ООО «МЗ ТОНАР».

 Система создается на основании технического задания (ТЗ). ТЗ на АС является основным документом, определяющим требования и порядок создания автоматизированной системы, в соответствии с которым проводится разработка АС и ее приемка при вводе в действие. Кроме того, при создании системы используются ГОСТ 34.602-89 “Техническое задание на создание автоматизированной системы”.

 Плановый срок начала работ: 11.05.2021 г.

 Плановый срок окончания работ: 28.06.2021 г.

 Автоматизируемая система создается на коммерческой основе.

 Порядок оформления и предъявления заказчику результатов работы по созданию системы определяется после получения начальной версии продукта, в которой должны быть реализованы все основные функции, определенные в ТЗ и утвержденные заказчиком.

2. Этап разработки раздела «Назначение и цели создания системы»:

 Вид автоматизируемой деятельности: учет компьютерной техники на предприятии.

 Перечень автоматизируемых процессов: обеспечение выполнения перехода по формам, заполнения таблиц БД из программы, распределение объектов (компьютеров) по иерархии.

 Наименование и значение показателей, которые будут достигнуты в результате внедрения БД: уменьшение затрат рабочего времени на ввод, редактирование и поиск данных о компьютерах на предприятии, формирование иерархии «Здание-Отдел-Компьютер, уменьшение бумажного документооборота.

3. Этап разработки раздела «Характеристики объекта автоматизации»

Краткие сведения о предприятии.

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

Организационная структура.
Организационная структура предприятия показана на рисунке 1.

Рис. 1 «Структура предприятия»
Описание автоматизируемых процессов, информационные потоки автоматизируемых процессов.

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

Если у работника ломается компьютер, он обращается в ОИТ с просьбой посмотреть компьютер. Если техник после осмотра обнаруживает поломку, он забирает компьютер на ремонт, обнаруживает в чем проблема, и, если поломка аппаратная, делает запрос в казначейство за новой деталью, после чего они одобряют заявку и покупают новую деталь.

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

Рис. 2 «Схема информационных потоков процесса»
В целом, до начала разработки данной системы вся отчетность велась в программе «1С Предприятие», которая не удовлетворяла потребностям ОИТ по тем или иным причинам. Таким образом, видно, насколько рационально использовать базу данных и приложение собственной разработки по работе с ней. Благодаря такому решению, предприятию не нужно будет платить за лицензию на использование стороннего ПО. Также, благодаря наличию собственных программистов, отладка приложения в случае нахождения багов не будет проблемой.

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

Процессоры:

o Имя производителя

o Маркировка

o Модель

o Частота

o Путь к картинке

o Описание

o Кеш У1

o Кеш У2

o Кеш У3

Накопители:

o Тип накопителя

o Объем

o Модель

o Производитель

ОЗУ:

o Тип

o Объем

o Производитель

o Модель

o Частота

Производители:

o Имя

Сокеты:

o Название сокета

o Производитель

и т.д.

4. Этап разработки раздела «Требования к ИС»

Назначение разработки

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

Требования к функциональным характеристикам

Автоматизированная информационная система должна обеспечивать выполнение перехода по формам, заполнению таблиц БД из программы, распределение объектов по иерархии.

Входные данные

Процессоры:

Имя производителя

Маркировка

Модель

Частота

Путь к картинке

Описание

Кеш У1

Кеш У2

Кеш У3

Накопители:

Тип накопителя

Объем

Модель

Производитель

ОЗУ:

Тип

Объем

Производитель

Модель

Частота

Производители:

Имя

Сокеты:

Название сокета

Производитель

Выходные данные

В виде выходных данных выступает информация из данных в базе:

Процессоры:

Имя производителя

Маркировка

Модель

Частота

Картинка

Описание

Кеш У1

Кеш У2

Кеш У3

Накопители:

Тип накопителя

Объем

Модель

Производитель

ОЗУ:

Тип

Объем

Производитель

Модель

Частота

Производители:

Имя

Сокеты:

Название сокета

Производитель

И т.д.

Требования к надежности и безопасности

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

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

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

При передаче экземпляра ПО, использовать безопасные методы передачи информации.

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

Процессор

Intel Core 2 Quad q6600

ОЗУ

512 мб

Видеоадаптер

Любой адаптер

Доступ к сети

Стабильное подключение к сети

Разрешение экрана

От 1280х720

Дисковое пространство

Не менее 200 мб

Устройства ввода

Мышь, клавиатура

1.5. Требования к информационной и программной совместимости

Программа должна работать на операционной системе Windows 10.

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

СУБД – Microsoft SQL Server 2019.

Утилита для подключения и управления БД - SQL Server Management Studio 18.

Программа для связи с БД – Visual Studio 2019.

1.6. Требования к программной документации

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

5. Этап разработки раздела «Стадии и этапы разработки»

Стадии разработки

Разработка должна быть проведена в три стадии:

 разработка технического задания;

 рабочее проектирование;

 внедрение.

6. Этапы разработки

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

На стадии рабочего проектирования должны быть выполнены перечисленные ниже этапы работ:

 разработка модели автоматизируемых процессов и функциональной модели ИС;

 разработки логической и физической моделей данных;

 разработка программы;

 разработка программной документации;

 испытания программы.

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

Приемо-сдаточные испытания должны проводиться на объекте заказчика в оговоренные сроки. Приемо-сдаточные испытания программы должны проводиться согласно разработанной исполнителем и согласованной заказчиком программы и методик испытаний.

Ход проведения приемо-сдаточных испытаний заказчик и исполнитель документируют в протоколе проведения испытаний. На основании протокола проведения испытаний исполнитель совместно с заказчиком подписывает акт приемки-сдачи программы в эксплуатацию.

ЗАДАНИЕ 2
УСТАВ ПРОЕКТА
1. Разработать устав проекта, согласно требованиям, предъявляемым к нему.

№

Раздел

Пояснения

1.

Название проекта

Система Учета Копьютеров на Предприятии

2.

Бизнес-причина возникновения проекта

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

3.

Бизнес-цель

Автоматизировать процесс учета компьютеров на предприятии

4.

Требования, удовлетворяющие потребности, пожелания и ожидания заказчика, спонсора и других участников проекта

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

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

5.

Расписание основных контрольных событий

Плановый срок начала работ: 11.05.2021 г.

Плановый срок окончания работ: 28.06.2021 г.

Вообще рекомендуется ограничить

количество контрольных событий теми,

которые абсолютно необходимы, т.е. обычно

тремя-пятью. Иными словами, принимая во

внимание цель устава и соответствующий

уровень детализации, совершенно излишне

разрабатывать длинный список событий - это

только создаст дополнительные ограничения

для выбора методологии реализации проекта.

Кроме того, организации, придающие

значение себестоимости, имеют тенденцию

указывать для основных событий специфику

бюджета ресурсов или бюджета средств.

6.

Участники проекта

Сотрудники ОИТ, бухгалтерия, пользователи ПК на предприятии

7.

Окружение проекта

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

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

8.

Допущения относительно организации и окружения, а также внешние допущения

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

- компетенции команды проекта достаточно для выполнения предпроектного обследования;

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

Обратите внимание, что при составлении устава проекта допущения формулируются со стороны организации-заказчика об организации-исполнителе

9.

Ограничения относительно организации и окружения, а также внешние ограничения

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

увеличение стоимости проекта не более чем на 10%;

- не менее 40% членов команды проекта,

предоставляемых исполнителем, заняты на

100% в проекте.

Обратите внимание, что при составлении

устава проекта ограничения формулируются

со стороны организации-заказчика об

организации-исполнителе и о проекте в целом

10.

Объем денежных средств, выделенных на достижение бизнес-цели

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

11.

Назначение руководителей проекта и общее определение полномочий ключевых членов проектной команды: РП, спонсор, координатор

Руководитель проекта назначается уставом

проекта и формально приступает к

выполнению своих обязанностей на

следующий день после подписания устава

проекта. Руководитель, или менеджер, проекта

несет основную ответственность за общее

планирование, направление и контроль

проекта в течение всех фаз его жизненного

цикла, ставя целью получение желаемого

результата в рамках утвержденного бюджета и

расписания. Основная задача руководителя

проекта - объединение усилий всех лиц,

участвующих в проекте. Для решения этой

задачи менеджер проекта наделяется

полномочиями по проекту, т.е. правом

отдавать функциональным лидерам проекта

распоряжения, необходимые для

планирования, исполнения, мониторинга,

оценивания и контроля работ, которые должны

быть выполнены по данному проекту.

Руководство проектом также включает в себя

получение информации, необходимой для

планирования, мониторинга, оценивания и

контроля проекта. Роль спонсора проекта

обычно берет на себя (не назначается!!!)

менеджер высшего звена, который действует

от лица руководства компании,

финансирующей или исполняющей проект.

Ключевая задача спонсора заключается в

обеспечении ресурсов проекта, в том числе

административных, а также в обеспечении

связи между проектом и руководством

организации-заказчика. На проекте спонсор

является лицом, принимающим те решения,

которые находятся за пределами полномочий

руководителя проекта, например:

- утверждать бизнес-цели проекта, включая

расписания и бюджет, и вносимые в них

изменения;

- назначать и утверждать менеджера

проекта, а также утверждать соответствующую

должностную инструкцию и порядок

подчинения;

формировать стратегические указания для

менеджера проекта по ходу отслеживания

результатов проекта;

- вносить и утверждать основные изменения

по проекту и решения, касающиеся выделения

ресурсов;

- принимать решения о внесении изменений

в базовую линию проекта.

Роль спонсора проекта обычно не

предполагает работы с полной занятостью вне

зависимости от размера проекта.

Администратор (координатор) проекта - это

специфическая функция на проекте, которая

необходима для поддержки работ, связанных с

администрированием и документированием

функционирования проектной организации и

обеспечением инфраструктуры проекта.

Работа администратора имеет своей ключевой

задачей поддержку руководителя проекта на

операционном уровне с целью его

высвобождения для интеллектуально-сложных

задач. В обязанности координатора проекта

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

контрактов и договоров на протяжении всего

ЖЦ, организация периодического сбора

статуса выполнения проекта и т.п. сбор статуса

- словосочетание, не несущее смысла, если

только это не специфический термин.

Формировать всю команду и тем более сразу

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

выделяют для проекта своих подчиненных,

только когда руководитель проекта составит

план потребности в ресурсах, после

определения состава работ проекта, и отправит

официальный запрос на ресурсы,

утвержденный спонсором проекта.

2. Выбрать вариант внедрения. Обосновать свой выбор. Оформить задание в виде таблицы.

ЗАДАНИЕ 3

Разработать план сопровождения проекта и отчет о модификации и дефектах.
План сопровождения

Наименование программного средства:

Система Учета Копьютеров на Предприятии

Назначение программного средства:

Автоматизация процесса учета компьютеров на предприятии

Разработка программного средства:

Начало разработки: 11.05.2021 г.

Конец разработки: 31.05.2021 г

Сроки сопровождения:

Дата начала: 01.06.2021 г.

Дата завершения: 28.06.2021

Разработчик: Шабалкин Д. А.

Заказчик: ООО «МЗ ТОНАР»

Список работ при сопровождении:

Установка, обновление, переустановка драйверов
подключаемого фискального регистратора на 1 рабочем
месте клиента по запросу

Установка, обновление, переустановка, привязка
приложения Б.Ру Касса на 1 рабочем месте по запросу

Предоставляется возможность использования мобильного
приложения запроса в 1 клик
Выявление и диагностика ошибок фискального регистратора
и его ремонт, с данным вопросом необходимо обращаться в
ЦТО Вашего города

Обучение пользователей по работе с приложением

Состав исполнителей работ по сопровождению:

1. Разработчик – модификация структуры программного средства

Отчет о дефектах и модификации программного средства

Название дефекта или изменения

Статус

Действие

Роль

Дефект в функции «Добавление сотрудника»

1. Назначено

2. Открыто

3. Реализовано

4. Протестировано

5. Закрыто

1. Обнаружение ошибки

2. Просмотр ошибки

3. Исправление ошибки

4. Завершение исправления ошибки

5. Тестирование справленной ошибки

6. Эксплуатация ПС

Добавление функции «Поиск топлива»

1.Начальный

2.Назначено

3.Открыто

4.Реализовано

5.Протестировано

6.Закрыто

1. Утверждение изменения.

2. Разработка функции

3. Внедрение функции

4. Тестирование функции

5. Эксплуатация ПС

Добавление функции «Запрос на заправку»

1.Начальный

2.Назначено

3.Открыто

4.Реализовано

5.Протестировано

6.Закрыто

1. Утверждение изменения.

2. Разработка функции

3. Внедрение функции

4. Тестирование функции

5. Эксплуатация ПС

Дефект в функции «Ошибка дате поступления топлива»

1. Назначено

2. Открыто

3. Реализовано

4. Протестировано

5. Закрыто

1. Обнаружение ошибки

2. Просмотр ошибки

3. Исправление ошибки

4. Завершение исправления ошибки

5. Тестирование справленной ошибки

6. Эксплуатация ПС

ЗАДАНИЕ 4
1. Составить акт внедрения в опытную эксплуатацию.

2. Составить акт приемки в промышленную эксплуатацию.

АКТ ПРИЕМКИ В ПРОМЫШЛЕННУЮ ЭКСПЛУАТАЦИЮ
Наименование объекта автоматизации и АС (или ее части), принимаемой в промышленную эксплуатацию
Сведения о статусе приемочной комиссии (государственная, межведомственная, ведомственная), ее составе и основание для работы

Комиссия в составе:

Председатель комиссии

(должность, ФИО)

Заместитель председателя

комиссии

(должность, ФИО)

Члены комиссии:

(должность, ФИО)

(должность, ФИО)

(должность, ФИО)

Период времени работы комиссии
Наименование организации-разработчика, организации-соисполнителя и организации-заказчика

Наименование документа, на основании которого разработана АС
Состав функций АС (или ее части), принимаемой в промышленную эксплуатацию
Перечень составляющих технического, программного, информационного и организационного обеспечений, принимаемых в Промышленную эксплуатацию
Перечень документов, предъявляемых комиссии
Заключение о результатах опытной эксплуатации АС
Оценка соответствия принимаемой АС техническому заданию на ее создание
Краткая характеристика и основные результаты выполненной работы по созданию АС

Оценка экономической эффективности от внедрения АС (по проектным данным)
Решение комиссии
Рекомендации комиссии по дальнейшему развитию системы