3 методика выполнения контрольной работы

Кемеровский институт (филиал)
ГОУ ВПО «РГТЭУ»
Кафедра вычислительной техники и информационных технологий
Н.А. Ткаченко
РАЗРАБОТКА И СТАНДАРТИЗАЦИЯ
ПРОГРАММНЫХ СРЕДСТВ И
ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ
Методические указания по выполнению контрольных работ
для студентов специальности 080801
«Прикладная информатика (в экономике)» заочной формы обучения
Кемерово 2009
УДК 681.3.06(075.8)
ББК 32.973.26-018.2
М52
Утверждено на заседании кафедры 22.10.2009 г., протокол
№3
К52
Рекомендовано к печати учебнометодической комиссией по математическим и информационным дисциплинам 6 ноября 2009 г.,
протокол №3
Ткаченко Н.А.
Разработка и стандартизация программных средств и информационных технологий [Текст]: Методические указания по
выполнению контрольных работ для студентов специальности
080801 «Прикладная информатика в экономике» заочной формы
обучения / Н.А. Ткаченко – Кемерово: Кемеровский институт
(филиал) ГОУ ВПО «РГТЭУ», 2009. – 54 с.: ил.
Текст дан в авторской редакции.
Методические указания составлены в соответствии с требованиями Государственного образовательного стандарта (стандарт
ЕН.Ф.05) высшего профессионального образования, содержат краткую теорию предмета, устанавливает требования к содержанию контрольной работы, включает варианты задания, методические указания
по их выполнению, пример выполнения контрольной работы, список
рекомендуемой литературы.
УДК 681.3.06(075.8)
ББК 32.973.26-018.2
© Кемеровский институт (филиал)
ГОУ ВПО «РГТЭУ», 2009
Ткаченко Н.А., 2009
2
СОДЕРЖАНИЕ
1 МЕТОДИКИ ИЗМЕРЕНИЯ ПРОГРАММНОГО ПРОДУКТА И
ПРОЦЕССА ЕГО РАЗРАБОТКИ .............................................................. 4
1.1 Конструктивная модель стоимости…………………………...4
1.2 Модель композиции приложения……………………………..5
1.3 Модель раннего этапа проектирования………………………7
1.4 Модель этапа постархитектуры……………………………...10
2 ТЕМАТИКА КОНТРОЛЬНЫХ РАБОТ .............................................. 15
2.1 Выбор варианта……………………………………………….15
2.2 Задание №1. Теоретический вопрос…………………………15
2.3 Задание №2. Предпроектный анализ предметной области...16
2.4 Задание№ 3. Сценарии оценки стоимости разработки…….17
2.5 Задание №4. Тестирование программы…..…………………29
3 МЕТОДИКА ВЫПОЛНЕНИЯ КОНТРОЛЬНОЙ РАБОТЫ.............. 38
3.1 Пример выполнения задания 2………………………………38
3.2 Пример выполнения задания 3………………………………46
3.3 Пример выполнения задания 4………………………………47
4 СПИСОК ЛИТЕРАТУРЫ…………………………………………….53
3
1 МЕТОДИКИ ИЗМЕРЕНИЯ ПРОГРАММНОГО ПРОДУКТА И
ПРОЦЕССА ЕГО РАЗРАБОТКИ
1.1 Конструктивная модель стоимости
В данной модели для вывода формул использовался статистический подход — учитывались реальные результаты огромного количества проектов. Автор оригинальной модели — Барри Боэм (1981) —
дал ей название СОСОМО 81 (Constructive Cost Model) и ввел в ее состав три разные по сложности статистические подмодели .
Иерархию подмоделей Боэма (версии 1981 года) образуют:
 базисная СОСОМО — статическая модель, вычисляет затраты разработки и ее стоимость как функцию размера программы;
 промежуточная СОСОМО — дополнительно учитывает атрибуты
стоимости, включающие основные оценки продукта, аппаратуры, персонала и проектной среды;
 усовершенствованная СОСОМО — объединяет все характеристики
промежуточной модели, дополнительно учитывает влияние всех атрибутов стоимости на каждый этап процесса разработки ПО (анализ,
проектирование, кодирование, тестирование и т. д.).
Подмодели СОСОМО 81 могут применяться к трем типам программных проектов. По терминологии Боэма, их образуют:
 распространенный тип — небольшие программные проекты, над
которыми работает небольшая группа разработчиков с хорошим стажем работы, устанавливаются мягкие требования к проекту;
 полунезависимый тип — средний по размеру проект, выполняется
группой разработчиков с разным опытом, устанавливаются как мягкие, так и жесткие требования к проекту;
 встроенный тип — программный проект разрабатывается в условиях жестких аппаратных, программных и вычислительных ограничений.
В 1995 году Боэм ввел более совершенную модель СОСОМО II,
ориентированную на применение в программной инженерии XXI века. В состав СОСОМО II входят:
 модель композиции приложения;
 модель раннего этапа проектирования;
 модель этапа постархитектуры.
4
Для описания моделей СОСОМО II требуется информация о
размере программного продукта.
1.2 Модель композиции приложения
Модель композиции используется на ранней стадии конструирования ПО, когда:
 рассматривается макетирование пользовательских интерфейсов;
 обсуждается взаимодействие ПО и компьютерной системы;
 оценивается производительность;
 определяется степень зрелости технологии.
Модель композиции приложения ориентирована на применение
объектных указателей. Объектный указатель — средство косвенного
измерения ПО, для его расчета определяется количество экранов (как
элементов пользовательского интерфейса), отчетов и компонентов,
требуемых для построения приложения. Как показано в табл. 1.1, каждый объектный экземпляр (экран, отчет) относят к одному из трех
уровней сложности. Здесь места подстановки измеренных и вычисленных значений отмечены прямоугольниками (прямоугольник играет
роль метки-заполнителя). В свою очередь, сложность является функцией от параметров клиентских и серверных таблиц данных (см. табл.
1.2 и 1.3), которые требуются для генерации экрана и отчета, а также
от количества представлений и секций, входящих в экран или отчет.
Таблица 1.1. Оценка количества объектных указателей
Тип объекта
Количество
Экран
0
Отчет
0
3GL компонент 0
Объектные указатели
Вес
Итого
Простой
х1
х2
Средний Сложный
х2
х3
х5
х8
х10
=0
=0
=0
=0
Таблица 1.2. Оценка сложности экрана
Экраны
Количество
ставлений
Количество серверных (срв) и клиентских (клт)
таблиц данных
пред- Всего < 4
Всего < 8
Всего > 8
(< 2 срв, <3клт) (2-3 срв, 3-5 клт) (>3срв, >5клт)
5
Экраны
<3
3-7
>8
Количество серверных (срв) и клиентских (клт)
таблиц данных
Простой
Простой
Средний
Простой
Средний
Сложный
Средний
Сложный
Сложный
Таблица 1.3. Оценка сложности отчета
Отчеты
Количество
представлений
0 или 1
2 или 3
>4
Количество серверных (срв) и клиентских (клт)
таблиц данных
Всего < 4
Всего < 8
Всего > 8
(< 2 срв, < 3 клт) (2-3 срв, 3-5 клт) (>3срв, > 5 клт)
Простой
Простой
Средний
Простой
Средний
Сложный
Средний
Сложный
Сложный
После определения сложности количество экранов, отчетов и
компонентов взвешивается в соответствии с табл. 1.1. Количество
объектных указателей определяется перемножением исходного числа
объектных экземпляров на весовые коэффициенты и последующим
суммированием промежуточных результатов.
Для учета реальных условий разработки вычисляется процент
повторного использования программных компонентов %REUSE и
определяется количество новых объектных указателей NOP:
NOP = (Объектные указатели) х [(100 - %REUSE) /100].
Для оценки затрат, основанной на величине NOP, надо знать
скорость разработки продукта PROD. Эту скорость определяют по
табл. 1.4, учитывающей уровень опытности разработчиков и зрелость
среды разработки.
Проектные затраты оцениваются по формуле
ЗАТРАТЫ = NOP /PROD [чел.-мес], где PROD — производительность
разработки, выраженная в терминах объектных указателей.
Таблица 1.4. Оценка скорости разработки
Опытность/ возможности Зрелость/
возможности
разработчика
среды разработки
Очень низкая
Очень низкая
Низкая
Низкая
Номинальная
Номинальная
Высокая
Высокая
6
PROD
4
7
13
25
Опытность/ возможности Зрелость/
возможности
разработчика
среды разработки
Очень высокая
Очень высокая
PROD
50
В более развитых моделях дополнительно учитывается множество масштабных факторов, формирователей затрат, процедур поправок.
1.3 Модель раннего этапа проектирования
Модель раннего этапа проектирования используется в период,
когда стабилизируются требования и определяется базисная программная архитектура.
Основное уравнение этой модели имеет следующий вид:
ЗАТРАТЫ = А х РАЗМЕРв х Ме + ЗАТРАТЫаuto[чел.-мес], где:
 масштабный коэффициент А = 2,5;
 показатель В отражает нелинейную зависимость затрат от размера
проекта (размер системы РАЗМЕР выражается в тысячах LOC- это
количество срок в программном коде);
 множитель поправки Мe зависит от 7 формирователей затрат, характеризующих продукт, процесс и персонал;
 слагаемое ЗАТРАТЫаuto отражает затраты на автоматически генерируемый программный код.
Значение показателя степени В изменяется в диапазоне 1,01...
1,26, зависит от пяти масштабных факторов Wi и вычисляется по формуле
5
B  1,01  0,01Wi .
i 1
Общая характеристика масштабных факторов приведена в табл.
1.5, а табл. 1.20 позволяет определить оценки этих факторов. Оценки
принимают 6 значений: от очень низкой (5) до сверхвысокой (0).
Таблица 1.5. Характеристика масштабных факторов
Масштабный фактор (Wi) Пояснение
Предсказуемость PREC
Отражает предыдущий опыт организации в
реализации проектов этого типа. Очень низкий
означает отсутствие опыта. Сверхвысокий
означает, что организация полностью знакома с
этой прикладной областью
7
Масштабный фактор (Wi) Пояснение
Гибкость разработки FLEX Отражает степень гибкости процесса разработки. Очень низкий означает, что используется
заданный процесс. Сверхвысокий означает, что
клиент установил только общие цели
Разрешение
архитектуры Отражает степень выполняемого анализа риска.
/риска RESL
Очень низкий означает малый анализ. Сверхвысокий означает полный и сквозной анализ
риска
Связность группы TEAM
Отражает, насколько хорошо разработчики
группы знают друг друга и насколько удачно
они совместно работают. Очень низкий означает очень трудные взаимодействия. Сверхвысокий, означает интегрированную группу, без
проблем взаимодействия
Означает зрелость процесса в организации.
Зрелость процесса РМАТ
Вычисление этого фактора может выполняться
по вопроснику СММ
В качестве иллюстрации рассмотрим компанию, которая берет
проект в малознакомой проблемной области. Положим, что заказчик
не определил используемый процесс разработки и не допускает выделения времени на всесторонний анализ риска. Для реализации этой
программной системы нужно создать новую группу разработчиков.
Компания имеет возможности, соответствующие 2-му уровню зрелости согласно модели СММ. Возможны следующие значения масштабных факторов:
 предсказуемость. Это новый проект для компании — значение Низкий (4);
 гибкость разработки. Заказчик требует некоторого согласования —
значение Очень высокий (1);
 разрешение архитектуры/риска. Не выполняется анализ риска, как
следствие, малое разрешение риска — значение Очень низкий (5);
 связность группы. Новая группа, нет информации — значение Номинальный (3);
 зрелость процесса. Имеет место некоторое управление процессом значение Номинальный (3).
8
Таблица 1.6. Оценка масштабных факторов
Фактор Очень
(Wi)
низкий 5
PRЕС Полностью
непредсказуемый
проект
FLEX
Точный,
строгий
процесс
разработки
Низкий 4
Номинальный 3
Главным
Отчасти
образом
непредсканепредска- зуемый
зуемый
Редкое
Некоторое
расслаблен расслаблен
ие в работе ие в работе
RESL
Малое
(20%)
Некоторое Частое
(40%)
(60%)
TEAM
Очень
трудное
взаимодействие
Достаточ- Среднее
но трудное взаимовзаимодействие
действие
PREC
Полностью
непредсказуемый
проект
РМАТ
Высокий 2 Очень
высокий 1
Большей
В значичастью
тельной
знакомый степени
знакомый
Большей
Некоторое
частью
согласовани
согласован е процесса
ный
процесс
Большей
Почти всечастью
гда (90%)
(75%)
Главным
Высокая
образом
кооперативкоопераность
тивность
Сверхвысокий 0
Полностью
знакомый
Заказчик
определил
только
общие цели
Полное
(100%)
Безукоризненное взаимодействие
В значи- Отчасти
Большей
В
значи- Полностью
тельной
непредска- частью
тельной
знакомый
степени
зуемый
знакомый степени
непредсказнакомый
зуемый
Взвешенное среднее значение от количества ответов «Yes» на вопросник
СММ Maturity
Сумма этих значений равна 16, поэтому конечное значение степени В= 1,17. Вернемся к обсуждению основного уравнения модели
раннего этапа проектирования. Множитель поправки Мe зависит от
набора формирователей затрат, перечисленных в табл. 1.7.
Для каждого формирователя затрат определяется оценка (по 6балльной шкале), где 1 соответствует очень низкому значению, а 6 —
сверхвысокому значению. На основе оценки для каждого формирователя по таблице Боэма определяется множитель затрат EMi Перемножение всех множителей затрат формирует множитель поправки:
7
М e   EM i .
i 1
Слагаемое 3ATPATbIauto используется, если некоторый процент
программного кода генерируется автоматически. Поскольку производительность такой работы значительно выше, чем при ручной разра9
ботке кода, требуемые затраты вычисляются отдельно, по следующей
формуле:
ЗАТРАТЫаuto = (КALOC x (AT /100)) / ATPROD, где:
 KALOC — количество строк автоматически генерируемого кода (в
тысячах строк);
 AT — процент автоматически генерируемого кода (от всего кода
системы);
 ATPROD — производительность автоматической генерации кода.
Сомножитель AT в этой формуле позволяет учесть затраты на
организацию взаимодействия автоматически генерируемого кода с
оставшейся частью системы.
Далее затраты на автоматическую генерацию добавляются к затратам, вычисленным для кода, разработанного вручную.
Таблица 1.7. Формирователи затрат для раннего этапа проектирования
Обозначение
PERS
RCPX
RUSE
PDIF
PREX
FСIL
SCED
Название
Возможности персонала (Personnel Capability)
Надежность и сложность продукта (Product Reliability
and Complexity)
Требуемое повторное использование (Required Reuse)
Трудность платформы (Platform Difficulty)
Опытность персонала (Personnel Experience)
Средства поддержки (Facilities)
График (Schedule)
1.4 Модель этапа постархитектуры
Модель этапа постархитектуры используется в период, когда
уже сформирована архитектура и выполняется дальнейшая разработка
программного продукта.
Основное уравнение постархитектурной модели является развитием уравнения предыдущей модели и имеет следующий вид:
ЗАТРАТЫ = А х К~req х РАЗМЕРB х Мр +3ATPATЫauto [чел.-мес], где
 коэффициент К~req учитывает возможные изменения в требованиях;
 показатель В отражает нелинейную зависимость затрат от размера
проекта (размер выражается в KLOC), вычисляется так же, как и в
10
предыдущей модели;
 в размере проекта различают две составляющие — новый код и повторно используемый код;
 множитель поправки Мр зависит от 17 факторов затрат, характеризующих продукт, аппаратуру, персонал и проект.
Изменчивость требований приводит к повторной работе, требуемой для учета предлагаемых изменений, оценка их влияния выполняется по формуле
К~req =l + (BRAK/100),
где BRAK — процент кода, отброшенного (модифицированного) из-за изменения требований.
Размер проекта и продукта определяют по выражению
РАЗМЕР = PA3MEPnew + PA3MEPreuse [KLOC], где
 PA3MEPnew — размер нового (создаваемого) программного кода;
 PA3MEPreuse — размер повторно используемого программного
кода.
Формула для расчета размера повторно используемого кода записывается следующим образом:
PA3MEPreuse =KASLOC x ((100 - AT)/ 100) x (AA + SU + 0,4 DM + 0,3
CM + 0,3 IM) /100, где
 KASLOC — количество строк повторно используемого кода, который должен быть модифицирован (в тысячах строк);
 AT — процент автоматически генерируемого кода;
 DM — процент модифицируемых проектных моделей;
 CM — процент модифицируемого программного кода;
 IM — процент затрат на интеграцию, требуемых для подключения
повторно используемого ПО;
 SU — фактор, основанный на стоимости понимания добавляемого
ПО; изменяется от 50 (для сложного неструктурированного кода) до
10 (для хорошо написанного объектно-ориентированного кода);
 АА — фактор, который отражает стоимость решения о том, может
ли ПО быть повторно используемым; зависит от размера требуемого
тестирования и оценивания (величина изменяется от 0 до 8).
Правила выбора этих параметров приведены в руководстве по
СОСОМО II.
Для определения множителя поправки Мр основного уравнения
используют 17 факторов затрат, которые могут быть разбиты на 4 категории. Перечислим факторы затрат, сгруппировав их по категориям.
Факторы продукта:
11
1) требуемая надежность ПО — RELY;
2) размер базы данных — DATA;
3) сложность продукта — CPLX;
4) требуемая повторная используемость — RUSE;
5) документирование требований жизненного цикла — DOCU.
Факторы платформы (виртуальной машины):
6) ограничения времени выполнения — TIME;
7) ограничения оперативной памяти — STOR;
8) изменчивость платформы — PVOL.
Факторы персонала:
9) возможности аналитика — АСАР;
10) возможности программиста — РСАР;
11) опыт работы с приложением — АЕХР;
12) опыт работы с платформой — РЕХР;
13) опыт работы с языком и утилитами — LTEX;
14) непрерывность персонала — PCON.
Факторы проекта:
15) использование программных утилит — TOOL;
16) мультисетевая разработка — SITE;
17) требуемый график разработки — SCED.
Таблица 1.8 Числовые значения множителей затрат
Фактор Очень
низкий
RELY Легкое
беспокойство
0,75
DATA
CPLX
RUSE
0,75
Низкий
Номинальный
Низкая, лег- Умеренная,
ко восста- легко восстанавливаенавливаемые
мые потери потери 1,00
0,88
байты
10  D/P<100
БД/LOС
1,00
прогр. <10
0,93
0,88
1,00
Высокий Очень
Сверхвывысокий сокий
Высокая, Риск для
финансо- человечевые поте- ской жизри 1,15
ни 1,39
1,15
1,30
1,66
Нет
0,91
На уровне
программы
1,14
На уровне
семейства
продуктов
1,29
На уровне
нескольких
семейств
продуктов
1,49
На уровне
проекта
1,00
12
100  D/P D/P
< <1000  1000
1,09
1,19
Фактор Очень
низкий
DOCU Многие
требования
жизненного
цикла
не учтены
0,89
Низкий
TIME
Используется
< 50%
возможного
времени
выполнения
1,00
Используется
< 50%
доступной
памяти
1,00
Значитель- Значительны
ные измене- через 6 мес.;
ния
незначительчерез 1 год; ные через 2
незначитель недели
ные
1,00
через 1 мес.
0,87
STOR
PVOL
ACAP
PCAP
PCON
AEXP
PEXP
LTEX
15%
1,50
15%
1,37
48%/год
1,24
≤2 месяцев
1,22
≤ 2 месяцев
1,25
≤2 месяцев
1,22
Номинальный
Некоторые Оптимизиротребования важизненного ны
цикла
к требованиям
не учтены
жизненного
0,95
цикла
1,00
Высокий Очень
высокий
Избыточ- Очень
ны
избыточны
по
по
отноотноше- шению
нию к
к требоватребова- ниям
ниям
жизненножизненго
ного
цикла
цикла
1,13
1,06
70%
85%
1,11
1,31
Сверхвысокий
70%
1,06
85%
1,21
95%
1,57
Значтельные
через
2
нед.
незначительные
через 2 дня
1,30
0,81
6 лет
0,84
35%
1,22
35%
1,16
24%/год
1,10
6 месяцев
1,10
6 месяцев
55%
1,00
55%
1,00
12%/год
1,00
1 год
1,00
1 год
Значительные
через 2
мес.; незначи
тельные
через 1
неделю
1,15
75%
0,83
75%
0,87
6%/год
0,92
3 года
0,89
Згода
1,12
6 месяцев
1,10
1,00
1 год
1,00
0,88
3 года
0,91
13
90%
0,67
90%
0,74
3%/год
0,84
6 лет
0,81
6 лет
95%
1,67
Фактор Очень
низкий
TOOL Редактирование,
кодирование,
отладка
1,24
Низкий
Простая
входная,
выходная
CASE
утилита,
малая
интеграция
1,12
SITE
коммуникации
Один те- Индивидулефон,
альные
почта
телефоны,
1,25
FAX
1,10
SCED
75%
от номин.
1,29
85%
1,10
Номинальный
Базовые
утилиты
жизненного
цикла,
умеренная
интеграция
1,00
Высокий Очень
высокий
Развитые Развитые
утилиты утилиты
жизненжизненноного
го цикла,
цикла,
хорошая
умеренная интеграция
интегра- 0,72
ция
0,86
Узкополосный Широко- Широкоe-mail
полое
полосные
1,00
коммуни- коммуникакации,
ции
иногда
0,92
видеоконференции
0,84
100%
1,00
130%
1,00
Сверхвысокий
Интерактивные
мультимедиа
0,78
160%
1,00
Для каждого фактора определяется оценка (по 6-балльной шкале). На основе оценки для каждого фактора по таблице Боэма определяется множитель затрат ЕМi. Перемножение всех множителей затрат
дает множитель поправки пост-архитектурной модели:
17
M p   EM i .
i 1
Значение Мр отражает реальные условия выполнения программного проекта и позволяет троекратно увеличить (уменьшить) начальную оценку затрат.
От оценки затрат легко перейти к стоимости проекта. Переход
выполняют по формуле:
СТОИМОСТЬ = ЗАТРАТЫ х РАБ_ КОЭФ, где среднее значение рабочего коэффициента составляет $15 000 за человеко-месяц.
После определения затрат и стоимости можно оценить длительность разработки. Модель СОСОМО II содержит уравнение для оценки календарного времени TDEV, требуемого для выполнения проекта.
Для моделей всех уровней справедливо:
Длительность (TDEV) = [3,0 х (ЗАТРАТЫ)(0,33+0,2(B-1,01))] х
SCEDPercentage/100 [мес], где
14
 В — ранее рассчитанный показатель степени;
 SCEDPercentage — процент увеличения (уменьшения) номинального графика.
Если нужно определить номинальный график, то принимается
SCEDPercentage =100 и правый сомножитель в уравнении обращается
в единицу. Следует отметить, что СОСОМО II ограничивает диапазон
уплотнения/растягивания графика (от 75 до 160%). Причина проста —
если планируемый график существенно отличается от номинального,
это означает внесение в проект высокого риска. СОСОМО II — авторитетная и многоплановая модель, позволяющая решать самые разнообразные задачи управления программным проектом.
2 ТЕМАТИКА КОНТРОЛЬНЫХ РАБОТ
2.1 Выбор варианта
Обозначим за XY код, заданный преподавателем, или две последние цифры номера вашей зачетной книжки. Тогда номер вашего
варианта задания в контрольной работе выбирается следующим образом:
N = XY - 25*K, где
-1, если XY =00
0, если XY <=25
K=
1, если XY <=50
2, если XY <=75
3, если XY <=99
Например, ваш шифр 3423, XY=23, номер варианта N=2325*0=23. Для шифра 3482, N=82-25*3=7, номер варианта 7.
Контрольная работа состоит из трёх заданий.
При оформлении задания своего варианта необходимо:
 выполнить построение математической модели;
 разработать блок-схему алгоритма;
 написать программу на алгоритмическом языке.
2.2 Задание №1. Теоретический вопрос
Подготовить ответ на теоретический вопрос, согласно вашему
варианту.
15
1. Прикладные программы с высокой степенью автоматизации
управления.
2. Организация процесса разработки программных средств.
3. Руководство программным проектом.
4. Классические методы анализа требований. Метод Джексона.
5. Классические методы проектирования программных систем. Метод Джексона.
6. Организация процесса тестирования программного обеспечения.
7. Основы объектно-ориентированного представления программных
систем.
8. Структурное тестирование программного обеспечения.
9. Функциональное тестирование программного обеспечения.
10. Адаптируемость пакетов программ.
11. Проектирования программ сложной структуры.
12. Типовые приемы конструирования пакетов программ сложной
структуры.
13. Организация проектирования программного обеспечения.
14. Этапы процесса проектирования.
15. Способы формального представления знаний.
16. Основы устройства и использование экспертных систем в разработке адаптируемого программного обеспечения.
17. Основные направления интеллектуализации ПО.
18. Стандартизация и метрология в разработке программного обеспечения.
19. Стандартизация информационных технологий.
20. Действующие стандарты и проблемы программных интерфейсов.
21. Оценка качественных и количественных характеристик программного обеспечения.
22. Математические модели оценки характеристик качества и надежности программного и информационного обеспечения.
23. Оценка эффективности программных средств.
24. Сертификация программного обеспечения.
25. Понятие рынка программных средств
2.3 Задание №2. Предпроектный анализ предметной области.
Выполнить предпроектный анализ предметной области, выбранной
согласно своему варианту либо предложенный студентом самостоятельно и согласованный с преподавателем.
16
1. Управление персоналом
2. Управление запасами
3 Сбыт и реализация продукции
4. Управление выполнением заказов
5. Учет продаж
6. Налоговая инспекция
7. Таможня
8. Статистика
9. Страхование
10. Поликлиника
11. Букинистический магазин
12. Библиотека
13. Санаторий
14. Турфирма
15. Агентство недвижимости
16. Рекламное агентство
17. Кадровое агентство
18. Видеотека
19. Электронный магазин
20. Разработка WEB-сайта фирмы
21. Управление кредитной политикой
22. Ведение архивов записей о персонале
23. Исследование рынка и прогнозирование продаж
24. Планирование объемов работ и разработка календарных
25. Анализ и прогнозирование потребности в трудовых ресурсах
2.4 Задание№ 3. Сценарии оценки стоимости разработки
.
Сценарий №1
Сценарий понижения зарплаты
Положим, что заказчик решил сэкономить на зарплате разработчиков. Рычаг — понижение квалификации аналитика и программиста.
Соответственно, зарплата сотрудников снижается до $5000. Оценки
их возможностей становятся номинальными, а соответствующие множители затрат принимают единичные значения:
EMACAP=EMPCAP=1.
Определите множитель поправки, затраты, стоимость, проигрыш в стоимости.
17
Сценарий №2
Сценарий наращивания памяти
Положим, что разработчик предложил нарастить память — купить за $1000 чип ОЗУ емкостью 96 Кбайт (вместо 64 Кбайт). Это меняет ограничение памяти (используется не 70%, а 47%), после чего
фактор STOR снижается до номинального:EMSTOR=1-> Мр =1,026.
Определите множитель поправки, затраты, стоимость, выигрыш
в стоимости.
Сценарий №3
Сценарий использования нового микропроцессора
Положим, что заказчик предложил использовать новый, более
дешевый МП (дешевле на $1000). К чему это приведет? Опыт работы
с его языком и утилитами понижается от номинального до очень низкого , а разработанные для него утилиты (компиляторы, ассемблеры и
отладчики) примитивны и ненадежны (в результате фактор TOOL понижается от высокого до очень низкого ). Определите множитель поправки, затраты, стоимость, выигрыш в стоимости.
Сценарий №4
Сценарий уменьшения средств на завершение проекта
Положим, что к разработке принят сценарий с наращиванием
памяти:
ЗАТРАТЫ = 36 х 1,026 = 37 [чел.-мес],
СТОИМОСТЬ = ЗАТРАТЫ х $6000 = $222000.
Кроме того, предположим, что завершился этап анализа требований, на который было израсходовано $22 000 (10% от бюджета).
После этого на завершение проекта осталось $200 000.
Допустим, что в этот момент «коварный» заказчик сообщает об
отсутствии у него достаточных денежных средств и о предоставлении
на завершение разработки только $170 000 (15%-ное уменьшение
оплаты).
Для решения этой проблемы установите возможные изменения
факторов затрат, позволяющие уменьшить оценку затрат на 15%.
18
Решение: уменьшение размера продукта (за счет исключения
некоторых функций). Определить размер минимизированного продукта.
Сценарий №5
Сценарий уменьшения средств на завершение проекта
Положим, что к разработке принят сценарий с наращиванием
памяти:
ЗАТРАТЫ = 36 х 1,026 = 37 [чел.-мес],
СТОИМОСТЬ = ЗАТРАТЫ х $6000 = $222000.
Кроме того, предположим, что завершился этап анализа требований, на который было израсходовано $22 000 (10% от бюджета).
После этого на завершение проекта осталось $200 000.
Допустим, что в этот момент «коварный» заказчик сообщает об
отсутствии у него достаточных денежных средств и о предоставлении
на завершение разработки только $170 000 (15%-ное уменьшение
оплаты).
Для решения этой проблемы надо установить возможные изменения факторов затрат, позволяющие уменьшить оценку затрат на
15%. Уменьшите требуемую надежность с номинальной до низкой.
Сценарий №6.
Сценарий уменьшения средств на завершение проекта
Положим, что к разработке принят сценарий с наращиванием
памяти:
ЗАТРАТЫ = 36 х 1,026 = 37 [чел.-мес],
СТОИМОСТЬ = ЗАТРАТЫ х $6000 = $222000.
Кроме того, предположим, что завершился этап анализа требований, на который было израсходовано $22 000 (10% от бюджета).
После этого на завершение проекта осталось $200 000.
Допустим, что в этот момент «коварный» заказчик сообщает об
отсутствии у него достаточных денежных средств и о предоставлении
на завершение разработки только $170 000 (15%-ное уменьшение
оплаты).
19
Для решения этой проблемы надо установить возможные изменения факторов затрат, позволяющие уменьшить оценку затрат на
15%.
Сценарий №7
Сценарий уменьшения средств на завершение проекта
Положим, что к разработке принят сценарий с наращиванием
памяти:
ЗАТРАТЫ = 36 х 1,026 = 37 [чел.-мес],
СТОИМОСТЬ = ЗАТРАТЫ х $6000 = $222000.
Кроме того, предположим, что завершился этап анализа требований, на который было израсходовано $22 000 (10% от бюджета).
После этого на завершение проекта осталось $200 000.
Допустим, что в этот момент «коварный» заказчик сообщает об
отсутствии у него достаточных денежных средств и о предоставлении
на завершение разработки только $170 000 (15%-ное уменьшение
оплаты).
Для решения этой проблемы надо установить возможные изменения факторов затрат, позволяющие уменьшить оценку затрат на
15%. Решение: повысить требования к квалификации аналитиков и
программистов (с высоких до очень высоких).
Сценарий №8
Сценарий уменьшения средств на завершение проекта
Положим, что к разработке принят сценарий с наращиванием
памяти:
ЗАТРАТЫ = 36 х 1,026 = 37 [чел.-мес],
СТОИМОСТЬ = ЗАТРАТЫ х $6000 = $222000.
Кроме того, предположим, что завершился этап анализа требований, на который было израсходовано $22 000 (10% от бюджета).
После этого на завершение проекта осталось $200 000.
Допустим, что в этот момент «коварный» заказчик сообщает об
отсутствии у него достаточных денежных средств и о предоставлении
на завершение разработки только $170 000 (15%-ное уменьшение
оплаты).
Для решения этой проблемы надо установить возможные изменения факторов затрат, позволяющие уменьшить оценку затрат на
20
15%. Решение:повысить требования к опыту работы с приложением
(с номинальных до очень высоких) .
Сценарий №9
Сценарий уменьшения средств на завершение проекта
Положим, что к разработке принят сценарий с наращиванием
памяти:
ЗАТРАТЫ = 36 х 1,026 = 37 [чел.-мес],
СТОИМОСТЬ = ЗАТРАТЫ х $6000 = $222000.
Кроме того, предположим, что завершился этап анализа требований, на который было израсходовано $22 000 (10% от бюджета).
После этого на завершение проекта осталось $200 000.
Допустим, что в этот момент «коварный» заказчик сообщает об
отсутствии у него достаточных денежных средств и о предоставлении
на завершение разработки только $170 000 (15%-ное уменьшение
оплаты).
Для решения этой проблемы надо установить возможные изменения факторов затрат, позволяющие уменьшить оценку затрат на
15%. Решение: повысить уровень мультисетевой разработки с низкого до высокого.
Сценарий №10
Сценарий уменьшения средств на завершение проекта
Положим, что к разработке принят сценарий с наращиванием
памяти:
ЗАТРАТЫ = 36 х 1,026 = 37 [чел.-мес],
СТОИМОСТЬ = ЗАТРАТЫ х $6000 = $222000.
Кроме того, предположим, что завершился этап анализа требований, на который было израсходовано $22 000 (10% от бюджета).
После этого на завершение проекта осталось $200 000.
Допустим, что в этот момент «коварный» заказчик сообщает об
отсутствии у него достаточных денежных средств и о предоставлении
на завершение разработки только $170 000 (10%-ное уменьшение
оплаты).
Для решения этой проблемы надо установить возможные изменения факторов затрат, позволяющие уменьшить оценку затрат на
10%. Решение:ослабить требования к режиму работы в реальном вре21
мени. Предположим, что 70%-ное ограничение по времени выполнения связано с желанием заказчика обеспечить обработку одного сообщения за 2 мс. Если же заказчик согласится на увеличение среднего
времени обработки с 2 до 3 мс, то ограничение по времени станет равно (2 мс/3 мс) х 70% = 47%.
Сценарий №11
Сценарий уменьшения средств на завершение проекта
Положим, что к разработке принят сценарий с наращиванием
памяти:
ЗАТРАТЫ = 36 х 1,026 = 37 [чел.-мес],
СТОИМОСТЬ = ЗАТРАТЫ х $6000 = $222000.
Кроме того, предположим, что завершился этап анализа требований, на который было израсходовано $22 000 (10% от бюджета).
После этого на завершение проекта осталось $200 000.
Допустим, что в этот момент «коварный» заказчик сообщает об
отсутствии у него достаточных денежных средств и о предоставлении
на завершение разработки только $170 000 (15%-ное уменьшение
оплаты).
Для решения этой проблемы надо установить возможные изменения факторов затрат, позволяющие уменьшить оценку затрат на
15%. Решение:повысить требования к опыту работы с платформой (с
низких до высоких).
Сценарий №12
Сценарий понижения зарплаты
Положим, что заказчик решил сэкономить на зарплате разработчиков. Рычаг — понижение квалификации аналитика и программиста.
Соответственно, зарплата сотрудников снижается до $5000. Оценки
их возможностей становятся номинальными, а соответствующие множители затрат принимают единичные значения:
EMACAP=EMPCAP=1.
Определите множитель поправки, затраты, стоимость, проигрыш в стоимости.
Сценарий №13
22
Сценарий наращивания памяти
Положим, что разработчик предложил нарастить память — купить за $1000 чип ОЗУ емкостью 96 Кбайт (вместо 64 Кбайт). Это меняет ограничение памяти (используется не 70%, а 47%), после чего
фактор STOR снижается до номинального:EMSTOR=1-> Мр =1,026.
Определите множитель поправки, затраты, стоимость, выигрыш
в стоимости.
Сценарий №14
Сценарий использования нового микропроцессора
Положим, что заказчик предложил использовать новый, более
дешевый МП (дешевле на $1000). К чему это приведет? Опыт работы
с его языком и утилитами понижается от номинального до очень низкого , а разработанные для него утилиты (компиляторы, ассемблеры и
отладчики) примитивны и ненадежны (в результате фактор TOOL понижается от высокого до очень низкого ). Определите множитель поправки, затраты, стоимость, выигрыш в стоимости.
Сценарий №15
Сценарий уменьшения средств на завершение проекта
Положим, что к разработке принят сценарий с наращиванием
памяти:
ЗАТРАТЫ = 36 х 1,026 = 37 [чел.-мес],
СТОИМОСТЬ = ЗАТРАТЫ х $6000 = $222000.
Кроме того, предположим, что завершился этап анализа требований, на который было израсходовано $22 000 (10% от бюджета).
После этого на завершение проекта осталось $200 000.
Допустим, что в этот момент «коварный» заказчик сообщает об
отсутствии у него достаточных денежных средств и о предоставлении
на завершение разработки только $170 000 (15%-ное уменьшение
оплаты).
Для решения этой проблемы установите возможные изменения
факторов затрат, позволяющие уменьшить оценку затрат на 15%.
Решение: уменьшение размера продукта (за счет исключения
некоторых функций). Определить размер минимизированного продукта.
23
Сценарий №16
Сценарий уменьшения средств на завершение проекта
Положим, что к разработке принят сценарий с наращиванием
памяти:
ЗАТРАТЫ = 36 х 1,026 = 37 [чел.-мес],
СТОИМОСТЬ = ЗАТРАТЫ х $6000 = $222000.
Кроме того, предположим, что завершился этап анализа требований, на который было израсходовано $22 000 (10% от бюджета).
После этого на завершение проекта осталось $200 000.
Допустим, что в этот момент «коварный» заказчик сообщает об
отсутствии у него достаточных денежных средств и о предоставлении
на завершение разработки только $170 000 (15%-ное уменьшение
оплаты).
Для решения этой проблемы надо установить возможные изменения факторов затрат, позволяющие уменьшить оценку затрат на
15%. Уменьшите требуемую надежность с номинальной до низкой.
Сценарий №17.
Сценарий уменьшения средств на завершение проекта
Положим, что к разработке принят сценарий с наращиванием
памяти:
ЗАТРАТЫ = 36 х 1,026 = 37 [чел.-мес],
СТОИМОСТЬ = ЗАТРАТЫ х $6000 = $222000.
Кроме того, предположим, что завершился этап анализа требований, на который было израсходовано $22 000 (10% от бюджета).
После этого на завершение проекта осталось $200 000.
Допустим, что в этот момент «коварный» заказчик сообщает об
отсутствии у него достаточных денежных средств и о предоставлении
на завершение разработки только $170 000 (15%-ное уменьшение
оплаты).
Для решения этой проблемы надо установить возможные изменения факторов затрат, позволяющие уменьшить оценку затрат на
15%.
24
Сценарий №18
Сценарий уменьшения средств на завершение проекта
Положим, что к разработке принят сценарий с наращиванием
памяти:
ЗАТРАТЫ = 36 х 1,026 = 37 [чел.-мес],
СТОИМОСТЬ = ЗАТРАТЫ х $6000 = $222000.
Кроме того, предположим, что завершился этап анализа требований, на который было израсходовано $22 000 (10% от бюджета).
После этого на завершение проекта осталось $200 000.
Допустим, что в этот момент «коварный» заказчик сообщает об
отсутствии у него достаточных денежных средств и о предоставлении
на завершение разработки только $170 000 (15%-ное уменьшение
оплаты).
Для решения этой проблемы надо установить возможные изменения факторов затрат, позволяющие уменьшить оценку затрат на
15%. Решение: повысить требования к квалификации аналитиков и
программистов (с высоких до очень высоких).
Сценарий №19
Сценарий уменьшения средств на завершение проекта
Положим, что к разработке принят сценарий с наращиванием
памяти:
ЗАТРАТЫ = 36 х 1,026 = 37 [чел.-мес],
СТОИМОСТЬ = ЗАТРАТЫ х $6000 = $222000.
Кроме того, предположим, что завершился этап анализа требований, на который было израсходовано $22 000 (10% от бюджета).
После этого на завершение проекта осталось $200 000.
Допустим, что в этот момент «коварный» заказчик сообщает об
отсутствии у него достаточных денежных средств и о предоставлении
на завершение разработки только $170 000 (15%-ное уменьшение
оплаты).
Для решения этой проблемы надо установить возможные изменения факторов затрат, позволяющие уменьшить оценку затрат на
15%. Решение:повысить требования к опыту работы с приложением
(с номинальных до очень высоких) .
25
Сценарий №20
Сценарий уменьшения средств на завершение проекта
Положим, что к разработке принят сценарий с наращиванием
памяти:
ЗАТРАТЫ = 36 х 1,026 = 37 [чел.-мес],
СТОИМОСТЬ = ЗАТРАТЫ х $6000 = $222000.
Кроме того, предположим, что завершился этап анализа требований, на который было израсходовано $22 000 (10% от бюджета).
После этого на завершение проекта осталось $200 000.
Допустим, что в этот момент «коварный» заказчик сообщает об
отсутствии у него достаточных денежных средств и о предоставлении
на завершение разработки только $170 000 (15%-ное уменьшение
оплаты).
Для решения этой проблемы надо установить возможные изменения факторов затрат, позволяющие уменьшить оценку затрат на
15%. Решение: повысить уровень мультисетевой разработки с низкого до высокого.
Сценарий №21
Сценарий уменьшения средств на завершение проекта
Положим, что к разработке принят сценарий с наращиванием
памяти:
ЗАТРАТЫ = 36 х 1,026 = 37 [чел.-мес],
СТОИМОСТЬ = ЗАТРАТЫ х $6000 = $222000.
Кроме того, предположим, что завершился этап анализа требований, на который было израсходовано $22 000 (10% от бюджета).
После этого на завершение проекта осталось $200 000.
Допустим, что в этот момент «коварный» заказчик сообщает об
отсутствии у него достаточных денежных средств и о предоставлении
на завершение разработки только $170 000 (10%-ное уменьшение
оплаты).
Для решения этой проблемы надо установить возможные изменения факторов затрат, позволяющие уменьшить оценку затрат на
10%. Решение:ослабить требования к режиму работы в реальном времени. Предположим, что 70%-ное ограничение по времени выполнения связано с желанием заказчика обеспечить обработку одного сообщения за 2 мс. Если же заказчик согласится на увеличение среднего
26
времени обработки с 2 до 3 мс, то ограничение по времени станет равно (2 мс/3 мс) х 70% = 47%.
Сценарий №22
Сценарий уменьшения средств на завершение проекта
Положим, что к разработке принят сценарий с наращиванием
памяти:
ЗАТРАТЫ = 36 х 1,026 = 37 [чел.-мес],
СТОИМОСТЬ = ЗАТРАТЫ х $6000 = $222000.
Кроме того, предположим, что завершился этап анализа требований, на который было израсходовано $22 000 (10% от бюджета).
После этого на завершение проекта осталось $200 000.
Допустим, что в этот момент «коварный» заказчик сообщает об
отсутствии у него достаточных денежных средств и о предоставлении
на завершение разработки только $170 000 (15%-ное уменьшение
оплаты).
Для решения этой проблемы надо установить возможные изменения факторов затрат, позволяющие уменьшить оценку затрат на
15%. Решение:повысить требования к опыту работы с платформой (с
низких до высоких).
Сценарий №23
Сценарий уменьшения средств на завершение проекта
Положим, что к разработке принят сценарий с наращиванием
памяти:
ЗАТРАТЫ = 36 х 1,026 = 37 [чел.-мес],
СТОИМОСТЬ = ЗАТРАТЫ х $6000 = $222000.
Кроме того, предположим, что завершился этап анализа требований, на который было израсходовано $22 000 (10% от бюджета).
После этого на завершение проекта осталось $200 000.
Допустим, что в этот момент «коварный» заказчик сообщает об
отсутствии у него достаточных денежных средств и о предоставлении
на завершение разработки только $170 000 (15%-ное уменьшение
оплаты).
27
Для решения этой проблемы надо установить возможные изменения факторов затрат, позволяющие уменьшить оценку затрат на
15%. Уменьшите требуемую надежность с номинальной до низкой.
Сценарий №24.
Сценарий уменьшения средств на завершение проекта
Положим, что к разработке принят сценарий с наращиванием
памяти:
ЗАТРАТЫ = 36 х 1,026 = 37 [чел.-мес],
СТОИМОСТЬ = ЗАТРАТЫ х $6000 = $222000.
Кроме того, предположим, что завершился этап анализа требований, на который было израсходовано $22 000 (10% от бюджета).
После этого на завершение проекта осталось $200 000.
Допустим, что в этот момент «коварный» заказчик сообщает об
отсутствии у него достаточных денежных средств и о предоставлении
на завершение разработки только $170 000 (15%-ное уменьшение
оплаты).
Для решения этой проблемы надо установить возможные изменения факторов затрат, позволяющие уменьшить оценку затрат на
15%.
Сценарий №25.
Сценарий уменьшения средств на завершение проекта
Положим, что к разработке принят сценарий с наращиванием
памяти:
ЗАТРАТЫ = 36 х 1,026 = 37 [чел.-мес],
СТОИМОСТЬ = ЗАТРАТЫ х $6000 = $222000.
Кроме того, предположим, что завершился этап анализа требований, на который было израсходовано $22 000 (10% от бюджета).
После этого на завершение проекта осталось $200 000.
Допустим, что в этот момент «коварный» заказчик сообщает об
отсутствии у него достаточных денежных средств и о предоставлении
на завершение разработки только $170 000 (15%-ное уменьшение
оплаты).
28
Для решения этой проблемы надо установить возможные изменения факторов затрат, позволяющие уменьшить оценку затрат на
15%. Решение: повысить требования к квалификации аналитиков и
программистов (с высоких до очень высоких).
2.5 Задание №4. Тестирование программы
1. Пусть КТ тестировщиков выполняют оценку надежности КР
проектов (где КТ – количество тестировщиков, КР – количество
проектов). Пусть в момент оценки надежности по протоколу все
ошибки делятся на собственные и искусственные.
N 
S n
V
где N – первоначальное число ошибок в программе,
n – число найденных собственных ошибок,
V – число обнаруженных к моменту оценки искусственных
ошибок,
S – количество искусственно внесенных ошибок.
В зависимости от значений N, V, S, n генерировать сообщения для
каждого проекта и каждого тестировщика:
все искусственно внесенные ошибки найдены;
 обнаружено Р% искусственных ошибок;
 предполагаемое число ошибок в программе – N;
 в программе найдены все ошибки.
2. Пусть КТ тестировщиков выполняют оценку КР проектов по
модели надежности Милса (где КТ – количество тестировщиков,
КР – количество проектов). Пусть величина С является мерой доверия к модели надежности программных систем и показывает
насколько правильно найдено первоначальное число ошибок в
программе.
29
1, если n  K

C
S

, если
 S  K  1
nK
Где n – число найденных собственных ошибок,
К – число собственных ошибок,
S – количество искусственно внесенных ошибок
В зависимости от значения С генерировать сообщения для каждого
проекта и каждого тестировщика.
велика вероятность того, что в программе не ошибок;
 невелика вероятность того, что в программе нет ошибок;
 предположение о том, что в программе нет ошибок не подтвердилось.
3. Пусть необходимо дать рекомендации по выбору модели
надежности для КР проектов ( где КР – количество проектов). Организуйте диалог с пользователем и выдайте рекомендации по использованию моделей надежности ПС.
Рекомендуется Модель Шумана, если


тестирование проводится в несколько этапов;
тестирование проводится на полном комплексе разработанных
тестовых наборов;
 выявленные ошибки регистрируются, но не исправляются.
Рекомендуется модель La PaduLa, если


тестирование проводится в несколько этапов;
тестирование проводится на полном комплексе разработанных
тестовых наборов;
 выявленные ошибки регистрируются и исправляются.
Рекомендуется модель Джелинского – Моранды, если



фиксируется время до очередного отказа;
каждая обнаруженная ошибка устраняется;
число оставшихся ошибок уменьшается на единицу.
30
4. Пусть необходимо дать рекомендации по выбору модели
надежности для КР проектов ( где КР – количество проектов). Организуйте диалог с пользователем и выдайте рекомендации по использованию моделей надежности ПС.
Рекомендуются аналитические статические модели надежности, если

не учитывается время появления ошибок в процессе тестирования,
 не используются предположения о поведении функции риска,
 собирается статистика об ошибках
Рекомендуется эмпирическая модель надежности ,если



необходимо прогнозировать требуемые ресурсы тестирования;
необходимо определить меру сложности программ;
необходимо предсказать возможное число ошибок.
Пусть разрабатывается комплекс из КР программ. Определить
уровень сложности каждой программы комплекса.
При длине программы 103 операторов программа считается простой.
При длине программы 104 операторов программа средней сложности.
При длине программы 105 операторов программа считается сложной.
При длине программы 106 операторов программа считается сверхсложной.
5.
6.
Диапазон изменения количества модулей в комплексе из КР
программ следующий: 1-3 модуля – простой КП, 10-100 модулей
для КП средней сложности, 1000 модулей для сложного КП,
10000 модулей для сверхсложной программы. Определить уровень
сложности каждой программы из комплекса программ.
7.
Пусть разрабатывается КТ проектов. Каждый проект состоит из
КРКТ программных комплексов. Если количество обрабатываемых
переменных в программном комплексе 10,
то программа считается простой. Если количество обрабатываемых переменных
в программном комплексе от 100 до 1000, то программа средней
сложности.
Если количество обрабатываемых переменных в
программном комплексе от 104 до 105 то программа считается
сложной. Если количество обрабатываемых переменных в про31
граммном комплексе от 106 до
108 то программа считается
сверхсложной.
Определить уровень сложности программного
комплекса для каждого из КТ проектов.
8. Пусть разрабатывается Р программ. Если программа разрабатывается от 0,1 до 0,5 лет , то это показатель простой программы. Если программа разрабатывается от 1 до 3 лет , то это показатель программы средней сложности. Если программа разрабатывается от
2 до 5 лет , то это показатель сложной программы. Если программа
разрабатывается от 3 до 10 лет , то это показатель уникальной программы. Определить уровень сложности каждой из программ.
9. Пусть разрабатывается Р программ. Если в разработке программы
принимают участие от 1 до 2 человек, то программа
считается
простой. Если в разработке программы принимают участие от 3 10
человек, то сложность программы средняя. Если в разработке программы принимают участие
от 10 до 100 человек, то программа
считается сложной. Если в разработке программы
принимают
участие от 100 до 1000 человек, то программа считается уникальной.
Определить уровень сложности каждой из программ.
10. Пусть разрабатывается Р программ. Определить выбор принципов и методов обеспечения надежности для пользователя в виде меню. Программа должна быть информативна т.е. содержать
следующую
информацию:
 по предупреждению ошибок – принципы и методы,
позволяющие справиться со сложностью, достигать большую
точность процессов перевода, совершенствовать информационные связи разработчиков.
 по обнаружению ошибок - принципы взаимного подозрения, немедленного
обнаружения , избыточности; методы полноты
32


проверки, проверки признаков данных, проверки на ограничения
и совместимость.
по исправлению ошибок – принципы и методы запасного модуля,
борьбы с искажениями.
по устойчивости к ошибкам – принципы и методы динамической
избыточности, отступления, голосования.
Выдайте рекомендации по использованию принципов и методов
для каждой из Р программ.
11. Пусть разрабатывается Р программ. Создайте для пользователя
информативную программу по видам и степени прочности, видам и
степени сцепления модуля. Предусмотреть виды прочности модуля:
по совпадению (0), логическую (1), временную (3), процедурную
(5), коммуникативную (7), последовательную (9), функциональную
10). Предусмотреть виды сцепления : по кодам (9), по внешним
ссылкам (7), по управлению (5), по общей области (4), по образцу (3),
по данным (1), независимое (0). По виду прочности и виду сцепления
определите степень прочности и степень сцепления в каждой из Р
программ.
12. Пусть разрабатывается Р программ. Согласно ГОСТ 28195-89
оценочными элементами фактора надежности ПС являются:
 наличия требований к программе по устойчивости,
 возможность обработки ошибочных ситуаций,
 полнота обработки ошибочных ситуаций,
 наличие тестов для проверки допустимых значений,
 наличие схемы контроля полноты входных данных.
 наличие средств контроля корректности входных данных,
 наличие средств контроля непротиворечивости входных данных,
 наличие обработки граничных результатов,
 наличие обработки неопределенностей.
Оценка фактора либо 0 либо 1. Поставьте оценку надежности
каждой из Р разрабатываемых программ.
13. Пусть сопровождается Р программ. Согласно ГОСТ 28195-89
оценочными элементами фактора сопровождаемости ПС являются
33
 наличие комментариев ко всем частям программы,
 соответствие комментариев принятым соглашениям,
 наличие проверки корректности передаваемых данных,
 наличие ограничений на размер модуля,
 наличие модульной схемы программы,
 наличие требований к независимости модулей,
 наличие уникальных модулей,
 соблюдение принципа разработки программы сверху вниз.
Оценка фактора либо 0 либо 1. Поставьте оценку сопровождаемости каждой из Р программ.
14. Пусть разрабатывается Р программ. Определить надежность каждой программы по статической модели Нельсона.
Предполагается, что область данных, необходимых для выполнения
тестирования.программного средства, разделяется на К взаимоисключающих подобластей Zi, i=1,2,…,k. Пусть Рi – вероятность того, что
набор данных Zi будет выбран для очередного выполнения программы. Предполагая, что к моменту оценки надежности было выполнено
Ni прогонов программы на Zi наборе данных и из них ni количество
прогонов закончилось отказом, надежность ПС в этом случае равна:
R
K
1  
i 1
(ni )
N
P
i
i
15. Пусть КТ тестировщиков выполняют оценку надежности проекта
по разработке пограммного средства (где КТ – количество
тестировщиков). Пусть в момент оценки надежности по протоколу
все ошибки делятся на собственные и искусственные.
N 
S n
V
где N – первоначальное число ошибок в программе,
34
n – число найденных собственных ошибок,
V – число обнаруженных к моменту оценки искусственных
ошибок,
S – количество искусственно внесенных ошибок.
В зависимости от значений N, V, S, n генерировать сообщения для
каждого тестировщика:
все искусственно внесенные ошибки найдены;
 обнаружено Р% искусственных ошибок;
 предполагаемое число ошибок в программе – N;
 в программе найдены все ошибки.
16. Пусть КТ тестировщиков выполняют оценку проекта по модели
надежности Милса (где КТ – количество тестировщиков). Пусть величина С является мерой доверия к модели надежности программных
систем и показывает насколько правильно найдено первоначальное
число ошибок в программе.
1, если n  K

C
S

, если
 S  K  1
nK
Где n – число найденных собственных ошибок,
К – число собственных ошибок,
S – количество искусственно внесенных ошибок
В зависимости от значения С генерировать сообщения для каждого
тестировщика.
велика вероятность того, что в программе не ошибок;
невелика вероятность того, что в программе нет ошибок;
предположение о том, что в программе нет ошибок не подтвердилось.
35
17. Пусть необходимо дать рекомендации по выбору модели надежности для КР проектов ( где КР – количество проектов). Организуйте
диалог с пользователем и выдайте рекомендации по использованию
моделей надежности ПС. Рекомендуется Модель Шумана, если тестирование проводится в несколько этапов; тестирование проводится на
полном комплексе разработанных тестовых наборов; выявленные
ошибки регистрируются, но не исправляются.. Рекомендуется модель
La PaduLa, если тестирование проводится в несколько этапов; тестирование проводится на полном комплексе разработанных тестовых
наборов; выявленные ошибки регистрируются и исправляются. Рекомендуется модель Джелинского – Моранды, если фиксируется время
до очередного отказа; каждая обнаруженная ошибка устраняется; число оставшихся ошибок уменьшается на единицу.
18. Пусть необходимо дать рекомендации по выбору модели надежности для КР проектов ( где КР – количество проектов). Организуйте
диалог с пользователем и выдайте рекомендации по использованию
моделей надежности ПС .Рекомендуются аналитические статические
модели надежности, если не учитывается время появления ошибок в
процессе тестирования, не используются предположения о поведении
функции риска, собирается статистика об ошибках. Рекомендуется
эмпирическая модель надежности ,если необходимо прогнозировать
требуемые ресурсы тестирования; необходимо определить меру сложности программ; необходимо предсказать возможное число ошибок.
19. Определить уровень сложности из КР программ.При длине программы 103 операторов программа считается простой. При длине
программы 104 операторов программа средней сложности. При длине
программы 105 операторов программа считается сложной. При длине
программы 106 операторов программа считается сверхсложной.
20. Диапазон изменения количества модулей в комплексе из КР программ следующий:1-3 модуля – простой КП, 10-100 модулей для КП
средней сложности, 1000 модулей для сложного КП, 10000 модулей
36
для сверхсложной программы. Определить уровень сложности комплекса программ.
21. Пусть разрабатывается комплекс из КР программ. Определить
уровень сложности каждой программы комплекса.
При длине программы 103 операторов программа считается простой.
При длине программы 104 операторов программа средней сложности.
При длине программы 105 операторов программа считается сложной.
При длине программы 106 операторов программа считается сверхсложной.
22. Диапазон изменения количества модулей в комплексе из КР
программ следующий: 1-3 модуля – простой КП, 10-100 модулей для
КП средней сложности, 1000 модулей для сложного КП, 10000 модулей для сверхсложной программы. Определить уровень сложности
каждой программы из комплекса программ.
23. Пусть разрабатывается КТ проектов. Каждый проект состоит из
КРКТ программных комплексов. Если количество обрабатываемых
переменных в программном комплексе 10,
то программа считается простой. Если количество обрабатываемых переменных в программном комплексе от 100 до 1000, то программа средней сложности.
Если количество обрабатываемых переменных в программном комплексе от 104 до 105 то программа считается сложной. Если
количество обрабатываемых переменных в программном комплексе
от 106 до
108 то программа считается сверхсложной.
Определить уровень сложности программного комплекса для каждого из
КТ проектов.
24. Пусть разрабатывается Р программ. Если программа разрабатывается от 0,1 до 0,5 лет , то это показатель простой программы. Если программа разрабатывается от 1 до 3 лет , то это показатель программы средней сложности. Если программа разрабатывается от
2 до 5 лет , то это показатель сложной программы. Если программа
разрабатывается от 3 до 10 лет , то это показатель уникальной программы. Определить уровень сложности каждой из программ.
37
25. Пусть разрабатывается Р программ. Если в разработке программы
принимают участие от 1 до 2 человек, то программа
считается
простой. Если в разработке программы принимают участие от 3 10
человек, то сложность программы средняя. Если в разработке программы принимают участие
от 10 до 100 человек, то программа
считается сложной. Если в разработке программы
принимают
участие от 100 до 1000 человек, то программа считается уникальной.
Определить уровень сложности каждой из программ.
3 МЕТОДИКА ВЫПОЛНЕНИЯ КОНТРОЛЬНОЙ РАБОТЫ
3.1 Пример выполнения задания 2
План выполнения предпроектного анализа предметной области.
1. Описание учреждения
1.1 Цели функционирования учреждения
1.2 Описание организационной структуры учреждения
1.3 Состав бизнес процессов учреждения
1.4 Описание бизнес процесса
1.5 Объекты (документы) основного бизнес процесса
1.6. Типовые бизнес решения, подлежащие автоматизации
2. Формирование требований.
2.1 Состав требований.
2.2 Определение состава сценариев, реализующих требования.
2.3 Разработка содержания сценариев.
2.4 Определение требований к пользовательскому интерфейсу.
Для примера проведения предпроектного анализа выбрана
предметная область «Суд».
1. Описание учреждения
1.1 Цели функционирования учреждения
38
Суд - это и учреждение государственной власти, и результаты
его работы напрямую влияют на отношения к этой власти, её авторитет, поэтому основной целью функционирования данной учреждения
является повышение авторитета государственной власти через осуществления государственной защиты прав и свобод человека.
1.2 Описание организационной структуры учреждения
Председатель суда осуществляет общее руководство судом,
связь с другими организациями, председательствует в судебных заседаниях, назначает судей в качестве председательствующих в судебных заседаниях, распределяет обязанности между судьями районного суда.
Заместитель председателя суда выполняет те же обязанности что
и председатель во время его отсутствия.
Помощник председателя суда подготавливает материалы для
докладов и выступлений председателя суда, оказывает помощь председателю суда в подготовке дела к судебному разбирательству.
Судьи рассматривают уголовные и гражданские дела, а также
выносят по ним решения.
Помощники судей оказывают помощь судье в подготовке дела к
судебному разбирательству.
Секретари судебного заседания извещают участников процесса и
других лиц, имеющих отношение к рассматриваемому делу.
1.3 Состав бизнес процессов учреждения
Бизнес-процесс «Заведение гражданского дела» заключается в
подготовке дела к рассмотрению и приведение его в надлежащий вид
Бизнес-процесс «Подготовка докладов, выступлений, обращений» необходим для того чтобы помощники судей и помощник председателя суда смогли собрать и подготовить необходимую информацию для проведения выступлений.
Бизнес-процесс «Рассмотрение уголовных и гражданских дел»
заключается в детальном прочтении дела и просмотре всех материалов следствия.
Бизнес-процесс «Вынесение решения по уголовным и гражданским делам» заключается в вынесении приговора либо решения в зале
заседаний суда.
Бизнес-процесс «Управление судом» заключается в общем руководстве работой аппарата суда, распределение обязанностей между
судьями.
39
Бизнес-процесс «Занесение решений и информации о делах в
базу данных» заключается в наборе на компьютере сведений о делах
(кто вел дело, истец ответчик, либо обвиняемый, мера наказания и
т.д.)
Бизнес-процесс «Распределение инженерно-технического и
программного обеспечения» заключается в обновлении старого оборудования и программного обеспечения, распределении расходных
материалов, а так же их учету.
Бизнес-процесс «Трудоустройство и разработка расписания
суда» заключается в принятии в организацию новых сотрудников и
отправки сведений о них в судебный департамент.
1.4 Описание бизнес процесса учреждения
Содержание бизнес-процесса «Заведение гражданского дела»
состоит из последовательного выполнения действий: «Прием заявления», «Занесение информации о заявлении в журнал», «Распределение
заявлений между судьями», «Проверка заявления судьей», «Подшив
дела»
В действии «Прием заявления» происходит беседа с гражданином, который принес заявление и его проверка.
В действии «Занесение информации о заявлении в журнал»
ставится дата в журнал, когда было принесено заявление и краткая
информация о нем.
В действии «Распределение заявлений между судьями» происходит закрепление судьи за определенным заявлением для дальнейшего рассмотрения.
В действии «Проверка заявления судьей» изучается правильность составленного заявления, а так же происходит знакомство судьи
с предстоящей работой.
«Подшив дела» заключается в перемещении заявления и приложений в специальную папку-скоросшиватель
Содержание бизнес-процесса «Подготовка докладов, выступлений, обращений» состоит из последовательного выполнения шести
действий:«Подбор данных и материалов для обобщений, докладов,
выступлений»,«Создание отчета о количестве принятых заявлений
определенной судьей»,«Создание отчета, в котором отображаются
заявления по их типу»,«Создание отчета о количестве сформированных дел»,«Создание отчета о делах, по которым уже было вынесено
решение»,«Составление плана обобщения, доклада, выступления».
40
В действии «Подбор данных и материалов для обобщений, докладов, выступлений» происходит анализ необходимых материалов,
корреспонденции, а так же нововведений в правовых актах и кодексах.
В действии «Создание отчета о количестве принятых заявлений определенной судьей» подсчитываются заявления, записанные на
определенную судью, создается отчет, в котором отображается фамилия имя отчество судьи и краткая характеристика принятых ею заявлений.
В действии «Создание отчета, в котором отображаются заявления по определенному типу» формируется отчет, содержащий все
заявления разделенных на три группы. Каждая группа соответствует
типу заявления.
В действии «Создание отчета о количестве сформированных
дел» подсчитываются дела, создается отчет, в котором отображается
фамилия имя отчество судьи и краткая характеристика дела которое
ведет данная судья, а так же состояние дела на данный момент времени.
В действии «Создание отчета о делах, по которым уже было
вынесено решение» происходит формирование отчета, в котором
отображены дела с вынесенными решениями.
В действии «Составление плана обобщения, доклада, выступления» составляется примерный план, по которому будет вестись выступление.
1.5 Объекты (документы) основного бизнес процесса учреждения
Объекты бизнес-процесса «Заведение гражданского дела»:
Объект «Заявление» - содержит информацию об истце ответчике либо заявителе и заинтересованном лице, информацию о предоставленном приложении и текст заявления и имеет атрибуты: «ФИО
истца» - тип «ntext», «Адрес истца» - тип «ntext», «ФИО ответчика» тип «ntext», «Адрес ответчика» - тип «ntext», «Цена иска» - тип «int»,
«Тело заявления» - тип «ntext», «Приложение» - тип «ntext», «Дата» тип «datetime».
Объект «Журнал заявлений» - содержит краткую информацию
о заявлении и имеет атрибуты: «Номер заявления» - тип «int», «ФИО
истца» - тип «ntext», «ФИО ответчика» - тип «ntext»,«Тип заявления»
- тип «char»,«ФИО судьи» - тип «ntext»,«Дата» - тип «datetime».
41
Объект «Список судей»- содержит имена, фамилии и отчества
судей, которые работают в суде.
Объекты бизнес-процесса «Подготовка докладов, выступлений,
обращений».
Объект «Регистрационный журнал дел» содержит краткую информацию о делах и имеет атрибуты:«Номер дела» - тип «int», «ФИО
истца» - тип «ntext», «ФИО ответчика» - тип «ntext», «ФИО судьи» тип «ntext»,«О чем дело» - тип «ntext»,«Состояние дела» - тип
«char»,«Дата заведения» - тип «datetime».
Объект «Правовые акты и кодексы» содержит информацию о
статьях, которые находятся в правовых актах и кодексах, и имеет атрибуты: «Номер статьи» - тип «int», «Заголовок статьи» - тип «ntext»,
«Содержание статьи» - тип «ntext».
Объект «Специальная корреспонденция» включает в себя корреспонденцию с тематикой, которая связана с судопроизводством и
имеет атрибуты:«Статья» - тип «ntext».
Объект «Отчет, в котором отображаются заявления по определенному типу» содержит заявления, разделенные на три типа: исковое
производство, особое производство, публично-правовые отношения и
имеет атрибуты:«Количество заявлений данного типа» - тип
«int»,«Тип заявления» - тип «char»,«ФИО судьи» - тип
«ntext»,«Период» - тип «datetime».
Объект «Отчет о количестве принятых заявлений определенной
судьей» отображает, сколько каждая судья приняла заявлений, имеет
атрибуты:«Количество заявлений» - тип «int», «О чем заявление» - тип
«ntext», «ФИО судьи» - тип «ntext», «Период» - тип «datetime».
Объект «Отчет о количестве сформированных дел» отображает,
сколько всего было сформировано дел в суде за определенный период,
имеет атрибуты:«Номер дела» - тип «int»,«О чем дело» - тип «ntext»,
«ФИО судьи» - тип «ntext», «Период» - тип «datetime», «Общее количество дел» - тип «int».
Объект «Отчет о делах, по которым уже было вынесено решение» отображает список дел, в котором указано текущее состояние
конкретного дела, имеет атрибуты: «Номер дела» - тип «int», «О чем
дело» - тип «ntext», «ФИО судьи» - тип «ntext», «Состояние дела» тип «char», «Период» - тип «datetime».
Объект «План обобщения, доклада, выступления» содержит информацию, исходя из которой будет проводиться выступление, имеет
атрибуты: «Вступление» - тип «ntext», «Основная тема» - тип «ntext»,
42
«ФИО судьи» - тип «ntext», «Тип заявления» - тип «char», «О чем заявление» - тип «ntext», «Количество заявлений данного типа» - тип
«int», «Количество заявлений» - тип «int», «Номер дела» - тип «int»,
«О чем дело» - тип «ntext», «Общее количество дел» - тип «int», «Состояние дела» - тип «char», «Период» - тип «datetime», «Подведение
итогов» - тип «ntext».
1.6 Типовые бизнес процессы, подлежащие автоматизации.
В качестве типовых бизнес-решений, то есть элементов бизнеспроцессов требующих автоматизации были выбраны следующие:
«Прием заявления», «Занесение информации о заявлении в журнал»,
«Проверка заявления судьей», «Распределение заявлений между судьями», «Создание отчета о количестве принятых заявлений определенной судьей», «Создание отчета, в котором отображаются заявления по
их типу».
Бизнес-решения «Прием заявления», «Занесение информации о
заявлении в журнал», «Проверка заявления судьей», «Распределение
заявлений между судьями» входят в состав бизнес- процесса «Обработка заявления», а бизнес-решения «Создание отчета о количестве
принятых заявлений определенной судьей», «Создание отчета, в котором отображаются заявления по их типу» относятся к бизнес-процессу
«Подготовка докладов, выступлений, обращений».
Автоматизация бизнес-решений относящихся к бизнес- процессу «Обработка заявления» необходима для ускорения приема заявлений, для устранения ошибок возникающих при приеме заявления, сохранности заявления в надлежащем виде, систематизации данных в
суде. Автоматизация бизнес-решений относящихся к бизнес- процессу
«Подготовка докладов, выступлений, обращений» необходима для
быстрого и безошибочного подсчета количества заявлений.
2. Формирование требований.
2.1 Состав требований.
В матрице, изображенной на рисунке 2.1 выделенные функциональные требования соответствуют типовым бизнес-решениям т.е. бизнес-процессам требующим автоматизации. Бизнес-процессы требующие автоматизации мы делим на бизнес подсистемы по функциональному признаку и строим матрицу трассировки "Подсистема – Функциональное требование".
При группировке бизнес-процессов требующих автоматизации
получили две подсистемы «Подсистема работы с заявлениями» и «Подсистема создания отчетов». «Подсистема работы с заявлениями» реали43
зует следующие требования «Занесение информации о заявлении в
журнал», «Прием заявления», «Проверка заявления судьей», «Распределение заявлений между судьями», а «Подсистема создания отчетов»
реализует «Создание отчета в котором отображаются заявления по их
типу», «Создание отчета о количестве принятых заявлений определенной судьей».
2.2 Определение состава сценариев, реализующих требования.
Для реализации требований может быть использовано несколько
сценариев:

Добавить заявление.

Редактировать заявление.

Удалить заявление.

Назначение судьи на рассмотрение заявления и работа со
списком судей.

Формирование отчетов.
2.3 Разработка содержания сценариев.
В сценарии «Добавить заявление» происходит формирование формы «Журнал заявлений» при помощи объекта «Журнал заявлений»,
после выбора действия добавить заявление, открывается новая форма
«Выбор типа заявления», на этой форме выбирается тип заявления.
Если выбрано исковое производство, то формируется форма «Исковое
производство», если выбрано особое производство, то формируется
форма «Особое производство», если выбраны публично-правовые
отношения, то формируется форма «Публично-правовые отношения».
Следующим действием является заполнение полей форм данными из
объекта «Заявление» и сохранение введенных данных.
В сценарии «Редактировать заявление» происходит формирование формы «Журнал заявлений», затем на форме происходит поиск
необходимого заявления и его выбор. В зависимости от типа выбранного заявления: если выбрано заявление типа «Исковое производство», формируется форма «Исковое производство» с заполненными
полями, если выбрано заявление типа «Особое производство», формируется форма «Особое производство» с заполненными полями, если
выбрано заявление типа «Публично-правовые отношения», формируется форма «Публично-правовые отношения» с заполненными полями. После этого происходит редактирование полей ввода и сохранение данных.
44
В сценарии «Удалить заявление» происходит формирование
формы «Журнал заявлений» затем поиск заявления, которое необходимо удалить, выбор этого заявления и удаление его из объекта
«Журнал заявлений».
В сценарии «Назначение судьи на рассмотрение заявления и работа со списком судей» сначала формируется форма «Журнал заявлений», затем происходит выбор действий на форме: если необходимо
назначить судью на рассмотрение заявления, то производится поиск
необходимого заявления и его выбор, затем формирование формы
«Список судей», если необходимо с добавить новую судью, то сразу
происходит формирование формы «Список судей». На форме «Список
судей» выбираются действия: если выбирается удалить, то происходит удаление судьи из списка судей, если выбрано сохранить, то происходит сохранение в список судей введенной судьи, если выбрано
назначить судью на рассмотрение заявления, то в журнале заявлений
статус заявления меняется на фамилию назначенной судьи.
В сценарии «Формирование отчетов» происходит формирование
формы «Журнал заявлений» затем выбирается создание отчетов,
формируется форма «Создание отчетов» на ней происходит выбор
действий: если выбрано отчет о количестве принятых заявлений определенной судьей, за определенный период, становятся активными поля ввода «список судей» и «период», если выбрано отчет с заявлениями, распределенными по их типу, за определенный период, становится
активным поле ввода период. Следующим шагом является ввод данных, потом формирование отчета в Word в зависимости от его типа.
2.4 Определение требований к пользовательскому интерфейсу.
Форма «Журнал заявлений» это основная форма, она предназначена для удаления, редактирования и добавления заявлений. Также
на этой форме существует панель поиска при помощи, которой можно
найти необходимое заявление. Панель поиска содержит несколько параметров, для осуществления поиска. Форма «Журнал заявлений»
отображает список заявлений, на которые можно назначать судей для
рассмотрения На форме «Выбор типа заявлений» отображается три
типа заявлений, после выбора какого-либо типа происходит переход
на другую форму соответствующую выбору.
Форма «Исковое производство» представляет тип заявлений,
которые относятся к исковому производству, содержит объекты для
45
внесения всех необходимых данных с оригинального заявления и поступившего с ним приложения.
Форма «Особое производство» представляет тип заявлений, которые относятся к особому производству, содержит объекты для внесения всех необходимых данных с оригинального заявления и поступившего с ним приложения.
Форма «Публично-правовые отношения» представляет тип заявлений, которые относятся к публично-правовым отношениям, содержит объекты для внесения всех необходимых данных с оригинального заявления и поступившего с ним приложения.
Форма «Список судей» отображает список всех существующих
судей, при помощи объектов расположенных на этой форме можно
добавлять новых судей, удалять существующих, также назначить судью на рассмотрение заявления.
Форма «Создание отчетов» предназначена для создания отчетов текстовом редакторе Word. При помощи этой формы можно создать два типа отчетов необходимых для проведения докладов и выступлений.
3.2 Пример выполнения задания 3
В качестве варианта контрольной работы вам предлагается рассмотреть один из сценариев возможного развития событий для следующего программного проекта.
Будем считать, что корпорация «СверхМобильныеСвязи» заказала разработку ПО для встроенной космической системы обработки
сообщений. Ожидаемый размер ПО — 10 KLOC, используется серийный микропроцессор. Примем, что масштабные факторы имеют номинальные значения (показатель степени В = 1,16) и что автоматическая генерация кода не предусматривается. К проведению разработки
привлекаются главный аналитик и главный программист высокой
квалификации, поэтому средняя зарплата в команде составит $ 6000 в
месяц. Команда имеет годовой опыт работы с этой проблемной областью и полгода работает с нужной аппаратной платформой.
Оценку постархитектурных факторов затрат для проекта сведите в табл. 3.1. (см. таблицу 1.8) т. е. заполните значениями четвертый столбец таблицы – множитель. Из таблицы следует, что увеличение затрат в 1,3 раза из-за очень высокой сложности продукта уравно46
вешивается их уменьшением вследствие высокой квалификации аналитика и программиста, а также активного использования программных утилит.
Таблица 3.1. Оценка пост-архитектурных факторов затрат
Фактор
Описание
Оценка
1
RELY
DATA
CPLX
RUSE
DOCU
TIME
2
Требуемая надежность ПО
Размер базы данных — 20 Кбайт
Сложность продукта
Требуемая повторная используем.
Документирование жизненного цикла
Ограничения времени выполнения
(70%)
STOR
Ограничения оперативной памяти (45
из 64 Кбайт, 70%)
PVOL
Изменчивость платформы (каждые 6
месяцев)
ACAP
Возможности аналитика (75%)
PCAP
Возможности программиста (75%)
AEXP
Опыт работы с приложением (1 год)
PEXP
Опыт работы с платформой (6 месяцев)
LTEX
Опыт работы с языком и утилитами (1
год)
PCON
Непрерывность персонала ( 1 2% в год)
TOOL
Активное использование программных
утилит
SITE
Мультисетевая разработка (телефоны)
SCED
Требуемый график разработки
Множитель поправки Мр
3
Номинал.
Низкая
Очень высок.
Номинал.
Номинал.
Высокая
Множитель
4
Высокая
Номинал.
Высокая
Высокая
Номинал.
Низкая
Номинал.
Номинал.
Высокая
Низкая
Номинал.
Рассчитайте затраты и стоимость проекта:
ЗАТРАТЫ=AхРАЗМЕРBхМр],
СТОИМОСТЬ = ЗАТРАТЫ х $6000.
Таковы стартовые условия программного проекта.
Рассмотрите сценарий возможного развития событий согласно
своему варианту.
3.3 Пример выполнения задания 4
47
Выполнение задания тестирования программы разбивается на
пять шагов.
Шаг 1. Составить текст программы для задачи, согласно вашему варианту.
Шаг 2. На основе текста программы сформировать потоковый граф.
Шаг 3. Определить цикломатическую сложность потокового графа .
1)
V(G)= 6 регионов
2)
V(G)= 17дуг -13узлов+2=6
3)
V(G)= 5 предикатных узлов +1
Шаг 4. Определить базовое множество независимых линейных путей
Шаг 5. Подготовить тестовые варианты, инициирующие выполнение
каждого пути.
Технология выполнения задания 2
Цикломатическая сложность (ЦС) - метрика ПО, которая
обеспечивает количественную оценку логической сложности программы.
Метрика – мера степени обладания свойством, имеющая числовое значения.
В способе тестирования базового пути ЦС определяет:
- количество независимых путей в базовом множестве программы;
- верхнюю оценку количества тестов, которое гарантирует однократное выполнение всех операторов.
Независимым называется любой путь, который вводит новый
оператор обработки или новое условие т.е. независимый путь должен
содержать дугу, не входящую в ранее определенные пути. Путь начинается в начальном узле, а заканчивается в конечном узле графа.
Все независимые пути графа образуют базовое множество.
тесты, обеспечивающие его проверку, гарантируют:
- однократное выполнение каждого оператора;
- выполнение каждого условия по True- ветви и по False- ветви.
2 мощность базового множества равна цикломатической сложности потокового графа т.е. оно дает априорную оценку количества
независимых путей, которые следует искать в графе.
ЦС вычисляется одним из трех способов:
1 ЦС равна количеству регионов потокового графа;
2 ЦС определяется по формуле V(G)=E-N+2, где G - потоковый
граф, E- количество дуг, N - количество узлов.
48
3 ЦС определяется по формуле V(G)= p+1, где p– количество
предикатных узлов в потоковом графе.
Шаги способа тестирования базового пути
Рассмотрим процедуру вычисления среднего значения.
Процедура сред;
1 А:=1;
1 введено :=0;
1 колич:=0;
1 сум:=0;
Вып пока
2 вел(а) <> стоп
И
3 введено<= 500
4 введено:=введено +1;
Если
5 вел(а)>=мин
И
6 вел(а)<=макс
7 то колич := колич+1 ;
7 сум:= Сум+вел(а);
8 конец если;
8 а:=а+1;
9 конец вып;
10 если колич >0
11 то сред:=Сум/колич;
12 иначе сред:= стоп;
13 конец если
13 конец стоп
49
ложь
истина
1
10
R1
12
R2
11
2
3
13
4
R3
5
R6
R4
6
8
R5
7
9
Рисунок 1. Потоковый граф
Шаг 2. Определяется цикломатическая сложность потокового
графа .
4)
V(G)= 6 регионов
5)
V(G)= 17дуг -13узлов+2=6
6)
V(G)= 5 предикатных узлов +1
Шаг 3. Определяется базовое множество независимых линейных
путей.
Начинаем обход путей слева
Путь1: 1-2-10-12-13
Путь2: 1-2-10-11-13
Новый узел 11
Процедура сред;
1 А:=1;
1 введено :=0;
Процедура сред;
1 А:=1;
1 введено :=0;
50
1 колич:=0;
1 сум:=0;
Вып пока
2 вел(а) <> стоп
(нет)
10
если
колич
>0
1 колич:=0;
1 сум:=0;
Вып пока
2 вел(а) <> стоп
10 если колич >0
12 иначе сред:= стоп;
13 конец если
13 конец стоп
11 то сред:=Сум/колич;
13 конец если
13 конец стоп
Путь3: 1-2-3-10-11-13
Новый узел 3
Путь4: 1-2-3-4-5-8-9-2 ….
Новые узлы 4-5-8-9
Процедура сред;
1 А:=1;
1 введено :=0;
1 колич:=0;
1 сум:=0;
Вып пока
2
вел(а)
<>
стоп
Процедура сред;
1 А:=1;
1 введено :=0;
1 колич:=0;
1 сум:=0;
Вып пока
2 вел(а) <> стоп
(да)
500
И
3 введено<= 500
(да)
(нет)
(да)
(нет)
(да)
и
3
введено<=
(нет)
10 если колич >0
11 то сред:=Сум/колич;
13 конец если
13 конец стоп
4 введено:=введено +1;
Если
5 вел(а)>=мин
(нет)
И
8 конец если;
8 а:=а+1;
9 конец вып;
(на нач.
цикла)
10 если колич >0
11 то сред:=Сум/колич;
12 иначе сред:= стоп;
13 конец если
13 конец стоп
Путь5: 1-2-3-4-5-6-8-9-2…
Новый узел 6
Путь6: 1-2-3-4-5-6-7-8-9-2…
Новый узел 7
Процедура сред;
Процедура сред;
51
1 А:=1;
1 введено :=0;
1 колич:=0;
1 сум:=0;
Вып пока
2
вел(а)
<>
стоп
1 А:=1;
1 введено :=0;
1 колич:=0;
1 сум:=0;
Вып пока
2 вел(а) <> стоп
(да)
500
и
3 введено<= 500
(да)
(да)
и
3
введено<=
(да)
4 введено:=введено +1;
Если
5
вел(а)>=мин
4 введено:=введено +1;
Если
5 вел(а)>=мин
(да)
И
6
И
6 вел(а)<=макс
(да)
вел(а)<=макс
(да)
(да)
8 конец если;
8 а:=а+1;
9 конец вып;
7 то колич := колич+1 ;
7 сум:= Сум+вел(а);
8 конец если;
(на нач.
цикла)
10 если колич >0
11 то сред:=Сум/колич;
8 а:=а+1;
9 конец вып;
(на нач.
цикла)
12 иначе сред:= стоп;
13 конец если
13 конец стоп
10 если колич >0
11 то сред:=Сум/колич;
12 иначе сред:= стоп;
13 конец если
13 конец стоп
Точки в конце пути указывают, что допускается любое продолжение
Шаг 4. Подготавливаются тестовые варианты, инициирующие
выполнение каждого пути.
Каждый тестовый вариант (ТВ) формируется в следующем виде:
Исходные данные (ИД):
Ожидаемые результаты (ОР):
Исходные данные должны выбираться так, чтобы предикатные
вершины обеспечивали нужные переключения – запуск только тех
операторов, которые перечислены в конкретном пути в требуемом порядке. Некоторые пути не могут проверяться изолированно. Такие
пути должны проверяться при тестировании другого пути. Это путь2 и
52
путь. Они являются частью тестового варианта, включающего цикл 92
ТВ 1: ИД: вел(1)=стоп. ОР: сред=стоп, другие величины имеют
начальные значения
ТВ 2: ИД: т.к. в 10 если колич >0
ответ
(да) т.е. цикл
9-2 выполнялся какое – то количество раз
2≤ а ≤500, вел(а) = корректное значение
ОР: корректное усреднение к- величин. Нужно n - величин.
ТВ 3: ИД: попытка обработки 501 –й величины. Первые 500 величин должны быть правильными.
ОР: корректное усреднение к- величин. Нужно n - величин.
ТВ 4: Д: вел(а) = корректное значение, вел(к)< мин, где а<к
ОР: : корректное усреднение к- величин. Нужно n - величин.
ТВ 5: ИД: вел(а) = корректное значение, вел(к)>мак, где а<к
ОР: корректное усреднение к- величин. Нужно n - величин.
ТВ 6: ИД: вел(а) = корректное значение
ОР: корректное усреднение n- величин.
После выполнения всех тестовых вариантов гарантируется, что
все операторы программы выполнены по меньшей мере один раз.
4 СПИСОК ЛИТЕРАТУРЫ
Основная:
1. Гайдамакин Н.А. Автоматизированные информационные системы,
базы и банки данных. Вводный курс [текст] :учебное пособие/
Н.А.Гайдамакин - М.: Гелиос АРВ, 2002. -368с.
2. Харитонова И.А., Михеева В.Д., Microsoft Access 2000.- СПб.:БХВ
– Санкт-Петербург,2000.-1088с
3. Информатика: Учебник/ под ред. проф. Н.В. Макаровой. - М.: Финансы и статистика 1997 - 768.
Дополнительная:
53
1. Смирнов М.И., Трубилин И.Т., Лойко В.И., Барановская Т.П. Автоматизированные информационные технологии в экономике М.:
Финансы и статистика. -2002.-415 с.
2. Информационные системы в экономике: Учебник (под ред. Проф.
В.В. Дика). –М.: Финансы и статистика. -1996.
3. Цветков В.Я. Геоинформационные системы и технологии. –М.: Финансы и статистика. -1998.
4. Автоматизированные информационные системы в экономике:
Учебник (под ред. Проф. Г.А. Титоренко). –М.: Компьютер – Юнити. -1998.
5. Козырев А.А. Информационные технологии в экономике и управлении. –Спб.: Изд. Михайлова. -2001. -358 с.
6. Дарахвелидзе, П.Г. Delphi – среда визуального программирования.
[текст] / П.Г. Дарахвелидзе– СПб.: BHY – Санкт-Петербург, 2002. –
352с.
7. Епанешков, А.М. Delphi. Среда разработки. [текст] / А.М. Епанешков– М.: Диалог – МИФИ, 2001. – 336с.
8. Рубенкинг,
Н.А.
Программирование
в
Delphi.[текст]
/
Н.А.Рубенкинг– Киев: Диалектика, 2000. – 304с.
54