Технологии программирования Software engineering Евгений Александрович Мирошниченко доцент кафедры вычислительной техники, к. т. н. В США водопроводчик учится около 8 лет. И это чтобы починить мой чёртов унитаз. Ну, и сколько же вы должны учиться, чтобы вам позволили создавать программы для самолетов с сотнями людей на борту? Джеймс Коплиен

Литература, вопросы к экзамену Брауде Э. Технология разработки программного обеспечения. СПб.: «Питер», с.: ил. Брукс Ф. Мифический человеко-месяц или как создаются программные си-стемы: Пер. с англ. СПб.: Символ-Плюс, с.: ил. Орлов С.А. Технологии разработки программного обеспечения, 2-е изд. СПб.: "Питер", с.: ил. Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения. СПб.: Питер, с.: ил. Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приемы объектно-ориентированного проектирования. Паттерны проектирования. СПб.: Питер, с.: ил. Дастин Э., Рэшка Дж., Пол Дж. Автоматизированное тестирование программного обеспечения. Внедрение, управление и эксплуатация: Пер. с англ. М: Лори, с.: ил. Йордан Э. Путь камикадзе. Как разработчику программного обеспечения выжить в безнадежном проекте. М.: Лори, с.

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

Software engineering Применение систематического, упорядоченного, измеримого подхода к разработке, использованию и сопровождению ПО, то есть использование инженерного искусства в ПО. Создание подходов п. (1)

Кризис ПО Чего хотел пользовательКак было предложено организатором разработки Как было описано в техническом задании Как было спроектировано ведущим системным специалистом Как было реализовано программистами Как было внедрено

в 1995 г. ожидалось, что только 9 % проектов, выполняемых крупными компаниями, будут завершены в срок и без превышения запланированного бюджета; 52 % проектов должны были стоить в среднем 189 % от их первоначально оцененной стоимости; в то же время 31 % всех проектов вообще ожидало приостановление или полное прекращение, причем затраты на них ничем не компенсируемые убытки оценивались ни много ни мало в 81 млрд долл. Через десятилетие, в 2004 г. 18 % проектов провалились, 53 % (более половины!) не уложились в заданный бюджет или сроки, только 29 % были признаны успешными.

Сложность разработки ПО Управление сложностью суть программирования. Брайан Керниган Сложность предметной области Внутренняя сложность программ Отсутствие хороших способов представления больших систем Трудности управления процессом разработки Изменение требований к программе в процессе её разработки

Жизненный цикл программного продукта ISO/IEC 12207:2008 «System and software engineering Software life cycle processes» ГОСТ Р ИСО/МЭК Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств

Жизненный цикл Жизненный цикл (ЖЦ) программного средства есть совокупность взаимосвязанных процессов создания и последовательного изменения его состояния от формирования исходных требований до окончания эксплуатации. Процесс ЖЦ конкретный вид деятельности, систематически выполняющийся для решения определённых задач ЖЦ.

Группы процессов ЖЦ a) процессы соглашения 2 b) процессы организационного обеспечения проекта 5 c) процессы проекта 7; d) технические процессы 11 e) процессы реализации программных средств 7 f) процессы поддержки программных средств 8 g) процессы повторного применения программных средств 3

Процессы соглашения Поставка Приобретение

Процессы организационного обеспечения проекта a) процесс менеджмента модели жизненного цикла; b) процесс менеджмента инфраструктуры; c) процесс менеджмента портфеля проектов; d) процесс менеджмента людских ресурсов; e) процесс менеджмента качества.

Процессы проекта Процессы менеджмента проекта – процесс планирования проекта; – процесс управления и оценки проекта. Процессы поддержки проекта – процесс менеджмента решений; – процесс менеджмента рисков; – процесс менеджмента конфигурации; – процесс менеджмента информации; – процесс измерений.

Технические процессы a) определение требований правообладателей b) анализ системных требований c) проектирование архитектуры системы d) процесс реализации e) процесс комплексирования системы f) процесс квалификационного тестирования системы g) процесс инсталляции программных средств h) процесс поддержки приемки программных средств i) процесс функционирования программных средств j) процесс сопровождения программных средств k) процесс изъятия из обращения программных средств

Процессы реализации программных средств а) процесс анализа требований к программным средствам; b) процесс проектирования архитектуры программных средств; c) процесс детального проектирования программных средств; d) процесс конструирования программных средств; e) процесс комплексирования программных средств; f) процесс квалификационного тестирования программных средств

Процессы поддержки программных средств a) процесс менеджмента документации программных средств; b) процесс менеджмента конфигурации программных средств; c) процесс обеспечения гарантии качества программных средств; d) процесс верификации программных средств; e) процесс валидации программных средств; f) процесс ревизии программных средств; g) процесс аудита программных средств; h) процесс решения проблем в программных средствах.

Процессы повторного применения программных средств a) процесс проектирования доменов; b) процесс менеджмента повторного применения активов; c) процесс менеджмента повторного применения программ.

Модели разработки Водопадная (каскадная, последовательная) Эволюционная (итеративная, инкрементальная)

Водопадная (waterfall)

Эволюционная (IID)

Методологии разработки Последовательность работ и их содержание; артефакты, которые необходимо создавать в процессе работы: документы, диаграммы, исходные тексты и т. д.; организацию команды и ролевую ответственность специалистов; лучшие практики (best practices), позволяющие максимально эффективно воспользоваться методологией и её моделью

Методологии разработки Единая система программной документации (ЕСПД) Microsoft Solutions Framework (MSF) Rational Unified Process (RUP) Agile-методологии – Экстремальное программирование (eXtreme Programming, XP) – Adaptive Software Development (ASD), Lean Development, SCRUM, Feature Driven Development (FDD), Dynamic Systems Development Method (DSDM), Crystal Clear

Выбор и адаптация методологии Масштаб проекта Надёжность программы Распределённость команды Новизна проекта Требования заказчика Долговечность проекта

Управление проектом Управлять программистами это всё равно, что пытаться пасти котов. Грег Сетл Проект = Design = модель будущей системы Проект = Project = комплекс действий, направленных на создание продукта или услуги

Основные задачи Планирование (planning) Контроль исполнения (tracking and oversight)

Планирование Структура декомпозиции работ (work breakdown structure, WBS), или иерархическая структура работ Исполнители Время Планирование = отображение списка работ на список исполнителей во времени.

Планирование Железный треугольник (треугольник возможностей): Если жёстко задан (неизменяем) какой-то один из этих параметров, то можно варьировать одним из двух оставшихся. Последний неизбежно будет функцией двух первых. Время Деньги (ресурсы, люди) Качество (возможности, требования)

Управление конфигурацией Как организовать согласованную коллективную работу множества людей с одними и теми же файлами и документами; как хранить версии всех файлов (текстов программ, электронных документов), чтобы предотвратить потерю или порчу информации и обеспечить откат к нужной версии; как в точности определить, кто и какие изменения внёс.

Управление конфигурацией Конфигурация в данном контексте понимается как совокупность всей информации о проекте. Конфигурация физически распределена по файлам и документам проекта (состав и содержание всех материалов проекта и образует текущую конфигурацию). Как правило, это исходные тексты и бинарные файлы разрабатываемой программы и вся сопроводительная и организационная документация.

Задачи Определить что надо хранить (выполнить конфигурационную идентификацию); организовать хранение всей истории изменений; организовать согласованность внесения изменений (контроль конфигурации); организовать хранение моментальных снимков (версий) конфигурации, то есть согласованных состояний проекта в некоторые важные моменты времени.

Внедрение и управление Внедрение управления конфигурацией: выбор и внедрение системы управления версиями (version control system); разработка организационного обеспечения (регламента). Дальнейшее управление: управление составом конфигурации; управление правами доступа к системе управления версиями; разрешение проблем; резервное копирование (backup).

Оценка качества процесса разработки Насколько «правильно» данная организация производит продукцию? ISO серии 9000 CMM (Capability Maturity Model) модель зрелости возможностей ISO/IEC 15504: Information Technology Software Process Assessment = SPICE (Software Process Improvement and Capability dEtermination)

CMM (Capability Maturity Model) 1. Начальный уровень 2. Повторяемый уровень 3. Определённый уровень 4. Управляемый уровень 1. Оптимизирующий уровень

CMM 1. Начальный уровень (Initial level) В организации царит анархия при разработке, нет четких процессов управления и четких инженерных процессов. Могут существовать стандарты и инструкции, но им никто не следует. Неравномерность процесса разработки наличие затиший и авралов в работе 2. Повторяемый уровень (Repeatable level) Внедрено управление проектами, управление конфигурацией. Полная зависимость от конкретных личностей сохраняется, а организация имеет сильную тенденцию «сползания» к начальному уровню. 3. Определённый уровень (Defined level) Процессы управления интегрированы с инженерными процессами (методологий разработки) в единый стандартный документированный программный процесс. Нет деградации процесса в стрессовых ситуациях 4. Управляемый уровень (Managed level) Устанавливаются количественные показатели качества, которые собираются с помощью специального измерительного инструментария и оперативно анализируются менеджерами. Достигается полное управление проектами и предсказуемость программного процесса и качества программ. 5. Оптимизирующий уровень (Optimizing level) Организация постоянно и целенаправленно занимается улучшением существующих процессов, и делает это полностью контролируемым образом. Организация нацелена на предупреждение дефектов (defect prevention).

CMMI В 2000 г. SEI предложил сменить CMM новой, улучшенной моделью CMMI (Capability Maturity Model for Integration). CMMI фактически является обобщением CMM, поскольку рассматривает не только процессы разработки, как CMM, но и другие процессы ЖЦ (приобретение, сопровождение и т. д.) Часто используется сокращение CMM/CMMI.

Анализ требований Анализ требований представляет собой исследование предметной области, выявление роли и места будущей программной системы, её основных функций и характеристик. Формальным результатом анализа является спецификация требований (requirements/product/preliminary specification) в том или ином виде.

Основные работы при анализе Исходная постановка задачи Сбор и исследование информации – Данные о предметной области в целом. – Данные о существующих аналогах. – Данные о специфике предприятия-заказчика: специфика бизнес-процессов организации; данные об унаследованном ПО (legacy software); используемое аппаратное обеспечение; политика безопасности организации; уровень квалификации персонала. Выбор приоритетных критериев качества Определение входных, хранимых и выходных данных Формализация требований, их описание

Техническое задание ГОСТ Единая система программной документации. Техническое задание. Требования к содержанию и оформлению ГОСТ Информационная технология. Техническое задание на создание автоматизированной системы

Варианты использования Автор: Айвар Якобсон (Ivar Jacobson) Вариант использования это формальное описание взаимодействия системы и пользователя при решении конкретной задачи. Каждый ВИ нацелен на конкретную бизнес-цель (конкретную задачу). «Usage scenario» «usage case» «use case»

Варианты использования Краткий (brief) ВИ Бессистемный (casual) ВИ Детальный (detailed) ВИ – 1. Название (Name). Краткое, максимально понятное, в виде команды (что сделать). – 2. Цель (Goal). Краткая (до нескольких предложений) характеристика задачи, которую должен в результате решить ВИ. – 3. Начальное состояние (Initial state). Формулировка условий, при которых данный ВИ может быть инициирован. – 4. Основной сценарий (Main scenario). Сценарий это последовательность шагов, описывающая процесс решения задачи, которой посвящен ВИ. – 5 и т. д. альтернативные сценарии

Варианты использования Название: Отправить электронное письмо. Цель: Отправить созданное письмо с проверкой корректности его атрибутов. Начальное состояние: Выполнен ВИ «Создать новое письмо» или ВИ «Создать ответ на письмо». Основной сценарий: 1. Пользователь выполняет команду отправки письма. 2. Программа проверяет, правильно ли заполнено поле «Адрес». 3. Если нет, программа сообщает об ошибке и отменяет отправку. Конец. 4. Если да, то программа проверяет, заполнено ли поле «Тема». 5. Если нет, программа выдает предупреждение, но не отменяет отправку. 6. Программа помещает письмо в папку «Исходящие» и отсылает его. 7. После отправки программа перемещает письмо в папку «Отправленные». Сценарий обработки ошибок: Предусловие: на шаге 6 основного сценария происходит ошибка отправки письма (сбой сети и т. п.) 7. Программа сообщает об ошибке и предлагает сохранить текст письма в файл. 8. Если пользователь согласен сохранить текст, выполняется ВИ «Сохранить черновик в файл».

Виды применения ВИ Как средство фиксации функциональных требований на этапе анализа как источник информации о постановке задачи для выполнения проектирования и программной реализации системы для тестирования системы для написания пользовательской документации.

Проектирование Хороший проектировщик обязан полагаться на опыт, на ясное логическое мышление и на педантичную точность. Никакая магия здесь не поможет. Никлаус Вирт Цель преобразовать общие внешние требования к продукту в конкретные требования к внутреннему устройству и функционированию продукта.

Объекты проектирования виды проектных требований Физическая структура (physical structure) Логическая структура (logical structure); Алгоритмы (algorithms); Структуры данных (data structures); Пользовательский интерфейс (user interface).

Архитектурное и детальное проектирование Архитектурное проектирование = эскизное проектирование = концептуальное проектирование = проектирование в большом (design in large) Детальное проектирование = рабочее проектирование = техническое проектирование = проектирование в малом (design in small)

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

Декомпозиция проектируемой системы Основания декомпозиции: процедурное (алгоритмическое) и объектно-ориентированное. При процедурно- ориентированной декомпозиции выделяются процедуры, а при объектно-ориентированной классы и объекты.

Декомпозиция проектируемой системы При нисходящем проектировании (проектировании «сверху вниз», top-down design) проектирование начинается с верхнего уровня абстракции представления системы как «черного ящика». При восходящем проектировании (проектировании «снизу вверх», bottom-up design) сразу выделяется множество необходимых элементов нижнего уровня реализации, затем над ними надстраивается уровень управления. При проектировании методом расширения ядра (проектировании «от центра») выделяется базовый процесс или объект (ядро), на котором основана вся система. Проектирование ведется одновременно «вниз» (для реализации ядра на низком уровне) и «вверх» (для использования ядра на верхнем уровне).

Шаблоны проектирования То, что мы называем хаосом, просто шаблоны, которые мы не распознали. То, что мы называем случайным, шаблоны, которые мы не расшифровали. Чак Паланик Кристофер Александер (Christopher Alexander) в 1977 г. предложил язык описания шаблонов для плани­рования застройки городов и конструирования зданий. Широкое распространение шаблоны проектирования ПО получили после выхода в 1991 г. книги «банды четырёх» Эриха Гамма (Erich Gamma), Ричарда Хелма (Richard Helm), Ральфа Джонсона (Ralph Johnson) и Джона Влиссидеса (John Vlissides) «Приёмы объектно-ориентированного проектирования. Паттерны проектирования»

Шаблоны проектирования Шаблон (паттерн) проектирования представляет собой формализованное описание часто встречающейся задачи проектирования удачное решение данной задачи рекомендации по применению этого решения в различных ситуациях.

Шаблоны проектирования 1. Шаблоны проектирования классов/объектов 1.1. Структурные шаблоны проектирования классов/объектов 1.2. Шаблоны проектирования поведения классов/объектов 1.3. Порождающие шаблоны проектирования 2. Архитектурные системные шаблоны 2.1. Структурные шаблоны 2.2. Шаблоны управления Шаблоны централизованного управления Шаблоны управления, основанные на событиях Шаблоны взаимодействия с базой данных 3. Шаблоны интеграции корпоративных информационных систем 3.1. Структурные шаблоны интеграции 3.2. Шаблоны по методу интеграции 3.3. Шаблоны интеграции по типу обмена данными

Анти-шаблоны (anti-patterns) William J. Brown, Raphael C. Malveau, Hays W. McCormick III, and Thomas J. Mowbray AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis. John Wiley & Sons, ISBN

Проектирование модулей 1. Модуль есть единица структуры исходного текста программы, оформляемая, как правило, в виде отдельного файла. 2. Модуль в программных проектах является единицей ком­пи­ля­ции, описания и администрирования. 3. Модуль имеет две логически различные части: интерфейс и реализацию. Интерфейс модуля есть набор описаний (прототипов) функций и данных модуля, доступных «извне» модуля. Реализация модуля есть собственно программный код функций и данных.

Качество проектирования модулей Связность >> Зацепление

Качество проектирования модулей Достаточность интерфейса Полнота интерфейса

Проектирование интерфейса пользователя Для большинства пользователей интерфейс вашей системы и есть ваша система. Ребекка Райордан Когнитивная психология Физиология Лингвистика И др. Чтобы сделать хороший UI, необходимо понять, как человек думает, как общается, как манипулирует предметами, как запоминает и вспоминает, как догадывается, как учится, как видит, читает и пишет.

Проектирование интерфейса пользователя Интерфейсом (interface) двух объектов называется система правил и средств, соответственно регламентирующих и обеспечивающих их взаимодействие. Интерфейс пользователя (user interface) система правил и средств, соответственно регламентирующих и обеспечивающих взаимодействие пользователя и вычислительной системы в процессе выполнения данной программы.

Классификации интерфейса пользователя По типу выводимой информации, или по типу формирования изображения, отличают символьный интерфейс пользователя (character user interface, CUI) и графический интерфейс пользователя (graphical user interface, GUI). По типу управления различают командный интерфейс и визуальный интерфейс. По активной стороне выделяют классический интерфейс и интерфейс «Мастеров» (Wizards).

Характеристики интерфейса пользователя Дружественность (человечность) Предсказуемость (интуитивная понятность, очевидность). Простота Привлекательность (эстетичность) Целостность

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

Источники ошибок дизайна UI Отсутствие мотивации – Работает и ладно – И так сойдёт – Не мои проблемы – Да кого это волнует Ложная мотивация – Сделаю так «круто», чтобы все ахнули – Сделаю, как никто ещё не делал – А мне вот так интересно попробовать Плохие примеры для подражания

Примеры ошибок дизайна UI

Вот так правильно:

Примеры ошибок дизайна UI

Программирование Если отладка процесс удаления ошибок, то программирование должно быть процессом их внесения. Эдсгер Дейкстра Стандарты кодирования Оптимизация программы Безопасное программирование

Стандарты кодирования (1) Любой дурак способен писать код, который может понять компьютер. Хорошие программисты пишут код, который может понять человек. Мартин Фаулер Снижение зависимости от конкретных разработчиков Повышение сопровождаемости программ Повышение культуры программирования и снижение количества ошибок

Стандарты кодирования (2) Структурирование текста – Методы структурирования позволяют наглядно выявить соподчинённость конструкций и их группирование Разрежение текста – Методы разрежения текста позволяют облегчить чтение за счёт дополнительных пробелов (горизонтальное разрежение) и пустых строк (вертикальное разрежение) Именование объектов – Методы именования объектов включают системы именования переменных, типов, процедур и модулей Комментирование

Стандарты кодирования (3) Делайте функции небольшими Функция должна делать только одно дело Функции должны быть функционально простыми Избегайте глобальных переменных Избегайте рекурсии

Безопасное программирование Программирование есть соревнование между про­грам­мистами, делающими больше программ с все лучшей «защитой от дурака», и Вселенной, увеличивающей производство все более глупых идиотов. Похоже, что Вселенная пока выигрывает. Рич Кук Оптимистический подход Пессимистический подход – пользователь очень часто выполняет неверные и даже недопустимые действия – входные и выходные данные могут быть некорректными – созданный программистами код заведомо содержит ошибки – внешние программы и устройства постоянно подвержены сбоям

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

Безопасное программирование 1. Создавать «дуракоустойчивый» (foolproof) интерфейс. 2. Проверять корректность параметров, получаемых подпрограммой, даже если они заведомо должны быть правильными (проверка предусловий внутри подпрограммы). 3. Проверять корректность результатов, полученных в подпрограмме (проверка постусловий после вызова подпрограммы).

Безопасное программирование 4. Проверять результаты взаимодействия с внешними устройствами и программами, в особенности результаты файловых операций. 5. Проверять корректность указателей и индексов, чтобы исключить ошибки доступа к памяти. 6. Предотвращать ошибки арифметических операций (деление на ноль, корень из отрицательного числа, логарифм неположительного числа и т. п.), для чего вычислять соответствующие подвыражения отдельно и проверять их на корректность.

Дуракоустойчивый интерфейс 1. Делайте недоступными все элементы управления (кнопки, меню и т. д.), которые не должны в данный момент использоваться. 2. Где возможно, заменяйте поля клавиатурного ввода на специализированные компоненты: списки выбора (Combobox, Listbox), компоненты ввода чисел со стрелками инкремента/декремента (Spin edit), диалоги выбора файлов, папок, шрифтов и т. д. 3. В полях клавиатурного ввода широко используйте маски ввода, фильтрацию недопустимых символов и другие виды проверок корректности данных.

Дуракоустойчивый интерфейс 4. При неверном вводе данных выводите пояснения, позволяющие пользователю понять свою ошибку. 5. Для сложных задач, требующих определённой последователь­ности действий, создавайте Мастера (Wizards). 6. Затрудняйте случайное выполнение опасных операций (назначайте им более сложные комбинации клавиш, требуйте подтверждения и т. д.) 7. Обеспечивайте возможность отмены действий (команды Undo, Cancel).

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

Тестирование Знайте, что быть экспертом это больше, чем понимать, как система должна работать. Мастерство обретается исследованием того, почему она не работает. Брайан Редман Тестирование оценка/исследование правильности работы программы или выявление ошибок в программе?

Тестирование Тестирование это процесс анализа ПО, направленный на выявление отличий между его реально существующими и требуемыми свойствами и на оценку свойств ПО (IEEE Standard for Software Test Documentation). Ошибки: отклонения от спецификаций, при условии, что последние существуют и являются правильными, отклонения от требований «здравого смысла» (общесистемных требований), например, от законов математики и логики.

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

Объекты тестирования Исходные тексты программ Исполняемые модули (программы, библиотеки) Документация.

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

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

Критерии качества тестирования Не иметь ошибок это словно жить без смысла. Нет борьбы, нет и радости. Брайан Портер Критерии покрытия поведения (behavioral test coverage) – Полнота функционального тестирования Критерии покрытия структуры (structural test coverage) – Полнота покрытия операторов – Полнота покрытия маршрутов – Полнота покрытия данных

Полнота покрытия маршрутов Сто триллионов (10 14 ) маршрутов выполнения

Основные виды тестирования Автономное и комплексное тестирование Тестирование белого и черного ящика Альфа- и бета-тестирование Функциональное тестирование Регрессионное тестирование Дымовое тестирование Нагрузочное тестирование Тестирование уязвимости

Методы, используемые для тестирования Инспекция кода Многократная разработка Метод эквивалентных разбиений Метод анализа граничных значений

Метод эквивалентных разбиений X: [0;100] Поиск подстроки s в строке S Один класс допустимых значений [0;100] и два недопустимых: (–;0) и (100;+) Минимально допустимый набор классов: {s есть в S} и {s нет в S}

Метод анализа граничных значений [0;100]: {–0,00001; 0; 0,00001; 99,99999; 100; 100,00001} s в S: длина(s) = длина(S)–1; длина(s) = длина(S); длина(s) = длина(S)+1; длина(s и/или S) = 0; длина(s и/или S) = 1; s = nil; S = nil.

Средства автоматизации тестирования Системы поддержки автоматизированного модульного тестирования Системы учёта и отслеживания дефектов Генераторы тестовых данных. Системы выявления ошибок времени выполнения – неинициализированные переменные, переполнение стека, обращение по недопустимому адресу, утечки памяти Системы анализа покрытия Системы тестирования пользовательского интерфейса

Организация тестирования Задачи – подбор команды тестирования – разработка регламента тестирования – организация разработки тестов создание сценариев тестирования создание тестовых данных – контроль за исполнением регламента. Специалисты – Тест-инженер (test engineer): наиболее квалифицированный специалист, который владеет навыками планирования тестирования, разработки и проведения тестов, а также понимает предметную область – Тестер, тестировщик (test technician, test specialist) менее квалифицированный специалист, который главным образом занимается выполнением тестов

Классификация ошибок по серьёзности Если вы с первого раза написали программу, в которой транслятор не обнаружил ни одной ошибки, сообщите об этом автору транслятора. Он исправит ошибки в трансляторе. Ошибки с высокой серьёзностью – препятствуют решению важных задач – проявляются всегда или с высокой степенью вероятности. Ошибки со средней серьёзностью – препятствуют решению маловажных задач – проявляются редко, при маловероятном стечении обстоятельств. Ошибки с низкой серьёзностью – не препятствуют решению задач – скорее раздражают пользователей, чем по-настоящему мешают.

Классификация ошибок по видам деятельности, которые привели к их возникновению Ошибки анализа – не предусмотрена нужная функциональ­ность; дублирование функций; лишние функции; неверно оценены требования к техническим средствам; неверно оценены требования к производительности или переносимости. Ошибки (архитектурного) проектирования – в рамках предложенного проекта невозможно достичь требуемой в ТЗ функциональности и критериев качества. Ошибки программной реализации Ошибки документации

Некоторые интересные факты Есть два способа написания программ без ошибок; но работает только третий. Для исправления проблем, выявленных при сопровождении продукта, программисты по статистике тратят до 60 % времени, пытаясь понять документацию и логику программы. Фирмой IBM установлено, что в среднем одна ранее не обнаруженная ошибка появляется в каждых 100 операторах программы Большинство ошибок содержится в сопряжениях модулей и операторах ввода-вывода После того как проведено тестирование отдельно каждого модуля, и они объединяются в систему, в 90 % всех новых модулей и в 15 % старых необходимо вносить изменения При этом приблизительно в 15 % новых модулей и 6 % старых следует внести более 10 изменений

Документирование Документация как секс: если она качественная, это очень хорошо; если плоха, это лучше, чем ничего. Единая система программной документации (ЕСПД) ГОСТ Р ИСО/МЭК (ISO/IEC ) Программная и эксплуатационная документация может использоваться для изготовления и сопровождения программного изделия, для его тестирования (испытания), для его эксплуатации. Документирование должно начинаться одновременно с разработкой продукта или даже раньше

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

Терминология (1) a) применять общие и нетехнические термины в соответствии с их определениями, установленными в общих словарях; b) создавать глоссарии (словники), содержащие: 1) определения всех специфических и неизвестных терминов, 2) виды и определения всех обозначений и сокращений, 3) толкования непривычного использования слов, применение имен существительных в качестве наречий, 4) библиографию специализированных словарей и стандартов; c) специальная терминология должна быть основана на национальных или международных терминологических стандартах, общепризнанных словарях или согласованных глоссариях; d) каждое сокращение должно быть расшифровано при первом его появлении в тексте основной части документа;

Терминология (2) e) каждый термин должен одинаково трактоваться в документе, диалоговой информации и системной библиотеке; f) составные выражения (например, «ввод данных [data input]») должны иметь одно смысловое значение во всей документации; g) составные выражения не должны содержать более трех слов; h) одно и то же слово не должно использоваться для различных частей речи; i) все специфические и специальные термины должны использоваться в соответствующем контексте; j) термины, вводимые вне соответствующего контекста, например наименования клавиш или команды, должны быть определены в глоссарии

Физические факторы a) сокращения нецелесообразно использовать только для экономии места; b) предусмотреть необходимые места для простановки соответствующих значений, например цены; c) следует использовать стандартные графические инструментальные средства (пакеты) и избегать применения вклеек; d) избегать внесения поясняющего текста в рисунки; e) следует использовать графические символы, имеющие общепринятое смысловое значение; f) по возможности вместо словесного пояснения использовать графические изображения.

Диалоговая информация a) при наличии обратной связи с разработчиками программных средств следует обеспечить выделение диалоговой информации (текстов и сообщений) из логики программы; b) каждый блок текста или сообщение должны иметь индивидуальное идентификационное обозначение с указанием соответствующей классификационной группы данного текста или сообщения; c) конкретное программное средство не должно ориентироваться на длину, формат или расположение экранных полей ввода-вывода (input and output fields); d) для каждого понятия следует использовать отдельное сообщение. Сообщения не должны быть надуманными; e) переменные в сообщении должны содержать только непереводимую информацию, например ключевые слова и коды возврата; f) из предложений не следует исключать предлоги в целях экономии места.

Культурные факторы (1) a) иллюстративные материалы (например, лица, животные и звуки речи) должны быть независимыми от национальных культурных особенностей; b) следует избегать использования примеров, связанных со специфическими национальными традициями или особенностями (например, праздниками, банковским делом, зарплатой, спортом и т.д.); c) в тексте и иллюстрациях следует избегать использования идиоматических выражений, присущих национальному языку документатора; d) следует избегать использования юмористических выражений, особенно каламбуров. e) следует осторожно использовать иронические выражения;

Культурные факторы (2) f) необходимо избегать использования сленговых, жаргонных и простонародных выражений; g) не должны использоваться упоминания первых лиц государства; h) не следует выражать даты только в числовом виде. Месяц всегда должен быть написан полностью (например, 28 июля 1991); i) обычно следует использовать двумерные представления, если международные соглашения не требуют иного (например, для автошин, водопроводов, гвоздей и фотопленки); j) когда метрические величины располагаются вместе с величинами в других системах измерения, из контекста должно быть понятно, какая из величин относится к соответствующей системе измерений.

Выпуск Основные этапы готовности продукта: 1.Реализация базовых функций – множество возможностей ещё отсутствуют, однако все базовые уже реализованы 2. Альфа-версия – завершенный, но ещё полный ошибок продукт – имеются практически все её функции, однако некоторые могут работать крайне нестабильно – интерфейс и документация находятся в стадии доработки 3. Бета-версия – практически законченный продукт, в котором разработчики выполнили своими силами всё возможное тестирование 4. Релиз – приёмо-сдаточные испытания

Приёмо-сдаточные испытания Общее планирование испытаний : – Разработка общей стратегии испытаний системы – Календарный график проведения испытаний планирование ресурсов планирование видов испытаний планирование состава комиссии для каждого испытания Детальное планирование испытаний – Выявить условия, демонстрирующие функционирование системы с точки зрения пользователей – Подготовить демонстрационные тесты подготовить демонстрационные данные подготовить демонстрационные сценарии – Описать программу и методику испытаний

Контрольные бланки испытания Название программного продукта: Информационная система «Сеть отелей» Характеристика испытания: Заказ на бронирование места в отеле, расположенном в данном районе Дата испытания: Состав комиссии: Описание тестаОжидаемый результат Фактический результат 1Неверно задан районвыборка не должна производиться 2Район задан верно, но класс отеля назван неправильно выборка не должна производиться 3Область и класс отеля заданы вернодолжна производиться выборка 4В первом выбранном отеле есть свободные номера при бронировании будет выдано подтверждение 5В первом выбранном отеле свободных номеров нет бронирование не выполняется, перейти к следующему отелю 6В последнем из отелей, расположенных на территории данного района, есть свободные номера при бронировании будет выдано подтверждение 7Ни в одном из отелей на территории данного района свободных номеров нет заказ на бронирование отклоняется

Внедрение Испытания Исправления Опытная эксплуатация Промышленная эксплуатация

Оценка качества ПО Измеряй то, что измеримо, и делай измеримым то, что нельзя измерить. Галилео Галилей Квалиметрия: дисциплина, изучающая количественную оценку качества теоретическая: математические модели прикладная: конкретные видов объектов – географическая – педагогическая – …

Понятие качества Качество программы (quality) весь объём признаков и характеристик программы, который относится к её способности удовлетворять установленным или предполагаемым потребностям. Уровень качества функционирования (level of performance) степень, в которой удовлетворяются потребности, представленные конкретным набором значений для характеристик качества.

Свойства программного средства Функциональные свойства – Отражают возможности и специфику применения программы и обусловливают степень её соответствия своему целевому назначению. Они характеризуют программу с точки зрения того, как в действительности она выполняется. Конструктивные свойства – Характеризуют программу с точки зрения того, как в действительности она сконструирована, устроена. Более или менее не зависят от её функциональных возможностей и назначения.

Методы оценки свойств ПО ГОСТ «Оценка качества программных средств» по способам получения информации – измерительный, – регистрационный, – органолептический, – расчётный; по источникам получения информации – традиционный, – экспертный, – Социологический.

Номенклатура показателей качества ГОСТ Р ИСО/МЭК «Оценка программной продукции. Характеристики качества и руководства по их применению» Функциональные возможности (Functionality) Надёжность (Reliability) Практичность (Usability) Эффективность (Efficiencies) Сопровождаемость (Maintainability) Мобильность (Portability)

Описание методов программной инженерии «Essence: Kernel and Language for Software Engineering Methods» («Основы: ядро и язык методов программной инженерии») стандарт OMG 2013 г., созданный SEMAT. OMG (Object Management Group): консорциум по стандартам в компьютерной индустрии, основан в 1989 г. SEMAT (Software Engineering Method and Theory): консорциум по унификации теории программной инженерии, основан в 2009 г.

Ядро (Kernel) Ядро программной инженерии (Software Engineering Kernel) минимальный набор определений, который выражает суть программной инженерии способом, независимым от конкретных практик. Альфы (Alphas) ключевые понятия (essential things to work with). Типовые деятельности (Activity Spaces) ключевые типы деятельности (essential things to do). Компетенции (Competencies) ключевые способности (the abilities needed).

Ядро: Альфа Ключевой элемент, с помощью оценки состояния которого которого можно оценить прогресс и успешность проекта. An essential element of the software engineering endeavor that is relevant to an assessment of the progress and health of the endeavor. Alpha is an acronym for an Abstract- Level Progress Health Attribute.

Ядро: Типовая деятельность Заготовка (placeholder) для типовой деятельности в проекте. Называет, что должно делаться, но не предписывает как именно. A placeholder for something to be done in the software engineering endeavor. A placeholder may consist of zero to many activities.

Ядро: Компетенция Характеристика представителя стейкхолдера или члена команды с точки зрения способности к определённой работе. A characteristic of a stakeholder or team member that reflects the ability to do work.

Альфы

Альфы (область клиента) 1. Opportunity: The set of circumstances that makes it appropriate to develop or change a software system. 2. Stakeholders: The people, groups, or organizations who affect or are affected by a software system.

Альфы (область решения) 3. Requirements: What the software system must do to address the opportunity and satisfy the stakeholders. 4. Software System: A system made up of software, hardware, and data that provides its primary value by the execution of the software.

Альфы (область предпринятия) 5. Work: Activity involving mental or physical effort done in order to achieve a result. 6. Team: The group of people actively engaged in the development, maintenance, delivery and support of a specific software system. 7. Way-of-Working: The tailored set of practices and tools used by a team to guide and support their work.

Стейкхолдеры: состояния

Возможности: состояния

Требования: состояния

Система: состояния

Команда: состояния

Работа: состояния

Технология работы: состояния

StateChecklist Recognized All the different groups of stakeholders that are, or will be, affected by the development and operation of the software system are identified. There is agreement on the stakeholder groups to be represented. At a minimum, the stakeholders groups that fund, use, support, and maintain the system have been considered. The responsibilities of the stakeholder representatives have been defined. Represented The stakeholder representatives have agreed to take on their responsibilities. The stakeholder representatives are authorized to carry out their responsibilities. The collaboration approach among the stakeholder representatives has been agreed. The stakeholder representatives support and respect the team's way of working. Involved The stakeholder representatives assist the team in accordance with their responsibilities. The stakeholder representatives provide feedback and take part in decision making in a timely manner. The stakeholder representatives promptly communicate changes that are relevant for their stakeholder groups. In Agreement The stakeholder representatives have agreed upon their minimal expectations for the next deployment of the new system. The stakeholder representatives are happy with their involvement in the work. The stakeholder representatives agree that their input is valued by the team and treated with respect. The team members agree that their input is valued by the stakeholder representatives and treated with respect. The stakeholder representatives agree with how their different priorities and perspectives are being balanced to provide a clear direction for the team. Satisfied for Deployment The stakeholder representatives provide feedback on the system from their stakeholder group perspective. The stakeholder representatives confirm that the system is ready for deployment. Satisfied in Use Stakeholders are using the new system and providing feedback on their experiences. The stakeholders confirm that the new system meets their expectations.

Типовые деятельности

Компетенции