Тема 1. 3 сопровождение программного обеспечения. Эволюция программных систем. Автоматизированные средства разработки по.

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

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

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

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

— исправление ошибок — корректировка программ, выдаюіцих неправильные результаты в условиях, ограниченных техническим заданием и документацией. Исправление ошибок требуют около 20% общих затрат на сопровождение.

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

— модернизация — расширение функциональных возможностей или улучшение характеристик решения отдельных задач в соответствии с новым или дополнительным техническим заданием на программное изделие. Модернизация занимает до 60% общих затрат на сопровождение.

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

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

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

Сопровождение программ - это «ложка дегтя» для каждого программиста, всегда помеха при начале разработки какого-либо нового проекта, заставляющая отвлекаться от его разработки и возвращаться к старым программам и старым проблемам.

Что делает сопровождение программного обеспечения крайне непривлекательным? Это плохо документированный код, недостаточно полное начальное проектирование и отсутствие внешней документации.

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

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

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

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

Тема 1.4 Анализ предметной области. Определение и разработка требований к программным продуктам. Определение спецификаций требований программного обеспечения.

 

 

 

 

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

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

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

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

Состав спецификации требований

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

Введение

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

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

Общее описание

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

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

Пользователи. Приводят перечисление классов предполагаемых пользователей и их характеристики.

Окружение. Описывают рабочую среду программной системы: аппаратные средства, операционные системы. Здесь же перечисляют другие программные компоненты, с которыми система должна быть совместима.

Ограничения реализации. Перечисляют все факторы, ограничивающие возможности разработчика, например:

· технологии, языки программирования, базы данных, стандарты разработки, которые следует (или не следует) использовать;

· ограничения операционной среды, аппаратуры;

· ограничения, связанные с продуктами, разработанными ранее;

· соглашения, связанные с пользовательским интерфейсом, форматом обмена данными и т.д.

Функции системы

Для каждой функции системы должно быть указано:

· название и приоритет;

· системные входные и выходные данные, или последовательности «воздействие – реакция»;

· детальные функциональные требования;

· реакция на ошибки ввода данных или неверные действия пользователя.

Внешний интерфейс

Раздел должен содержать описание логических характеристик каждого пользовательского интерфейса, например:

· ссылки на стандарты графического интерфейса, шрифтов, элементов управления и т.п.;

· конфигурация экрана, стандартные кнопки и функции навигации;

· стандарты отображения сообщений и т.д.

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

Нефункциональные требования

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

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

 

Тема 1.5 Качество ПО и методы его контроля. Понятие качества. Характеристики качества программных средств.

Качество программного обеспечения (ПО)

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

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

− функциональность; 

− надежность;

− легкость применения;

− эффективность;

− сопровождаемость;  

− мобильность.

Функциональность − это способность ПС выполнять набор функций, удовлетворяющих заданным или подразумеваемым потребностям пользователей. Набор указанных функций определяется во внешнем описании ПС.

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

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

Легкость применения − это характеристики ПС, которые позволяют минимизировать усилия пользователя по подготовке исходных данных, применению ПС и оценке полученных результатов, а также вызывать положительные эмоции определенного или подразумеваемого пользователя.

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

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

Мобильность − это способность ПС быть перенесенным из одной среды (окружения) в другую, в частности, с одной ЭВМ на другую.

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

Функциональность: завершенность.

Надежность: завершенность, точность, автономность, устойчивость, защищенность.

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

Эффективность: временнáя эффективность, эффективность по ресурсам (по памяти), эффективность по устройствам.

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

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

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

Изучаемость: С-документированность, информативность (здесь применительно к документации по сопровождению), понятность, структурированность, удобочитаемость.

Модифицируемость: расширяемость, модифицируемость (в узком смысле, как примитив качества), структурированность, модульность.

Мобильность: независимость от устройств, автономность, структурированность, модульность.

Ниже даются определения используемых примитивов качества ПС. 

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

Точность (accuracy) − мера, характеризующая приемлемость величины погрешности в выдаваемых программами ПС результатах с точки зрения предполагаемого их использования.

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

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

Защищенность (defensiveness) − свойство, характеризующее способность ПС противостоять преднамеренным или нечаянным деструктивным (разрушающим) действиям пользователя.

П-документированность (u. documentation) − свойство, характеризующее наличие, полноту, понятность, доступность и наглядность учебной, инструктивной и справочной документации, необходимой для применения ПС.

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

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

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

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

Эффективность по устройствам (device efficiency) − мера, характеризующая экономичность использования устройств машины для решения поставленной задачи.

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

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

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

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

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

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

Модульность (modularity) − свойство, характеризующее ПС с точки зрения организации его программ из таких дискретных компонент, что изменение одной из них оказывает минимальное воздействие на другие компоненты.

Независимость от устройств (device independence) − свойство, характеризующее способность ПС работать на разнообразном аппаратном обеспечении (различных типах, марках, моделях ЭВМ).