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

Обновлено: 03.07.2024

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

Существует три вида сопровождения системы:

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

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

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

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


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

Рис.1. Распределение типов сопровождения

Согласно исследованиям, 65% сопровождения связано с выполнением новых требований, 18% отводится на изменения системы с целью адаптации к новому окружению и 17% связано с исправлением ошибок (рис. 1.).

Из этого можно определить, что исправление ошибок не является самым распростра­ненным видом сопровождения. Модернизация системы в соответствии с новым рабочим окружением либо в соответствии с новыми требованиями более эффективна. Поэтому со­провождение само по себе является естественным процессом продолжения разработки системы со своими процессами проектирования, реализации и тестирования. Таким об­разом, спиральная модель, показанная на рис. 2, лучше представляет процесс развития ПО, чем каскадная модель, где сопровождение рассматривается как отдель­ный процесс.


Рис.2. Спиральная модель развития ПО

Значительная часть бюджета большинства организаций уходит на сопровождение ПО, а не на само использование программных систем. В 1980-х годах было обнаружено, что во многих организациях по меньшей мере 50% всех средств, потраченных на программирование, идет на развитие уже существующих систем. При этом от 65 до 75% средств общего бюджета расходуется на сопровождение. Так как предприятия заменяют старые системы коммерческим ПО, например программами планирования ресурсов, эти цифры никак не будут уменьшаться. Поэтому можно утверждать, что из­менение ПО все еще остается доминирующим в статье затрат организаций на про­граммное обеспечение.

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

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

На рис. 3 показано, как снижается стоимость сопровождения хорошо разработан­ных систем. Здесь при разработке системы 1 выделено дополнительно $25 000 для облег­чения процесса сопровождения. В результате за время эксплуатации системы это помогло сэкономить около $100 000. Из сказанного следует, что увеличение средств на разработку системы пропорционально снизит затраты на ее сопровождение.


Рис.3. Расходы на разработку и сопровождение систем

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

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

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

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

4. Возраст и структура программы. С возрастом структура программ нарушается вследствие частых изменений, поэтому их становится сложнее понимать и из­менять. Кроме того, многие наследуемые системы были созданы без использо­вания современных технологий. Они никогда не отличались хорошей качест­венной структурой; изменения, сделанные в них, были направлены скорее на повышение эффективности функционирования, чем на повышение удобства сопровождения. Документация на старые системы часто бывает неполной либо вообще отсутствует.

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

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

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

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

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

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

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

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

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

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

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

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.


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).

127.jpg

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

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

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

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

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

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

128.jpg

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

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

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

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

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

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

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

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


129.jpg

Рис. 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). Введение:

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

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

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

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 типа программ.

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

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

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

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

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

Заказчику

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

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

Вендору

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

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

Гост

ГОСТ

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

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

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

  1. Технология проектирования программных продуктов (к примеру, нисходящее проектирование, объектно-ориентированное и структурное проектирование и другое).
  2. Методики по тестированию программных продуктов.
  3. Методики, позволяющие доказать правильность программ.
  4. Анализ качественных показателей функционирования программ.
  5. Осуществление документирования программ.
  6. Осуществление разработки и применение программных средств, которые облегчают процесс проектирования программных продуктов.

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

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

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

Готовые работы на аналогичную тему

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

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

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

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

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

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

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

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

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

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


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

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

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

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

Определение сопровождения систем автоматизации программного обеспечения

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

В свою очередь, стандарт жизненного цикла 12207 (IEEE, ISO/IEC, ГОСТ Р ИСО/МЭК) позиционирует сопровождение как один из главных процессов жизненного цикла. Этот стандарт описывает сопровождение как процесс модификации программного продукта в части его кода и документации для решения возникающих проблем или реализации потребностей в улучшениях . Задача состоит в модификации продукта при условии сохранения его целостности. Международный стандарт ISO/IEC 14764 определяет сопровождение систем автоматизации программного обеспечения в тех же терминах, что и стандарт 12207, придавая особое значение работам по подготовке к деятельности по сопровождению до передачи системы в реальную эксплуатацию, например, вопросам планирования регламентов и операций по сопровождению.

Библиотека инфраструктуры информационных технологий ITIL

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

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

Использованный в библиотеке процессный подход полностью соответствует стандартам серии ISO 9000 (ГОСТ РИСО 9000). Процессный подход акцентирует внимание предприятия на достижении поставленных целей, анализе ключевых показателей эффективности (KPI), а также на ресурсах, затраченных на достижение этих целей.

Основные действия сопровождения систем автоматизации программного обеспечения

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

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

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

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

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

Процессы сопровождения описывают необходимые работы и детальные входы/выходы этих работ. Эти процессы рассматриваются в стандартах IEEE 1219 и ISO / IEC 14764.

Процесс сопровождения начинается по стандарту IEEE 1219 с момента передачи программной системы в эксплуатацию и касается таких вопросов, как планирование деятельности по сопровождению (см. рисунок 1).


Рисунок 1 - Работы в процессе сопровождения по стандарту IEEE 1219

Стандарт ISO/IEC 14764 уточняет положения, связанные с процессом сопровождения, стандарта жизненного цикла 12207. Работы по сопровождению, описанные в этом стандарте аналогичны работам в IEEE 1219, за исключением того, что сгруппированы несколько иначе (см. рисунок 2).


Рисунок 2 - Процесс сопровождения по стандарту ISO/IEC 14764

Работы по сопровождению в стандарте 14764 разбиты на задачи:

  • Process Implementation – реализация процесса;
  • Problem and Modification Analysis – анализ проблем и модификаций ;
  • Modification Implementation – проведение модификаций;
  • Maintenance Review/Acceptance – оценка и принятие при сопровождении;
  • Migration – миграция (на модифицированную или новую версию программного обеспечения);

Software Retirement – вывод из эксплуатации (прекращение эксплуатации программного обеспечения).

В представленных источниках можно найти описание истории эволюции соответствующих процессных моделей упоминаемых стандартов ISO/IEC и IEEE. Кроме того, существует и общая (обобщенная) модель процессов сопровождения. Agile-методологии, активно развивающиеся в последние годы, предлагают “облегченные” (light или lightweight) процессы, в том числе, и для организации деятельности по сопровождению, например, Extreme maintenance.

Соммервилл И. Инженерия программного обеспечения. Пер. с англ. — М.: Вильяме, 2002.

Уайт Б.А. Управление конфигурацией программных средств. Практическое руководство по Rational ClearCase. Пер. с англ. — М.: ДМК Пресс, 2002.

Основные термины (генерируются автоматически): IEEE, ISO, программное обеспечение, IEC, жизненный цикл, сопровождение систем автоматизации, Процесс сопровождения, сопровождение, стандарт, программный продукт.

Похожие статьи

Основные действия сопровождения систем автоматизации ТОиР

В свою очередь, стандарт жизненного цикла 12207 (IEEE, ISO/IEC, ГОСТ Р ИСО/МЭК) позиционирует сопровождение как один из главных процессов жизненного цикла.

Эффективность использования новых технических систем.

Сопровождение систем автоматизации ТОиР.

Модель управления и автоматизации этапов жизненного цикла автоматизированных систем диспетчерского управления на основе PLM-систем.

Модель взаимодействия команды сопровождения и команды.

Процесс сопровождения программных средств является одним основных этапов жизненного цикла программных средств. Согласно ГОСТ Р ИСО/МЭК 12207–2010 процесс сопровождения определяет работы персонала сопровождения, то есть организации.

Модель управления и автоматизации этапов жизненного цикла.

Жизненный цикл автоматизированных систем (ЖЦ АС) носит итерационный характер, в процессе его развития для минимизации

- участие в жизненном цикле различного как программно-аппаратного обеспечения, так и проектного и эксплуатирующего персонала.

Анализ существующего программного обеспечения для.

Сопровождение систем автоматизации программного обеспечения.

Характеристика существующего программного обеспечения системы банковских расчетов.

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

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

Информационно-компьютерное сопровождение.

Информационно-компьютерное сопровождение бизнес-процессов торговой компании.

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

Объектно-ориентированные расширения в программировании.

Сопровождение систем автоматизации ТОиР.

Модель управления и автоматизации этапов жизненного цикла автоматизированных систем диспетчерского управления на основе PLM-систем.

Метод обеспечения совместимости и интеграции АСУ.

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

Похожие статьи. Организация непрерывной интеграции в процессе разработки программного обеспечения.

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