Методологии разработки ПО. Основные принципы. Инструменты. Основные ошибки планирования. Точность планирования

Методологии разработки ПО

Лекции 7,8,9

(с) , 2010

СБОР ТРЕБОВАНИЙ

(с) , 2010

Основные принципы

Заказчик всегда врет! У любого человека очень идеализированные представления о своей организованности У любого сотрудника завышенные представления о полезности своей деятельности Полная постановка стоит дороже, чем реализация и устаревает раньше окончания сбора требований

(с) , 2010

Требование должно быть:

Unitary: описывающее что-то одно Complete : полностью Consistent : непротиворечиво Atomic: без частицы «и» Traceable: с отслеживаемыми связями Current: не устаревшее и не предполагаемое Feasible: реализуемое Unambiguous: понятно описанное Mandatory: действительно необходимое Verifiable: проверяемое

(с) , 2010

Ну или с мнемоникой

Specific (конкретными) Measurable (измеримыми) Actionable (действенными) Realistic (реалистичными) Timebound (ограниченными во времени)

(с) , 2010

Важные термины

Функциональные требования Нефункциональные требования Traceability Первичные требования Сценарии использования (use cases) Пользовательские сценарии (user stories)

(с) , 2010

Инструменты

Rational RequsitePro и подобные монстры IssueTracker+Wiki в первую очередь Jira+Confluence Sharepoint Excel + Word Стикеры Голова руководителя проекта

(с) , 2010

ПЛАНИРОВАНИЕ

(с) , 2010

Чем планы отличаются

Целью Детализацией Наличием привязки к ресурсам Наличие привязки к датам Потребителями

(с) , 2010

Основные ошибки планирования

Подгонка под ответ Идеализация производительности Игнорирование рисков Страх пересмотра Невалидируемость

(с) , 2010

Точность планирования

План с учетом рисков не может быть точным Точность обеспечивается: рефлексией прошедших проектов регулярным пересмотром плана рефлексией метода оценки сроков Полезные термины: Nanopercent date Load factor

(с) , 2010

Риски

• Риск:
  1. Возможное в будущем событие, которое приведет к нежелательным результатам
  2. Сам нежелательный результат
• или
  1. Взвешенное отображение возможных результатов и связанных с ними последствий

(с) , 2010

Стандартные риски

• внутренние изъяны календарного планирования
• раздувание или изменение требований
• текучесть кадров
• нарушение спецификаций
• низкая производительность команды

(с) , 2010

Инструменты

MS Project Jira + Grosshopper Специализированные инструменты отдельных методологий Excel Листок бумаги

(с) , 2010

ДОКУМЕНТИРОВАНИЕ

(с) , 2010

Инструменты

Где хранить: Внутри кода (javadoc) Рядом с кодом (CVS) В общем доступе (Wiki) В библиотеке Необходима: история и отслеживание изменений, нотификации при изменениях

(с) , 2010

Стандартные документы

• Обзор системы
• Обзор архитектуры
• Обзор размещения
• Обзоры решений особо сложных задач
• Обзор безопасности
• Стандарты кодирования
• Регламенты
• How-to
• Лучшие практики
• Список хаков
• Планы
• Список рисков
• Персоналии

(с) , 2010

РАЗРАБОТКА

(с) , 2010

Основные артефакты

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

(с) , 2010

Требования к сборкам

• Включает весь необходимый исполняемый код
• Однозначно связан с документацией
• Однозначно связан с исходным кодом
• Описывает все внешние зависимости
• Содержит всю информацию для установки
• Содержит указание на создателя

(с) , 2010

Свойства сборки

Номер Например, 1.7.3.1093 Статус Unstable, tested, release Список изменений Bug fixes, выполненные требования Как устанавливать/обновлять Как тестировать

(с) , 2010

Как хранить исходный код

(с) , 2010

Основные термины

Commit (check out) Update (check in) Branch Tag Lock Merge Commit comment

(с) , 2010

Стратегии работы с кодом

Разработка в trunk Все изменения осуществляются в trunk Каждая сборка – свой тэг Багфикс в бранчах или тегах с объединением в trunk Один поток существенных изменений Простота в управлении Разработка в branch По ветке на каждую крупную задачу и/или релиз Багфикс в бранчах Сколько угодно потоков изменений Сложность в управлении

(с) , 2010

От кода к сборке

• Сборка должна осуществляться одной кнопкой
• Все зависимости сборки должны быть включены в сборку
• Автоматическое тестирование неплохо бы проводить в процессе сборки
• Инструменты сборки: ant, maven, make, ivy, DebCreator etc
• Инструменты управления: CruiseControl, TeamCity
• http://en.wikipedia.org/wiki/Continuous_Integration#Software

(с) , 2010

ТЕСТИРОВАНИЕ

(с) , 2010

Основные методы тестирования

Статическое тестирование Ревью кода Автоматический анализ кода Динамическое тестирование Unit testing Integration (module) testing System testing

(с) , 2010

Термины

Регрессионное тестирование Приемочное тестирование Альфа и бета тестирование Черный и белый ящик Test plan Test suite Test case

(с) , 2010

Особенные виды тестирования

Нагрузочное тестирование load, stress, endurance, etc Тестирование интерфейса Тестирование надежности Тестирование безопасности

(с) , 2010

ОРГАНИЗАЦИЯ ВЫКЛАДКИ/ВЫПУСКА

(с) , 2010

Какие бывают продукты (напомним)

Внутренние корпоративные системы Публичные сервисы Коробка с железкой Коробка с софтом

(с) , 2010

Особенности выпуска продукта

• Для коробочных продуктов
  • Тестирование процедуры установки/удаления в различных средах
  • Высокая стоимость ошибки после выпуска
  • Организация процесса внесения изменений и исправления ошибок
  • Обеспечение обратной связи

(с) , 2010

Особенности выкладки сервиса

• Нужно ответить на вопросы
  • Зачем выкладываем
  • Какие риски
  • Когда выкладываем
  • Как выкладываем
• Особо думать о
  • Выкладка в кластере
  • Изменение внешних интерфейсов

(с) , 2010

Практики

Обратная совместимость Возможность отката Частичная выкладка Постоянный мониторинг

(с) , 2010

ПРОЕКТИРОВАНИЕ

(с) , 2010

Современные концепции и подходы

OOP Шаблоны проектирования Фреймворки (каркасы) IoC MVC ORM RCP Программирование в XML Multithreading Стандарты defacto

(с) , 2010

Слои и уровни

Layer – способ разделение ответственности по модулям (логическое) Tier – способ разделения ответственности по серверам (физическое) Много – это больше 3х

(с) , 2010

Несколько терминов

Legacy CRC (Class-Responsibility-Collaboration) card Vendor lock SOA Opensource XML AJAX

(с) , 2010

Критерии архитектуры

Простота Модифицируемость Тестируемость Повторное использование Минимальность

Надежность Производительность Масштабируемость Безопасность

(с) , 2010

Как хранить данные

Файловая система Базы данных реляционные ключ-значение специализированные объектные

(с) , 2010

Стратегии работы с БД

БД как простое хранилище ORM Entity-Attribute-Value Blob БД как слой работы с данными Партицирование данных Шардинг

(с) , 2010

Основные выборы

Выбор языка Толстый или тонкий клиент Выбор БД Выбор каркаса Выбор уровней логики и презентации Выбор ОС Выбор железа

(с) , 2010

Стандартные решения

Кэширование Кластеризация (HA и LB) Шардинг Message Queue Асинхронные операции JSON

(с) , 2010

Несколько практик и советов 

Design review Прототипирование Читайте хорошие книжки Архитектор должен продолжать программировать Лучше использовать стандартные решения Не стоит доверять обещаниям вендоров

(с) , 2010

Что нас ждет

Functional Programming DSL Cloud’s Grid’s SaaS Проектирование онтологий Non-relational storage ….

(с) , 2010

Ресурсы

wikipedia.org rsdn.ru LiveJournal.com w3c.org Ibm.com Msdn.com google.com …

(с) , 2010