ПО с большим и малым временем жизни

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

Жизненный цикл ПО (ЖЦ ПО) - ϶ᴛᴏ непрерывный и упорядоченный набор видов деятельности, осуществляемый и управляемый в рамках каждого проекта по разработке и эксплуатации ПО, начинающийся с момента появления идеи(замысла) создания некоторого программного обеспечения и принятия решения о крайне важности его создания и заканчивающийся в момент его полного изъятия из эксплуатации по причинам:

а) морального старения;

б) потери крайне важности решения соответствующих задач.

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

 

ПО с большим и малым временем жизни

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

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

Каскадная модель ЖЦ ПО

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

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

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

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

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

 

Раскрыть понятие концептуального моделирование структуры данных. Описать модель «сущность-связь» (ERD). Перечислить основные моменты при построении модели данных.

 

Концептуальная модель — это абстрактная модель, определяющая структуру моделируемой системы, свойства её элементов и причинно-следственные связи, присущие системе и существенные для достижения цели моделирования.

Обычно различают концептуальные модели двух видов:

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

Одной из наиболее популярных семантических моделей данных является модель «сущность-связь».

Для моделирования структуры данных используются ER-диаграммы (диаграммы «сущность-связь»), которые в наглядной форме представляют связи между сущностями.

Основными понятиями ER-диаграммы являются сущность, связь и атрибут.

Сущность

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

· иметь уникальный идентификатор;

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

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

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

В диаграммах ER-модели сущность представляется в виде прямоугольника, содержащего имя сущности (рис. 1).

Рисунок 1. Отображение сущности.

Связь

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

Связь представляется в виде линии, связывающей две сущности или идущей от сущности к ней же самой (рис. 2). Для каждой связи между сущностями указы­ваются правила, обеспечивающие ее поддержание.

Рисунок 2. Связь между двумя сущностями.

Типы связей

• Первый тип связи – «один к одному» (1:1 или 1 – 1). Эта связь означает, что одному экземпляру объекта А может соответствовать один и только один экземпляр связанного с ним объекта B.

• Второй тип связи – «один ко многим» (1:М или 1 – ∞). Это означает, что одному экземпляру объекта А соответствует несколько (много) экземпляров объекта B.

• Третий тип связи – «много к одному» (М:1 или ∞ – 1). Означает, что одному или нескольким экземплярам объекта А соответствует один экземпляр объекта B.

• Четвертый тип связи – «многие ко многим» (М:N или ∞ – ∞). Означает, что одному экземпляру объекта А соответствует несколько (много) экземпляров объекта B и наоборот, каждому экземпляру объекта B может соответствовать несколько экземпляров объекта А.

Атрибут

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

Рисунок 3. Атрибуты сущности.

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

 

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

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

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

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

 

класс – это группа или множество объектов с общими свойствами или свойством.

С точки зрения ООD можно дать следующее определение: класс – это множество объектов, связанных общностью структуры и поведения.

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

 

Объект не может быть классом, но класс может быть объектом. Класс, экземплярами которого являются классы называется метаклассом.

 

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

Интерфейсную часть класса можно разделить на три составляющие:

• Общедоступная – та часть, в которой даются определения, видимые для всех объектов пользователей

• Защищенная, где даются определения, видимые только для объектов, относящихся к подклассам данного класса

• Обособленная, в которой даются определения, скрытые для объектов всех других классов

 

Отношение между Классами

Существует 3 основных типа отношений между классами:

• Разновидность,определяющая степень общности,

• Составная часть,которая определяет агрегатирование объектов (т. е. показывает, что какой-то объект является частью другого объекта),

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

Объектно-ориентированные ЯП реализуют перечисленных выше отношения несколькими общими способами:

• Наследование

• Использование

• Представление

• Метаклассы

 

Агрегация это вложенность одного класса в другой, но при этом класс обертка не управляет сроком жизни вложенного объекта (который представлен ссылкой на искомый объект).

 

Зависимость (dependency)— это однонаправленное отношение использования между двумя классами. На одном конце отношения находится зависимый класс, на втором — независимый. Объект-клиент зависимого класса для своего корректного функционирования пользуется услугами объекта-сервера независимого класса.

 

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

 

Отношение между Классами

Существует 3 основных типа отношений между классами:

• Разновидность,определяющая степень общности,

• Составная часть,которая определяет агрегатирование объектов (т. е. показывает, что какой-то объект является частью другого объекта),

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

Объектно-ориентированные ЯП реализуют перечисленных выше отношения несколькими общими способами:

• Наследование

• Использование

• Представление

• Метаклассы

 

Ассоциация - это отношение, показывающее, что объекты одного типа неким образом связаны с объектами другого типа («клиент» может сделать «заказ»). Если между двумя классами определена ассоциация, то можно перемещаться от объектов одного класса к объектам другого.

 

Наследование классов (inheritance) – иерархическое отношение между классами типа «частное – общее»; «частные» классы наследуют состояние и поведение (поля и методы) «общих» классов, то есть «частный» класс обладает как собственным состоянием и поведением (полями и методами), так и «унаследованным» состоянием и поведением, определенным в «общем» классе.

 

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

 

Отношения между объектами

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

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

• Воздействие, т. е объект может воздействовать, никогда не подвергаясь воздействию со стороны других объектов, что соответствует понятию – активный объект

• Исполнение, в этом случае объект подвергается воздействию со стороны другого объекта, никогда не выступая в роли активного

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

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

• Объект-транслятор – пассивный объект с одним каналом управления

• Блокированный объект – пассивный объект с несколькими каналами управления

• Параллельный объект – активный объект с несколькими каналами управления

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

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

Состав типовой CASE-системы

— диаграммы,

— средства для конструирования пользовательского интерфейса,

— генераторы приложений,

— генераторы документации,

— система программирования,

— центральная база данных проекта – репозиторий

 

Основные CASE -средства:

— ERWIN (разработка ER-моделей),

— BPWIN (разработка диаграмм потоков данных),

— POWER DESIGNER,

— DESIGNER 2000,

— RATIONAL ROSE,

— PARADIGM+

 

Классификация по функциональной ориентации:

Анализ и проектирование.

—  CASE- аналитик (Эйтекс);

— Design/IDEF (Meta Software);

— BPWin (Logic Works);

Отношения

В UML используются четыре основных типа отношений:

- зависимость (dependency);

- ассоциация (association);

- обобщение (generalization);

- реализация (realization).

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

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

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

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

20. Раскрыть понятие унифицированный язык моделирования программных систем UML. Описать принципы построения диаграммы вариантов использования.

UML — это язык моделирования.

Модель UML — это, прежде всего, описание объекта или явления, а также и кое-что другое, а именно все, что авторам UML удалось включить в язык, не нарушая принципа унификации.

 

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

 

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

 

} Во-первых, UML не является языком программирования.

} Во-вторых, UML не является спецификацией инструмента.

} В-третьих, UML не является моделью процесса разработки приложений.

 

Диаграмма использования (use case diagram) — это наиболее общее представление функционального назначения системы.

 

Виды объектов

Actor – экземпляр участника процесса (актера)

Lifeline – объект общего назначения

Boundary – экран пользовательского интерфейса или устройство ввода-вывода

Entity – постоянный элемент. Как правило, соответствует таблице или элементу базы данных

Control – активный элемент, который управляет выполнением процесса

 

Сообщения

Сообщение (message) - спецификация обмена данными между объектами, при котором передается некая информация в расчете на то, что в ответ последует определенное действие.

Получение объектом экземпляра сообщения можно считать экземпляром события.

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

Асинхронное сообщение

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

 

Пример:

 

ДИАГРАММА КООПЕРАЦИИ.

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

Кооперация. (collaboration) - служит для обозначения множества взаимодействующих с определенной целью объектов в общем контексте моделируемой системы.

 

Основные компоненты

- объекты;

- связи;

- сообщения.

 

Объекты:

 

Связь

Экземпляр или пример произвольной ассоциации.

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

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

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

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

 

Сообщения

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

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

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

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

Сообщения специфицируют роли, которые играют объекты отправитель и получатель сообщения.

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

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

- сплошная линия с V-образной стрелкой обозначает простой поток управления. Каждая такая стрелка изображает один этап в последовательности потока управления. Обычно все такие сообщения являются асинхронными;

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

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

 

Пример:

 

Пример

 

Диаграмма компонентов

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

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

Визуализация общей структуры исходного кода программной системы.

Спецификация исполнимого варианта программной системы.

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

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

 

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

Имя экземпляра компонента записывается аналогично имени линии жизни на диаграммах взаимодействия в следующем формате (БНФ):

       < имя-экземпляра-компонента >::=[ <собственное-имя-компонента> ][ ‘:’<имя-типа> ],

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

Примеры изображения простого компонента и компонента с интерфейсами

 

Интерфейсы

Предоставляемый интерфейс (provided interface) – интерфейс, который компонент предлагает для своего окружения.

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

 

Порты

Порт определяет различимую точку взаимодействия между компонентом и окружающей его средой или между компонентом и его внутренними частями

Наличие имени у порта не является обязательным

При отсутствии имени порта его тип ассоциируется с типом интерфейса, с которым связан порт.

 

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

Пример диаграммы компонентов с собирающими соединителями для одинаковых интерфейсов

 

Менее важные принципы:

ü Обучение обучению;

ü небольшие начальные инвестиции;

ü игра для того, чтобы победить;

ü надежное экспериментирование;

ü открытая честная коммуникация;

ü работа в соответствии с человеческими инстинктами;

ü принимаемая ответственность;

ü локальная адаптация;

ü «путешествие налегке»;

ü откровенные оценки.

 

Базис ХР образуют перечисленные ниже двенадцать методов:

1. Игра планирования (Planninggame) — быстрое определение области действия следующей реализации путем объединения деловых приоритетов и технических оценок. Заказчик формирует область действия, приоритетность и сроки с точки зрения бизнеса, а разработчики оценивают и прослеживают продвижение (прогресс).

2. Частая смена версий (Smallreleases) — быстрый запуск в производство простой системы. Новые версии реализуются в очень коротком (двухнедельном) цикле.

3. Метафора (Metaphor) — вся разработка проводится на основе простой, общедоступной истории о том, как работает вся система.

4. Простое проектирование (Simpledesign) — проектирование выполняется настолько просто, насколько это возможно в данный момент.

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

6. Реорганизация (Refactoring) — система реструктурируется, но ее поведение не изменяется; цель — устранить дублирование, улучшить взаимодействие, упростить систему или добавить в нее гибкость.

7. Парное программирование (Pairprogramming) — весь код пишется двумя программистами, работающими на одном компьютере.

8. Коллективное владение кодом (Collectiveownership) — любой разработчик может улучшать любой код системы в любое время.

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

10. 40-часовая неделя (40-hour week) — как правило, работают не более 40 часов в неделю. Нельзя удваивать рабочую неделю за счет сверхурочных работ.

11. Локальный заказчик (On-sitecustomer) — в группе все время должен находиться представитель заказчика, действительно готовый отвечать на вопросы разработчиков.

12. Стандарты кодирования (Codingstandards) — должны выдерживаться правила, обеспечивающие одинаковое представление программного кода во всех частях программной системы.

Три ключевых фактора:

ü Простой дизайн без лишних элементов;

ü  Автоматические тесты;

ü  Постоянная практика в деле модификации дизайна системы.

Стандарты кодирования ПО

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

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

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

— соглашения по наименованию для компонентов, подпрограмм, переменных, констант;

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

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

Коллективное владение кодом

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

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

 

Непрерывная интеграция

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

Каждая пара разработчиков должна отдавать свой код, как только для этого появляется разумная возможность. Это может быть, когда все UnitTest-ы проходят на 100%. Отдавая изменения несколько раз в день, Вы сводите проблемы интеграции практически к нулю. Интеграция — это деятельность вида «заплати сейчас или заплати больше позднее». Поэтому, интегрируя изменения ежедневно маленькими порциями, вы не окажетесь перед необходимостью тратить неделю, чтобы связать систему в одно целое непосредственно перед сдачей проекта. Всегда работайте над последней версией системы.

 

31. Раскрыть понятие тестирование и испытание ПО. Перечислить классы ошибок, этапы тестирования ПО. Дать понятие к ачество и критерии качества программного средства.

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

 

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

 

Классы ошибок:

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

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

- ошибки ввода–вывода и манипулирования данными - являются следствием некачественной подготовки данных для выполнения программы, сбоев при занесении их в базах данных или при выборке из нее;

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

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

 

Процесс тестирования состоит из следующих этапов:

- Планирование тестирования

- Мониторинг и контроль тестирования

- Анализ тестирования

- Проектирование тестов

- Реализация тестов

- Выполнение тестов

- Завершение тестирования

 

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

 

Критерии качества ПО:

- Надежность

- Сопровождаемость

- Удобство использования

- Эффективность

- Универсальность

- Функциональность

 

32. Раскрыть понятие тестирование и испытание ПО. Описать методы тестирования (метод классов, стратегии «белого и черного ящика»).

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

 

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

 

Метод «Черного ящика»

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

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