Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
1)Технологией программирования называют совокупность методов и средств, используемых в процессе разработки программного обеспечения. Как любая другая технология, технология программирования представляет собой набор технологических инструкций, включающих:
Кроме набора операций и их последовательности, технология также определяет способ описания проектируемой системы, точнее модели, используемой на конкретном этапе разработки.
Различают технологии, используемые на конкретных этапах разработки или для решения отдельных задач этих этапов, и технологии, охватывающие несколько этапов или весь процесс разработки. В основе первых, как правило, лежит ограниченно применимый метод, позволяющий решить конкретную задачу. В основе вторых обычно лежит базовый метод или подход (парадигма), определяющий совокупность методов, используемых на разных этапах разработки, или методологию.
2) программного обеспечения состоит в том, что оно производится в одной форме — в виде исходного текста, а распространяется и используется часто в другой — в виде исполнимых программ, машинных кодов, по которым невозможно однозначно восстановить исходный текст. Чтобы эффективно изменять программу, исправлять ошибки или даже просто точно установить, что и как делает программа, необходимо располагать её исходным текстом, поскольку при компиляции в машинный код программа утрачивает удобочитаемость.
Программа — данные, предназначенные для управления конкретными компонентами системы обработки информации в целях реализации определённого алгоритма.
Программа — представленная в объективной форме совокупность данных и команд, предназначенных для функционирования ЭВМ и других компьютерных устройств с целью получения определённого результата, включая подготовительные материалы, полученные в ходе разработки программы для ЭВМ, и порождаемые ею аудиовизуальные отображения.
Задача — проблемная ситуация с явно заданной целью, которую необходимо достичь; в более узком смысле задачей также называют саму эту цель, данную в рамках проблемной ситуации, то есть то, что требуется сделать.
Алгори́тм — набор инструкций, описывающих порядок действий исполнителя для достижения результата решения задачи за конечное число действий. В старой трактовке вместо слова «порядок» использовалось слово «последовательность», но по мере развития параллельности в работе компьютеров слово «последовательность» стали заменять более общим словом «порядок.
Утилита (англ. utility или tool) — вспомогательная компьютерная программа в составе общего программного обеспечения для выполнения специализированных типовых задач, связанных с работой оборудования и операционной системы (ОС)[1].
Утилиты предоставляют доступ к возможностям (параметрам, настройкам, установкам), недоступным без их применения, либо делают процесс изменения некоторых параметров проще (автоматизируют его).
Утилиты могут входить в состав операционных систем, идти в комплекте со специализированным оборудованием или распространяться отдельно.
Спецификация —может означать определение и перечень специфических особенностей, уточнённая классификация чего-нибудь.
3)
4) Основная категория специалистов, занятых разработкой программ — это программисты.
Системный программист (system /software programmer, toolsmith) занимается разработкой, эксплуатацией и сопровождением системногопрограммного обеспечения, поддерживающего работоспособность компьютера и создающего среду для выполнения программ, обеспечивающих реализацию функциональных задач.
Прикладной программист (application programmer)осуществляет разработку и отладку программ для решения функциональных задач.
Программист-аналитик (programmer-analyst)анализирует и проектирует комплекс взаимосвязанных программ для реализации функций предметной области.
Постановщики задач участвуют в процессе создания программ на начальной стадии работ
Администратор базы данных организует поддержку базы данных, если база данных является интегрированной, обеспечивающая работу с данными многих приложений.
Конечный пользователь (end user) является основным потребителем программ, относится к категории пользователей-непрограммистов.
5) Под программным обеспечением понимается совокупность программ, выполняемых вычислительной системой. К программному обеспечению относится также вся область деятельности по проектированию и разработке ПО: технология проектирования программ; методы тестирования программ; методы доказательства правильности программ; анализ качества работы программ; документирование программ; разработка и использование программных средств, облегчающих процесс проектирования программного обеспечения, и многое другое.
6) Основные характеристики программ:
– алгоритмическая сложность (логика алгоритмов обработки информации);
– состав и глубина проработки реализованных функций обработки;
– полнота и системность функций обработки;
– объем файлов программ;
– требования к операционной системе и техническим средствам обработки со стороны программного средства;
– объем дисковой памяти;
– размер оперативной памяти для запуска программ;
– тип процессора;
– версия операционной системы;
– наличие вычислительной сети и др.
7) Качество ПП — это совокупность его черт и характеристик, которые влияют на способность ПП удовлетворять заданные потребности пользователя. Это, однако, не означает, что разные ПП должны обладать одним и тем же набором свойств с одинаковыми значениями количественных показателей. Как и в случае технических устройств, показатели качества являются противоречивыми, что означает: улучшение одних показателей качества может быть достигнуто за счет ухудшения других. Качество ПП является удовлетворительным, если количественные показатели свойств гарантируют успешное его использование.
Критериями качества ПП являются :функциональность, надежность; легкость применения; эффективность; сопровождаемость, мобильность.
8) Жизненный цикл программного обеспечения (ПО) — период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации[1]. Этот цикл — процесс построения и развития ПО.
9) Понятие жизненного цикла программного продукта
Программный продукт (ПП) представляет собой набор компьютерных программ, процедур и связанной с ними документации и данных.
Жизненный цикл программного продукта — это период времени, начинающийся с момента принятия решения о необходимости создания ПП и заканчивающийся в момент его полного изъятия из эксплуатации.
10) Вспомогательные процессы ЖЦПП;
Основной целью в вспомогательных процессах является создание надёжного, полностью удовлетворяющего требованиям заказчика ПП, в установленные договором сроки.
Процесс документирования – предусматривает формализованное описание информации, созданной в течение ЖЦПП. Данный процесс состоит из действий, с помощью которых планируют, проектируют, разрабатывают, выпускают, редактируют, распространяют и сопровождают документы. Включает в себя:
-подготовительная работа;
-проектирование и разработка документации;
-выпуск документации и сопровождение;
Управление конфигурацией – предполагает применение административных и технических процедур на всем протяжении ЖЦПП. Включает в себя:
-определение состояния компонентов ПП;
-управление модификациями ПП;
-описание и подготовка отчетов о состоянии компонентов ПП;
-управления хранением и поставкой ПП;
Процесс обеспечения качества – обеспечивает соответствующие гарантии того, что ПП и процессы его ЖЦ соответствуют заданным требованиям и утвержденным планам. Под качеством ПП понимают совокупность свойств, которые характеризуют способность ПП удовлетворять заданным требованиям
Процесс верификации – состоит в доказательстве того, что ПП является результатом некоторого действия, полностью удовлетворяет требованиям или условиям. В процессе проверяют:
-непротиворечивость к требованиям в системе и степень учета потребностей пользователей;
-возможности поставщика выполнить заданные требования;
-соответствие выбранных процессов ЖЦ условиям договора;
-адекватность стандартов процедур и среды разработки процессам ЖЦПП;
-корректность описания входных и выходных данных, последовательности событий, интерфейсов, логики и т.д.;
-тестируемость и корректность кода;
-адекватность, полнота и непротиворечивость документаций;
Процесс аттестации. Под аттестацией понимают подтверждение и оценку достоверности проведенного тестирования ПП.
Процесс совместной оценки – предназначен для оценки состояния работ по проекту и ПП, создаваемому при выполнении данных работ.
Процесс аудита. Аудит – это ревизия, проводимая компетентным органом в целях обеспечения независимой оценки степени соответствия ПП, установленным требованиям, планам, условиям договора, контрактом.
Процесс разрешения проблем – предусматривает анализ и решение проблемы, обнаруженных в ходе разработки эксплуатации, сопровождении и др. процессов
11) Организационные процессы жизненного цикла программного продукта. Основной целью организационных процессов является организация процесса разработки надежного, полностью удовлетворяющего требованиям заказчика ПП в установленные договором сроки и управление этим процессом. К организационным относятся процессы управления, создания инфраструктуры, усовершенствования, обучения.
12) Процессы жизненного цикла ПП, регламентируемые стандартом ISO/IEC 12207, могут использоваться различными организациями в конкретных проектах самым различным образом. Тем не менее, стандарт предлагает некоторый базовый набор взаимосвязей между процессами с различных точек зрения, или в различных аспектах. Взаимосвязи между процессами, описанные в стандарте, носят статический характер. Более важные динамические связи между процессами и реализующими их сторонами устанавливаются в реальных проектах.
13) Определение: надежность ПО – свойство составляющих его программ выполнять заданные функции в заданных условиях на конкретном КТС.Две основные причины возникновения отказов ПО:Разработчики ПО нарушили технические требования к программам (нарушены спецификации))Сами спецификации неточные или неполные, т. е. само описание того, что должна делать каждая программа, без указания как она должна это делать – неточное или неполное.Отличия надежности ПО от надежности КТС.элементы ПО не стареют от износа;число способов контроля ПО значительно больше, чем способов контроля аппаратуры;в ПО гораздо больше объектов для контроля, чем в аппаратуре в ПО гораздо проще вносить изменения, чем в аппаратуру, но это трудно делать корректно и безошибочно.
14) Жизненный цикл программного продукта – это период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации.Программы любого вида характеризуются жизненным циклом, состоящим из отдельных этапов:a) маркетинг рынка программных средств, спецификация требований к программному продукту;b) проектирование структуры программного продукта;c) программирование (создание программного кода), тестирование, автономная и комплексная отладка программ d) документирование программного продукта, подготовка эксплуатационной и технологической документации;e) выход на рынок программных средств, распространение программного продукта;f) эксплуатация программного продукта пользователями;g) сопровождение программного продукта;h) снятие программного продукта с продажи, отказ от сопровождения.
15. Модели жизненного цикла разработки программного продукта
Жизненный цикл программного обеспечения (ПО) — период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации[1]. Этот цикл — процесс построения и развития ПО.
Модель жизненного цикла ПО — структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач на протяжении жизненного цикла. Модель жизненного цикла зависит от специфики, масштаба и сложности проекта и специфики условий, в которых система создается и функционирует.
Стандарт ГОСТ Р ИСО/МЭК 12207-99 не предлагает конкретную модель жизненного цикла. Его положения являются общими для любых моделей жизненного цикла, методов и технологий создания ИС. Он описывает структуру процессов жизненного цикла, не конкретизируя, как реализовать или выполнить действия и задачи, включенные в эти процессы.
Модель ЖЦ ПО включает в себя:
Стадия — часть процесса создания ПО, ограниченная определенными временными рамками и заканчивающаяся выпуском конкретного продукта (моделей, программных компонентов, документации), определяемого заданными для данной стадии требованиями.
На каждой стадии могут выполняться несколько процессов, определенных в стандарте ГОСТ Р ИСО/МЭК 12207-99, и наоборот, один и тот же процесс может выполняться на различных стадиях. Соотношение между процессами и стадиями также определяется используемой моделью жизненного цикла ПО.
16.Каскадная модель разработки ПП
Принципиальная особенность каскадного подхода: переход на следующий этап осуществляется только после того, как будет полностью завершена работа на текущем этапе, и возврат на пройденные этапы не предусматривается. Каждый этап завершается выпуском полного комплекта документации, достаточно для того, чтобы разработка могла быть продолжена другой командой разработчиков.
На каждой стадии формируется набор проектной документации, отвечающий критериям полноты и согласованности.
Выполняемые в логичной последовательности стадии работ позволяют планировать сроки завершения всех работ и соответствующие затраты.
Недостатки. Процесс разработки носит, как правило, итерационный характер: результаты очередного этапа часто вызывают изменения в проектных решениях , выработанных на более ранних стадиях. Таким образом, постоянно возникает потребность в возрасте к предыдущим этапам и уточнении или пересмотре ранее принятых решений. В результату реальных процесс разработки принимает иной вид.
Существенное запаздывание с получением результатов и, как следствие, достаточно высокий риск создания системы, не удовлетворяющей изменившимися потребностями пользователей. Пользователи могут внести замечания только после того, как работа над ПП полностью завершена.
17.Модель быстрой разработки приложений (RAD-модель)
Конечный пользователь играет решающую роль. В начале жизненного цикла на конечного пользователя выпадает большая часть работы. В традиционном жизненном цикле разработки большую часть работы составляют программирование и тестирование.
Модель включает в себя следующие фазы:
Составление требовании и планирование – осуществляются с использованием, так называемого совместного планирования требований, который заключается в структурном анализе и обсуждения решаемых задач.
Описание пользователя – проектирование ПП, выполняемое при непосредственном участии заказчика.
Создание – детальное проектирование, кодирование и тестирование ПП, а также поставка его заказчику.
Сопровождение – приемочные испытания, установка ПП и обучение пользователей.
RAD-модель можно применять при разработке ПП, которые хорошо поддаются моделированию, когда требования к ПП хорошо известны, а заказчик может принять непосредственное участие в процессе разработки.
18.Многопроходная модель разработки ПП
Многопроходная модель – это несколько итераций процесса строения прототипа ПП с добавлением на каждой следующей итерации новых функциональных возможностей или повышением эффективности ПП.
Преимущества многопроходной модели:
*В начале разработки требуются средства только для разработки и реализации основных функций ПП.
*После каждого инкремента получается функциональный продукт.
*Снижается риск неудачи и изменения требований.
Недостатки многопроходной модели:
*Не предусмотрены итерации внутри каждого инкремента.
*Определение полной функциональности должно быть осуществлено в самом начале жизненного цикла разработки.
*Может возникнуть тенденция оттягивания решения трудных задач.
*Общие затраты на создание ПП не будут снижены по сравнению с другими моделями.
Многопроходная модель может быть применена, если большинство требований к ПП будут сформулированы заранее, а для выполнения проекта будет выделен большой период времени.
19.Спиральная модель разработки ПП
Спиральная модель (англ. spiral model) была разработана в середине 1980-х годов Барри Боэмом. Она основана на классическом цикле Деминга PDCA (plan-do-check-act). При использовании этой модели ПО создается в несколько итераций (витков спирали) методом прототипирования.
Принципиальная особенность заключается в том, что прикладной ПП создается не сразу, как в случае каскадного подхода, а по частям и использованием метода прототипирования. Под прототипом понимается действующий программный компонент, реализующий отдельные функции и внешние интерфейсы разрабатываемого ПП. Создание прототипов осуществляется за несколько итераций, или вигков спирали. Каждая итерация соответствует созданию фрагмента, или версии ПП, на ней уточняются цели и характеристики проекта, оценивается качество полученных результатов и планируются работы следующей итерации.
Основная проблема спиральной модели – определение момента перехода на следующую стадию. Для её решения необходимо весте временные ограничения на каждую из стадий жизненного цикла.
Спиральная модель обладает следующими достоинствами:
Недостатки спиральной модели:
Использование спиральной модели целесообразно, если существует хотя бы одна из следующих причин:
20.Документы, создаваемые на этапах ЖЦ ПП
Целью вспомогательных процессов являются: Создание надежного полностью удовлетворенного требованиям заказчика ПП в установленные договором сроки. К ним относится относятся процессы: Документирования, Управления конфигурацией, обеспечение качества, Верификации, Аттестации, Совместной оценки, аудита разрешения проблем.
Процесс документирования предусматривает: Формализованное описание информации созданные в течении Ж.Ц.П.П.
Данный процесс состоит из набора действий с помощью которых планируют, проектируют, разрабатывают, выпускают, редактируют, распространяют и сопровождают документы.
Процесс документирования включает в себя:
21.Кризис программирования и способ выхода из него
В начале 1970-х готов в США был отмечен кризис программирования. Это выражалось в том, что большие проекты стали выполняться с отставанием от графика или с превышением сметы расходов, разработанный ПП не обладал требуемыми функциональными возможностями, производительность его была низка, качество не устраивало потребителей.
Потребность контролировать процесс разработки ПП, прогнозировать и гарантировать стоимость разработки, сроки и качество результатов привела в конце 1970-х готов к необходимости перехода от кустарных к индустриальным способам создания ПП и появление совокупности инженерных методов.
В числе причин возможных неудач фигурируют: нечеткая и неполная формулировка требований к ПП, недостаточное вовлечении пользователей в работу над проектом, отсутствие необходимых ресурсов, неудовлетворительное планирование требований и спецификаций.
22.Методики оценки состояния процесса разработки ПО
--------------------------ХЗ ГДЕ ТАКОЕ ВООБЩЕ……
23.Модель оценки зрелости технологических процессов CMM-SEI
Измерение и анализ результатов измерений являются составной частью модели зрелости программного обеспечения, предложенной институтом SEI. Каждый ключевой процесс в модели CMM-SEI на любом уровне зрелости содержит компоненты измерения и анализа. Измерение и анализ результатов измерения необходимы для уточнения состояния процесса, проекта и продукта.
24.Управление качеством разработки программного продукта с помощью системы стандартов ISO 9001
Взаимосвязь между моделью СММ и системой стандартов ISO 9001 следующая: ISO 9001 содержит перечень требования, а СММ определяет детали требований к процессу разработки для включения их в документы по управлению качеством.
Целью ISO 9001 является построение системы сквозного управления качеством, которая должна обеспечивать качество на всех этапах разработки.
Система стандартов ISO 9001 определяется минимальный набор требований к управлению качеством. Условно этот набор разбивается на три части: требования к менеджменту к определяет минимальный набор требований к управлению качеством. Условно этот набор разбивается на три части: требования к менеджменту, компании, контролю продукции и процессу разработки. Управление продукцией включает в себя контроль за версиями систем, приобретением готовых пакетов и программ, продукцией, которая в настоящий момент не отвечает требованиям качества. Управления процессом разработки – важнейшая часть ISO 9001 для организаций, занятых программированием. Она включает в себя требования к построению документированию всего процесса разработки ПП – от заключения контракта до распространения готового продукта.
25.Защита программного продукта (выберите нужное и пишите)
Программное обеспечение является объектом защиты также и в связи со сложностью и трудоемкостью восстановления его работоспособности, значимостью программного обеспечения для работы информационной системы.
Защита программного обеспечения преследует цели:2
Программный продукт и базы данных должны быть защищены по нескольким направлениям от воздействия:
Самый простой и доступный способ защиты программных продуктов и базы данных – ограничение доступа. Контроль доступа к программному продукту и базе данных строится путем:
Могут также использоваться и криптографические методы защиты информации базы данных или головных программных модулей.
Данные системы предотвращают нелицензионное использование программных продуктов и баз данных. Программа выполняется только при опознании некоторого уникального некопируемого ключевого элемента.
Таким ключевым элементом могут быть:
Программные системы защиты от копирования программных продуктов:
Для идентификации запускающих дискет применяются следующие методы:
Идентификация среды компьютера обеспечивается за счет:
На Западе наиболее популярны методы правовой защиты программных продуктов и баз данных.
26.Примерная структура процесса и организации, занимающейся разработкой ПП
Для распределения обязанностей и контроля над качеством и правильностью кода в команде должны присутствовать старшие или более опытные разработчики, в обязанности которых входит обсуждение функционала, постановка задачи и реализация и/или проверка написанного кода. Код, попадающий в работающую систему без дополнительной проверки, рискует содержать в себе недочёты, даже при условии его автоматического тестирования. В идеале написание тестов и собственно разработка кода должна выполнятся различными людьми или даже различными командами на основе одной спецификации – таким образом можно исключить допуск одинаковых ошибок в коде и в тестах.
Исходя из этого, структура выглядит следующим образом:
- тимлидер – осуществляет распределение частей проекта между старшими разработчиками, просмотр кода, отслеживает сроки выполнения заданий а так же создание новых при необходимости;
- старшие разработчики во главе с тимлидером – создают спецификации, основываясь на предложениях самих разработчиков или пожеланиях заказчика. Старшие разработчики распределяют задания среди младших или выполняют сами, после чего проверяют результаты или передают другим (или тимлидеру) для проверки. Так же задание может быть передано другой команде (скажем, системным администраторам) для выполнения промежуточных действий. Задачи старших разработчиков так же могут различаться в зависимости от роли в команде – релиз-менеджер, поддержка пользователей и т.д.);
- младшие разработчики – осуществляют непосредственно разработку кода заданий, полученных от старших разработчиков.
27.Роль метрик в процессе разработки ПП
Под метриками понимают количественную оценку ПП, процесса или проекта, которая используется непосредственно либо на основе которой производится, другие измерения или выполняется прогноз. Измерения в ходе разработки программного продукта – количественно оценивание произвольных аспектов процесса программного инжиниринга, программного продукта или контекста; оно служит для совершенствования представления, помогает контролировать, прогнозировать и вносить улучшения в создаваемый продукт, а также в применяемые рабочие методы. Все метрики модно разделить на три основные группы: метрики процесса, метрики проекта, метрики продукта.
Внутри каждой группы существуют следующие типы метрик: непосредственно наблюдаемые, прогнозируемые, вычисляемые.
28.Основные источники метрических показателей
(БЛЯТЬ ХОТЬ УБЕЙТЕ , НЕ НАШЕЛ)….
29.Планирование работ по созданию ПП: структура разделения работ по созданию ПП, оценка объемов, ресурсов, рисков
30- Управление требованиями процесс, включающий идентификацию, выявление, документирование, анализ, отслеживание, приоритезацию требований, достижение соглашения по требованиям и затем управление изменениями и уведомление соответствующих заинтересованных лиц. Управление требованиями — непрерывный процесс на протяжении всего проекта разработки программного обеспечения.
Цель управления требованиями состоит в том, чтобы гарантировать что организация документирует, проверяет и удовлетворяет потребности и ожидания её клиентов и внутренних или внешних заинтересованных лиц. Управление требованиями начинается с выявления и анализа целей и ограничений клиента. Управление требованиями далее включает поддержку требований, интеграцию требований и организацию работы с требованиями и сопутствующей информацией, поставляющейся вместе с требованиями.
Управление требованиями включает общение между проектной командой и заинтересованными лицами с целью корректировки требований на протяжении всего проекта, и чтобы ни один класс разработок не доминировал над другим
31- Проектирование является важнейшим этапом в современной технологии создания ПО. На этом этапе закладываются не только основные технические характеристики программных изделий, но и определяется содержание и характер работы на остальных этапах разработки: кодирования, тестирования и отладке. Решения, принимаемые на этапе проектирования, определяют простоту или сложность сопровождения.
32- Системное программное обеспечение предназначено для:
создания операционной среды функционирования других программ (другими словами, для организации выполнения программ);
автоматизации разработки (создания) новых программ;
обеспечения надежной и эффективной работы самого компьютера и вычислительной сети;
проведения диагностики и профилактики аппаратуры компьютера и вычислительных сетей;
выполнения вспомогательных технологических процессов (копирование, архивирование, восстановление файлов программ и баз данных и т.д.).
Данный класс программных продуктов тесно связан с типом компьютера и является его неотъемлемой частью.
Программные продукты данного класса в основном ориентированы на квалифицированных пользователей - профессионалов в компьютерной области: системного программиста, администратора сети, прикладного программиста, оператора.
33-хуй знает честно
34- В разработке программного обеспечения, стадии разработки программного обеспечения используются для описания степени готовности программного продукта.
Кодирование обеспечивает реализацию проектных решений в выбранной среде программирования. Тестирование — обязательный этап для выявления дефектов программного продукта
35- Часто бывает так, что над созданием ПП работают несколько человек, но никто из них не несет полной ответственности за его качество.
Справочная система ПП формируется на основе материала, разработанного для руководства пользователя.
У хорошо документированного ПП имеются следующие пре¬имущества:
• Легкость использования., Меньшая стоимость технической поддержки , Высокая надежность. Легкость сопровождения. Упрощенная установка. Коммерческий успех. Достоверность информации.
36- Тестирование представляет собой деятельность по проверке программного кода и документации. Она должна заранее плани¬роваться и систематически проводиться специально назначенным независимым тестировщиком.
1-синтаксическая проверка 2- проверка соответствия стандартам кодирования 3- технический обзор программного кода.
37. Виды тестирования. Требования к хорошему тесту (Модульное тестирование-представляет собой проверки программных процедур и подпрограмм, Интеграционное тестирование-проводится для проверки совместной работы отдельных модулей, Системное тестирование-предназначен для проверки программной системы в целом, Выходное тестирование-проверяется готовность ПП к поставке заказчику, Приемочное тестирование.)(Хороший тест-должна быть достаточной вероятность выявления тестом ошибки, набор тестов не должен быть избыточным, должен быть наилучшим в своей категории, не должен быть слишком простым или сложным)
38. Программные ошибки. Синтаксические и семантические ошибки. (Функциональные недостатки, недостатки пользовательского интерфейса, обработка ошибки, ошибки вычислений, перегрузки, ошибки управления потоком)(
39. Понятие тестирования. Понятие отладки. Различие между отладкой и тестированием.
40. Тестирование документации(Читая и анализируя документацию, тестировщик прежде всего должен уделять внимание ее точности, полноте, ясности, простоте использования и тому насколько она соответствует ПП)
41. Роль этапа сопровождения в ЖЦ ПП(Подготовительная работа, анализ проблем и запросов на модификацию ПП, модификация ПП, проверка и приемка, перенос ПП в новую среду работы, снятие ПП с эксплуатации)
42. Управление поставками программных продуктов(Процедура поставки ПП, схемы классификации ПП, методы проверки и отслеживанию соответствий ПП)
43. Обеспечение надежности программных продуктов(Надежность ПП необходимо планировать на начальных стадиях выполнения проекта. Методы: Прогнозирование ошибок, Предотвращение ошибок, Устранение ошибок, Обеспечение отказоустойчиватси)
44. Характеристики качества программного продукта
2 Угринович Н.Д. Информатика и информационные технологии. – М.: Бином, 2007. – с. 262.