Программные средства являются одним из наиболее гибких видов промышленных изделий и эпизодически подвергаются изменениям в течение всего времени их использования.
Иногда достаточно при корректировке программного обеспечения внести только одну ошибку для того, чтобы резко снизилась его надежность или его корректность при некоторых исходных данных.
Для сохранения и повышения качества программного обеспечения необходимо регламентировать процесс модификации и поддерживать его соответствующим тестированием и контролем качества. В результате программное изделие со временем обычно улучшается как по функциональным возможностям, так и по качеству решения отдельных задач.
Работы, обеспечивающие контроль и повышение качества, а также развитие функциональных возможностей программ, составляют процесс сопровождения.В процессе сопровождения в программное обеспечение вносятся следующие изменения, значительно различающиеся причинами и характеристиками:
— исправление ошибок — корректировка программ, выдаюіцих неправильные результаты в условиях, ограниченных техническим заданием и документацией. Исправление ошибок требуют около 20% общих затрат на сопровождение.
— регламентированная документами адаптация программного обеспечения к условиям конкретного использования, с учетом характеристик внешней среды или конфигурации аппаратуры, на которой предстоит функционировать программам. Адаптация занимает около 20% общих затрат на сопровождение.
— модернизация — расширение функциональных возможностей или улучшение характеристик решения отдельных задач в соответствии с новым или дополнительным техническим заданием на программное изделие. Модернизация занимает до 60% общих затрат на сопровождение.
Первый вид изменений (исправление ошибок) является непредсказуемым и его трудно регламентировать.Остальные виды корректировок носят упорядоченный характер и проводятся в соответствии с заранее подготавливаемыми планами и документами. Эти корректировки в наибольшей степени изменяют программные изделия и требуют наибольших затрат.
Поэтому изменения, обусловленные ошибками, в большинстве случаев целесообразно по возможности накапливать и реализовывать их, приурочивая к изменениям, регламентированным модернизациями.
Однако некоторые ошибки вызывают необходимость срочного исправления программ. В этих случаях допустимо некоторое отставание корректировки документации при более срочном и регистрируемом исправлении самих программ.
Сопровождение программ - это «ложка дегтя» для каждого программиста, всегда помеха при начале разработки какого-либонового проекта, заставляющая отвлекаться от его разработки и возвращаться к старым программам и старым проблемам.
Что делает сопровождение программного обеспечения крайне непривлекательным? Это плохо документированный код, недостаточно полное начальное проектирование и отсутствие внешней документации.
Если все этапы жизненного цикла разработки программного обеспечения выполнялись правильно, то сопровождение не будет вызывать серьезных проблем, а будет элементарной технической поддержкой и модификацией внедренного программного продукта.
Со временем, иногда через десятки лет, сопровождение программного обеспечения прекращается. Это может быть обусловлено: разработкой более совершенных программных средств; прекращением использования сопровождаемого программного продукта; нерентабельным возрастанием затрат на его сопровождение.
Отметим, однако, что программное изделие может долго применяться кем-либо и после прекращения его сопровождения от лица разработчика, потому, что этот некто может плодотворно использовать программное изделие у себя самостоятельно, без помощи разработчика.
Для того чтобы со временем прийти к обоснованному решению о прекращении сопровождения программного обеспечения, необходимо периодически оценивать эффективность его эксплуатации, возможный ущерб от отмены сопровождения. В некоторых случаях решение о прекращении сопровождения принимается при противодействии со стороны отдельных пользователей.
Тема 1.4 Анализ предметной области. Определение и разработка требований к программным продуктам. Определение спецификаций требований программного обеспечения.
На этапе анализа разрабатываются пользовательские и системные требования к программной системе, которые должны быть оформлены в виде единого документа – спецификации требований.
Спецификация требований – это собой итоговый набор расположенных по приоритетам требований, который является формальным соглашением заказчика с разработчиком системы.
Спецификация требований – основной документ, описывающий разрабатываемую систему, и она необходима различным группам заинтересованных лиц. Это клиенты и специалисты по продажам, менеджеры проекта, разработчики, пользователи и т.д.
Учитывая важность спецификации и различные группы ее читателей, к ней предъявляются противоположные требования. С одной стороны, она должна быть простой, ясной и понятной пользователю неспециалисту, а с другой, для разработчика, – точной, подробной и формальной. Для учета этих требований спецификация, обычно, состоит из двух частей, первая из которых описывает пользовательские требования, а вторая – системные требования.
Состав спецификации требований
Существует достаточно большое число шаблонов (схем) спецификации требований, отличающихся структурой или способом упорядочения требований. Но каждый из шаблонов требует включения в спецификацию следующей информации.
Введение
Этот раздел должен содержать обзор спецификации, позволяющий читателю разобраться в структуре и принципах ее построения. Здесь определяется специфицируемая далее система или подсистема, указывается ее редакция и версия; перечисляются стандарты, используемые при написании спецификации, а также все документы, на которые есть ссылки в спецификации.
Часто во введении приводят краткое описание концепции системы, перечисляют различные группы пользователей спецификации и приводится рекомендуемая последовательность чтения разделов для них.
Общее описание
В этом разделе должен быть представлен общий обзор продукта и той среды, в которой он будет применяться, предполагаемые пользователи, известные ограничения и зависимости. Обычно общее описание содержит следующую информацию.
Продукт. Здесь указывают особенности продукта или его основные функции, приводят основные группы требований и их взаимосвязь, используя, например, диаграмму потоков данных высокого уровня, диаграмму варианта использования и т.п.
Пользователи. Приводят перечисление классов предполагаемых пользователей и их характеристики.
Окружение. Описывают рабочую среду программной системы: аппаратные средства, операционные системы. Здесь же перечисляют другие программные компоненты, с которыми система должна быть совместима.
Ограничения реализации. Перечисляют все факторы, ограничивающие возможности разработчика, например:
· технологии, языки программирования, базы данных, стандарты разработки, которые следует (или не следует) использовать;
· ограничения операционной среды, аппаратуры;
· ограничения, связанные с продуктами, разработанными ранее;
· соглашения, связанные с пользовательским интерфейсом, форматом обмена данными и т.д.
Функции системы
Для каждой функции системы должно быть указано:
· название и приоритет;
· системные входные и выходные данные, или последовательности «воздействие – реакция»;
· детальные функциональные требования;
· реакция на ошибки ввода данных или неверные действия пользователя.
Внешний интерфейс
Раздел должен содержать описание логических характеристик каждого пользовательского интерфейса, например:
· ссылки на стандарты графического интерфейса, шрифтов, элементов управления и т.п.;
· конфигурация экрана, стандартные кнопки и функции навигации;
· стандарты отображения сообщений и т.д.
Здесь же описывают характеристики интерфейсов программных и аппаратных компонентов системы, протоколы их взаимодействия. Кроме этого – интерфейсы между системой и другими программными компонентами и интерфейсы передачи информации.
Нефункциональные требования
В этом разделе описывают остальные нефункциональные требования (не относящиеся к уже описанным требованиям к интерфейсу). Это могут быть требования к производительности, атрибуты качества продукта, требования к безопасности, охране труда и т.д.
Кроме перечисленной информации, в спецификацию требований часто включают словарь терминов, которые пользователю необходимо знать для понимания спецификации, список нерешенных проблем, связанных с требованиями и т.д.
