Адаптация программного продукта реферат

Обновлено: 05.07.2024

Категории и природа сопровождения программного обеспечения, оценка его трудоемкости. Разработка логической модели программы по регистрации контрольных работ. Организация вывода информации на web-страницу. Определение годового экономического эффекта.

Обозначения и сокращения

ИС Информационная Система

ЖЦ Жизненный Цикл

ПО Программное обеспечение

ГОСТ Государственный Стандарт

PHP Hypertext Preprocessor, гипертекстовый процессор

HTML Hyper Text Markup Languare, язык разметки гипертекста

АИС Автоматизированная Информационная Система

СУБД Система Управления Базами Данных

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

1. Теоретическая часть

1.1 Жизненный цикл

Методология проектирования ИС описывает процесс создания и сопровождения систем в виде жизненного цикла ИС.

ЖЦ ПО - это период разработки и эксплуатации ПО, в котором можно выделить следующие этапы:

- ввод в действие.

Существуют стандарты, регламентирующие ЖЦ, например ГОСТ 34.601-90. Распространяется на АИС и устанавливает стадии и этапы их создания. Содержит описания содержания работ на каждом этапе. Стадии и этапы работы, закреплены в стандарты соответствия каскадной модели ЖЦ.

ISO\IEC 12207:1995. Стандарт на процесс и организацию ЖЦ не содержит описания стадий и этапов.

1.2 Сопровождение программного обеспечения

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;

- простота - механизм РНР просто начинает выполнять код после первой экранирующей последовательности ( );

- безопасность - в РНР реализован механизм безопасности - это обеспечивает максимальную свободу действий и безопасность;

- гибкость - нет проблем и с зависимостью от браузеров, поскольку перед отправкой клиенту сценарии РНР полностью компилируются на стороне сервера.

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.

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

Рубрика	Программирование, компьютеры и кибернетика
Вид	презентация
Язык	русский
Дата добавления	15.09.2016
Размер файла	73,4 K

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

HTML-версии работы пока нет.
Cкачать архив работы можно перейдя по ссылке, которая находятся ниже.

Подобные документы

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

курсовая работа [636,2 K], добавлен 23.08.2011

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

дипломная работа [2,3 M], добавлен 22.07.2013

Практические аспекты использования прикладного программного обеспечения при разработке базы данных "Аудиторный фонд ГБОУ СПО "Старооскольский педагогический колледж". Системы управления базами данных. Описание и функциональные возможности приложения.

курсовая работа [360,4 K], добавлен 07.10.2014

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

курсовая работа [163,4 K], добавлен 20.01.2010

Цели и задачи программной инженерии. Понятие программного обеспечения. Шесть принципов эффективного использования программного обеспечения. Виды программного обеспечения: общесистемное, сетевое и прикладное. Принципы построения программного обеспечения.

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

Адаптация и модификация ПО — это изменения в программе для ЭВМ

Согласно пп. 9 п. 2 ст. 1270 ГК РФ адаптация программы — это внесение изменений, осуществляемых исключительно в целях функционирования программы для ЭВМ или базы данных на конкретных технических средствах пользователя или под управлением конкретных программ пользователя.

Практические критерии и примеры адаптации программного обеспечения

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

На практике очень часто при адаптации ПО в программу вносятся уникальные идентификаторы оборудования (или его отдельных блоков) или уникальные номера копий программ пользователя и/или устанавливаются иные критически важные для работоспособности взаимосвязи адаптируемого ПО с аппаратно-программным комплексом пользователя.

Пример адаптации, подпадающий под данные практические критерии, приводится и разобран в статье А.В. Дюкова. Так, автор считает, что «с точки зрения определения пределов правомерной адаптации могут представлять интерес программы для ЭВМ с встроенной программной защитой от несанкционированного копирования, несанкционированного доступа и других действий пользователя с программой, осуществление которых по тем или иным причинам желает ограничить или запретить правообладатель. Использование такой программной защиты — достаточно распространенная практика на рынке программного обеспечения. Указанная программная защита зачастую является встроенной, т.е. представляет собой неотъемлемую часть самой программы для ЭВМ.

Таким образом, мнение правообладателя является определяющим для квалификации изменений и пределов использования программного обеспечения, таких как модификация, адаптация или иное правомерное использование программы для ЭВМ. То есть правообладатель определяет, что есть модификация и адаптация программы для ЭВМ.

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

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

Коллегия судей отмечает, что нарушением исключительных прав правообладателя (незаконным использованием) является в силу подпункта 9 пункта 2 статьи 1270 ГК РФ переработка (модификация) программы для ЭВМ…

Разграничение адаптации и модификации ПО

К признакам, отличающим адаптацию от модификации программного обеспечения, можно отнести следующие:

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

Заключение

Таким образом, адаптация ПО — это такие изменения в исходный и/или объектный код ПО, которые удовлетворяют следующим практическим критериям:

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

8 мая 2012

Сопровождение программных систем

Определение процесса сопровождения

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

ISO/IEC 14764 (2006, русский перевод стандарта 1999 г. — 2002 г.);
ISO/IEC 12207 (2008, русский перевод стандарта 2010г.);
ISO 20000;
SWEBOK (2004 г.);
ITIL v3 (2007 г, обновление — 2011 г.);
COBIT v5 (2012 г.).

В общем случае процесс сопровождения состоит из следующих задач:

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

Сопровождение и удовлетворенность пользователей

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

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

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

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

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

Типы заявок предложений о модификации

Процесс сопровождения состоит из обработки заявок пользователей. Эти заявки целесообразно классифицировать по типам (см. рис. 2).

Рис. 2. Иерархия типов предложения по модификации ПО (по стандарту ГОСТ Р ИСО/МЭК 14764-2002)

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

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

Полное (совершенствующее) сопровождение — изменение программного продукта после поставки для улучшения производительности или удобства эксплуатации.

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

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

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

Этапы процесса сопровождения

Рис. 3. Общая структура процесса сопровождения (по стандарту ГОСТ Р ИСО/МЭК 14764-2002)

Формирование процесса сопровождения начинается с разработки концепции сопровождения. Такой документ, например, по стандарту ISO/IEC 14764 (Standard for Software Engineering — Software Maintenance), должен содержать следующие разделы:

1. Область сопровождения программного средства.

2. Практическое применение (адаптация) данного процесса.

3. Определение организаций (лиц), ответственных за сопровождение.

4. Оценка стоимости сопровождения:

4.1. Проезд до места расположения пользователя.
4.2. Обучение как сопроводителей, так и пользователей.
4.3. СПИ (среда программной инженерии) и СТПС (среда тестирования программного средства) и их ежегодное сопровождение.
4.4. Персонал (зарплата и премии).

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

Стандарт ГОСТ Р ИСО/МЭК 14764-2002 предлагает следующий состав такого плана:

a). Введение:

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

b). Концепция сопровождения (уже кратко описанная выше):

описание концепции;
описание уровня поддержки системы;
установление периода поддержки;
адаптация (практическое применение) процесса сопровождения;

c). Организационные работы и работы по сопровождению:

1. роли и обязанности сопроводителя до поставки программного продукта:

реализация процесса;
определение инфраструктуры процесса;
установление процесса обучения;
установление процесса сопровождения;

2. роли и обязанности сопроводителя после поставки программного продукта:

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

3. роль пользователя:

приемочные испытания;
взаимосвязи (интерфейсы) с другими организациями;

d). Ресурсы:

состав персонала для конкретного проекта; Структура, отвечающая за сопровождение, должна проводить общую деятельность по бизнес-планированию, касающуюся бюджетирования, финансового менеджмента и управления человеческими ресурсами в области сопровождения.

2. программные средства:

определение программных средств, необходимых для поддержки эксплуатации системы (с учетом системных требований и требований к СПИ, СТПС и инструментальным средствам);

3. технические средства:

определение технических средств, необходимых для поддержки эксплуатации системы (с учетом системных требований и требований к СПИ, СТПС и инструментальным средствам);

4. оборудование (аппаратура):

определение требований к оборудованию (аппаратуре) системы (помимо технических средств вычислительной техники);

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

6. данные;
7. другие требования к ресурсам (при необходимости);

e). Процесс (как должна быть выполнена конкретная деятельность):

1. процесс, выполняемый сопроводителем (приводят общее описание процесса без детализации в плане сопровождения всего процесса);

2. процесс адаптации (практического применения сопровождения к условиям проекта);

f). Обучение:

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

g). Протоколы и отчеты по сопровождению:

1. перечень запросов пользователя на оказание услуг по сопровождению, предложение о модификациях или отчеты о проблемах;
2. состояния запросов (предложений, отчетов) по категориям;
3. приоритеты запросов (предложений, отчетов);
4. контрольные данные, собранные при работах по сопровождению.

Связь сопровождения с эволюцией ПО

Отдельно хочется коснуться связи сопровождения с эволюцией программных систем. В 1969 году Мэнни М. Леман впервые связал деятельность по сопровождению и вопросы эволюции программного обеспечения. Результаты более чем 20-ти летних исследований группы, которой он руководил, привели к формулированию ряда важных положений.
Ключевой результат: деятельность по сопровождению, по сути, представляет собой эволюционную разработку программных систем. Принятию тех или иных решений в процессе сопровождения, помогает понимание того, что происходит с программной системой в процессе ее эксплуатации.

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

Леман вместе с Белади (Lehman and Belady) выделили 3 типа программ.

Программы S-типа, требования к которым могут быть формализованы.
Программы P-типа, которые развиваются итеративно.
Программы E-типа, которые влияют на окружающую среду. Поэтому их нельзя рассматривать изолированно от нее.

На основании этой классификации для программных систем Е-типа постепенно Леманом были сформулированы законы эволюции:

(1974) Непрерывное изменение — системы E-типа должны непрерывно адаптироваться или они будут все менее удовлетворять потребностям компании.
(1974) Увеличение сложности — по мере развития систем E-типа их сложность будет возрастать, если не поддерживать их и не уменьшать сложность.
(1974) Саморегулирование — процесс эволюции систем E-типа саморегулируем, распространение продукта близко к нормальному закону.
(1978) Сохранение организационной стабильности — средняя скорость развития систем E-типа инвариантна относительного жизненного типа программного продукта.
(1978) Сохранение осведомленности — поскольку системы E-типа вовлечены во все с ними связанное: разработчиков, продавцов, пользователей, то для достижения полезного развития необходимо поддерживать знание их содержания и поведения различными группами пользователей. Избыточное развитие ухудшает владение системой.
(1991) Непрерывное развитие — функциональное содержание систем E-типа должно непрерывно расширяться, чтобы обеспечить удовлетворенность пользователей на период жизненного цикла системы.
(1996) Ухудшение качества — качество систем E-типа будет ухудшаться, если они не будут тщательно сопровождаться и адаптироваться под изменения операционной среды.
(1996) Система обратной связи (впервые — 1974, формализовано — 1996) — процессы эволюции систем E-типа представляют собой системы многоуровневой, многоконтурной и охватывающей многих сотрудников обратной связи и должны быть такими, чтобы достигнуть существенных улучшений разумными средствами.

Сопровождение выгодно всем

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

Заказчику

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

Внедренцу — возможность:

Вендору

возможность эффективно развивать продукт и оперативно исправлять ошибки;
возможность повысить удовлетворенность партнеров и клиентов.

Тем, кто этого еще не сделал, необходимо обратить свое внимание на процесс сопровождения программного обеспечения.

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

автор IS2002 12.02.14 0:59

ИЗВЕСТИЯ ПЕНЗЕНСКОГО ГОСУДАРСТВЕННОГО ПЕДАГОГИЧЕСКОГО УНИВЕРСИТЕТА имени В. Г. БЕЛИНСКОГО ФИЗИКО-МАТЕМАТИЧЕСКИЕ И ТЕХНИЧЕСКИЕ НАУКИ № 13 (17) 2009
А. Б. БАКАНОВ, В. В. ДРОЖДИН, Р. Е. ЗИНЧЕНКО, Р. Н. КУЗНЕЦОВ

Программное обеспечение (ПО) появилось одновременно с техническими средствами компьютеров и вместе с совершенствованием компьютерной техники прошло существенный путь своего развития. В настоящее время область ПО является одной из самых науко- и трудоемких областей деятельности человечества, практически полностью базирующейся на ручном труде. Считается, что в истории развития ПО было всего две серьезных революции: возникновение программного управления техническими средствами компьютеров на заре зарождения компьютерной техники и разработка языков программирования высокого уровня и трансляторов с них в машинный код в 70-х годах ХХ века. Ни разработка более мощных языков программирования и объектных библиотек, ни использование Case-средств проектирования и создания программных систем, к сожалению, не дали ожидаемого эффекта на фоне грандиозных возможностей современных компьютеров и компьютерных сетей вследствие пассивности программно-технических систем и слабой модифицируемости создаваемого ПО.

Поколения развития ПО

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

2. ПО с установкой и инсталляцией

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

В 70-80 годах математик и программист Э. Кодд окончательно сформулировал и разработал концепцию реляционных баз данных (БД). Подобный подход к организации и хранению информации допускал эффективную реализацию обработки данных большого объема на компьютере и доступа к ней различных пользователей. По мере развития компьютеров, машины становились все меньше, а их ресурсы все больше, что явилось толчком к использованию одной и той же информации многими пользователями. Поэтому возникла насущная необходимость объединения большого количества компьютеров в сети.
Одной из первых, действительно удачных реализаций реляционных баз данных стала система управления базой данных (СУБД) dBase фирмы Aston Table, достоинство который состояло в том, что она реально позволяла создавать таблицы и связи между ними. dBase поддерживала встроенный язык обработки данных xBase и была интерпретатором. Язык xBase оказался эффективным средством описания действий с таблицами БД поэтому было разработано несколько реализующих его систем: компилятор Clipper, интерпретатор и компилятор FoxBASE и др.
Однако настоящий взрыв произвело появление СУБД FoxPro фирмы FoxSoftware, ориентированной преимущественно на разработчиков БД, а не на пользователей. язык FoxPro был значительно расширен конструкциями для оформления программ, создания интерфейсов взаимодействия с пользователями и др. Но самое главное отличие FoxPro состояло в наличии оптимизатора доступа к данным по технологии Rushmore, обеспечивающего высокую эффективность обработки данных. После покупки компании FoxSoftware корпорацией Microsoft был разработан мощный продукт Visual FoxPro, полностью поддерживающий концепцию реляционных БД и включенный в объектно-ориентированную среду программирования, предназначенную для профессиональных разработчиков ПО.
По пути поддержки специализированных языков программирования пошли также разработчики и
других СУБД, например, поддержка языка PL-SQL в СУБД ORACLE.
Не отстают от СУБД и развитые прикладные системы, наиболее ярким представителем которых является система 1С:Предприятие.
Система 1С:Предприятие может дорабатываться и устанавливаться на малых и больших предприятиях, на предприятиях разных форм собственности и др.
Таким образом, именно наличие встроенных средств программирования, позволяющих существенно расширять и модифицировать функции базовой системы, позволяют системам данного класса получить достаточно широкое распространение и увеличить срок их эксплуатации. Однако создание и сопровождение прикладных систем на базе систем со встроенными средствами доработки являются очень трудоемкими.
На понижение этой трудоемкости ориентированы системы следующего класса.

4. ПО, создаваемое на основе проектирования, и самонастраивающееся ПО

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

5. Самоорганизующееся ПО

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

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

Методы адаптации ПО

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

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

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

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

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

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

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

IS2002 Бакалавр

Читайте также: