программы, причем особое внимание уделяется следующим ееэлементам:
комментариям и их соответствию тексту программы ;
условиям в операторах условного выбора ( IF, CASE ) и цикла;
сложным логическим выражениям;
возможности незавершения итерационных циклов ( WHILE, REPEAT, LOOP ).
Второй этап визуального контроля — сквозной контроль программы
( ее ручная прокрутка на нескольких заранее подобранных простых тестах).
Распространенное мнение , что более выгодным являетсяперекладывание большей
части работы по контролю программных средств на компьютере, ошибочно. Основной
довод в пользу этого таков : при работе накомпьютере главным образом
совершенствуются навыки в использовании клавиатуры, в то время как
программистская квалификация преобретается прежде всего застолом.
Статический контроль- это проверка программы по ее тексту (без
выполнения) спомощью инструментальных средств. Наиболее известной формой
статического контроля является синтаксический контроль программы с помощью
Мастер-класс: «Введение в фармацевтическое право: основы регулирования индустрии»
компилятора , прикотором проверяется соответствие текста программы
синтаксическим правилам языка программирования.
Сообщения компилятора обычно делятся на несколько групп в зависимости от уровня
тяжести нарушения синтаксиса языкапрограммирования :
— информационные сообщения и предупреждения , при обнаружении
которыхкомпилятор, как правило, строит корректный объектный код и дальнейшая
работа с программой (компоновка, выполнение) возможна (тем не менее сообщения
этойгруппы также должны тщательно анализироваться, так как их появление также
может свидетельствовать об ошибке в программе — например, из-за неверного
— сообщения об ошибках, при обнаружении которых компилятор
пытается их исправить и строит объектный код, ноего корректность маловероятна и
дальнейшая работа с ним скорее всего не возможна;
— сообщения о серьезных ошибках , при наличии которых
построенный компилятором объектный код заведомо некорректени его дальнейшее
— сообщения об ошибках , обнаружение которых привело к
прекращениюсинтаксического контроля и построения объектного кода .
Однако, практически любой компилятор пропускает некоторые виды синтаксических
ошибок. Место обнаружения ошибки может находитьсядалеко по тексту программы от
места истинной ошибки, а текст сообщения компилятора может не указывать на
истинную причину ошибки. Одна синтаксическаяошибка может повлечь за собой
генерацию компилятором нескольких сообщений об ошибках (например, ошибка в
описании переменной приводит к появлению сообщенияоб ошибке в каждом операторе
программы, использующем эту переменную).
Второй формой синтаксического контроля может быть контроль структурированности
программ, то есть проверка выполнениясоглашений и ограничений структурного
программирования. Примером подобной проверки может быть выявление в тексте
Виды и типы контроля. (Основы менеджмента)
программы ситуаций, когда циклобразуется с помощью оператора безусловного
перехода (использования оператора GOTO для перехода вверх по тексту программы ).
Для проведения контроляструктурированности могут быть созданы специальные
инструментальные средства, а при их отсутствии эта форма статического контроля
может совмещаться свизуальным контролем .
Третья форма статического контроля — контроль правдоподобия программы, то есть
выявление в ее тексте конструкций, которые хотя исинтаксически корректны, но
скорее всего содержат ошибку или свидетельствуют о ней. Основные
— использование в программе неинициализированных переменных (то
естьпеременных, не получивших начального значения) ;
— наличие в программе описаний элементов, переменных, процедур,
меток,файлов, в дальнейшем не используемых в ее тексте;
— наличие в тексте программы фрагментов, никогда не
— наличие в тексте программы переменных, ни разу не используемых
длячтения после присваивая им значений;
— наличие в тексте программы заведомо бесконечных циклов ;
Даже если присутствие в тексте программы неправдоподобных конструкций не
приводит к ее неправильной работе, исправлениеэтого фрагмента повысит ясность и
эффективность программы, т. е. благотворно скажется на еекачестве.
Для возможности проведения контроля правдоподобия в полном объеме также должны
быть созданы специальные инструментальныесредства, хотя ряд возможностей по
контролю правдоподобия имеется в существующих отладочных и обычныхкомпиляторах.
Следует отметить, что создание инструментальных средств контроля
структурированности и правдоподобия программ может бытьсущественно
упрощено при применении следующих принципов:
1) проведение этих дополнительных форм статического контроля
после завершения компиляции и только для синтаксическикорректных программ ;
2) максимальное использование результатов компиляции программы
и, вчастности, информации, включаемой в листинг компилятора;
3) вместо полного синтаксического разбора текста проверяемой
программыпостроение для нее списка идентификаторов и списка операторов с
указанием всех их необходимых признаков.
При отсутствии инструментальных средств контроля правдоподобия эта фаза
статического контроля также может объединяться свизуальным контролем.
Четвертой формой статического контроля программ является их верификация, то есть
аналитическое доказательство их корректности.
В интуитивном смысле под корректностью понимают свойства программы,
свидетельствующие об отсутствии в ней ошибок, допущенныхразработчиком на
различных этапах проектирования ( спецификации, проектирование алгоритма и
структур данных, кодирование ). Корректность самой программы поотношению к
целям, поставленным перед ее разработкой ( то есть это относительное свойство ).
Отличие понятия корректности и надежности программ в следующем :
надежность характеризует как программу, так и ее “окружение” (
качествоаппаратуры, квалификацию пользователя и т.п. );
говоря о надежности программы, обычно допускают определенную,
хотя ималую, долю ошибок в ней и оценивают вероятность их появления.
Надежность можно представить совокупностью следующих характеристик :
1) целостность программного средства (способность его к защите
2) живучесть (способность к входному контролю данных и их
проверки входе работы) ;
3) завершенность (бездеффектность готового программного
средства,характеристика качества его тестирования);
4) работоспособность (способность программного средства к
восстановлению своих возможностей полесбоев).
Очевидно, что не всякая синтаксически правильная программа является корректной в
указанном выше смысле, т. е. корректностьхарактеризует семантические свойства
С учетом специфики появления ошибок в программах можно выделить две стороны
1) корректность как точное соответствие целям разработки
программы(которые отражены в спецификации) при условии ее завершения или
2) завершение программы , то есть достижение программой в
процессе еевыполнения своей конечной точки.
В зависимости от выполнения или невыполнения каждого из двух названных свойств
программы различают шесть задач анализакорректности :
1) доказательство частичной корректности ;
2) доказательство частичной некорректности ;
3) доказательство завершения программы ;
4) доказательство незавершения программы ;
5) доказательство тотальной (полной ) корректности (то есть
одновременное решение первой и третьей задач);
6) доказательство некорректности (решение второй или четвертой задачи).
Методы доказательства частичной корректности программ как правило опираются
нааксиоматический подход к формализации семантики языков программирования. В
настоящее время известны аксиоматические семантики Паскаля, подмножества ПЛ/1
инекоторых других языков.
Аксиоматическая семантика языка программирования представляет собой совокупность
аксиоми правил вывода. С помощью аксиом задается семантика простых операторов
языка (присваивания, ввода — вывода, вызовапроцедур). С помощью правил вывода
описывается семантика составных операторов или управляющих структур
(последовательности, условного выбора, циклов). Средиэтих правил вывода надо
отметить правило вывода для операторов цикла так как оно требует знания
инварианта цикла(формулы, истинности которой не изменяется при любом прохождении
Построение инварианта для оператора цикла по его тексту является алгоритмически
не разрешимой задачи, поэтому для описаниясемантики циклов требуется своего рода
”подсказка” от разработчика программы.
Наиболее известным из методов доказательства частичной корректности программ
является метод индуктивных утвержденийпредложенный Флойдом и усовершенствованный
Хоаром. Метод состоит из трех этапов.
Первый этап — получение аннотированной программы. На этом этапе для
синтаксически правильной программы должны быть заданыутверждения на языке логики
предикатов первого порядка :
Источник: smekni.com
Технологии программирования 81 стр.
11.6. КРИТЕРИИ ВЫБОРА НАИЛУЧШЕЙ СТРАТЕГИИ РЕАЛИЗАЦИИ
Критериями выбора наилучшей стратегии реализации программы являются:
• время до полной сборки программы;
• время реализации скелета программы;
• имеющийся инструментарий тестирования;
• мера параллелизма ранних этапов реализации;
• возможность проверки любых путей программы данными из заглушек;
• сложность планирования и соблюдения графика реализации;
11.7. СПОСОБЫ И ВИДЫ ТЕСТИРОВАНИЯ ПОДПРОГРАММ. ПРОЕКТИРОВАНИЕ ТЕСТОВ
Существуют два способа тестирования: публичный и приватный.
Публичное тестирование означает, что любой желающий может получить данный продукт (либо бесплатно, либо по цене дисков и доставки).
Приватный способ тестирования означает, что проверку продукта производит ограниченный круг тестировщиков, которые выразили согласие активно работать с продуктом и оперативно сообщать обо всех выявленных дефектах. Часто используются оба способа: сначала программа проходит приватное тестирование, а затем, когда все крупные проколы уже выявлены, начинается ее публичное тестирование, чтобы собрать отзывы широкого круга пользователей.
Большинство компаний-разработчиков требуют, чтобы приватный бета-тестировщик подписал «Соглашение о неразглашении» (NDA, Non-Disclosure Agreement). Тем самым он обязуется не разглашать подробности о тестируемом продукте и не передавать его копии третьим лицам. Подобные соглашения подписываются в целях сохранения коммерческой тайны и во избежание недобросовестной конкуренции.
Так, фирма «Microsoft» использует все перечисленные выше подходы для тестирования своих продуктов. С ее сайтов всегда можно бесплатно загрузить большое количество продуктов, проходящих публичное бета-тестирование. Однако их появлению предшествует многомесячный процесс приватного тестирования.
Фирма «Microsoft» проводит политику открытого набора приватных бета-тестировщиков, при которой каждый желающий может сообщить корпорации о своем желании принять участие в тестировании того или иного продукта. На самом деле круг приватных бета-тестеров Microsoft очень узок, и шанс, что вас включат в их число, невелик. Тем не менее он существует, а попадают в список бета-тестеров практически пожизненно.
Приватное тестирование подпрограмм начинается с этапа контроля, основными разновидностями которого являются: визуальный, статический и динамический.
Визуальный контроль — это проверка текстов «за столом», без использования компьютера.
На первом этапе визуального контроля осуществляется чтение текста подпрограммы, причем особое внимание уделяется: комментариям и их соответствию тексту программы; условиям в операторах условного выбора и цикла; сложным логическим выражениям; возможности незавершения итерационных циклов.
Второй этап визуального контроля — сквозной контроль текста подпрограммы (его ручная прокрутка на нескольких заранее подобранных простых тестах). Распространенное мнение, что более выгодным является перекладывание большей части работы по контролю программных средств на компьютер, ошибочно. Основной довод в пользу этого таков: при работе на компьютере главным образом совершенствуются навыки в использовании клавиатуры, в то время как программистская квалификация приобретается, прежде всего, за столом.
Статический контроль — это проверка текста подпрограммы (без выполнения) с помощью инструментальных средств.
Первой, наиболее известной формой статического контроля является синтаксический контроль программы с помощью компилятора, при котором проверяется соответствие текста программы синтаксическим правилам языка программирования.
Сообщения компилятора обычно делятся на несколько групп в зависимости от уровня тяжести нарушения синтаксиса языка программирования:
1) информационные сообщения и предупреждения, при обнаружении которых компилятор, как правило, строит корректный объектный код и дальнейшая работа с программой (компоновка, выполнение) возможна (тем не менее сообщения этой группы должны тщательно анализироваться, так как их появление также может свидетельствовать об ошибке в программе — например, из-за неверного понимания синтаксиса языка);
2) сообщения об ошибках, при обнаружении которых компилятор пытается их исправить и строит объектный код, но его корректность маловероятна и дальнейшая работа с ним, скорее всего, невозможна;
3) сообщения о серьезных ошибках, при наличии которых построенный компилятором объектный код заведомо некорректен и его дальнейшее использование невозможно;
4) сообщения об ошибках, обнаружение которых привело к прекращению синтаксического контроля и построения объектного кода.
Однако практически любой компилятор пропускает некоторые виды синтаксических ошибок. Место обнаружения ошибки может находиться далеко по тексту подпрограммы от места истинной ошибки, а текст сообщения компилятора может не указывать на истинную причину ошибки. Одна синтаксическая ошибка может повлечь за собой генерацию компилятором нескольких сообщений об ошибках (например, ошибка в описании переменной приводит к появлению сообщения об ошибке в каждом операторе подпрограммы, использующем эту переменную).
Второй формой статического контроля может быть контроль структурированности текста подпрограммы, т. е. проверка выполнения соглашений и ограничений структурного программирования. Примером подобной проверки может быть выявление в тексте подпрограммы ситуаций, когда цикл образуется с помощью оператора безусловного перехода (использования оператора GOTO для перехода вверх по тексту программы). Для проведения контроля структурированности могут быть созданы специальные инструментальные средства, а при их отсутствии эта форма статического контроля может совмещаться с визуальным контролем.
Третья форма статического контроля — контроль правдоподобия подпрограммы, т. е. выявление в ее тексте конструкций, которые хотя и синтаксически корректны, но скорее всего содержат ошибку или свидетельствуют о ней. Основные неправдоподобные ситуации:
• использование в программе неинициализированных переменных (т. е. переменных, не получивших начального значения);
• наличие в программе описаний элементов, переменных, процедур, меток, файлов, в дальнейшем не используемых в ее тексте;
• наличие в тексте подпрограммы фрагментов, никогда не выполняющихся;
• наличие в тексте программы переменных, ни разу не используемых для чтения после присваивания им значений;
• наличие в тексте подпрограммы заведомо бесконечных циклов.
Даже если присутствие в тексте программы неправдоподобных конструкций не приводит к ее неправильной работе, исправление этого фрагмента повысит ясность и эффективность программы, т. е. благотворно скажется на ее качестве.
Для возможности проведения контроля правдоподобия в полном объеме также должны быть созданы специальные инструментальные средства, хотя ряд возможностей по контролю правдоподобия имеется в существующих отладочных и обычных компиляторах.
Следует отметить, что создание инструментальных средств контроля структурированности и правдоподобия программ может быть упрощено существенно при применении следующих принципов:
1) проведение дополнительных форм статического контроля после завершения компиляции и только для синтаксически корректных программ;
2) максимальное использование результатов компиляции и линковки программы и, в частности, информации, включаемой в листинг компилятора и линкера;
3) вместо полного синтаксического разбора текста проверяемой программы необходимо построение для нее списка идентификаторов и списка операторов с указанием всех их необходимых признаков.
При отсутствии инструментальных средств контроля правдоподобия эта фаза статического контроля также может объединяться с визуальным контролем.
Четвертой формой статического контроля программ является их верификация, т. е. аналитическое доказательство их корректности.
Несмотря на достаточную сложность процесса верификации программы и на то, что даже успешно завершенная верификация не дает гарантий качества программы (так как ошибка может содержаться и в верификации), применение методов аналитического доказательства правильности очень полезно для уточнения смысла разрабатываемой программы, а знание этих методов благотворно сказывается на квалификации программиста.
Динамический контроль программы — это проверка правильности программы при ее выполнении на компьютере, т. е. тестирование. Минимальное автономное тестирование подпрограммы должно обеспечивать прохождение всех путей вычислений.
Проектная процедура тестирования подпрограммы заключается в следующем:
— по внешним спецификациям модуля подготовьте тесты для каждой ситуации и каждого недопустимого условия;
— просмотрите текст подпрограммы, чтобы убедиться, что все условные переходы будут выполняться в каждом направлении; при необходимости добавьте тесты;
— убедитесь по тексту подпрограммы, что тесты охватывают достаточно много путей; для циклов должны быть тесты без повторения, с одним повторением и с несколькими повторениями;
— проверьте по тексту подпрограммы ее чувствительность к особым значениям данных (наиболее опасные числа — это ноль и единица), в случае необходимости добавьте тесты.
Источник: sharlib.com
Прочитайте онлайн Технологии программирования | 11.7. СПОСОБЫ И ВИДЫ ТЕСТИРОВАНИЯ ПОДПРОГРАММ. ПРОЕКТИРОВАНИЕ ТЕСТОВ
Существуют два способа тестирования: публичный и приватный.
Публичное тестирование означает, что любой желающий может получить данный продукт (либо бесплатно, либо по цене дисков и доставки).
Приватный способ тестирования означает, что проверку продукта производит ограниченный круг тестировщиков, которые выразили согласие активно работать с продуктом и оперативно сообщать обо всех выявленных дефектах. Часто используются оба способа: сначала программа проходит приватное тестирование, а затем, когда все крупные проколы уже выявлены, начинается ее публичное тестирование, чтобы собрать отзывы широкого круга пользователей.
Большинство компаний-разработчиков требуют, чтобы приватный бета-тестировщик подписал «Соглашение о неразглашении» (NDA, Non-Disclosure Agreement). Тем самым он обязуется не разглашать подробности о тестируемом продукте и не передавать его копии третьим лицам. Подобные соглашения подписываются в целях сохранения коммерческой тайны и во избежание недобросовестной конкуренции.
Так, фирма «Microsoft» использует все перечисленные выше подходы для тестирования своих продуктов. С ее сайтов всегда можно бесплатно загрузить большое количество продуктов, проходящих публичное бета-тестирование. Однако их появлению предшествует многомесячный процесс приватного тестирования.
Фирма «Microsoft» проводит политику открытого набора приватных бета-тестировщиков, при которой каждый желающий может сообщить корпорации о своем желании принять участие в тестировании того или иного продукта. На самом деле круг приватных бета-тестеров Microsoft очень узок, и шанс, что вас включат в их число, невелик. Тем не менее он существует, а попадают в список бета-тестеров практически пожизненно.
Приватное тестирование подпрограмм начинается с этапа контроля, основными разновидностями которого являются: визуальный, статический и динамический.
Визуальный контроль — это проверка текстов «за столом», без использования компьютера.
На первом этапе визуального контроля осуществляется чтение текста подпрограммы, причем особое внимание уделяется: комментариям и их соответствию тексту программы; условиям в операторах условного выбора и цикла; сложным логическим выражениям; возможности незавершения итерационных циклов.
Второй этап визуального контроля — сквозной контроль текста подпрограммы (его ручная прокрутка на нескольких заранее подобранных простых тестах). Распространенное мнение, что более выгодным является перекладывание большей части работы по контролю программных средств на компьютер, ошибочно. Основной довод в пользу этого таков: при работе на компьютере главным образом совершенствуются навыки в использовании клавиатуры, в то время как программистская квалификация приобретается, прежде всего, за столом.
Статический контроль — это проверка текста подпрограммы (без выполнения) с помощью инструментальных средств.
Первой, наиболее известной формой статического контроля является синтаксический контроль программы с помощью компилятора, при котором проверяется соответствие текста программы синтаксическим правилам языка программирования.
Сообщения компилятора обычно делятся на несколько групп в зависимости от уровня тяжести нарушения синтаксиса языка программирования:
1) информационные сообщения и предупреждения, при обнаружении которых компилятор, как правило, строит корректный объектный код и дальнейшая работа с программой (компоновка, выполнение) возможна (тем не менее сообщения этой группы должны тщательно анализироваться, так как их появление также может свидетельствовать об ошибке в программе — например, из-за неверного понимания синтаксиса языка);
2) сообщения об ошибках, при обнаружении которых компилятор пытается их исправить и строит объектный код, но его корректность маловероятна и дальнейшая работа с ним, скорее всего, невозможна;
3) сообщения о серьезных ошибках, при наличии которых построенный компилятором объектный код заведомо некорректен и его дальнейшее использование невозможно;
4) сообщения об ошибках, обнаружение которых привело к прекращению синтаксического контроля и построения объектного кода.
Однако практически любой компилятор пропускает некоторые виды синтаксических ошибок. Место обнаружения ошибки может находиться далеко по тексту подпрограммы от места истинной ошибки, а текст сообщения компилятора может не указывать на истинную причину ошибки. Одна синтаксическая ошибка может повлечь за собой генерацию компилятором нескольких сообщений об ошибках (например, ошибка в описании переменной приводит к появлению сообщения об ошибке в каждом операторе подпрограммы, использующем эту переменную).
Второй формой статического контроля может быть контроль структурированности текста подпрограммы, т. е. проверка выполнения соглашений и ограничений структурного программирования. Примером подобной проверки может быть выявление в тексте подпрограммы ситуаций, когда цикл образуется с помощью оператора безусловного перехода (использования оператора GOTO для перехода вверх по тексту программы). Для проведения контроля структурированности могут быть созданы специальные инструментальные средства, а при их отсутствии эта форма статического контроля может совмещаться с визуальным контролем.
Третья форма статического контроля — контроль правдоподобия подпрограммы, т. е. выявление в ее тексте конструкций, которые хотя и синтаксически корректны, но скорее всего содержат ошибку или свидетельствуют о ней. Основные неправдоподобные ситуации:
• использование в программе неинициализированных переменных (т. е. переменных, не получивших начального значения);
• наличие в программе описаний элементов, переменных, процедур, меток, файлов, в дальнейшем не используемых в ее тексте;
• наличие в тексте подпрограммы фрагментов, никогда не выполняющихся;
• наличие в тексте программы переменных, ни разу не используемых для чтения после присваивания им значений;
• наличие в тексте подпрограммы заведомо бесконечных циклов.
Даже если присутствие в тексте программы неправдоподобных конструкций не приводит к ее неправильной работе, исправление этого фрагмента повысит ясность и эффективность программы, т. е. благотворно скажется на ее качестве.
Для возможности проведения контроля правдоподобия в полном объеме также должны быть созданы специальные инструментальные средства, хотя ряд возможностей по контролю правдоподобия имеется в существующих отладочных и обычных компиляторах.
Следует отметить, что создание инструментальных средств контроля структурированности и правдоподобия программ может быть упрощено существенно при применении следующих принципов:
1) проведение дополнительных форм статического контроля после завершения компиляции и только для синтаксически корректных программ;
2) максимальное использование результатов компиляции и линковки программы и, в частности, информации, включаемой в листинг компилятора и линкера;
3) вместо полного синтаксического разбора текста проверяемой программы необходимо построение для нее списка идентификаторов и списка операторов с указанием всех их необходимых признаков.
При отсутствии инструментальных средств контроля правдоподобия эта фаза статического контроля также может объединяться с визуальным контролем.
Четвертой формой статического контроля программ является их верификация, т. е. аналитическое доказательство их корректности.
Несмотря на достаточную сложность процесса верификации программы и на то, что даже успешно завершенная верификация не дает гарантий качества программы (так как ошибка может содержаться и в верификации), применение методов аналитического доказательства правильности очень полезно для уточнения смысла разрабатываемой программы, а знание этих методов благотворно сказывается на квалификации программиста.
Динамический контроль программы — это проверка правильности программы при ее выполнении на компьютере, т. е. тестирование. Минимальное автономное тестирование подпрограммы должно обеспечивать прохождение всех путей вычислений.
Проектная процедура тестирования подпрограммы заключается в следующем:
— по внешним спецификациям модуля подготовьте тесты для каждой ситуации и каждого недопустимого условия;
— просмотрите текст подпрограммы, чтобы убедиться, что все условные переходы будут выполняться в каждом направлении; при необходимости добавьте тесты;
— убедитесь по тексту подпрограммы, что тесты охватывают достаточно много путей; для циклов должны быть тесты без повторения, с одним повторением и с несколькими повторениями;
— проверьте по тексту подпрограммы ее чувствительность к особым значениям данных (наиболее опасные числа — это ноль и единица), в случае необходимости добавьте тесты.
- ПРЕДИСЛОВИЕ
- ВВЕДЕНИЕ
- 1.1. ОБЩИЕ ПОЛОЖЕНИЯ ТЕОРИИ ПРОЕКТИРОВАНИЯ
- 1.2. ОБЩИЕ ПРИНЦИПЫ РАЗРАБОТКИ ПРОГРАММ
- 1.3. СИСТЕМНЫЙ ПОДХОД И ПРОГРАММИРОВАНИЕ
- 1.4. ОБЩЕСИСТЕМНЫЕ ПРИНЦИПЫ СОЗДАНИЯ ПРОГРАММ
- 1.5. ОСОБЕННОСТИ ПРОГРАММНЫХ РАЗРАБОТОК
- 1.6. СТАНДАРТЫ И ПРОГРАММИРОВАНИЕ
- 1.7. ОПИСАНИЕ ЦИКЛА ЖИЗНИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
- 1.8. СТАДИИ И ЭТАПЫ РАЗРАБОТКИ ПРОГРАММ
- 1.9. ТИПОВЫЕ ОШИБКИ ОБУЧАЕМЫХ ПРИ СОСТАВЛЕНИИ ТЕХНИЧЕСКОГО ЗАДАНИЯ
- 1.10. МОДЕЛИРОВАНИЕ И ПРОГРАММИРОВАНИЕ. ПОНЯТИЕ СПЕЦИФИКАЦИЙ
- 1.11. МНЕМОНИКА ИМЕН В ПРОГРАММАХ
- 1.12. ПРОБЛЕМА ТИПОВЫХ ЭЛЕМЕНТОВ В ПРОГРАММИРОВАНИИ
- 2.1. ВЫБОР ОПТИМАЛЬНОГО ВАРИАНТА ПРОЕКТНОГО РЕШЕНИЯ
- 2.2. ПРИМЕР ВЫБОРА ОПТИМАЛЬНОГО ВАРИАНТА ПРОГРАММНОГО РЕШЕНИЯ
- 2.3. МЕТОДЫ СИНТЕЗА ВАРИАНТОВ РЕАЛИЗАЦИЙ ПРОГРАММ
- 2.4. АНАЛИЗ ТРЕБОВАНИЙ К СИСТЕМЕ (СИСТЕМНЫЙ АНАЛИЗ) И ФОРМУЛИРОВКА ЦЕЛЕЙ
- 2.5. ПРОЕКТНАЯ ПРОЦЕДУРА ПОСТАНОВКИ ЗАДАЧИ РАЗРАБОТКИ ПРОГРАММЫ
- 2.6. ПСИХОФИЗИОЛОГИЧЕСКИЕ ОСОБЕННОСТИ ВЗАИМОДЕЙСТВИЯ ЧЕЛОВЕКА И ЭВМ
- 2.7. КЛАССИФИКАЦИЯ ТИПОВ ДИАЛОГА ПРОГРАММ
- 3.1. ОСНОВНЫЕ СВЕДЕНИЯ
- 3.2. РАННИЕ ТЕХНОЛОГИЧЕСКИЕ ПОДХОДЫ
- 3.3. КАСКАДНЫЕ ТЕХНОЛОГИЧЕСКИЕ ПОДХОДЫ
- 3.4. КАРКАСНЫЕ ТЕХНОЛОГИЧЕСКИЕ ПОДХОДЫ
- 3.5. ГЕНЕТИЧЕСКИЕ ТЕХНОЛОГИЧЕСКИЕ ПОДХОДЫ
- 3.6. ПОДХОДЫ НА ОСНОВЕ ФОРМАЛЬНЫХ ПРЕОБРАЗОВАНИЙ
- 3.7. РАННИЕ ПОДХОДЫ БЫСТРОЙ РАЗРАБОТКИ
- 3.8. АДАПТИВНЫЕ ТЕХНОЛОГИЧЕСКИЕ ПОДХОДЫ
- 3.9. ПОДХОДЫ ИССЛЕДОВАТЕЛЬСКОГО ПРОГРАММИРОВАНИЯ
- 4.1. ПОНЯТИЕ СТРУКТУРЫ ДАННЫХ ПРОГРАММ
- 4.2. ОПЕРАЦИИ НАД СТРУКТУРАМИ ДАННЫХ
- 4.3. ОБЩАЯ КЛАССИФИКАЦИЯ ЛОГИЧЕСКИХ СТРУКТУР ДАННЫХ
- 4.4. КЛАССИФИКАЦИЯ ВИДОВ ОПЕРАТИВНЫХ СТРУКТУР ДАННЫХ ПО ИХ ЛОГИЧЕСКОМУ УСТРОЙСТВУ
- 4.5. ПРОЕКТИРОВАНИЕ И ДОКУМЕНТИРОВАНИЕ ОПЕРАТИВНЫХ СТРУКТУР ДАННЫХ
- 4.6. ФАЙЛОВЫЕ СТРУКТУРЫ
- 5.1. ОБЩИЕ СВЕДЕНИЯ О ПРОЕКТНОЙ ПРОЦЕДУРЕ
- 5.2. ИСТОРИЯ ВОЗНИКНОВЕНИЯ ПРОЕКТНОЙ ПРОЦЕДУРЫ
- 5.3. ОБЩЕЕ ОПИСАНИЕ ПРОЕКТНОЙ ПРОЦЕДУРЫ
- 5.4. РЕКОМЕНДАЦИИ НАЧИНАЮЩИМ ПО СОСТАВЛЕНИЮ ОПИСАНИЙ АЛГОРИТМОВ И ЭВРОРИТМОВ
- 5.5. ПРИМЕР РАЗРАБОТКИ ОПИСАНИЯ ПРОЦЕССА «КИПЯЧЕНИЕ ВОДЫ В ЧАЙНИКЕ»
- 5.6. ПРИМЕР ОПИСАНИЯ ПРОГРАММЫ «РЕДАКТОР ТЕКСТОВ»
- 5.7. РЕФАКТОРИНГ АЛГОРИТМОВ И ЭВРОРИТМОВ
- 5.8. КОДИРОВАНИЕ ТИПОВЫХ СТРУКТУР НА ЯЗЫКАХ ПРОГРАММИРОВАНИЯ
- 5.9. МЕТОДИКА РАЗРАБОТКИ АЛГОРИТМОВ ПРОГРАММ
- 5.10. ПРИМЕР ВЫПОЛНЕНИЯ УЧЕБНОЙ РАБОТЫ «РАЗРАБОТКА АЛГОРИТМА УМНОЖЕНИЯ»
- 5.11. ПРИМЕР ПРИМЕНЕНИЯ ПРОЕКТНОЙ ПРОЦЕДУРЫ ДЛЯ КОДИРОВАНИЯ ПРОГРАММЫ ПЕЧАТИ КАЛЕНДАРЯ НА ПРИНТЕРЕ
- 6.1. ПОНЯТИЕ АРХИТЕКТУРЫ ПРОГРАММНОЙ СИСТЕМЫ
- 6.2. СИСТЕМЫ ИЗ ОТДЕЛЬНЫХ ПРОГРАММ
- 6.3. СИСТЕМЫ ИЗ ОТДЕЛЬНЫХ РЕЗИДЕНТНЫХ ПРОГРАММ
- 6.4. СИСТЕМЫ ИЗ ПРОГРАММ, ОБМЕНИВАЮЩИХСЯ ДАННЫМИ ЧЕРЕЗ ПОРТЫ
- 6.5. ПОДХОД К ПРОЕКТИРОВАНИЮ АРХИТЕКТУРЫ СИСТЕМЫ НА ОСНОВЕ АБСТРАКТНЫХ МАШИН ДЕЙКСТРЫ
- 6.6. СОМ — ТЕХНОЛОГИЯ РАЗРАБОТКИ РАЗВИВАЮЩИХСЯ И РАССРЕДОТОЧЕННЫХ КОМПЛЕКСОВ ПРОГРАММ
- 7.1. ПОНЯТИЕ СТРУКТУРЫ ПРОГРАММЫ
- 7.2. МОДУЛЬ И ОСНОВНЫЕ ПРИНЦИПЫ СТРУКТУРНОГО ПОДХОДА
- 7.3. РЕТРОСПЕКТИВНОЕ ПРОЕКТИРОВАНИЕ ДЕМОНСТРАЦИОННОЙ ПРОГРАММЫ MCALC ФИРМЫ «BORLAND INC.»
- 8.1. ИСТОРИЯ СОЗДАНИЯ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПРОГРАММИРОВАНИЯ
- 8.2. ВВЕДЕНИЕ В ОБЪЕКТНО-ОРИЕНТИРОВАННЫЙ ПОДХОД К РАЗРАБОТКЕ ПРОГРАММ
- 8.3. СРАВНИТЕЛЬНЫЙ АНАЛИЗ ТЕХНОЛОГИЙ СТРУКТУРНОГО И ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПРОГРАММИРОВАНИЯ
- 8.4. ОСНОВНЫЕ ПОНЯТИЯ ОБЪЕКТНО-ОРИЕНТИРОВАННОЙ ТЕХНОЛОГИИ
- 8.5. ОСНОВНЫЕ ПОНЯТИЯ, ИСПОЛЬЗУЕМЫЕ В ОБЪЕКТНО-ОРИЕНТИРОВАННЫХ ЯЗЫКАХ
- 8.6. ЭТАПЫ И МОДЕЛИ ОБЪЕКТНО-ОРИЕНТИРОВАННОЙ ТЕХНОЛОГИИ
- 8.7. КАКИМИ БЫВАЮТ ОБЪЕКТЫ ПО УСТРОЙСТВУ
- 8.8. ПРОЕКТНАЯ ПРОЦЕДУРА ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПРОЕКТИРОВАНИЯ ПО Б. СТРАУСТРУПУ
- 8.9. ТЕХНОЛОГИЯ ПРОЕКТИРОВАНИЯ НА ОСНОВЕ ОБЯЗАННОСТЕЙ
- 8.10. ПРИМЕР РЕТРОСПЕКТИВНОЙ РАЗРАБОТКИ ИЕРАРХИИ КЛАССОВ БИБЛИОТЕКИ ВИЗУАЛЬНЫХ КОМПОНЕНТ DELPHI И C++ BUILDER
- 8.11. АЛЬТЕРНАТИВНЫЙ ПРОЕКТ ГРАФИЧЕСКОГО ИНТЕРФЕЙСА
- 8.12. ПРОЕКТ АСУ ПРЕДПРИЯТИЯ
- 8.13. ОБЗОР ОСОБЕННОСТЕЙ ПРОЕКТОВ ПРИКЛАДНЫХ СИСТЕМ
- 8.14. ГИБРИДНЫЕ ТЕХНОЛОГИИ ПРОЕКТИРОВАНИЯ
- 9.1. ОБЩЕЕ ПОНЯТИЕ ВИЗУАЛЬНОГО ПРОГРАММИРОВАНИЯ
- 9.2. ТЕХНОЛОГИЯ ВИЗУАЛЬНОГО ПРОГРАММИРОВАНИЯ
- 10.1. ПРЕДПОСЫЛКИ ПОЯВЛЕНИЯ CASE-СРЕДСТВ
- 10.2. ОБЗОР CASE-СИСТЕМ
- 10.3. ВИЗУАЛЬНОЕ МОДЕЛИРОВАНИЕ В RATIONAL ROSE
- 10.4. ДИАГРАММЫ UML
- 10.5. ВИЗУАЛЬНОЕ МОДЕЛИРОВАНИЕ И ПРОЦЕСС РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
- 10.6. РАБОТА НАД ПРОЕКТОМ В СРЕДЕ RATIONAL ROSE
- 11.1. ОСНОВНЫЕ СВЕДЕНИЯ
- 11.2. СВОЙСТВА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
- 11.3. СВЯЗЬ ПРОЦЕССОВ ТЕСТИРОВАНИЯ С ПРОЦЕССОМ ПРОЕКТИРОВАНИЯ
- 11.4. ПОДХОДЫ К ПРОЕКТИРОВАНИЮ ТЕСТОВ
- 11.5. ПРОЕКТИРОВАНИЕ ТЕСТОВ БОЛЬШИХ ПРОГРАММ
- 11.6. КРИТЕРИИ ВЫБОРА НАИЛУЧШЕЙ СТРАТЕГИИ РЕАЛИЗАЦИИ
- 11.7. СПОСОБЫ И ВИДЫ ТЕСТИРОВАНИЯ ПОДПРОГРАММ. ПРОЕКТИРОВАНИЕ ТЕСТОВ
- 11.8. ПРОЕКТИРОВАНИЕ КОМПЛЕКСНОГО ТЕСТА
- 11.9. СРЕДСТВА АВТОМАТИЗАЦИИ ТЕСТИРОВАНИЯ
- 12.1. УПРАВЛЕНИЕ РАЗРАБОТКОЙ ПРОГРАММНЫХ СИСТЕМ
- 12.2. СТРУКТУРА УПРАВЛЕНИЯ РАЗРАБОТКОЙ ПРОГРАММНЫХ СРЕДСТВ
- 12.3. ПОДБОР КОМАНДЫ
- 12.4. МЕТОДОЛОГИЯ УПРАВЛЕНИЯ ПРОЕКТОМ
- 12.5. СОСТАВЛЯЮЩИЕ МЕТОДОЛОГИИ РАЗРАБОТКИ
- 12.6. АНАЛИЗ ПОЖЕЛАНИЙ И ТРЕБОВАНИЙ ЗАКАЗЧИКА
- 12.7. АНАЛИЗ ТРЕБОВАНИЙ К ПРОЕКТУ
- 12.8. ТРЕБОВАНИЯ ПОЛЬЗОВАТЕЛЯ
- 12.9. ТЕХНИЧЕСКОЕ ПРОЕКТИРОВАНИЕ
- 12.10. РЕАЛИЗАЦИЯ
- 12.11. СИСТЕМНОЕ ТЕСТИРОВАНИЕ
- 12.12. ПРИЕМОЧНЫЙ ТЕСТ
- 12.13. ПОСЛЕРЕАЛИЗАЦИОННЫЙ ОБЗОР
- 12.14. СОПРОВОЖДЕНИЕ ПРОГРАММ
- Приложение 1 СТАДИИ И ЭТАПЫ РАЗРАБОТКИ ПРОГРАММ ПО ГОСТ 19.102-77
- Приложение 2 ПРИМЕР ВЫПОЛНЕНИЯ УЧЕБНОГО ТЕХНИЧЕСКОГО ЗАДАНИЯ
- Приложение 3 ФОНД ЭВРИСТИЧЕСКИХ ПРИЕМОВ ПРОЕКТИРОВАНИЯ ПРОГРАММ
- Приложение 4 ЭЛЕМЕНТЫ ЯЗЫКА OBJECT PASCAL
- Приложение 5 ОСНОВНЫЕ ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ
- ЛИТЕРАТУРА
- Лучшее в рейтинге
- 67 Блог на миллион долларов
- 59 Сделай свой компьютер стабильнее и быстрее: Что Майкрософт забыла вам сказать
- 50 Идиомы и стили С++
- 49 О чём не пишут в книгах по Delphi
- 48 ПАКЕТЫ ПРОГРАММ Требования к качеству и тестирование
- 47 Создаем порт для FreeBSD своими руками. Часть I
- 46 Базовые алгоритмы Qt 4 (Qt 4’s Generic Algorithms)
- 45 Настоящий профессионал и настоящий ламер
- 44 ДЕЙВ БАРРИ В КИБЕРПРОСТРАНСТВЕ
- 43 FictionBook Editor V 2.66 Руководство