
Ответы на вопросы к экзамену по Методам Программирования
.pdf
2. |
Анализ требований к |
+ |
+ |
|
|
|
|
|
|
системе. |
|
|
|
|
|
|
|
3. |
Проектирование |
|
+ |
|
|
|
|
|
|
архитектурной |
|
|
|
|
|
|
|
|
системы. |
|
|
|
|
|
|
|
4. |
Анализ требований к |
+ |
+ |
|
|
|
|
|
|
ПО. |
|
|
|
|
|
|
|
5. |
Проектирование |
|
+ |
|
|
|
|
|
|
архитектуры ПО. |
|
|
|
|
|
|
|
6. |
Детальное |
|
+ |
|
|
|
|
|
|
проектирование ПО. |
|
|
|
|
|
|
|
7. |
Кодирование и |
|
|
+ |
|
|
|
|
|
тестирование. |
|
|
|
|
|
|
|
8. |
Интеграция ПО. |
|
|
+ |
|
|
|
|
|
|
|
|
|
|
|
|
|
9. |
Квалификационное |
|
|
+ |
+ |
|
|
|
|
тестирование. |
|
|
|
|
|
|
|
10. |
Интеграция системы. |
|
|
+ |
|
|
|
|
|
|
|
|
|
|
|
|
|
11. |
Квалификационное |
|
|
+ |
+ |
|
|
|
|
тестирование |
|
|
|
|
|
|
|
|
системы. |
|
|
|
|
|
|
|
12. |
Установка ПО. |
|
|
|
|
+ |
|
|
|
|
|
|
|
|
|
|
|
13. |
Приемка. |
|
|
|
|
+ |
|
|
|
|
|
|
|
|
|
|
|
Дополнительные процессы.
18. Каковы наиболее распространенные модели ЖЦ ПО? В чѐм состоят их
преимущества и недостатки?
Модель жизненного цикла: каскадная модель.
Все стадии выполняются строго последовательно.
Каждая стадия завершается законченным набором проектной документации.
Переход на следующую стадию выполняется после завершения текущей стадии, не предполагается возврат к предыдущим стадиям.
Но это не всегда возможно.

Успешно такой подход применяется для создания программной системы, для которой можно точно определить требования (они заранее известны).
При каскадной модели силы направляют на поиск оптимальных требований (используется в системе реального разделения времени).
Спиральная модель жизненного цикла.
o Основывается на использовании метода «Прототипов».
oПрототип – действующий программный компонент, реализующий отдельные функции и интерфейсы разрабатываемого программного обеспечения.
o Разработка состоит из повторения стадий -> спиральная.
Преимущества:
-Устранение необходимости полного и точного определения требований к системе.
-На каждом витке спирали прототип передается пользователю (необходима предварительная оценка).
В анализе исключаются определения целей, ограничение исходных требований.
В проектировании включаются идентификация и оценка расходов.
В реализацию включается тестирование.
Сложно определить переходы между стадиями (основная проблема – определить этот момент). Эта проблема решается жестким графиком.
19.В чем состоит быстрая разработка приложений?
I. Проектирование по RAD.
-Пользователи под руководством разработчиков участвуют в технологическом проектировании.
-Детально рассматриваются все процессы системы. Для каждого процесса создаются частичные прототипы (экранная форма, диалог, отчет).
-Устанавливаются требования к разграничению доступа к данным .
-Определяется состав необходимой документации.
-Определяется количество функциональных точек в системе. - Система делится на подсистемы.

Функциональная точка – одно из:
1)Входные элементы или электронная форма.
2)Отчет или выходной элемент.
3)Вопрос (с) – Ответ (n).
4)Лог-файл или логически связанная запись.
5)Совокупность записей переданных/полученных от программного компонента /системы приложения.
20.Каковы особенности тестирования ПО при ООП?
Особенности тестирования при ООП.
Тестирование наследования.
Тестирование полиморфизма.
Если в базовом классе тестируется метод, то в производном классе он тестируется повторно.
Полнота(покрытие кода)тестирования оценивается долей тестируемых элементов(100%- редко, 85%- обычно) структурном тестировании.
Функциональное тестирование – известны спецификации, нет информации о структуре (ветвях, путях и т.д.).
Заранее закладывается невозможность полного покрытия.
21.Каковы методы разработки функциональных тестов?
1) Эквивалентные разбиения – все возможное пространство тестовых данных
разбивается на классы эквивалентности.
Для каждого класса выделяются представители, которые используются для составления тестов.
1.Если входное значение имеет вид чисел. x Є *10.0….999.0+
Верный класс: 10 <= x<= 999. Классы ошибки: x>999
x<10.
2.Если входное значение имеет вид условия.
Образуется один класс (входных значений) выполнено условие и 2 класса с нарушением.
3.Если входное значение состоит из множества значений, обработка которых требует различную реализацию (алгоритм).
Пример: bmp, jpeg, gif.
Проверяется правильность обработки алгоритма каждого из трех файлов.При txt выдается ошибка.
2)Граничные тесты. x Є *-1, 1]
Проверяется: -1; +1; -1,01;+1,01.
3)Входной параметр принимает дискретные значения. 1,2…..256.

Тест с проверкой граничных условий и выхода за границы: 0; 256.
4)Если входные и выходные значения упорядочены, то анализируется первый и последний элементы.
Анализ причинно-следственных связей.
5)Предположение об ошибке.
22.Как определяется надежность программ?
Надежность программ.
-Отсутствие отказа.
-Надежность задается в проекте и проверяется тестированием.
Оценка:
1)Отсутствие отказа (возникновение внештатной ситуации).
2)Количество ошибок в программе.
3)Среднее время безотказной работы.
4)Коэффициент готовности.
5)Интенсивность отказов (среднее число отказов в единицу времени).
При определении этих параметров предполагается, что отказы образуют простейший поток случайных событий: редки, вероятность константа, независимы. Распределение Пуассона: P(t)= − .
λ – интенсивность отказов, [час-1].
E(P(t))=1 – мат. ожидание, время безотказной работы.
Время безотказной работы:
1.Электромеханические 102 - 103.
2.Электрическая аппаратура 103 – 104.
3.БИС 106 – 108.
4.ПО 101 – 103.
Методы выявления количества возможных ошибок:
1)Метод биологии.
Вносятся специальные ошибки в программу. При тестировании выявляются n невнесенных ошибок и v – внесенных. S – это количество ошибок, которые были внесены.
Тогда можно читать, что количество оставшихся невнесенных ошибок:
N=
Второй этап: снова вносится S ошибок и тестируется, пока все S ошибок не будет выявлено.
Вероятность того, что гипотеза может быть принята:
P{k>=n}=1, при n>k. P{k>=n}= + +1, приk>=n.
k – гипотеза об оставшихся ошибках.

n – ошибки выявленные помимо S.
2) Метод Руднера.
Тестирование проводится двумя командами независимо друг от друга.
Среди выявленных ошибок есть общие - |
n. |
||
|
1 2 |
||
Тогда число не выявленных ошибок: N= |
|
|
. |
|
n |
n1, n2 – число ошибок, выявленных соответственно первой и второй программой.
Для обоснования этой формулы используется гипергеометрическое распределение и метод максимума правдоподобия.
3)Метод, который использует «Motorola».
Оценивают надежность – среднее число ошибок на 1000 строк кода.
T = f(N, n, t) - время окончательного тестирования без отказов.
N– допустимое число ошибок в коде.
t – время , потраченное на выявление n ошибок.
n – общее число ошибок, обнаруженных при тестировании. Тестирование ограничено следующим образом:
Если нет ошибок, то тестирование закончено, и оно прекращается.
Если выявлена очередная ошибка, то n увеличивается на единицу, а время тестирования t увеличивается на интервал t’, на котором выявляется ошибка, то есть меняется и T.
T получается на основе одной из оценок λ(t), которая интерполирует динамику отладки (фиксирует в журнале отладки интервалы t’).
Одна из таких моделей: модель Джелинского – Моранды. Принципы:
1.Интенсивность отказов пропорциональна текущему оставшемуся числу ошибок.
R(t) ~ N-n.
2.Все ошибки выявляются с равной вероятностью и независимы.
3.При исправлении ошибок не вносятся новые ошибки.
4.На интервале времени обнаружения ошибок интенсивность постоянна.
R(t)= const.

t1, t2 – моменты выполнения ошибок.
5.R(t) совпадает с параметром
λ: R(t) ≈ λ(t)
Отличие: после завершения тестирования λ(t) остается константой.
Вводится следующая модель:
R(t)= K*(B - i), где
i– число обнаруженных ошибок к моменту t. B – неизвестное число исходных ошибок.
K –коэффициент пропорциональности, помогает лучше настроить модель.
Моменты времени:
Введем x, такое что: xi= ti+1 - ti, где ti+1,ti - это моменты обнаружения ошибок. xi имеет стационарное распределение.
Можно перейти к такой модели:
R(xi) = exp(-K*(B- i)* xi)
Зная xiможно определить параметры K и B, используя метод максимума правдоподобия. Модификация этого метода ( более упрощенная модель).
Рассматривается уравнение:
( ) |
= |
−( ) |
|
|||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
( ) |
= R(t) |
( ) |
= -K*R(t) |
|||
|
|
|||||
|
|
При граничных условияхN(0)=0 и R(0) = K*B:
R(t) = K(B – N(t))
R(t) = K*B*exp(-Kt)
Вводятсяпараметры: a = ln(K*B), b = -k, тогдаR(t) = exp(a + bt).
Логарифмируем зависимость и, переходя к дискретному времени, получаем систему уравнений вида:
Ln (R(t)) = a + bti, i = 1,…,n.
Решается методом наименьших квадратов, находятся a и b, из которых извлекаются параметры K и B.
23. Какими документами регламентируется управление качеством ПО?
Управление качеством программ:
ISO : 9001
Называется CMM-SEI – модель зрелости производителей программ. Модель делится на 5 уровней производителей по их зрелости:
1)Начальный (спонтанный характер, успех зависит от энтузиазма разработчиков).
2)Повторяющийся (есть основные процессы управления разработкой, позволяет отслеживать характеристики разработки и график работы.Производитель повторяет успешный проект).
3)Определенный (на предприятии существуют стандарты, и все проекты используют утвержденные методы разработки и поддержки программных систем, переданных в эксплуатацию).
4)Управляемый (существуют способы детального измерения качества процесса разработки и программного продукта.Количественные характеристики продукта, количественные характеристики процесса разработки хорошо изучены и легко управляемы).
5)Оптимизированный (существует непрерывное улучшение процесса разработки, основанное на количественных характеристиках и на внедрении новых технологий).
Сертификация на четырех уровнях (2-5).
Организации должны разработать и внедрить ключевые процессы: Второй уровень:
Управление версиями.
Проверка качества программ.
Управление контрактами.
Контроль программных проектов.
Планирование проектов.
Управление заданиями.
Третий уровень:
Рецензирование и обсуждение результатов.
Координация между командами разработчиков.
Повышение квалификации.
Определение организации команд.
Четвертый уровень:
Управления качеством разработки.
Результаты управления должны приводить к оценимым эффектам.
Пятый уровень:
Управление изменениями процессов.
Управление изменениями технологий.
Процесс предотвращения появления ошибок.
Оценка показателей (до 6 баллов):
1)Заинтересованность руководства.
2)Широта применения.
3)Успех применения процесса.
-70% всех производителей работают на первом уровне.
-несколько тысяч на 3, 4 уровнях.
Стандарт ISO 9001 делится на части:
I.Требование к управлению.
II.Требование к контролю продукции.
III.Требование к процессу разработки.

4)Контроль версий за приобретаемыми продуктами, управление продукцией, не соответствующей заявленным качествам.
5)Построение и документирование процесса разработки.
24.Каковы основные принципы экстремального программирования?
Экстремальное программирование.
Организация работы над проектом (быстрая разработки приложений). В основном предназначено для небольших приложений, частей проектов.
Принципы:
1)Работа с заказчиком (непосредственно принимает участие в планировании реализации и написании сценариев).
2)Используется метафоры для описания сложных процессов (упрощает взаимодействие с заказчиком).
3)Планирование (горизонт планирования - приблизительно 2 недели). Заказчик участвует в планировании:
Приоритеты задач.
Содержание версий.
Дата выпуска версий.
4)Короткие совещания (ежедневные). Дискуссии отсутствуют. Они в рабочем порядке.
5)Сначала пишутся тесты. Это полезно, так как последовательно проверяется выполнение всех требования к системе. Возможно точно определить момент завершения работы.
6)Упрощение интерфейсов и кода.
7)Программирование в паре. Каждое задание выполняется двумя программистами. Первый: пишет тесты, затем тексты программ, перерабатывает систему.
Второй: наблюдает, ищет ошибки, предлагает свои варианты решения.
8)Разработка программы согласно стандартам.
9)Коллективное владение кодом.
10)Постоянное интегрирование системы.
11)Переработка – изменение в алгоритме не меняет интерфейс.
12)Частый выпуск версий.
13)40 –часовая рабочая неделя.
14)Изменения приветствуются.
25.В чем состоит документирование ПО?
ГОСТ 34.201-89: Устанавливается соответствие документов и стадий разработки. 34.601-90: Определяет стадии и этапы создания автоматизированных систем. 34.602-89: ТЗ на создание автоматизированной системы (актуален).
Разделы:
1.Общие сведения.
2.Название и цели создания (развития).
3.Характеристика объекта автоматизации.
4.Требования к системе.
5.Состав и содержание работ по созданию системы.
6.Порядок контроля и приемки системы.
7.Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие.
8.Требование к документированию.
9.Источники разработки.
Проверка выполнения работы может производиться по ТЗ специалистом не из области информационных технологий.
Руководство пользователя.
Регламентируется: РД 50-34.698-90 – требование к содержанию документации (РД – руководящий документ).
Разделы:
1.Назначение программы.
2.Установка и условие выполнения программы.
3.Выполнение программы
3.1.Запуск программы на выполнение
3.2.Описание интерфейса
3.3.Описание контрольного примера
3.4.Завершение работы программы
3.5.Использование результата
4.Особые ситуации, сообщение пользователям.