Классификация пакетов программ. Требования к пакетам программ. Типы вариантов разработки. Каскадная модель разработки пакетов программ. Структура и состав команды программистов, страница 7

3.  Постадийная разработка. Разрабатывается вся структура модулей и программ. Как можно раньше выполняется интерфейс пользователя. Получается созданная работающая система. Пользователь формирует требования по изменению модуля (интерфейса). На каждой стадии разработки имеется готовая работающая система. При этом на следующем этапе характеристики улучшаются. Особенность: жесткие требования к тестированию каждого варианта в стадии разработки.

4.  Экстремальное программирование XP. Над программой должен работать коллектив из 2-3 человек, каждый из которых отвечает за разработку. Обычно для проверки пишут тестирующую программу, и все свои решения программисты могут проверить на тесте.

Сценарий реализации программы: разрабатываются несколько сценариев, каждый из которых можно тестировать на тестовой программе и предъявлять заказчику.

Сценарий разработки – использование данных, модулей и конкретная их реализация в рамках данного сценария (версия, вариант реализации)

Реализация проекта идёт по нескольким сценариям от самого простого к более сложному.

Так как группа маленькая, желательно организовать работу так, чтобы разработка шла постоянно в режиме контакта.

5.  Исследовательское программирование. Решается исследовательская задача. Заранее не известны ни спецификации, ни данные, ни результат. Они должны быть достигнуты в процессе разработки.

Особенности:

-  Не известен срок окончания разработки

-  Нельзя чётко определить методы, необходимые для решения этой задачи

30. Критерии оценки программ. Полнота реализации, надежность.

№	Название		Мера	Шкала
1	Полнота реализации – насколько полно реализована функция в соответствии со спецификацией		Количество реализованных функций	1-100
2	Надёжность – характеристика системы предоставления информации пользователю в заданное время	Наработка на отказ	Часы, минуты, года	0-10
		Устойчивость (наработка на отказ с использованием механизма перезапуска системы)	Часы	0-100
		Количество дополнительных операторов для реализации функции восстановления	%	0-30
		Восстанавливаемость (время. необходимое для настройки нормального функционирования ПП)	Минуты, часы, секунды	0-60
		Готовность (может быть оценена, как вероятность функционирования системы)	Вероятность	0,8-1

31. Критерии оценки программ. Эффективность, практичность.

3	Эффективность	Время отклика системы на типовое задание	Часы, минуты, сек.	0-1
		Пропускная способность (характеризуется числом заданий в ед. времени)	Кол-во заданий/ в сек, мин, час	10,20…
		Используемость ресурсов ЭВМ	%	10-100
4	Практичность	Понятливость (чёткость концепций пакета, демонстрация возможности пакета, наглядность и полнота документации – то от чего зависит понятливость)	Шкала порядка	Плохой Достаточ Хороший
		Простота использования (простота управления функциями, комфортность эксплуатации)	Шкала порядка	См. выше
		Среднее время ввода задания	Секунды	30-200
		Изучаемость ПП (трудоемкость изучения – сколько чел/часов требуется для изучения этого ПП)	Чел/час	1-10
		Продолжительность изучения	Час	1-20
		Объем эксплуатационной документации (объем электронного учебника)	Кол-во страниц	10-1000
		Привлекательность (субъективное восприятие интерфейса пользователя и интуитивно понятные алгоритмы работ)	Шкала наименования	1 – да 0 – нет

32. Критерии оценки программ. Сопровождаемость, мобильность.

5	Сопровождаемость (характеризует ПП, если в нем надо что-то менять)	Легкость анализа (возможность архитектуры, полнота, унификация интерфейса, полнота и корректность документации)	Шкала порядка	См. выше
		Изменчивость (трудоемкость внесения изменений в пакет программ)	Чел/час	1-100
		Стабильность (устойчивость к негативным проявлениям при изменении)	Шкала наименования	См. выше
		Тестируемость (возможность выявления ошибок при внесении изменений)	Чел/час	1-100
6	Мобильность (изменение условий эксплуатации)	Трудоемкость адаптации	Чел/час	1-10
		Время внесения изменений (с одного компьютера на другой, смена ОС)	Чел/час	1-10
		Простота установка (трудоемкость или время)	Чел/час, минут	1-5
		Замещаемость (возможность замены элементов программы)	Чел/час, минут	1-5

Часто оценки по этим критериям получить невозможно.

2 подхода:

-  оценка качества ПП

-  оценка процесса разработки ПП

ISO 9000 – международный стандарт качества процесса

9003, 9004 – стандарты для процесса управления качеством ПО, а ISO 9000 – оценивает все, что угодно.

Принцип Supplier Chain

ISO 9126 – оценка качества создаваемых программных продуктов. Оценивается сам процесс создания программы.

33. Модель зрелости процесса разработки программ.

Оценка зрелости процесса разработки программ. Всего 5 уровней:

1.  Начальный – нет системы управления процессом разработки, успех зависит от энтузиазма отдельных разработчиков.

2.  Повторяемый – некоторые процессы управления разработкой, график работ, отслеживается стоимость, результаты используют для аналогичных разработок

3.  Определенный – процесс стандартизован на уровне управления, документирован, не зависит от персональных программистов. В критических ситуациях не скатывается на уровень 2.

4.  Управляемый – характеризуется установленными детальными показателями качества разработки и организационные меры приводят к управлению качеством ПП

5.  Оптимизирующий. Совершенствование управления качеством, ввод механизмов, инноваций, влияющих на ПП так, что получается оптимально качество.