Конспект по качеству / Часть1. Страницы 1-12

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

1. Задать цель проекта

2. Задать стратегию разработки

3. Указать выполняемую работу

4. Указать риски и планы их уменьшения

5. Указать необходимые ресурсы

6. Назначить ресурсы

7. Указать компоненты продукта

8. Разбить проект на небольшие и поддающиеся определению задачи

9. Задать календарный план

10. Установить критичесчкие пути

11. Указать каких стандартов придерживаться

Виды деятельности по отслеживанию проектов:

1. Использование основных и второстепенных контрольных точек по отселижванию работы

2. Обнаружение потенциальных проблем

3. Реализация плана восстановления

4. Сравнение результата проекта с получившимися результатами

Конфигурационный менеджмент (SCM) позволяет контролировать сложность среды разработки ПО и целостность компонентов по мере того, как они исполняются в течении жизни разработки. Стандарты позволяют отслеживать исходный код, требования, тестовые примеры, руководство пользователя, проектную документацию. Виды деятельности SCM:

1. Координирование работы множества людей

2. Предоставление средств для выяснения состояния продукта

3. Поддержка множественных и параллельных потоков разработки

4. Получение контрольного следа изменения

5. Управление версиями

6. Управление конфигурацией

7. Управление внесением изменений (процесс, в ходе которого инициируется, подтверждается и наблюдается ход изменений)

8. Управление выпуском (автомтизированный процесс выпуска, в котором известно что и на каком уровне система содержит).

Менеджмент процессов. Позволяет оценить виды деятельности по разработке ПО путем отслеживания видов развития компонентов по фазам Ж/Ц разработки компонентов.

Отсутствие упрваления конфигурациями приводит к:

1. Проблемы обнаруженные ранее появляются вновь

2. Специальные файлы и функции отсутствуют при выпуске продукта

3. Изменения не сохраняются

Обеспечение качества ПО.

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

1. Задание плана качества

2. Проведение пересмотра ПО

3. Подтвреждение того, что существуют методы внесения контролируемых изменений документов и в исходный код

4. Аудит ПО на предмет соответсвия стандартам

5. Сбор метрик качества ПО

6. Оценка методов разработки и тестирования ПО

Аудит – назависимая оценка артифактов проекта, проверка соответствия разработки ПО утвержденным стандартам и нормам. Бывают внутренние и внешние. Обеспечение качества ПО оценивает качество процесса.

Пересмотр: осознать и удалить дефекты на стадии разработки, то есть перед написанеим кода, просматривая все артефакты по мере их создания: требования проекта, тестовые примеры, код если он написан. Пересмотр и аудит помогают устранить дефекты как можно раньше и предотвратить их распостранение на другие этапы разработки.

Наиболее окупаемыми являются проверка требований и документов проектирования. Типы пересмотров:

1. Технический пересмотр – утвердить или прокументировать рабочий продукт

2. Ознакомление. Проводится при содействии конструктора. Играет роль тренировочного инструмента, с помощью которого изучается рабочий продукт

3. Аудит ПО. Наиболее строгий вид пересмотра, следует формально структурированным процессам: использование таблицы контрольных проверок, назначение специфических ролей участникам, сравненем рассматриваемых элементов со стандартами, проведение доп. аудитов, состоавление отчетов по аудитам, хранение записей для описания слабых мест, составление статистики для измерения эфективности процесса аудита.

Среда тестирования ПО Требования -> Тестирование системы

Технические требования на проект -> тестирование компонентов

Технические тредования к элементам -> тестирование элементов

Элемент – наименьший компонент, кот можно скомпилировать

Поэлементное тестирование – тестирование изолированной проверки каждого отдельного элемента путем запуска тестов в искусственной среде, для этого используются драйверы и заглушки. Загрузка заменяет недостающий компонент, который вызывает элемент выполнения следующих действий: возвращает к элементу не выполняя других действий, возвращается пост значение.

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

Регрессионное тестирования – повторное использование тестов в новой версии приложения.

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

Требования

Требования. В требованиях описываются возможности системы с позиции пользователя. Тербования служат основой для проектирования, в которых описываются способы удовлетворения требования системой. Системные требования касаются внутреннего интерфейса, проектных ограничений, вопросов технических характеристик. К ним отсноится точность, выбор времени. Хоршие требования проверямы и не двусмыслены. К ним можно записать несколько примеров. Требования это основа, по отоношению к которой оценивается коненый продукт. При тестировании ПО требования необходимы для задания тестовых примеров, путем определения входных и выходных условий и создания сценариев. На ранней стадии проекта пересмотр требований помогает установить являются ли требования адекватными. Требования это описание функциональных возможностей и ограничений, накладываемых на программную систему, называется требованиями к этой системе. Сам процесс формирования анализа и документирования, и проверка этих функциоанльных возможностей и ограничений – это разработка требований. Документ, содержащий требования - это описание для разрабываемой ОС. Структура спецификаций требований:

1. Определить круг лиц, для которых этот документ, описываются предыдущие версии, изменения в предыдущих версиях

2. Введение, обоснование, краткое перечисление системных функций, описание работы системы с другими системами.

3. Глоссарий.

4. Пользовательские требования

5. Системная архитектура – распределение системных функций по компонентам.

6. Системные требования – функциональные и нефункциоанальный

7. Системные модули – взаимоотношения между системами и ее компонентами, между системой и ее окружением

8. Эволюция системы – прогнозирвование изменений в аппаратных средствах

9. Приложения

10. Указатели

Виды требований:

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

2. Системные требования – детализированное описание системных функций.

3. Проектно-системная спецификация – это дополнение, более детальное изложение системных требований

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

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

Проектная системная спецификация: специалисты организации заказчика, разработчики системной архитектуры.

Функциональные и нефункциональные требования. Функциональные требования: перечень сервисов, которые должна выполнять система, перечень возможных входных данных, указания, что система не должна делать. Нефункциональные требования – описывают характеристики системы и ее окружения, а не поведение системы. Нефункциональные требования: требования к продукту, организационные требования, внешние требования. Требования к продукту: к эксплуатации, к надежности, к переносимсоти, к эффективности. Организационные требования: выходные требования, требования на реализацию, требования на стандарты. Внешние требования: требования на взаимодействие, этические требования, юридические требования. Системные требования – более детальное описание пользовательских требований.

Система записи системных требований:

1. Структурированный естественный язык

2. Язык написания программ

3. Графические аннотации

4. Математическая спецификация.

Формальная спецификация в процессе разработки ПО:

1. Пользовательские требования

2. Спецификация программных систем

Два подхода к разработке формальной спецификации: 1)алгебраический подход, при котором система описывается в терминах операций и их отношений, 2)ориентированный на моделирование. Специфицирование интерфейса:

1. Структурирование спецификации – это представление неформальной спецификации интерфейса в виде множества абстрактных типов данных или объектных классов

2. Именование спецификации

3. Определение операций

4. Неформальная спецификация операций

5. Определение синтаксиса операций

6. Определение аксиом

Идентификация тестовых примеров

1. Идентификатор примера

2. Версия приложния

3. Врерсия аппаратного обеспечения

4. Машина для тестирования

5. Результат тестирования

6. Дата проведения

7. Имя тестера

8. Номер отчета о проблеме

Сокращение числа тестовых примеров

Схема приоритетных категорий:

Расстановка приоритетов – некий компросс. Тестеры сами выбирают, что реализовывать.

Ключевые понятия:

1. Какие функции нужно протестировать

2. Как непротетируемые функции повлияют на качество продукта

Оценивается время выполнения тестов любой категории, сравнивается с выделенным временем, если не входит в рамки, то разбивается снова.

Пример: 1-ая группа – тест должен быть пройден

2-ая группа – должен быть выполнен до выпуска

3-ая группа – выполняется, если позволит время

4-ая группа – можно подождать до следующего выпуска или провести вскоре после выпуска

5-ая группа – вероятностнее всего этот тест никогда не будет пройден