- •Основные требования к методологии проектирования программного обеспечения
- •Основные требования к методикам и методам проектирования ПО
- •Сложная система.
- •Разработка технического задания.
- •Диаграмма Use-Case (диаграмма прецедентов)
- •Методология быстрой разработки приложений – RAD.
- •Структурный подход в проектировании.
- •Методология Гейна/Сарсона.
- •Нотация Йордена/Де Марка
- •Синтаксис графического языка IDEF0.
- •Модель IDF3
- •Типы отношений.
- •Диаграмма атрибутов
- •Диаграмма потоков данных (ДПД, DFD)
- •Методология RUP и пример ее использования на простом примере о торговой фирме.
- •Спецификации прецедента «обновить данные из внешней системы».
- •Возможные отношения между сценариями.
- •UML, разновидности предметов, существующих в UML.
- •Операции
- •Группировка
- •Множественность. Как ее обозначить?
- •Реализация
- •Деревья наследования
- •Автомат
- •Диаграмма деятельности.
- •Зацикливание, выбор вариантов и циклы.
- •Оценка производительности распределенных информационных систем на этапе проектирования
- •Модели реализации.
- •Компонентная диаграмма
- •Computer-Aided Software/System Engineering (CASE)
- •Критерии классификации CASE-систем.
- •Тестирование ПО
- •Этапы тестирования.
- •Нагрузочное и предельное тестирование
- •Интеграционное тестирование при структурном подходе к программированию.
- •Тестирование при объектно-ориентированном подходе.
- •Сложность тестирования интеграционного класса.
- •Структурное тестирование программного обеспечения
- •Способ тестирования базового пути.
- •Потоковый граф
- •Графы и отношения
- •Отношения (симметричность, транзитивность)
- •Тестирование циклов
- •Тестирование очередей и потоков данных.
- •Как тестировать очереди.
- •Тестирование потока транзакций.
- •Тестируем декларацию.
- •Лекция 03.05.2011
- •Международные стандарты на разработку ПО
- •Стандарты, регламентирующие документирование программных средств и баз данных.
- •Профиль стандартов документирования объектов
- •Эксплуатационная документация
- •Исследовательская документация
- •Пользовательская документация
- •Лекция 10.05.2011
- •Характеристики качества программных средств
- •Модель качества ПП
- •Основные количественные характеристики программных средств и их атрибуты
- •Основные качественные характеристики программных средств и их аттрибутов.
- •Пример требований к количественным характеристикам качества программного средства.
- •Характеристики качества баз данных.
- •Жизненный цикл профилей стандартов
Лекция 10.05.2011
Характеристики качества программных средств
Международный стандарт ISO 9126:1-4 (1991г.), переиздан в 2002г. В качестве российского ГОСТа утвержден:
ГОСТР-1993г. IT. Оценка программного продукта. Характеристики качества и руководство по их применению:
Ч.1. Модель качества Ч.2. Внешние метрики качества ПП. Ч.3. Внутренние метрики
Ч.4. Метрики качества в использовании. Метрики характеристик качества отражают:
внешние качества – заданные требованиями заказчика в спецификациях и …;
внутренние качества – проявляются в процессе разработки и др. этапов жизненного цикла;
качество при использовании вашего ПП в процессе эксплуатации и результативность достижения потребностей пользователя с учетом затрат ресурсов.
Модель качества ПП
Модель характеристик качества состоит из 6 базовых показателей:
1.Функциональные возможности:
пригодность для применения по назначению;
корректность (правильность, точность) реализации требованиям;
способность к взаимодействию с компонентами и средой;
защищенность, безопасность функционирования.
2.Надежность ПП:
степень завершенности;
степень тестированности |
; |
устойчивость при наличии дефектов и ошибок;
восстанавливаемость после проявления дефектов (restart);
доступность, т.е. готовность реализации требуемых функций.
3.Эффективность ПИ рекомендуется отражать:
субвременнóй эффективностью реализации программ;
используемостью вычислительных ресурсов.
4.Применимость (практичность) ПИ:
понятность функций и сопроводительной документации;
простота использования комплекса программ;
простота изучения процесса функционирования и освоения.
5.Сопровождаемость:
анализируемость, т.е. удобство для анализа предложений модификации;
изменяемость компонентов и всего комплекса программ;
тестированность изменений при сопровождении.
6.Мобильность (переносимость):
адаптируемость к изменениям среды;
простота установки – инсталляций после переноса;
замещаемость компонентов при корректировке программ.
Характеристики, субхарактеристики и атрибуты качества ПП имеют 3 уровня детализации:
1.Категорийно-описательные – это описательные характеристики функций, категории ответственности защищенности и важности информационных потоков в вашей системе.
2.Количественные показатели – измеряемые характеристики, измеряются часами, метрикой, номинальной шкалой.
Романова Т.Н. – Технология программирования [2011]by Melvin |
Страница 58 |
3.Качественные – несколько упорядоченных свойств, которые характеризуются некоторыми субъективными оценками: хорошо, плохо, да, нет.
Основные количественные характеристики программных средств и их атрибуты
Характеристики качества |
Мера |
Шкала |
|
I. Надежность ПИ |
|
|
|
1. |
Завершенность: |
|
|
- наработка на отказ при отсутствии рестарта |
Час |
10-1000 |
|
- степень покрытия тестами функций и структуры |
% |
50-100 |
|
программного изделия |
|
|
|
2. |
Устойчивость |
|
|
- наработка на отказ при наличии автоматического |
Час |
10-1000 |
|
рестарта |
|
|
|
- относительные ресурсы, отведенные на |
% |
10-90 |
|
обеспечение надежности и рестарта |
|
|
|
3. |
Восстанавливаемость системы |
|
|
- длительность восстановления |
Мин. |
0.1 - 10 |
|
4. |
Доступность-готовность |
|
|
- относительное время работоспособности |
вероятность |
0.9-0.999 |
|
функционирования |
|
|
|
II. |
Эффективность |
|
|
1. |
ВременнАя эффективность |
|
|
- время отклика получения результата на типовое |
Сек. |
0.1-100 |
|
задание |
|
|
|
- пропускная способность – число типовых заданий |
Число запросов |
1-1000 |
|
в единицу времени |
в минуту |
|
|
2. |
Используемость ресурсов: |
|
|
- относительная величина используемости ресурсов |
вероятность |
0.7-0.95 |
|
ЭВМ, используемых программой |
|
|
Основные качественные характеристики программных средств и их аттрибутов.
|
Характеристики |
Мера |
Школа |
Приоритет |
|
|
|
|
|
|
|
(1-10) |
|
|
Практичность |
Порядковая |
Отл. |
1-10 |
|
|
|
1. |
Понятность: |
|
Хор. |
|
|
|
- четкость концепции программных средств |
|
Удовл. |
|
|
|
|
- демонстрационные возможности |
|
Неуд. |
|
|
|
|
- наглядность и полнота документации |
|
|
|
|
|
|
2. |
Полнота использования |
Порядковая |
Отл. Хор. |
1-10 |
|
|
- простота управления функциями программной |
|
Удовл. Неуд. |
|
|
|
|
системы |
|
|
|
|
|
|
- комфортность эксплуатации |
|
1-1000 |
|
|
|
|
- среднее время ввода заданий |
Сек. |
1-1000 |
|
|
|
|
- среднее время отлика на задание |
Сек |
|
|
|
|
|
3. |
Изучаемость |
Челокеко- |
1-100 |
|
|
|
- трудоемкость освоения ПС |
часы |
|
|
|
|
|
- продолжительность изучения |
Час |
1-100 |
|
|
|
|
- объем эксплуатационной документации |
Стр |
10-1000 |
|
|
|
|
- объем электронных учебников |
Кбайт |
100-10 00 |
|
|
|
|
4. |
Привлекательность |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Романова Т.Н. – Технология программирования [2011]by Melvin |
|
Страница 59 |
|
- субъективные или экспертные оценки. |
|
|
|
|
|
|
|
Лекция составлена Никифоровым |
Михаилом в 2011 году. |
Сопровождаемость |
Порядковая |
Отл., хор., |
|
|
3. |
Анализируемость |
|
уд., неуд. |
|
- стройность архитектуры программного средства |
|
|
|
|
- унифицированность интерфейса |
|
|
|
|
- полнота и корректность документации |
|
|
|
|
4. |
Изменяемость |
Человеко- |
|
|
- трудоемкость подготовки изменений |
часы, |
1-1000 |
|
|
- длительность подготовки изменений |
Часы |
1-1000 |
|
|
5. |
Стабильность |
|
|
|
- устойчивость при негативных проявлениях при |
Порядковая |
Отл,ХУНеуд |
|
|
изменениях |
|
|
|
|
6. |
Тестируемость |
|
|
|
- трудоемкость тестирования изменений на этапе |
Человеко- |
1-1000 |
|
|
сопровождения |
часы |
|
|
|
- длительность тестирования изменения |
Часы |
1-100 |
|
|
|
Хрень какая-то. |
|
|
Упс-пупс-тра-ля-ля |
Мобильность |
|
|
|
|
1. |
Адаптируемость |
|
|
|
- трудоемкость адаптирования |
Чел-час |
1-100 |
|
|
- длительность адаптации |
Час |
1-100 |
|
|
2. |
Простота установки: |
|
|
|
- трудоемкость установки |
Чел-час |
1-100 |
|
|
- длительность установки |
Час |
1-100 |
|
|
3. |
Замещаемость |
|
|
|
- трудоемкость установки |
Чел-час |
1-100 |
|
Романова Т.Н. – Технология программирования [2011]by Melvin |
Страница 60 |
Пример требований к количественным характеристикам качества программного средства.
Надежность.
Сколько нужно наработать наработать на отказ системе, чтобы она считалась надежной.
-завершенность – наработка на отказ при работе без рестарта.
-устойчивость – требуемое значение 50 часов.
-восстанавливаемость – длительность восстановления в минутах. Требуется 5 минут.
-доступность – вероятность доступности 0.998
-эффективность – не более 5 секунд.
-время отклика – время получения результата на получение типового задания – 5 секунд.
-пропускная способность – не менее 20 типовых заданий в минуту.
-используемость ресурсов – вероятность использования ресурсов ЭВМ – 0.8. Т.е. если пользователь работает с программой, которая использует ресурсов меньше 0.8, то программа не эффективна.
Практичность
–среднее время ввода заданий, среднее время отклика заданий. Не более 10 секунд.
–среднее время ввода заданий не более 10 секунд.
Изучаемость
–трудоемкость – не более 200 человеко-часов
–время изучения – не более 50 часов
–объем эксплуатационной документации 50
Сопровождаемость
–трудоемкость подготовки изменений - 10
–длительность подготовки изменений – не более 5
Тестируемость
–трудоемкость тестирования изменений – 20
–длительность тестирования изменений – не более 5.
Мобильность
–трудоемкость адаптации к новой платформе – не более 50 человеко-часов
–длительность адаптации – не более 10.
Инсталляция
–трудоемкость установки – не более 10 ч-часов.
–длительность установки – не более 5 часов
Замещаемость
–трудоемкость – 50
–длительность – 10.
Характеристики качества баз данных.
Стандарт ISO 9026 подробно описывает характеристики качества каждой из баз данных. Базу данных можно рассматривать как два независимых компонента:
1.СУБД (для управления данными)
2.Сами данные, которые структурирую по определенным данным.
Поскольку задач много, данные разнообразны, поэтому всеми данными нельзя управлять только одной СУБД, поэтому появилось их столько. У них разные модели управления данными. Для каждой модели существует свой класс системы управления базы данных. Чаще всего используем реляционную модель.
Как тестировать базу данных? Выбрали Oracle. Протестированная… навороченная… все может. Построили свою БД. Кэшировали какие-то запросы и т.д. Приступаем к тестированию. Что следует тестировать?
Романова Т.Н. – Технология программирования [2011]by Melvin |
Страница 61 |