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

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

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

ОБОРУДОВАНИЕ: ПК, 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. 
   Требования к функциональным характеристикам
   

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

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

Процессоры:

• 
  Имя производителя
  
• 
  Маркировка
  
• 
  Модель
  
• 
  Частота
  
• 
  Путь к картинке
  
• 
  Описание
  
• 
  Кеш У1
  
• 
  Кеш У2
  
• 
  Кеш У3
  

Накопители:

• 
  Тип накопителя
  
• 
  Объем
  
• 
  Модель
  
• 
  Производитель
  

ОЗУ:

• 
  Тип
  
• 
  Объем
  
• 
  Производитель
  
• 
  Модель
  
• 
  Частота
  

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

• 
  Имя
  

Сокеты:

• 
  Название сокета
  
• 
  Производитель
  

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

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

Процессоры:

• 
  Имя производителя
  
• 
  Маркировка
  
• 
  Модель
  
• 
  Частота
  
• 
  Картинка
  
• 
  Описание
  
• 
  Кеш У1
  
• 
  Кеш У2
  
• 
  Кеш У3
  

Накопители:

• 
  Тип накопителя
  
• 
  Объем
  
• 
  Модель
  
• 
  Производитель
  

ОЗУ:

• 
  Тип
  
• 
  Объем
  
• 
  Производитель
  
• 
  Модель
  
• 
  Частота
  

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

• 
  Имя
  

Сокеты:

• 
  Название сокета
  
• 
  Производитель
  

И т.д.

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. Этапы разработки

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

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

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

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

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

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

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

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

---

Смотрите также файлы

• Методические указания к выполнению лабораторнопрактической работы по дисциплине Конструкционные материалы для студентов энин.docx

• Практических заданий по дисциплине арбитражный процесс.docx

• 2. Журналистика в координатах истории.docx

• Транспортировка больных и пострадавших.pptx

• Мектеп 12 мектеп.docx