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

Текст из файла (страница 2)

кто-что делает)

на не очень большой срок

Метафора

системы

версия

тесты

разработка

Сценарий исп. для

Основная задача для системы – определить архитектурный стиль системы

Выброс решения

Техники в XP

1) мы пытаемся спланировать операции, на которых настроен пользователь, и, если у нас есть проблема с выполнением плана, то план нужно менять.

2) Частая смена версий, много релизов.

Пользователь быстро получает хоть что-то

3) Использование метафор(несколько емких предложений)

4) Простые решения(не нужно наворотов, делай то, что хочет пользователь)

5) Постоянная переработка для улучшения када

6) Разработка на основе тестов

Сначала делаем тесты, потом код

7) Парное программирование

один – прогает

второй – под руку советует (кто, что делает решают сами динамически)

8) Коллективное владение кодом

то есть нету областей ответственности

9

1. Постоянная интеграция – как только появляется новый кусок кода, его нужно вставить в систему.

2. Код – основное средство коммуникации.

3. 40-часовая рабочая неделя, переработка не приветствуется (т. к. означает, что не вошли в график и теперь делается наспех и некачественно).

4. Включение заказчика в систему (всегда должен отвечать на вопросы «Что вы хотите».

5. Открытое рабочее пространство.

6. Изменение правил по необходимости.

C3-system проект

Задача – сделать систему, которая контролирует все о работниках некоторой компании. Через год стало ясно, что проект не удался. Потом сделали на 10 тыс. человек, но дальнейшего расширения так и не добились. Но именно тогда были написаны многие книги по основам программной инженерии.

Работа с требованиями

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

Разработанная система решает некоторую проблему => изобретение наборов функций (абстрактных характеристик) для решения проблемы – обычно именно об этом разговаривают с заказчиком («пользовательские требования») => детализация требований (каждую функцию преобразовать в отдельный документ, детально описывающий характеристики).

IEEE-830 – стандарт на требования к ПО.

IEEE-1233 – стандарт на требования к программно-аппаратной системе.

Свойства IEEE-830

1. Корректность, адекватность

2. Полнота

3. Согласованность (непротиворечивость)

4. Ранжирование по важности

5. Ранжирование по стабильности (т. е. при выполнении требований нужно учитывать вероятность, что они могут измениться)

6. Проверяемость (т. е. всегда должен существовать человек, который может сказать, правильно или неправильно работает система)

7. Прослеживаемость (требования можно привязать к каким-то элементам системы)

8. Удобство внесения изменений (должны оформляться таким образом + они описаны систематически)

9. Однозначность

Набор деятельностей

(Порядок может быть сдвинут)

1. Выделение требований

   1. Нужно выделить все возможные источники (документы / люди (пользователи, эксперты))

   2. Извлечение требований из источников:

      1. Аналитические методы (думаешь сам)

      2. Коммуникационные методы (пристаешь к тем, кто знает):

         1. опросы

         2. демонстрационные

         3. когнитивные (пытаемся максимально отвлечься от предметной области)

   3. Согласование

2. Описание и систематизация требований
   Описываются варианты использования – основной сценарий и некоторый набор альтернатив + описание результатов на выходе.
   Абстрактные варианты использования – абстрактные решения задачи.
   Детализированные варианты использования – конкретные сценарии решения задачи.
   
   Связи – по использованию – т. е. один сценарий использует другой сценарий.
   
   Любой процесс можно описать диаграммой, но более детально.
   
   DFD – диаграммы потоков данных – процессы + потоки данных + хранилища + внешние сущности.
   ERD – сущности + связи + атрибуты.
   Сущности – некоторые понятия, например, товар, заказ, клиент.
   Связи ­– обязательно / не обязательно (один к одному / один ко многим / многие ко многим).
   
   ISO-9116 – набор характеристик качества по:

   1. функциональности

   2. надежности (как часты ошибки и как дорого устраняются)

   3. производительности

   4. переносимости

   5. удобству использования

   6. удобству сопровождения

Другой способ системаизации ­– фото 13, таблица сверху.

Также бывают позитивные/негативные требования, требования при сбоях.

1. Валидация и верификация

Ошибки в ПО и борьба с ними

Ошибки есть, так как система сложная.

Основные причины ошибок

1. Неправильное понимание того, что нужно сделать.

2. Придумали неправильное решение.

3. Опечатки и прочее.

Способы борьбы

1. Много думать, проверять и перепроверять свое понимание.

2. Стандартные методы контроля качества.

Defect – ошибка любого рода (любой природы).

Failure – сбой (система себя не так повела).

Fault – ошибка в коде, которая не всегда себя проявляет.

Error – ошибка, происходящая у разработчика в голове.

Чаще всего ошибки группируются в неясных и «темных» местах.

Методы контроля качества

1. Валидация – проверка, то ли делает система с точки зрения пользователя.

2. Верификация – проверка, делает ли система то, что записано в документации

   1. Экспертиза – человек смотрит в код и ТЗ и сравнивает

   2. Статический анализ – без выполнения кода

   3. Динамический анализ – с выполнением кода

   4. Формальные методы – строгое доказательство корректности математически

Инспекция по Фагону

Есть два документа, нужно проверить, соответствуют ли они друг другу (первичный и вторичный).

1. Вводятся роли

   1. Ведущий (организатор)

   2. Инспектор (ищет несоответствия)

   3. Автор (отвечает за первичную документацию)

   4. Интерпретатор (отвечает за вторичную документацию)

2. Вводится последовательность ходов

   1. Планирование (проверка готовности документации, набор людей, планирование совещаний и т. д.)

   2. Обзор – ознакомление с первичной документацией (в формате совещания)

   3. Подготовка – инспекторы сами анализируют

   4. Совместная инспекция – совещание, где каждый рассказывает про найденные несоответствия и задает еще вопросы

   5. Исправление

   6. Контроль ­– проверка, что все хорошо

Статический анализ

1. Находим стандартное место, где делают ошибки (проблема – много ложных срабатываний)

2. Наборы эвристик (накладываются поверх пункта 1)
   В основном ошибки двух видов:

   1. false positive – ложное срабатывание

   2. false negative – не нашли ошибку

Динамический анализ

Ориентированный на особенности выполнения анализа. Самое популярное: тестирование + профилирование.

1. «Дедуктивная» верификация
   Основывается на сборе трасс и построении модели, основанной на булевых выражениях (системных вызовов или данных и т. д.)
   
   Проблема с циклами (для борьбы с этим в циклах выделяются инварианты, не влияющие на выход из цикла).
   Другая проблема ­– пользовательский ввод и взаимодействие с другими программами.

2. Проверка моделей
   Работа модели описывается автоматной моделью. Модели бывают ложными и долгими, но зато большая точность + возможность контрпримеров.
   Еще можно тестировать модель, а потом проверять соответствие ей системы.

Тестирование

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

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

1. Тесты собираются по спецификации, и чем она лучше, тем тесты лучше.

2. Проверка при реальной работе системы.

3. При тестировании проверяются заранее выбранные ситуации.

Хочется уметь выбирать тесты, чтобы их минимальное количество максимально проверяло систему.

Критерий полноты

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

Критерии могут основываться на:

1. Структуре данных

2. Структуре программы

3. Структуре требований

4. Гипотезах об ошибках

5. Мутациях программы

Архитектура ПО

Функции -> Сценарии <-> Модули / компоненты <-> Сценарии развития.

Структура системы

Набор модулей и связей между ними.

Архитектура

Общие правила (концепция).

Функциональная декомпозиция

Смотрим на функции, которые нужны от системы, и делаем, как можем. Потом пытаемся предугадать изменения системы и переделать структуру так, чтобы потом было проще менять систему.

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

От структуры зависят

1. Свойства системы

2. Распределение работ

3. Демонстрация сценария работы (общение с пользователем)

4. Конфигурации (определение того, что все модули друг с другом работают)

Software Architecture Analysis Module (SAAM)

Берется архитектура и рассматривается с точки зрения дальнейшего расширения.

Этапы:

1. Описать сценарии развития системы

2. Описать сценарии развития архитектуры

3. Оценить сценарии (можно ли внести модификации без добавления модулей)

4. Оценить архитектуру (если есть модуль, который мешается во всех сценариях, то надо что-то делать)

Оценка зависит от использованных сценариев (т. е. фактически от цели использования).

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

Широко распространенные стили архитектуры

1. Конвейер

2. Вывод – возврат

   1. Процедурная декомпозиция

   2. Абстрактные типы данных

   3. Многоуровневая система

3. Интерактивная система
   Model – View – Controller (MVC)
   Presentation ­– Abstraction – Control (PAC) – нет View контроллеров – то же, что и MVC, но иерархическая
   Интерфейс состоит из агентов. Пользователь видит Presentation. У каждого агента свои данные.

4. Хранилища

   1. Репозиторий

   2. Blackboard – обычно используется в системах с искусственным интеллектом

Характеристики

Список файлов лекций