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

Страницы работы

Содержание работы

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

Лекции 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

Похожие материалы

Информация о работе