Предусмотрение изменений это принцип который влияет на такие качества программного обеспечения как

Обновлено: 17.05.2024

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

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

Понятие качества программного обеспечения

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

В настоящий момент этот показатель регулируется международным стандартом ISO/IEC 25010:2011. Данный стандарт устанавливает многоуровневую систему оценки качества ПО, основанную на восьми базовых характеристиках.

Параметры качества ПО

Основные характеристики качества программного обеспечения согласно стандарту ISO/IEC 25010:2011:

1. Функциональность. ПО признается функциональным, если выполняет возложенные на него задачи, отвечает заданным потребностям пользователей. Данный аспект предполагает правильную и точную работу, совместимость всех входящих в состав компонентов.
2. Надежность. Под надежностью ПО понимают бесперебойное выполнение возлагаемых на него задач на заданных условиях в течение установленного времени.
3. Юзабилити (удобство использования). Этот параметр характеризует степень удобства ПО для пользователей, его наглядность, легкость эксплуатации и изучения.
4. Эффективность. Параметру соответствует степень обеспечения продуктом необходимой производительности при заданных условиях.
5. Удобство сопровождения. Этот показатель характеризует простоту анализа, тестирования, коррекции компонентов ПО, его обслуживания, а также степень адаптации к новым условиям.
6. Портативность. Степень легкости его переноса на другую платформу. Обеспечение качества ПО предполагает его проверку по каждому из перечисленных параметров, выявление слабых сторон и устранение неисправностей.
7. Совместимость. Способность программных компонентов взаимодействовать друг с другом.
8. Защищенность, т.е. минимизация угроз, связанных с несанкционированным чтением, изменением информации и т. д. Угрозы могут быть также связаны с некорректным использованием ПО, внешним воздействием со стороны посторонних лиц, выходом из строя технических средств.

Обеспечение качества и тестирование

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

В задачи QA-специалистов входит:

• формирование критериев качества;
• планирование мероприятий по соблюдению критериев на каждом этапе разработки продукта;
• выбор инструментов тестирования;
• тестирование продукта;
• расчет KPI;
• предотвращение появления ошибок и усовершенствование процесса.

Тестирование – проверка программного обеспечения на соответствие требованиям.

Таким образом, вы видите, что обеспечение качества – более широкое понятие, которое включает в себя работы по тестированию.

Тестирование может быть автоматизированным, а может проводиться вручную; может быть полного цикла или направленным на проверку отдельного аспекта качества (безопасность, производительность, удобства использования и т.д.).

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

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

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

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

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

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

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

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

3. Проблема надежности ПО.

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

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

Методы борьбы с ошибками ПО имеют еще одно важнейшее направление: конструирование ПО со свойствами устойчивости к ошибкам.

4. Проблемы изменяемости ПО.

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

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

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

В настоящее время по американской статистике из-за неправильной технологии разработки ПО, низкого уровня планирования и организации работ – хаотического процесса разработки 15% всех программных продуктов так и не достигли своего завершения. А для оставшихся 85% превышение первоначально заявленной стоимости и сроков создания в 2-3 раза является обычным явлением.

Таким образом, разработка ПО требует трех знаний: знаний в предметной области, знаний в области программирования, знаний в области технологии разработки ПО.

Качество ПО и технология его производства. Влияние человеческого фактора

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

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

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

Рис. 8.1 - Факторы, влияющие на качество ПО

Технология разработки ПО включает в себя методы управления программным проектом, которые включают в себя методы и принципы:

-контроля хода разработки,

-мотивации разработчиков ПО.

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

Человеческий фактор влияет на качество ПО двумя сторонами. Во первых людям свойственно ошибаться. Ошибки бывают двух видов:

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

Кроме деструктивного влияния человеческого фактора можно отметить и позитивные его стороны. Имеются три грани в квалификации разработчиков ПО:

Уровень знаний и опыт в предметной области,

Уровень знаний и опыт в области программирования.

Уровень знаний и опыт в технологии разработки ПО.

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

Стандартизация характеристик качества ПО. Управление качеством ПО

Качество ПО в соответствии с этим стандартом оценивается шестью базовыми характеристиками:

-мобильность или переносимость на другую аппаратную платформу или в другое программное окружение прежде всего ОС.

Данный набор базовых критериев качества не лишен недостатков. Например, в нем явно не хватает требования по безопасности ПО.

В итоге процесс управления качеством ПО состоит из 5 шагов:

1.Определение критериев качества ПО и их мер с учетом конкретного назначения ПО.

2.Определение потребного уровня значений, выбранных критериев качества.

3.Определение методической базы измерения критериев качества.

4.Обеспечение качества ПО как множества процедур и стандартов и их адаптация для конкретного случая разработки ПО.

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

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

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

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

Системный подход к разработке ПО. Временной и "пространственный " аспекты системного подхода. Каскадная модель жизненного цикла ПО

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

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

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

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

1) анализ системных требований и области применения;

2) проектирование архитектуры системы;

3) анализ требований к ПО(спецификации, внешние интерфейсы,);

4) проектирование архитектуры ПО;

5) детальное проектирование каждой единицы ПО;

6) кодирование ПО (программирование)

7) тестирование единиц ПО;

8) интеграция (объединение ПО) и тестирование совокупности единиц ПО;

9) квалификационные испытания ПО (комплексное тестирование);

10) интеграция системы единицы структуры ПО должны быть объединены с единицами аппаратных средств;

11) квалификационные испытания системы;

12) установка ПО.

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

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

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

Рассмотренная модель жизненного цикла (ЖЦ) относится к модели каскадного типа. Этот тип модели ЖЦ хорош для ПО, для которого в самом начале разработки возможно полно и точно сформулировать все требования к ПО.

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

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

Главная задача как можно быстрее достичь работоспособного ПО, активизируя тем самым процесс уточнения и дополнения требований. Это так называемая спиральная модель ЖЦ ПО.

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

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

-интерактивное взаимодействие индивидуумов важнее формальных процедур и инструментов,

- работающее ПО важнее наличия документации на него,

- сотрудничество с заказчиком важнее формальных договоров,

- быстрое реагирование на внешние изменения важнее строгого следования намеченным планам.

проектирование

реализация

АО

КО

анализ

завершение версии 1

Определение требований

завершение версии 2

Рис. 8.2 - Схема спирального ЖЦ ПО

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

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

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

1. интерактивное взаимодействие индивидуумов важнее формальных процедур и инструментов,

2. работающее ПО важнее наличия документации на него,

3. сотрудничество с заказчиком важнее формальных договоров с ним,

4. быстрое реагирование на внешние изменения важнее строгого следования намеченным планам.

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

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

В больших коллективах разработчиков проблема управления – выходит на передний план.

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

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

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

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

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

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

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

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

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

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

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

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

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

  Качество программного обеспечения (Software Quality) - это степень, в которой программное обеспечение обладает требуемой комбинацией свойств.

  Качество программного обеспечения (Software Quality) - это совокупность характеристик программного обеспечения, относящихся к его способности удовлетворять установленные и предполагаемые потребности.

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

  Контроль качества (Quality Control - QC) - это совокупность действий, проводимых над продуктом в процессе разработки для получения информации о его актуальном состоянии в разрезах: "готовность продукта к выпуску", "соответствие зафиксированным требованиям", "соответствие заявленному уровню качества продукта".

  Тестирование программного обеспечения (Software Testing) - это одна из техник контроля качества, включающая в себя активности по планированию работ (Test Management), проектированию тестов (Test Design), выполнению тестирования (Test Execution) и анализу полученных результатов (Test Analysis).

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

  Валидация (validation) - это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, требованиям к системе.

  План Тестирования (Test Plan) - это документ, который описывает весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.

  Тест дизайн (Test Design) - это этап процесса тестирования ПО, на котором проектируются и создаются тестовые случаи (тест-кейсы), в соответствии с определенными ранее критериями качества и целями тестирования.

  Тестовый случай (Test Case) - это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.

  Баг/Дефект Репорт (Bug Report) - это документ, описывающий ситуацию или последовательность действий, приведшую к некорректной работе объекта тестирования с указанием причин и ожидаемого результата.

  Тестовое Покрытие (Test Coverage) - это одна из метрик оценки качества тестирования, представляющая из себя плотность покрытия тестами требований либо исполняемого кода.

  Детализация Тест-Кейсов (Test Case Specification) - это уровень детализации описания тестовых шагов и требуемого результата, при котором обеспечивается разумное соотношение времени прохождения к тестовому покрытию.

  Время Прохождения Тест Кейса(Test Case Pass Time) - это время от начала прохождения шагов тест-кейса до получения результата теста.

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

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

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

  Характеристики качества ПО

  Функциональность (Functionality) - определяется способностью ПО решать задачи, которые соответствуют зафиксированным и предполагаемым потребностям пользователя, при заданных условиях использования ПО. Т.е. эта характеристика отвечает то, что ПО работает исправно и точно, функционально совместимо соответствует стандартам отрасли и защищено от несанкционированного доступа.

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

  Удобство использования (Usability) – возможность легкого понимания, изучения, использования и привлекательности ПО для пользователя.

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

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

  Портативность (Portability) – характеризует ПО с точки зрения легкости его переноса из одного окружения (software/ hardware) в другое.

  Модель качества программного обеспечения

  
  

  На данный момент, наиболее распространена и используется многоуровневая модель качества программного обеспечения, представленная в наборе стандартов ISO 9126. На верхнем уровне выделено 6 основных характеристик качества ПО, каждую из которых определяют набором атрибутов, имеющих соответствующие метрики для последующей оценки.Рис.1. Модель качества программного обеспечения (ISO 9126-1)

  Кто такой тестировщик и что он делает

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

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

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

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

  Также отметим личностные качества, позволяющие тестировщику быстрее стать отличным специалистом:

  1. Повышенная ответственность и исполнительность;
  2. хорошие коммуникативные навыки, способность ясно, быстро, чётко выражать свои мысли;
  3. терпение, усидчивость, внимательность к деталям, наблюдательность;
  4. хорошее абстрактное и аналитическое мышление;
  5. способность ставить нестандартные эксперименты, склонность к исследовательской деятельности.

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

  Откуда берутся ошибки в ПО?

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

  Ошибка (error) – это действие человека, которое порождает неправильный результат.

  Однако программы разрабатываются и создаются людьми, которые также могут допускать (и допускают) ошибки. Это значит, что недостатки есть и в самом программном обеспечении. Они называются дефектами или багами (оба обозначения равносильны). Здесь важно помнить, что программное обеспечение – нечто большее, чем просто код.

  Дефект, Баг (Defect, Bug) – недостаток компонента или системы, который может привести к отказу определенной функциональности. Дефект, обнаруженный во время исполнения программы, может вызвать отказ отдельного компонента или всей системы.

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

  Сбой (failure) – несоответствие фактического результата (actual result) работы компонента или системы ожидаемому результату (expected result).

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

  Таким образом, баг существует при одновременном выполнении трех условий:

  • известен ожидаемый результат;
  • известен фактический результат;
  • фактический результат отличается от ожидаемого результата.

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

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

  Всего существует несколько источников дефектов и, соответственно, сбоев:

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

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

  Качество (Quality) – степень, в которой совокупность присущих характеристик соответствует требованиям.

  Качество программного обеспечения (Software Quality) – это совокупность характеристик программного обеспечения, отражающих его способность удовлетворять установленные и предполагаемые потребности.

  Требование (Requirement) – потребность или ожидание, которое установлено. Обычно предполагается или является обязательным.

  
  

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

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

  Условно можно выделить пять причин появления дефектов в программном коде.

  1. Недостаток или отсутствие общения в команде. Зачастую бизнес-требования просто не доходят до команды разработки. У заказчика есть понимание того, каким он хочет видеть готовый продукт, но, если должным образом не объяснить его идею разработчикам и тестировщикам, результат может оказаться не таким, как предполагалось. Требования должны быть доступны и понятны всем участникам процесса разработки ПО.
  2. Сложность программного обеспечения. Современное ПО состоит из множества компонентов, которые объединяются в сложные программные системы. Многопоточные приложения, клиент-серверная и распределенная архитектура, многоуровневые базы данных – программы становятся все сложнее в написании и поддержке, и тем труднее становится работа программистов. А чем труднее работа, тем больше ошибок может допустить исполняющий ее человек.
  3. Изменения требований. Даже незначительные изменения требований на поздних этапах разработки требуют большого объема работ по внесению изменений в систему. Меняется дизайн и архитектура приложения, что, в свою очередь, требует внесения изменений в исходный код и принципы взаимодействия программных модулей. Такие текущие изменения зачастую становятся источником трудноуловимых дефектов. Тем не менее, часто меняющиеся требования в современном бизнесе – скорее правило, чем исключение, поэтому непрерывное тестирование и контроль рисков в таких условиях – прямая обязанность специалистов отдела обеспечения качества.
  4. Плохо документированный код. Сложно поддерживать и изменять плохо написанный и слабо документированный программный код. Во многих компаниях существуют специальные правила по написанию и документированию кода программистами. Хотя на практике часто бывает так, что разработчики вынуждены писать программы в первую очередь быстро, а это сказывается на качестве продукта.
  5. Средства разработки ПО. Средства визуализации, библиотеки, компиляторы, генераторы скриптов и другие вспомогательные инструменты разработки – это тоже зачастую плохо работающие и слабо документированные программы, которые могут стать источником дефектов в готовом продукте.

  Принципы тестирования

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

  1. Тестирование показывает наличие дефектов

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

  2. Исчерпывающее тестирование невозможно

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

  3. Раннее тестирование

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

  4. Скопление дефектов

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

  5. Парадокс пестицида

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

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

  6. Тестирование зависит от контекста

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

  7. Заблуждение об отсутствии ошибок.

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

  И еще несколько важных принципов:

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

  Верификация и валидация

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

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

  Валидация (validation)– это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, требованиям к системе.

  Следующая таблица поможет выделить ключевые отличия между этими понятиями:

  
  

  На практике отличия верификации и валидации имеют большое значение:

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

  QA, QC и тестирование

  Так в чем же разница между QA и тестированием и что такое Quality Control?

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

  Можно оформить их соотношение в виде таблицы:

  
  

  Таким образом, мы можем построить модель иерархии процессов обеспечения качества: Тестирование – часть QC. QC – часть QA.

  
  

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

  Если провести аналогию с процессом конструирования, скажем, велосипеда, то получим такую картину:

  Узбекское Агентство
  Связи и Информатизации

  Ташкентский Университет Информационных Технологий

  Преподаватель дисциплины

  
  

  Выдержки из лекций

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

  Допустим, что кто-то разработал программное обеспечение системы в срок, не превысив при этом предусмотренных затрат. Пусть оно точно и эффективно выполняет все функции, пере­численные в документации. Значит ли это, что оно качественное? По целому ряду характеристик ответ на этот вопрос может быть отрицательным. Например:

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

  - программное обеспечение может оказаться трудным для правильного использования и легким — для неправильного;

  - может оказаться, что программное обеспечение в зна­чительной мере привязано к конкретной ЭВМ или плохо сты­куется с ранее разработанными программами.

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

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

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

  В связи с большим разнообразием пользователей невозможно предложить какую-то единую универсальную меру качества программного обеспечения.

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

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

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

  Основную проблему оценки качества программных продуктов пред ­ став ­ ляет тот факт, что многие его частные качественные характеристики противоречивы.

  - увеличение эффективности нередко становится возмож­ным лишь за счет ухудшения мобильности, точности, понятности и удобства эксплуатации;

  - повышение точности часто отрицательно сказывается на мобильности вследствие зависимости обеих характеристик от длины машинного слова;

  - достижение высокой степени осмысленности может всту­пать в конфликт с ограничениями на открытость.

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

  Повышение жизнеспособности программного обеспечения можно осуществлять следующими четырьмя способами:

  - установлением в явном виде целевых параметров качества и их относительных приоритетов;

  - применением контрольных таблиц и вопросников по ана­лизу качества;

  - введением специальных мер, гарантирующих высокое качество программ;

  - использованием специальных средств и методов повы­шения качества.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  Это свойство имеет две стороны:

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

  Например, если рассматривается информационно-справочная система, важно выяснить, может ли она использоваться не только для тех целей, которые ставились первоначально при ее создании.

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

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

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

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

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

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

  1) Способен ли программный продукт удовлетворить выд­винутым требованиям к нему? Если программный продукт — программа, то достигается ли необходимая точность процедур трансляции, загрузки и выполнения?

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

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

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

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

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

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

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

  В качестве отрицательного примера можно привести два оператора

  SUM: = TIIN/100; SUM: = SUM + TIIN/100;

  В результате их действий при некоторых значениях переменных ( TIIN = 20 и TIIN = 81) происходит нежелательная потеря целого сума (в результате получается SUM = 0).

  Для обеспечения требуемой точности это вычисление можно выполнить оператором

  SUM : = ( TIIN 1+ TIIN 2)/100;

  Доступность. Программный продукт обладает свойством дос­тупности, если он допускает селективное использование от­дельных его компонент.

  Отрицательным примером может служить запись

  GRVITY : = 1.40764548Е16/ R **2;

  Здесь GRVITY - переменная, обозначающая гравитационную постоянную.

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

  Для обеспечения широкой доступности программы целе­сообразна следующая форма выражения:

  GRVITY = GCONST / R **2;

  где переменной GCONST по умолчанию при запуске прог­раммы присваивается значение 1.4076548* 1016, но пользователь может задавать и/или изменить это значение на новое.

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

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

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

  Отрицательным примером может служить выдаваемое прог­раммой число или набор чисел без комментариев.

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

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

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

  
  
  
  
  
  
  

  Материал сайта является электронным пособием
  по дисциплине "Технология Программирования"
  в помощь студентам ТУИТ.
  

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

    
  • Нужна ли транзитная виза при пересадке в амстердаме для граждан россии
    
  • Что по утрам угрожает растениям ранней весной
    
  • Что будет если спать меньше чем положено
    
  • Сколько времени состоит на учете лицо допускающее правонарушения в семейно бытовых отношениях
    
  • Зима как неприступная холодная красавица выдерживает свой характер вплоть до узаконенной поры тепла