Организация и методы сопровождения программных средств.

ФГБОУ ВО «САМАРСКИЙ ГОСУДАРСТВЕННЫЙ ЭКОНОМИЧЕСКИЙ УНИВЕРСИТЕТ»
Институт систем управления
Кафедра прикладной информатики и информационной безопасности






                                                
                                                
                                                
                                                                                     


КУРСОВОЙ    ПРОЕКТ


По теме   Организация и методы сопровождения программных средств
               Этапы и процедуры при сопровождении программных средств


По дисциплине      Программная Инженерия

Автор курсового проекта     Рожков И. О.
                                        
                                        
Институт/факультет      Систем Управления
Направление, профиль    Прикладная Информатика в Экономике
              
Оценка за курсовой проект:______________________________

Руководитель проекта:  д. п. н. Абросимов А.Г
                                  
                                  
                                  
                                  
                                  
                                  
                                  
                                  
                                  
                                  
                                  
                                  
                                  
                                  
                                  
2015 г.
ЗАДАНИЕ
на выполнение курсового проекта

студент Рожков И.О.

группа   напр/профиль Прикладная информатика в экономике

институт/факультет Систем управления


1.  Тема проекта:  «Организация и методы сопровождения программных средств. Этапы и процедуры при сопровождении программных средств» 

2. Срок сдачи законченного проекта: _______________________

4. Исходные данные для проекта: 
Стандарты (ГОСТ);
Стандарты SWEBOK;
Учебно-методический материал по предмету «Программная инженерия».
5. Структура разделов курсового проекта  в соответствии с заданием.
     Организация и методы сопровождения программных средств
     Методы сопровождения
     Этапы и процедуры при сопровождении программных средств
     Пример

5. Провести поверку курсового проекта  на антиплагиат.

Научный руководитель 
проекта                                                    д. пед. н. Абросимов А.Г.
    
    Задание принял 
     Дата, подпись студента________________________________
     
     

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


Оглавление

Введение	5
Организация и методы сопровождения программных средств	6
Методы сопровождения	8
Анализ влияния факторов	8
Обратное проектирование	8
Реинжиниринг	9
Рефакторинг	10
Унаследованные приложения	11
Обновление документации	12
Этапы и процедуры при сопровождении программных средств	13
Подготовка процесса	13
Анализ проблем и изменений	18
Внесение изменений	21
Проверка и приемка модификаций	22
Перенос	23
Снятие с эксплуатации	25
Пример	27
Заключение	30
Список сокращений	31
Библиографический список	32
Приложение	33

   

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

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


Методы сопровождения
Анализ влияния факторов
   Сопровождение, так же как и обычная разработка, состоит из анализа, проектирования и реализации задачи. Основная разница заключается в том, что при сопровождении любые изменения влияют на существующую систему в целом. При этом согласно исследованию Вейсса, 19 % дефектов в приложениях образуются на этапе определения требований, 52 % — на этапе проектирования и 7 % — в самом процессе программирования. Однако, существует мнение, что количество ошибок из-за некорректной формулировки ТЗ или требований должно быть значительно выше Влияние устранения дефекта на объекты иллюстрирует Приложение 1.
   Чтобы не допустить большого числа ошибок в системе нужно ограничивать количество изменяемых объектов. В качестве примера можно рассмотреть ситуацию, когда программистом не использовались стандарты разработки программного обеспечения. Во время сопровождения программист вводит изменение в наименование переменной, что может привести к значительным последствиям функционирования всего программного обеспечения в целом, если эта переменная окажется глобальной. Или же наоборот, когда программист поддерживал необходимый уровень абстракции, то внесенные изменения в переменную будут касаться только этого модуля. Изменение в хорошо задокументированных приложениях является не сложной работой, в обратной ситуации программисту придется разбираться непосредственно в коде приложения, что займет значительно больше времени. 

Обратное проектирование
   Сопровождение программного продукта может оказаться нетривиальной задачей. Во многом это зависит от того, как хорошо велась документация по данному ПС. Так как документация не влияет на функционал программы, то многие разработчики пренебрегают этим этапом. Так же заказчику очень сложно объяснить необходимость финансирования данных работ, поэтому многие проекты встречаются с довольно скудной документацией или же вовсе без таковой. Если план работ по проекту подразумевает значительные или многочисленные изменения функционала, то необходимым пунктом выполнения работ по сопровождению является создание подробной согласованной документации. Для этого часто требуется восстановление архитектуры по исходному коду — обратное проектирование (reverse engineering). На данный момент существует множество программных средств, позволяющих выполнить эту задачу автоматически. Наиболее распространенными являются пакеты Rational Rose (Rational Corporation) и Together (Object International).  На выходе пакета мы получаем диаграммы, которые можно использовать для анализа. Однако необходимо понимать, что полностью восстановить намерения разработчика по этим диаграммам довольно сложно, так как, когда разработчик самостоятельно составляет UML диаграммы, то определенный смысл носит не только содержимое блоков, но и их расположение и группировка, воспринимаемая только людьми. 
   Обратное проектирование заключается не только в восстановлении последовательности или логики программы посредством восстановления кода, необходимо так же анализировать комментарии оставленные разработчиком, если такие присутствуют, а так же связи различных модулей ПС и их входные и выходные параметры. 

Реинжиниринг
   В 1980 году в книге Business Process Reengineering Хаммер и Чампи предлагали иначе взглянуть на процесс производства ценностей для потребителей и, как итог, спроектировать бизнес-процесс  заново. Авторы книги предлагали разработчикам акцентировать внимание на процессе как на систему в целом, а не на отдельные части. Это связанно с тем, что и процесс и система в целом должны стремиться к одной цели. Например, если система решает задачу по предоставлению определенных услуг, то рассматриваемый процесс, начиная от входных данных по заказу и заканчивая, например, отгрузкой товаров, не должен противоречить целям системы, а наоборот включать в себя дополнительные процессы способствующих достижению этих целей, таких как поддержка программы и вклад сотрудников в общее дело. Реинжиниринг заставляет взглянуть на требования к программным приложениям как на часть требований к предприятию (компании, организации и т. п.) в целом. Данные программные продукты принято называть корпоративными приложениями (enterprise application). Реинжиниринг помогает понять то, как должно работать существующее программное средство в рамках бизнес-процесса организации, а не о том как оно работает на данный момент. Реинжиниринг применяет системный подход к разработке. 
   Очень часто реинжиниринг относят к сопровождению программного продукта, так как предполагается изменение существующего функционала приложения. Сравнение бессистемного подхода и с использованием реинжиниринга на примере изменения конструкции моста приводится в Приложении 2. В одном из случаев строятся новые укрепления моста, а в другом – мост перестраивается, чтобы отвечать новым требованиям. Отмечается, что в индустрии существуют различные позиции в отношении реинжиниринга – одни считают, что реинжиниринг является наиболее радикальной и затратной формой изменений программных систем, другие, что такой подход может применяться и для не столь кардинальных изменений (например, как смена платформы или архитектуры).

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

Унаследованные приложения
   Унаследованные системы (legacy systems) — это приложения, решающие существующие задачи. Иногда термин legacy трактуется как устаревшие и применяется к программам, которые не стоят того, чтобы их модифицировать.
Беннетт  перечисляет возможные действия с унаследованными системами.
* Продолжать сопровождение;
* Прекратить сопровождение и заменить на покупной продукт;
* Заменить на собственный продукт, полученный обратным проектированием или разработкой с нуля. Возможна поэтапная замена;
* Присоединить к новому приложению. Сопровождение заморозить;
* Инкапсулировать и использовать как сервер. 
   Присоединение и инкапсуляцию иллюстрирует Приложение 3. Под меткой i на этом рисунке показано, каким образом новое приложение получается из исходного путем расширения или модифицирования последнего.
   При инкапсуляции исходное приложение практически не изменяется. Новое приложение создается полностью независимо, а в процессе его выполнения вызывается функциональность унаследованного приложения. Это может осуществляться как напрямую (метка ed), так и через обертку (метка ew). Часть рисунка под меткой ed отвечает образцу проектирования, если унаследованное приложение является объектно-ориентированным. Обертка — это программное обеспечение, предоставляющее интерфейс для обращения клиентов к унаследованному приложению. В частности, обертка может сделать любое приложение внешне объектно-ориентированным. 

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


Этапы и процедуры при сопровождении программных средств
      	
   В соответствии с требованиями стандарта ISO 12207 по развитию и модификации программного продукта в жизненном цикле должен быть организован процесс его сопровождения. Работы,  обеспечивающие  сопровождение  ПС, включают:
* подготовку процесса;
* анализ проблем и изменений;
* внесение изменений;
* проверку и приемку при сопровождении;
* перенос;
* снятие с эксплуатации.    
     Эти разделы и соответствующие процессы, детализированы в стандарте ISO 14764, которые и будут рассмотрены подробнее в данной главе курсовой работы.  
Подготовка процесса
    Начальным этапом общего процесса сопровождения является формирование стратегического плана, а так же процедуры и функции в него включаемые. Желательно формировать план сопровождения единовременно с планом разработки альфа- и бета-версий ПС.  При формировании плана необходимо учитывать организационные моменты, а так же системы взаимодействия между специалистами предприятия и привлеченными внешними специалистами (аутсорсинг). Начальными данными для формирования подготовительного процесса могут служить исходная версия программного продукта, техническая и пользовательская документации, план развития и предложения по модификации программного продукта. 
    Для решения задач процесса сопровождения специалист должен разработать и задокументировать стратегический план и процедуры проведения работ. План должен включать в себя процедуры сопровождения, которые детально описывают выполнение этапов и процессов сопровождения. Процесс создания стратегического плана и его процедур включает в себя следующие базовые этапы:
* первоначальная оценка программного продукта; 
* создание договора о сопровождении между заинтересованными сторонами; 
* анализ доступных ресурсов для сопровождения;
* заключение финансового договора с заказчиком о проведении работ по сопровождению;
* установка требования к процессу передачи программного продукта сопроводителю;
* определение перечня процессов подлежащих сопровождению;
* оформление договора об этапах сопровождения, согласованных с заказчиком, который включает в себя план и процедуры сопровождения.
    В условиях ограниченности ресурсов сопровождение должно опираться на существующие людские и материальные мощности, способные обеспечить развитие и модификацию программного продукта. Стратегия сопровождения приложения в обязательном порядке должна включать следующие основные компоненты: концепция сопровождения; план сопровождения; анализ ресурсов. Процесс разработки также неотрывно связан от процесса сопровождения и должен включать в себя ряд работ связанных с его планированием. 
    Основной целью планирования сопровождения является подготовка к последующим этапом самого сопровождения, а так же обеспечение для этого необходимых ресурсов. Само планирование может быть начато только после принятия концепции работ по сопровождению ПС. Результатом данного процесса является создания плана, который будет принят в качестве основополагающего по сопровождению. Бесспорным является тот факт, что процесс сопровождения занимает гораздо больше времени, чем процесс разработки программного продукта, так как сопровождение требуется во время всего ЖЦ ПС. Анализ доступных ресурсов является необходимым этапом планирования. Все ресурсы  должны быть оценены и заложены в бюджет еще при разработке системы. Еще раз подчеркнем, что для обеспечения качества выполнения целей процесс планирования работ по сопровождению должен начинается единовременно с процессом разработки самой системы.  Общий план сопровождения  должен определять:
* обоснование необходимости сопровождения;
* состав исполнителей работ по сопровождению;
* регламент, где расписаны обязанности каждого, кто вовлечен в процесс сопровождения; 
* описание итогов по основным выполненным работам; 
* описание ресурсов, имеющихся и необходимых; 
* методология организации работ по ведению проектной деятельности по управлению и выпуску продукта;
* перечень  всех проектных результатов и продуктов, подлежащих поставке заказчику;
* перечень необходимых критериев, по которым будет выводиться оценка о завершенности работ; 
* графики и отчетные сметы проведения работ; 
* сроки и даты отчетных периодов; 
* перечень необходимых отчетов по обнаруженным проблемам и их устранениям; 
* периоды и общая длительность работ по сопровождению; 
      
     Разработанный план также должен определять, каким образом пользователи системы будут сообщать об обнаруженных ошибках, сбоях, и проблемах в ПС, а так же предложения по модификации функционала. 
   Стандарт ГОСТ Р ИСО/МЭК 14764—2002 предлагает следующий состав такого плана:
* Введение:
o описание сопровождаемой системы;
o определение исходных состояний программного средства;
o описание уровня требуемой поддержки;
o определение организаций, осуществляющих сопровождение;
o описание любых условий (протоколов), согласованных между заказчиком и поставщиками;
*  Концепция сопровождения:
o описание концепции;
o описание уровня поддержки системы;
o установление периода поддержки;
o адаптация (практическое применение) процесса сопровождения;
* Организационные работы и работы по сопровождению:
o роли и обязанности сопроводителя до поставки программного продукта:
* реализация процесса;
* определение инфраструктуры процесса;
* установление процесса обучения;
* установление процесса сопровождения;
o роли и обязанности сопроводителя после поставки программного продукта:
* реализация процесса;
* анализы проблем и модификаций (изменений);
* реализация (внесение) модификаций (изменений);
* рассмотрение и принятие модификаций (изменений);
* перенос программного средства в новую среду;
* снятие программного средства с эксплуатации;
* решение проблем (включая справочную службу);
* при необходимости — обучение персонала (сопроводителя и пользователя);
* усовершенствование процесса;
o роль пользователя:
* приемочные испытания;
* взаимосвязи (интерфейсы) с другими организациями;
* Ресурсы:
o персонал:
* состав персонала для конкретного проекта;
o программные средства:
* определение программных средств, необходимых для поддержки эксплуатации системы;
o технические средства:
* определение технических средств, необходимых для поддержки эксплуатации системы;
o оборудование (аппаратура):
* определение требований к оборудованию (аппаратуре) системы (помимо технических средств вычислительной техники);
o документы:
* план обеспечения качества;
* план управления проектом;
* план управления конфигурацией;
* документы разработки;
* руководства по сопровождению;
* план проведения верификации;
* план проведения аттестации;
* план тестирования, процедуры тестирования и отчеты о тестировании;
* план обучения;
* руководство (а) пользователя;
o данные;
o другие требования к ресурсам (при необходимости);
* Процесс (как должна быть выполнена конкретная деятельность):
o процесс, выполняемый сопроводителем (приводят общее описание процесса без детализации в плане сопровождения всего процесса);
o процесс адаптации (практического применения сопровождения к условиям проекта);
* Обучение:
o определение уровня обучения, необходимого для сопроводителя и пользователей;
* Протоколы и отчеты по сопровождению:
o перечень запросов пользователя на оказание услуг по сопровождению, предложение о модификациях или отчеты о проблемах;
o состояния запросов (предложений, отчетов) по категориям;
o приоритеты запросов (предложений, отчетов);
o контрольные данные, собранные при работах по сопровождению.
   
   Структура, отвечающая за сопровождение, должна проводить общую деятельность по бизнес-планированию, касающуюся бюджетирования, финансового менеджмента и управления человеческими ресурсами в области сопровождения.
       Во время процесса разработки и проектирования необходимо производить версионирование всех компонентов программного средства, а так же интерфейсов взаимодействия, баз данных и используемых внешних компонентов. За счет использования стандартов ISO 9126 можно эффективно улучшить сопровождаемость ПО. На этапе проектирования должны быть четко оговорены процедуры получения, документирования, а так же контроля, отчетов об ошибках системы и предложения по модификации функционала от пользователей. Обнаруженные в процессе разработки и использования ПО ошибки, дефекты, случаи сбоя и предложения модификации должны быть строго задокументированы и включены в процесс изменения системы. Для этого следует придерживаться следующих этапов: 
* производить классификацию и приоритезацию выявленных требований к системе по разработанным заранее схемам; 
* составление процедур проведения изменений в системе; 
* организация обратной связи с пользователями по вопросам их обращений к службе сопровождения; 
* регламентирование действий пользователя во время проведения работ по сопровождению; 
* определение процедур о внесении изменений в базу данных программного средства; 
* регламентирование сроков по устранению найденных уязвимостей, дефектов, ошибок в ПО.
Анализ проблем и изменений
    Анализ проблем и изменений в стандарте ISO 14764 рекомендуется реализовать в следующем порядке:
* анализируются предложения о модификации  и отчеты о дефектах;
* дублируется или проверяется реальность каждого дефекта;
* разрабатываются варианты реализации изменения;
* документально оформляются: предложения о модификации  и отчеты о дефектах, результаты их рассмотрения и варианты реализации изменений;
* проводится согласование выбранного варианта реализации изменения с заказчиком.
    Перед началом процесса корректировки системы исполнитель обязан произвести анализ возможных последствий на деятельность предприятия в целом, на взаимосвязанные объекты и системы, задокументировать возможные альтернативные решения, согласовать выбранное решение с заказчиком. 
    Для обеспечения реализации представленного предложения на изменение сопроводитель должен определить:
* наличие соответствующего персонала, способного реализовать предлагаемое изменение;
* наличие достаточного финансирования для реализации предлагаемого изменения в программе;
* наличие соответствующих ресурсов ЭВМ,  и степень влияния модификации на  реализуемую  или уже реализованные версии программного продукта;
* влияет ли отсутствие предполагаемых изменений на требования к системным интерфейсам, ожидаемый срок службы системы, приоритеты;
* влияние изменений на безопасность и защиту системы при эксплуатации;
* единовременные и долгосрочные затраты на корректировку;
* преимущества, получаемые после проведения модификации;
* влияние реализации изменений на графики проведения работ по версии программного продукта;
* необходимые процессы верификации, тестирования и оценки характеристик системы и программного продукта после внесения корректировки.   
    Помимо самого процесса устранения ошибки разработчику необходимо составить стратегию верификации и тестирования системы с целью проверки по факту устранения обнаруженной проблемы. Так же необходимо задокументировать процесс устранения и тестирования обнаруженной уязвимости. Если описанная ошибка является плавающей, то есть, нет возможности по повторению ее примера в системе, то разработчик должен проанализировать документацию модуля, в котором была обнаружена ошибка, постараться ее выявить и описать данный случай. На основе проведенного анализа сопроводитель должен разработать варианты реализации изменения:
* присвоить соответствующий приоритет проблеме   или предложению о модификации;
* установить наличие возможностей и  средств  для решения проблемы;
* оценить масштаб и трудоемкость данной модификации;
* разработать варианты реализации конкретного изменения;
* определить влияние данных вариантов на функциональную пригодность и технические средства системы;
* выполнить анализы риска для каждого варианта модификации.
* реализовать процесс управления конфигурацией для управления изменениями существующей системы или определить организационный интерфейс с данным процессом.
	Перед тем как внести необходимые изменения в ПС, исполнитель обязан предварительно согласовать выбранный вариант корректировки. Этому должны предшествовать разработанный план, процедуры сопровождения, процедуры устранения дефектов, регламенты организации обратной связи с пользователем, а так же регламенты передачи корректировок заказчику и пользователю. 
        После всех работ необходимо провести анализ рисков. Основанием для этого анализа могут являться предварительные оценки этих ресурсов. К данному анализу необходимо привлекать представителей пользователей и заказчика.  
Внесение изменений
    Исполнителю необходимо при внесении изменений разработать конкретные тесты к определенной версии программного продукта. Эти работы проводятся исходя из базовой версии программного средства, документа  о внесении корректировок, утвержденного заказчиком, отчеты по проделанной работе. Исполнитель должен понимать о том какие процессы будут затронуты и модифицированы при выполнении работ.  Необходимо внести изменения в документацию программного средства и описать добавленный функционал или изменения в логике работы ПО. Все проведенные работы должны быть оформлены в комплекты документов: 
* определены компоненты в существующей системе, подлежащие изменению;
* определены компоненты конкретного интерфейса, затрагиваемые данным изменением;
* определены документы, подлежащие обновлению;
* обновлен комплект документов базовой версии программного продукта; 
* установлены и документально оформлены критерии проведения квалификационного тестирования и испытаний, оценки их результатов в измененных и неизмененных объектах (программных модулях,  компонентах  и  элементах   конфигурации)   системы;
* обеспечены полнота и правильность реализации новых, и измененных требований, обеспечено, чтобы исходные, неизмененные требования и целостность системы  сохранились. 
        Все проведенные тесты корректировок должны быть задокументированы. После проведения корректировок, затрагивающие основной функционал системы, необходимо провести повторное планирование, документирование процедур сопровождения программного продукта. 
Проверка и приемка модификаций
    Подтверждение корректности внесенных изменений в функционал программы должен быть оговорен заранее и подчиняться единому стандарту и проходить по единой методологии. Проверка и прием работ по сопровождению должны опираться на текущую версию измененного программного продукта, результаты проведенных квалифицированных тестовых работ. Проверки необходимы для подтверждения корректности проведенных работ по требованиям, установленным заказчиком к данному программному продукту. Исполнитель обязан проверить каждое внесенное изменение в систему совместно с представителем заказчика для подтверждения работоспособности, как отдельного функционала, так и системы в целом:
* отслеживание реализованных предложений о модификации и отчетов о дефектах относительно требований предыдущей базовой версии проекта и программных кодов;
* проверку тестируемости текста (кодов) программы;
* проверку соблюдения стандартов на ЖЦ ПС и системы;
* проверку того, что изменены только нужные компоненты программного средства;
* проверку правильности сборки новых компонентов программного продукта;
* контроль обновления документов версии программного продукта;
* проверку полноты проведения тестирования и отчетов о тестировании.
       Исполнитель должен получить от заказчика подтверждающие документы о работоспособности системы, о принятии внесенных изменений, о планах по сопровождению и изменению функционала системы в дальнейшем. Результатами проведенных работ будут являться принятие новой базовой версии программного продукта, отчет о внесенных изменениях, отчет о проверке функционирования системы. 
Перенос
      Одним из ключевых пунктов процесса внедрения программного обеспечения является непосредственное внедрение нового ПС у заказчика. Однако следует помнить, что проведение подобных работ связаны с большим риском, поэтому не рекомендуется их проводить во время бухгалтерской отчетности, аудита и других ключевых моментах, связанных с производственными функциями предприятия. Если при внедрении ПС будет какая-то напряженная обстановка, то впоследствии и новая версия может показаться «неприятной». Это в дальнейшем может вызвать ненормальное взаимодействие заказчиков с разработчиками, к примеру, не будут вовремя отправляться отчеты об ошибке, или ваш продукт закритикуют.  Исполнитель должен понимать, что в успешном внедрении новой версии ПС немаловажную роль играет психологический аспект. Внедрение новой системы для пользователя является своего рода стрессовой ситуацией и для того чтобы избежать негативных оценок следует выбрать момент, когда влияние негативных внешних факторов на пользователя будет минимальным. Так же определенную трудность будет составлять необходимость перевода большого коллектива специалистов на новые методологии работы. Особенно ярко это выражается при внедрении новых версий ПС на стадии опытной эксплуатации. Когда количество ошибок по тем или иным причинам выше уровня текущей версии ПО. Дополнительную трудность может заключаться в переходе на абсолютно новый инструментарий. 
     Сопроводитель должен  документально оформить и представить заказчику:
* отчеты  о проблемах (дефектах)  и предложения о модификациях; и
* результаты их анализа и варианты реализации изменений; о
* результаты приемочных испытаний, верификации, аттестации и измерений характеристик качества новой версии программного продукта; у
* отчеты об обеспечении характеристик качества программного продукта и результаты их тестирования; ш
* результаты аудиторских проверок версии программного продукта;
* замечания заказчика и результаты взаимодействия с ним по устранению дефектов версии программного продукта; х
* комплект актуальных проектных документов и документов результатов сопровождения; ц
* оценки корректности реализованной политики, графика и Программы квалификационного тестирования версии программного продукта; о
* соотношение оценок необходимых и использованных  ресурсов; и
* официальные рекомендации с указаниями о целесообразных последующих модификациях и создании новых версий  ПС. и

   Для массового распространения программного продукта необходимо пройти через два этапа. На первом этапе выяв.......................