Сопровождение программного продукта. Сопровождение программного продукта.. Жц жизненный Цикл по программное обеспечение
 Скачать 0.97 Mb.
|
|
Обозначения и сокращения ИС Информационная Система ЖЦ Жизненный Цикл ПО Программное обеспечение ГОСТ Государственный Стандарт PHP Hypertext Preprocessor, гипертекстовый процессор HTML Hyper Text Markup Languare, язык разметки гипертекста АИС Автоматизированная Информационная Система БД База Данных СУБД Система Управления Базами Данных Введение Сопровождение программного продукта - это одна из стадий жизненного цикла ИС, она производится при проведении опытной эксплуатации созданного продукта, оно заключается в удовлетворении потребностей пользователя, проведение доработок и вообще повышении полезности программы. При этом могут выявляться недостатки продукта, ошибки в программном коде, для этого моделируются различные действия пользователя, аварийные ситуации, в ходе которых анализируется поведение программы. Если же выявлены недостатки, то специалист, занимающийся сопровождением данного продукта должен отладить программу и предоставить заказчику надежную рабочую версию. Надежность программы стоит понимать как уровень, при котором она удовлетворяет всем поставленным требованиям и пригодна для эксплуатации. 1. Теоретическая часть 1.1 Жизненный цикл Методология проектирования ИС описывает процесс создания и сопровождения систем в виде жизненного цикла ИС. ЖЦ ПО – это период разработки и эксплуатации ПО, в котором можно выделить следующие этапы: - разработка требований; - проектирование; - реализация; - тестирование; - ввод в действие. Существуют стандарты, регламентирующие ЖЦ, например ГОСТ 34.601-90. Распространяется на АИС и устанавливает стадии и этапы их создания. Содержит описания содержания работ на каждом этапе. Стадии и этапы работы, закреплены в стандарты соответствия каскадной модели ЖЦ. ISO\IEC 12207:1995. Стандарт на процесс и организацию ЖЦ не содержит описания стадий и этапов. 1.2 Сопровождение программного обеспечения Сопровождение ПО – процесс улучшения, оптимизации и устранения дефектов ПО после передачи его в эксплуатацию. В ходе сопровождения в программу вносятся изменения, с тем, чтобы исправить обнаруженные в процессе эксплуатации дефекты и недостатки, а также для добавления новой функциональности, с целью повышения удобства использования. Процессы сопровождения программных продуктов определяются стандартами IEEE 1219 (Standard for Software Maintenance) и ISO/IEC 14764 (Standard for Software Engineering - Software Maintenance). 1.2.1 Природа сопровождения Сопровождение программного обеспечения определяется как вся совокупность деятельности, необходимой для обеспечения эффективной поддержки программных систем. Эти работы выполняются как перед вводом системы в эксплуатацию, так и после этого. Предварительные работы включают планирование деятельности по сопровождению системы, а также организацию перехода к ее полнофункциональному использованию. Если новая система должна заменить старую систему, предназначенную для решения тех же задач, просто на новом уровне эффективности, стоимости использования, новых функциональных возможностей, в этом случае важно обеспечить плавный переход со старой системы на новую, максимально естественный для пользователей. С этим связано не только планирование, например, переноса информации, хранимой в соответствующих базах данных, но и обучение пользователей. Сопровождение поддерживает функционирование программного продукта на протяжении всего периода его эксплуатации. В процессе сопровождения фиксируются и отслеживаются запросы на модификацию, оценивается влияние предлагаемых изменений, модифицируется код и другие элементы продукта, проводится необходимое тестирование и, наконец, выпускается обновленная версия продукта. Кроме того, проводится обучение пользователей и обеспечивается их ежедневная поддержка при работе с текущей версией продукта. Специалист, занимающийся сопровождением, может получать знания о программном продукте непосредственно от разработчиков. Взаимодействие с разработчиками и раннее привлечение этих специалистов помогает уменьшить усилия, необходимые для адекватного сопровождения программной системы. Передача знаний сопроводителю, его обучение, должно начинаться не позднее начала опытной эксплуатации продукта. Специалист, занимающийся сопровождением должен иметь доступ к активам проекта (описанию его внутренней архитектуры), включая код, документацию. Как правило, основная нагрузка на службу сопровождения приходится на период первых 2-6 недель с момента передачи системы в эксплуатацию. Инженеры по технической поддержке производителя программного обеспечения должны не просто иметь доступ ко всем ключевым активам проекта (код, документация, спецификации требований, внутренние модели), но в их обязанности входит исправлений ошибок и, в особых случаях, такие изменения, до выпуска новой версии продукта, создаются с привлечением непосредственно разработчиков продукта. При этом, разработчики продукта информируются о найденных ошибках и, в случае нахождения соответствующих решений специалистами технической поддержки, такие решения передаются разработчикам с тем, чтобы те либо включили такие изменения в новую версию программного продукта, в случае успешного прохождения всех необходимых тестов, либо нашли более адекватное решение. В обязанности инженеров службы сопровождения, в общем случае, входит: - проверка пользовательского сценария, приводящего к сбою; - идентификация причин сбоя, т.е. локализация ошибки/причин ее появления; - предоставление соответствующих исправлений или, при невозможности создания таковых на данном этапе либо в заданные сроки – предоставление обходного пути решения проблемы для достижения требуемых задач; - журналирование всех работ и операций; помещение описания проблемы и ее решения в базу знаний службы сопровождения; передача всей информации разработчикам. 1.2.2 Потребность в сопровождении Сопровождение необходимо для обеспечения того, чтобы программный продукт на протяжении всего периода эксплуатации удовлетворял требованиям пользователей. Деятельность по сопровождению применима для программного обеспечения, созданного с использованием любой модели жизненного цикла. В общем случае, работы по сопровождению должны проводиться для решения следующих задач: - устранение сбоев; - улучшение дизайна; - реализация расширений; - создание интерфейсов взаимодействия с другими (внешними) системами; - адаптация (например, портирование) для возможности работы на другой аппаратной платформе (или обновленной платформе), применения новых системных возможностей, функционирования в среде обновленной телекоммуникационной инфраструктуры и т.п.; - миграции унаследованного программного обеспечения; - вывода программного обеспечения из эксплуатации. Деятельность персонала сопровождения включает четыре ключевых аспекта: - поддержка контроля (управляемости) программного обеспечения в течение всего цикла эксплуатации; - поддержка модификаций программных систем; - совершенствование существующих функций; - предотвращение падения производительности программной системы до неприемлемого уровня. 1.2.3 Категории сопровождения Определяют четыре категории работ по сопровождению: корректировка, адаптация, совершенствование и профилактическое сопровождение: - корректирующее сопровождение: “реактивная” модификация программного продукта, выполняемая уже после передачи в эксплуатацию для устранения сбоев; - адаптирующее сопровождение: модификация программного продукта на этапе эксплуатации для обеспечения продолжения его использования с заданной эффективностью (с точки зрения удовлетворения потребностей пользователей) в изменившемся или находящемся в процессе изменения окружении; - совершенствующее сопровождение: модификация программного продукта на этапе эксплуатации для повышения характеристик производительности и удобства сопровождения; - профилактическое сопровождение: модификация программного продукта на этапе эксплуатации для идентификации и предотвращения скрытых дефектов до того, когда они приведут к реальным сбоям. 1.2.4 Работы по сопровождению Многие работы по сопровождению похожи на аспекты деятельности по разработке. В обоих случаях необходимо проводить анализ, проектирование, кодирование, тестирование и документирование. Специалисты по сопровождению должны отслеживать требования так же, как и инженеры-разработчики и обновлять документацию по мере разработки и/или выпуска обновленных или новых релизов продукта. В то же время, деятельность по сопровождению обладает и определенными уникальными чертами, что приводит к необходимости использования специализированных процессов: - передача: контролируемая и координируемая деятельность по передаче программного обеспечения от разработчиков группе, службе или организации, отвечающей за дальнейшую поддержку; - принятие/отклонение запросов на модификацию: запросы на изменения могут как приниматься и передаваться в работу, так и отклоняться по различным обоснованным причинам – объему и/или сложности требуемых изменений, а также необходимых для этого усилий. Соответствующие решения могут также приниматься на основе приоритетности, оценке обоснованности, отсутствии ресурсов - средства извещения персонала сопровождения и отслеживания статуса запросов на модификацию и отчетов об ошибках: функция поддержки конечных пользователей, инициирующая работы по оценке (в том числе оценку необходимости), анализу приоритетности и стоимости модификаций, связанных с поступившим запросом или сообщенной проблемой. - анализ влияния: анализ возможных последствий изменений, вносимых в существующую систему; - поддержка программного обеспечения: работы по консультированию пользователей, проводимые в ответ на их информационные запросы, например, касающиеся соответствующих бизнес-правил, проверки, содержания данных и специфических вопросов пользователей и их сообщений о проблемах; - контракты и обязательства: к ним относятся классическое соглашение об уровне предоставляемого сервиса, а также другие договорные аспекты, на основании которых, группа/служба/организация по сопровождению выполняет соответствующие работы. 1.3 Язык программирования PHP PHP – это широко используемый язык сценариев общего назначения с открытым исходным кодом, специально разработанный для написания web-приложений (сценариев), исполняющихся на Web-сервере. Важным преимуществом языка PHP перед такими языками, как языков Perl и C заключается в возможности создания HTML документов с внедренными командами PHP, может быть встроен непосредственно в HTML-код страниц, которые, в свою очередь будут корректно обрабатываться PHP-интерпретатором. PHP обладает пятью важными характеристиками: - традиционность - код РНР очень похож на тот, который встречается в типичных программах на С или Pascal; - простота - механизм РНР просто начинает выполнять код после первой экранирующей последовательности (); - эффективность - «движок» PHP не является ни компилятором, ни интерпретатором. Он является транслирующим интерпретатором. Такое устройство «движка» PHP позволяет обрабатывать сценарии с достаточно высокой скоростью; - безопасность - в РНР реализован механизм безопасности - это обеспечивает максимальную свободу действий и безопасность; - гибкость - нет проблем и с зависимостью от браузеров, поскольку перед отправкой клиенту сценарии РНР полностью компилируются на стороне сервера. 2. Практическая часть 2.1 Словесное описание предметной области В Воткинском Машиностроительном техникуме существует заочное отделение. Каждый студент заочного отделения должен сдавать контрольную работу по дисциплинам, которые изучает. Идентифицировать студента можно, зная номер его студенческого билета и дату поступления, так как номера студенческих повторяются каждые пять лет. Секретарь регистрирует сдачу контрольной работы и вклеивает в работу рецензию, в которой краткая информация о сдаче контрольной работы (дата сдачи, дата проверки, специальность, группа, дисциплина, ФИО студента, ФИО рецензента). Сданные и зарегистрированные контрольные работы забирают преподаватели на проверку. После проверки работы преподаватель обязан поставить оценку и дату проверки на рецензии, после чего контрольную работу возвращают обратно к секретарю. Задача данного приложения регистрировать сданные контрольные работы и распечатывать рецензии, хранить информацию о преподавателе, проверившего контрольную работу, о дате проверки и оценке. Выдавать сведения по проверке контрольных работ, как по всем преподавателям, так и по отдельному преподавателю; вывод данных о сдаче контрольных работ студентами за определенный период, вывод данных на web-страницу. 2.2 Логическая модель Логическая модель представлена на рисунке 4.  Рисунок 4 – Логическая модель. Изменена сущность «Студент», добавлен атрибут «Дата поступления». Первичный ключ таблицы составной, состоит из двух полей: «Номер билета» и «Дата поступления». 2.3 Схема данных приложения Схема данных приложения представлена на рисунке 5.  Рисунок 5 – Схема данных приложения. Схема данных приложения изменена в соответствии с логической моделью. 2.4. Схема работы приложения Схема работы приложения представлена на рисунке 6.  Рисунок 6 – Схема работы приложения. Добавлена web страница для обновления БД MySQL со студентами и контрольными работами, отображены все формы 2.5 Внешний интерфейс Главная форма приложения представлена на рисунке 7.  Рисунок 7 – Главная форма приложения. Изменен цвет формы, добавлена картинка. Форма регистрации контрольных работ представлена на рисунке 8.  Рисунок 8 - Форма регистрации контрольных работ. Изменен цвет формы, добавлено поле с датой поступления студента. Форма перевода студентов на другой курс представлена на рисунке 9  Рисунок 9 - Форма перевода студентов на другой курс. Изменен цвет формы, добавлено поле с текущей датой и поле, поясняющее как перевести группу на следующий курс. Форма ввода новых студентов представлена на рисунке 10.  Рисунок 10 - Форма ввода новых студентов. Изменен цвет формы, добавлено поле с текущей датой. Форма для ввода нового преподавателя представлена на рисунке 11.  Рисунок 11 - Форма для ввода нового преподавателя. Изменен цвет формы, добавлена кнопка перехода к форме регистрации контрольных. 2.6 Организация вывода информации на web страницу Для организации вывода отчета по сданным контрольным работам на web страницу, была разработана идея переноса необходимых данных из MS Access в MySQL. После занесения новой записи в таблицу БД MS Access выполняется макрос, экспортирующий данные в текстовый файл. Далее выполняется php сценарий, записывающий данные из текстового файла в таблицу БД MySQL. Данные для отчета берутся из таблиц БД MySQL. Такой алгоритм работы был разработан ввиду невозможности прямого экспорта данных из MS Access в MySQL. Схема передачи данных из MS Access в MYSQL представлена на рисунке 12.  Рисунок 12 – Схема передачи данных из MS Access в MYSQL. Алгоритм работы php-скрипта обновления таблиц со студентами и контрольными работами в БД MySQL представлен на рисунке 13.  Рисунок 13 – алгоритм работы php-скрипта обновления таблиц со студентами и контрольными работами в БД MySQL Web страница для обновления БД MySQL представлена на рисунке 14.  Рисунок 14 – Web страница обновления БД. Web страница после обновления БД MySQL, представлена на рисунке 15.  Рисунок 15 - Web страница после обновления БД. Web страница для ввода данных для получения контрольных работ представлена на рисунке 16  Рисунок 16 - Web страница для ввода данных для получения контрольных работ. Web страница с контрольными работами определенного студента представлена на рисунке 17.  Рисунок 17 – Web страница с контрольными работами. 3. Экономическая часть 3.1 Определение годового экономического эффекта Таблица 1- Нормы времени по видам работ
Далее производится расчет годовой экономии рабочего времени по формуле Эг = ( Нруч – Навт ) * Др, (1) где Эг – экономия годовая; Н |