Практическая работа по теме_ «разработка сценария внедрения и со. 17-18Практическая работа по теме_ «разработка сценария внедрения. Практическая работа по теме разработка сценария внедрения и сопровождения программного продукта для рабочего места
Скачать 0.67 Mb.
|
|
Варианты внедрения программного обеспечения | ||
Вариант | Преимущества | Недостатки |
Внедрение полностью собственными силами | Меньшие финансовые затраты Знание бизнес-процессов Независимость на этапе эксплуатации | Требуются специалисты с хорошим знанием программного продукта Требуются программисты Требуется разработка методологии управления проектом и четкое следование ей Необходимость решения вопроса занятости сотрудников, выделенных (или нанятых) для реализации проекта |
Реализация проекта (или его этапов) «под ключ» силами внешней компании-консультанта | Опыт управления проектами Разработанная и «обкатанная» методология внедрения Опыт внедрения системы на нескольких предприятиях Владение современными методами построения систем управления Штат опытных программистов | Большие финансовые затраты Сторонние консультанты не знают особенностей конкретного предприятия, и им требуется время на их изучение Проблема поддержания системы на этапе эксплуатации |
Привлечение руководителя проекта от внешней компании-консультанта | Меньшие финансовые затраты Опыт управления проектами Опыт внедрения системы на нескольких предприятиях Владение современными методами построения систем управления Независимость на этапе эксплуатации | Требуется разработка методологии управления проектом и четкое следование ей Необходимость решения вопроса занятости сотрудников, выделенных (или нанятых) для реализации проекта Требуются программисты |
Привлечение экспертов по продукту от внешней компании-консультанта | Меньшие финансовые затраты Знание программного продукта | Требуется разработка методологии управления проектом и четкое следование ей Необходимость решения вопроса занятости сотрудников |
ЗАДАНИЕ 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. | Назначение руководителей проекта и общее определение полномочий ключевых членов проектной команды: РП, спонсор, координатор | Руководитель проекта назначается уставом проекта и формально приступает к выполнению своих обязанностей на следующий день после подписания устава проекта. Руководитель, или менеджер, проекта несет основную ответственность за общее планирование, направление и контроль проекта в течение всех фаз его жизненного цикла, ставя целью получение желаемого результата в рамках утвержденного бюджета и расписания. Основная задача руководителя проекта - объединение усилий всех лиц, участвующих в проекте. Для решения этой задачи менеджер проекта наделяется полномочиями по проекту, т.е. правом отдавать функциональным лидерам проекта распоряжения, необходимые для планирования, исполнения, мониторинга, оценивания и контроля работ, которые должны быть выполнены по данному проекту. Руководство проектом также включает в себя получение информации, необходимой для планирования, мониторинга, оценивания и контроля проекта. Роль спонсора проекта обычно берет на себя (не назначается!!!) менеджер высшего звена, который действует от лица руководства компании, финансирующей или исполняющей проект. Ключевая задача спонсора заключается в обеспечении ресурсов проекта, в том числе административных, а также в обеспечении связи между проектом и руководством организации-заказчика. На проекте спонсор является лицом, принимающим те решения, которые находятся за пределами полномочий руководителя проекта, например: - утверждать бизнес-цели проекта, включая расписания и бюджет, и вносимые в них изменения; - назначать и утверждать менеджера проекта, а также утверждать соответствующую должностную инструкцию и порядок подчинения; | |
| | формировать стратегические указания для менеджера проекта по ходу отслеживания результатов проекта; - вносить и утверждать основные изменения по проекту и решения, касающиеся выделения ресурсов; - принимать решения о внесении изменений в базовую линию проекта. Роль спонсора проекта обычно не предполагает работы с полной занятостью вне зависимости от размера проекта. Администратор (координатор) проекта - это специфическая функция на проекте, которая необходима для поддержки работ, связанных с администрированием и документированием функционирования проектной организации и обеспечением инфраструктуры проекта. Работа администратора имеет своей ключевой задачей поддержку руководителя проекта на операционном уровне с целью его высвобождения для интеллектуально-сложных задач. В обязанности координатора проекта может входить: администрирование проектных контрактов и договоров на протяжении всего ЖЦ, организация периодического сбора статуса выполнения проекта и т.п. сбор статуса - словосочетание, не несущее смысла, если только это не специфический термин. Формировать всю команду и тем более сразу указывать имена всех ее членов не принято -функциональные руководители обычно выделяют для проекта своих подчиненных, только когда руководитель проекта составит план потребности в ресурсах, после определения состава работ проекта, и отправит официальный запрос на ресурсы, утвержденный спонсором проекта. |
|
ЗАДАНИЕ 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. Составить акт приемки в промышленную эксплуатацию.
АКТ ПРИЕМКИ В ПРОМЫШЛЕННУЮ ЭКСПЛУАТАЦИЮ
Наименование объекта автоматизации и АС (или ее части), принимаемой в промышленную эксплуатацию
Сведения о статусе приемочной комиссии (государственная, межведомственная, ведомственная), ее составе и основание для работы
Комиссия в составе:
Председатель комиссии | |
| (должность, ФИО) |
Заместитель председателя комиссии | |
| (должность, ФИО) |
Члены комиссии: | |
| (должность, ФИО) |
| |
| (должность, ФИО) |
| |
| (должность, ФИО) |
Период времени работы комиссии
Наименование организации-разработчика, организации-соисполнителя и организации-заказчика
Наименование документа, на основании которого разработана АС
Состав функций АС (или ее части), принимаемой в промышленную эксплуатацию
Перечень составляющих технического, программного, информационного и организационного обеспечений, принимаемых в Промышленную эксплуатацию
Перечень документов, предъявляемых комиссии
Заключение о результатах опытной эксплуатации АС
Оценка соответствия принимаемой АС техническому заданию на ее создание
Краткая характеристика и основные результаты выполненной работы по созданию АС
Оценка экономической эффективности от внедрения АС (по проектным данным)
Решение комиссии
Рекомендации комиссии по дальнейшему развитию системы