Две трети жизненного цикла программных систем
Сопровождение программного продукта — это поддержка работоспособности программного продукта, переход на его новые версии, внесение изменений, исправление обнаруженных ошибок и т.п.Сопровождение ПО представляет процесс, позволяющий уже существующим продуктам выполнять свои функции с продолжением продаж, установок и использования заказчиками, таким образом, принося прибыль организации-разработчику.
Сопровождение программного продукта — это поддержка работоспособности программного продукта, переход на его новые версии, внесение изменений, исправление обнаруженных ошибок и т.п.
Сопровождение ПО представляет процесс, позволяющий уже существующим продуктам выполнять свои функции с продолжением продаж, установок и использования заказчиками, таким образом, принося прибыль организации-разработчику.
В модели водопада сопровождение ПО выделяется в отдельную фазу цикла разработки. В спиральной модели, возникшей в ходе развития объектно-ориентированного программирования, сопровождение не выделяется как отдельный этап. Тем не менее, эта деятельность занимает значительное место, учитывая тот факт, что обычно около 2/3 жизненного цикла программных систем занимает сопровождение.
Термин сопровождение ПО определяется IEEE как "процесс модификации программной системы или ее компонентов, проводимый после поставки системы заказчику с целью устранения отказов, повышения производительности или улучшения других характеристик системы, или адаптации к изменившемуся программному окружению".
Ниже рассмотрим направления сопровождения программных продуктов на примере мультимедийных обучающих систем (МОС) компании ООО«Корпоративные системы»:
Корректирующее сопровождение - это исправление ошибок, выявленных при тестировании или эксплуатации. Пользователи ожидают от разработчиков оперативного исправления найденных в процессе работы "багов" и бывают очень недовольны, если их замечания теряются. Поэтому именно корректирующему сопровождению уделяется особое внимание.
Для того, чтобы разработчики оперативно устранили проблему, необходимо, чтобы и пользователи так же действововали оперативно, так как сопровождение - это двусторонний процесс.
К примеру, проводится обучение по МОС «Сталевар Дуговой электросталеплавильной печи» в Магнитогорском индустриальном колледже. Пользователи выявили ошибку: не все результаты тестирования в программе сохраняются. Если замечание зафиксировано в реестре замечаний, в нашем случае руководителем обучения по данной МОС, и о проблеме сразу сообщено разработчикам, то, как правило, в течение 5 рабочих дней замечание будет устранено.
Но бывают ситуации, когда пользователи выявили ошибку и трактуют ее по-своему, либо обозначают проблему абстрактно, разработчику сразу непонятно — что конкретно не работает. В ответ на такую формулировку проблемы - «программа не работает», разработчик едет на предприятие выяснить, в чем же все-таки дело. В результате оказывается, что пользователь запускал программу не следуя инструкции по запуску и, как следствие, — потерянное время. Такие факторы, как неграмотность пользователя, недостаточная подготовка пользователя к эксплуатации программного продукта, растягивают процесс сопровождения в 2-3 раза.
Улучшающее сопровождение - это добавление в продукт новых функций или защита системы от устаревания. Запросы на их включение обычно также исходят от пользователей.
Например, в МОС «Машинист дистрибутора», обучение по которой проводилось в Магнитогорском индустриальном колледже, по желанию пользователей требуется включить диаграмму состояния «железо-углерод», как справочной информации для пользователя. Разработчик оценивает целесообразность включения данной функции в МОС, только после этого задача ставится на реализацию. В данном случае — подключение такой функции, включая установку обновлений на предприятии, займет не более недели. Есть случаи, когда доработка требует значительных затрат.
Адаптивное сопровождение - поддержка соответствия ПО своему окружению: операционной системе, аппаратным средствам, основным компонентам, таким как СУБД, графическим интерфейсам пользователя и коммуникационным системам. Изменения в интерфейсе отдельных компонентов системы или структуры данных влекут за собой переделку части системы для возвращения ей работоспособного состояния. Но при этом функциональность не нуждается в расширении. Программа лишь должна выполнять старые функции в новых условиях или в новом окружении.
Например, одно предприятие, которое работает с МОС ООО «Корпоративные системы», использует в работе пакет офисных программ Microsoft Office, и требует, чтобы все отчеты по обучению формировались в формате *.doc. Изначально МОС была разработана под данное предприятие. Проходит время, число предприятий, которые хотят использовать МОС, растет, и среди них есть предприятия, на которых не используется пакет офисных программ Microsoft Office (под который «заточена» МОС). Для таких случаев разработчик добавляет дополнительную функцию в МОС — формирование отчетов в системе Fast Report.
Заметим, что внесение любых изменений в ПО, - это чаще всего правка исходного кода, которая влечет за собой весь комплекс работ по модернизации ПО - от анализа до тестирования и передачи пользователям. Для облегчения этого процесса создаются методики, позволяющие вносить изменения в программный код с меньшими трудозатратами, например, получивший широкое распространение объектно-ориентированный подход.
Однако, есть еще другая сторона сопровождения, также поглощающая немало человеко-дней. Здесь мы вспоминаем о сопровождении как о процессе. Независимо от того, к какому типу сопровождения принадлежит заявка (дефект программного обеспечения, требование на доработку и т.п.), она должна пройти по определенному маршруту между сотрудниками, меняя свой внутренний статус в зависимости от проведенных работ. Как этот процесс поставлен, сколько у него бюрократических инстанций, и каковы трудоемкость и стоимость прохождения каждого шага и поддержки процесса в целом - все это определяет общую стоимость сопровождения.
Процесс обработки заявки от пользователя представляет собой целый цикл работ по регистрации, отслеживанию, анализу запроса, принятию по нему решения, реализации, проверке и закрытию. Реализация заявки требует принятия ряда решений руководителями различных подразделений и обмена информацией между заинтересованными лицами о поставленных задачах и произведенных работах.
Одним из вариантов поддержки этого процесса будет его реализация при помощи внутренних регламентов организации, но при этом нельзя забывать, что для отслеживания их выполнения необходимо затрачивать дополнительные ресурсы. И все равно никто не гарантирует точного их соблюдения, ведь так велико искушение немного отступить от правил.
Рассмотрим обычный сценарий работы с запросом на изменение МОС. Например, пользователь сталкивается с проблемой, разрешить которую самостоятельно не в состоянии. Он звонит разработчикам и сообщает о ней. Проблема регистрируется, затем анализируется, и если есть возможность ее как-то обойти или решить "мирными" способами, т.е. без внесения изменений в исходный код, то такое решение и принимается. Если в обозримое время поиски обходных путей не дают результатов, то скорее всего придется дорабатывать программный продукт для устранения выявленной проблемы. Руководитель определяет трудоемкость работ, назначает ответственного и срок исполнения. После внесения изменений они тестируются, и новая версия отправляется пользователям. Проблема закрывается.
Организация такой или еще более сложной цепочки работ уже сама по себе непростая задача, требующая четкой регламентации последовательности действий.
Обычная картина для неформализованного процесса сопровождения - специалист по системе затрачивает значительную часть своего рабочего времени на общение с пользователями по телефону, разъяснение вопросов, касающихся эксплуатации ПО. При этом поступающая информация в лучшем случае фиксируется в Excel-файле и по мере внесения исправлений удаляется, а в худшем - вообще записывается на клочках бумаги, периодически куда-то пропадающих.
Налицо непродуктивная трата времени квалифицированного специалиста, вдобавок к этому возникают трудности с планированием работ по устранению замечаний. У руководителя нет полной информации по выявленным дефектам, нет сводной статистики по замечаниям, которые уже исправлены или еще нуждаются в рассмотрении.
Кто в подобных случаях расставляет приоритеты? Сам разработчик. Он принимает замечания и решает, что делать в первую очередь, а что отодвинуть на потом. Это должен быть чрезвычайно ответственный человек, который болеет за свое дело.
Пока нет вала замечаний, и у фирмы всего один-два клиента, работающих с МОС, с этим еще можно как-то мириться, но когда объемы возрастают, требуется кардинальное решение проблемы. Необходим инструмент, который позволит сделать сопровождение прозрачным, будет поддерживать необходимую организацию работ, запрещая отступать от правил и не требуя больших усилий на ведение процесса, и, конечно же, в нем должны храниться все полученные данные в одном месте для быстрого и беспрепятственного доступа команды сопровождения - от руководителя до программиста.
Таким образом, основа качественного сопровождения продукта: регулярность, оперативность, повышенное внимание к обслуживанию и поддержке программных продуктов. Сопровождение должно обеспечивать максимальную эффективность работы программного обеспечения. В отличие от проекта, который реализуется в определенные сроки, сопровождение является непрерывным процессом. Кроме того, сопровождение требует не только знания предметной области, но и опыта реализации.
Сопровождение ПО представляет процесс, позволяющий уже существующим продуктам выполнять свои функции с продолжением продаж, установок и использования заказчиками, таким образом, принося прибыль организации-разработчику.
В модели водопада сопровождение ПО выделяется в отдельную фазу цикла разработки. В спиральной модели, возникшей в ходе развития объектно-ориентированного программирования, сопровождение не выделяется как отдельный этап. Тем не менее, эта деятельность занимает значительное место, учитывая тот факт, что обычно около 2/3 жизненного цикла программных систем занимает сопровождение.
Термин сопровождение ПО определяется IEEE как "процесс модификации программной системы или ее компонентов, проводимый после поставки системы заказчику с целью устранения отказов, повышения производительности или улучшения других характеристик системы, или адаптации к изменившемуся программному окружению".
Ниже рассмотрим направления сопровождения программных продуктов на примере мультимедийных обучающих систем (МОС) компании ООО«Корпоративные системы»:
Корректирующее сопровождение - это исправление ошибок, выявленных при тестировании или эксплуатации. Пользователи ожидают от разработчиков оперативного исправления найденных в процессе работы "багов" и бывают очень недовольны, если их замечания теряются. Поэтому именно корректирующему сопровождению уделяется особое внимание.
Для того, чтобы разработчики оперативно устранили проблему, необходимо, чтобы и пользователи так же действововали оперативно, так как сопровождение - это двусторонний процесс.
К примеру, проводится обучение по МОС «Сталевар Дуговой электросталеплавильной печи» в Магнитогорском индустриальном колледже. Пользователи выявили ошибку: не все результаты тестирования в программе сохраняются. Если замечание зафиксировано в реестре замечаний, в нашем случае руководителем обучения по данной МОС, и о проблеме сразу сообщено разработчикам, то, как правило, в течение 5 рабочих дней замечание будет устранено.
Но бывают ситуации, когда пользователи выявили ошибку и трактуют ее по-своему, либо обозначают проблему абстрактно, разработчику сразу непонятно — что конкретно не работает. В ответ на такую формулировку проблемы - «программа не работает», разработчик едет на предприятие выяснить, в чем же все-таки дело. В результате оказывается, что пользователь запускал программу не следуя инструкции по запуску и, как следствие, — потерянное время. Такие факторы, как неграмотность пользователя, недостаточная подготовка пользователя к эксплуатации программного продукта, растягивают процесс сопровождения в 2-3 раза.
Улучшающее сопровождение - это добавление в продукт новых функций или защита системы от устаревания. Запросы на их включение обычно также исходят от пользователей.
Например, в МОС «Машинист дистрибутора», обучение по которой проводилось в Магнитогорском индустриальном колледже, по желанию пользователей требуется включить диаграмму состояния «железо-углерод», как справочной информации для пользователя. Разработчик оценивает целесообразность включения данной функции в МОС, только после этого задача ставится на реализацию. В данном случае — подключение такой функции, включая установку обновлений на предприятии, займет не более недели. Есть случаи, когда доработка требует значительных затрат.
Адаптивное сопровождение - поддержка соответствия ПО своему окружению: операционной системе, аппаратным средствам, основным компонентам, таким как СУБД, графическим интерфейсам пользователя и коммуникационным системам. Изменения в интерфейсе отдельных компонентов системы или структуры данных влекут за собой переделку части системы для возвращения ей работоспособного состояния. Но при этом функциональность не нуждается в расширении. Программа лишь должна выполнять старые функции в новых условиях или в новом окружении.
Например, одно предприятие, которое работает с МОС ООО «Корпоративные системы», использует в работе пакет офисных программ Microsoft Office, и требует, чтобы все отчеты по обучению формировались в формате *.doc. Изначально МОС была разработана под данное предприятие. Проходит время, число предприятий, которые хотят использовать МОС, растет, и среди них есть предприятия, на которых не используется пакет офисных программ Microsoft Office (под который «заточена» МОС). Для таких случаев разработчик добавляет дополнительную функцию в МОС — формирование отчетов в системе Fast Report.
Заметим, что внесение любых изменений в ПО, - это чаще всего правка исходного кода, которая влечет за собой весь комплекс работ по модернизации ПО - от анализа до тестирования и передачи пользователям. Для облегчения этого процесса создаются методики, позволяющие вносить изменения в программный код с меньшими трудозатратами, например, получивший широкое распространение объектно-ориентированный подход.
Однако, есть еще другая сторона сопровождения, также поглощающая немало человеко-дней. Здесь мы вспоминаем о сопровождении как о процессе. Независимо от того, к какому типу сопровождения принадлежит заявка (дефект программного обеспечения, требование на доработку и т.п.), она должна пройти по определенному маршруту между сотрудниками, меняя свой внутренний статус в зависимости от проведенных работ. Как этот процесс поставлен, сколько у него бюрократических инстанций, и каковы трудоемкость и стоимость прохождения каждого шага и поддержки процесса в целом - все это определяет общую стоимость сопровождения.
Процесс обработки заявки от пользователя представляет собой целый цикл работ по регистрации, отслеживанию, анализу запроса, принятию по нему решения, реализации, проверке и закрытию. Реализация заявки требует принятия ряда решений руководителями различных подразделений и обмена информацией между заинтересованными лицами о поставленных задачах и произведенных работах.
Одним из вариантов поддержки этого процесса будет его реализация при помощи внутренних регламентов организации, но при этом нельзя забывать, что для отслеживания их выполнения необходимо затрачивать дополнительные ресурсы. И все равно никто не гарантирует точного их соблюдения, ведь так велико искушение немного отступить от правил.
Рассмотрим обычный сценарий работы с запросом на изменение МОС. Например, пользователь сталкивается с проблемой, разрешить которую самостоятельно не в состоянии. Он звонит разработчикам и сообщает о ней. Проблема регистрируется, затем анализируется, и если есть возможность ее как-то обойти или решить "мирными" способами, т.е. без внесения изменений в исходный код, то такое решение и принимается. Если в обозримое время поиски обходных путей не дают результатов, то скорее всего придется дорабатывать программный продукт для устранения выявленной проблемы. Руководитель определяет трудоемкость работ, назначает ответственного и срок исполнения. После внесения изменений они тестируются, и новая версия отправляется пользователям. Проблема закрывается.
Организация такой или еще более сложной цепочки работ уже сама по себе непростая задача, требующая четкой регламентации последовательности действий.
Обычная картина для неформализованного процесса сопровождения - специалист по системе затрачивает значительную часть своего рабочего времени на общение с пользователями по телефону, разъяснение вопросов, касающихся эксплуатации ПО. При этом поступающая информация в лучшем случае фиксируется в Excel-файле и по мере внесения исправлений удаляется, а в худшем - вообще записывается на клочках бумаги, периодически куда-то пропадающих.
Налицо непродуктивная трата времени квалифицированного специалиста, вдобавок к этому возникают трудности с планированием работ по устранению замечаний. У руководителя нет полной информации по выявленным дефектам, нет сводной статистики по замечаниям, которые уже исправлены или еще нуждаются в рассмотрении.
Кто в подобных случаях расставляет приоритеты? Сам разработчик. Он принимает замечания и решает, что делать в первую очередь, а что отодвинуть на потом. Это должен быть чрезвычайно ответственный человек, который болеет за свое дело.
Пока нет вала замечаний, и у фирмы всего один-два клиента, работающих с МОС, с этим еще можно как-то мириться, но когда объемы возрастают, требуется кардинальное решение проблемы. Необходим инструмент, который позволит сделать сопровождение прозрачным, будет поддерживать необходимую организацию работ, запрещая отступать от правил и не требуя больших усилий на ведение процесса, и, конечно же, в нем должны храниться все полученные данные в одном месте для быстрого и беспрепятственного доступа команды сопровождения - от руководителя до программиста.
Таким образом, основа качественного сопровождения продукта: регулярность, оперативность, повышенное внимание к обслуживанию и поддержке программных продуктов. Сопровождение должно обеспечивать максимальную эффективность работы программного обеспечения. В отличие от проекта, который реализуется в определенные сроки, сопровождение является непрерывным процессом. Кроме того, сопровождение требует не только знания предметной области, но и опыта реализации.