Интернет-скорость развития - Internet-Speed Development
Интернет-скорость развития является Гибкая разработка программного обеспечения метод разработки с использованием комбинированного спиральная модель /модель водопада с ежедневными сборками, направленными на разработку продукта с высокой скоростью.
Он был разработан в конце девяностых, потому что разработка программного обеспечения быстро менялась. У компаний были проблемы с поставкой продуктов с правильными требованиями в сроки, запланированные для проекта, и поэтому они переходили на более гибкие методы разработки программного обеспечения. Более подробную информацию о том, как был разработан метод интернет-скорости, можно увидеть на эволюционной карте в статье Абрахамссона.[1]
Основные идеи, лежащие в основе развития скорости Интернета
Часто одна из самых больших проблем в разработке программного обеспечения заключается в том, что требования меняются быстро, и метод разработки со скоростью Интернета был создан для адаптации к этой ситуации. Идея состоит в том, чтобы объединить два основных стандарта в моделях программной инженерии, а именно спиральную модель и модель водопада, в новую модель и основать новый метод разработки программного обеспечения на этой новой модели. Основным недостатком модели водопада было то, что она была очень жесткой и не очень гибкой, когда дело касалось изменений требований, а недостатком спиральной модели было то, что она была не очень структурированной. Идея развития скорости Интернета заключается в том, что комбинация этих моделей приведет к методу, который не имеет этих недостатков и является лучшим методом для использования в ситуациях, когда требования могут быстро меняться, но проект должен выполняться в структурированном виде. путь.
Цель метода
Цель метода разработки со скоростью Интернета - позволить разработчикам программного обеспечения выполнять проект в структурированном виде, но при этом иметь возможность адаптироваться к потребностям заказчика. Его цель - предоставить программный продукт в короткие сроки за счет интенсивной разработки. Этот метод предоставляет средства для доставки полностью реализованной системы, а также позволяет определять прогресс в проекте с помощью контрольных точек. Одна из основных версий этого метода создана Microsoft и называется Microsoft Solutions Framework.
Концепции, лежащие в основе метода развития скорости Интернета
Первая концепция, которая очень важна для развития скорости Интернета, - это создание видения и объем (управление проектом). Это означает, что в начале проекта создается глобальное определение системы, в котором объясняется, какой должна быть система, и что входит в ее объем, а что нет. Это один из основных шагов, так как он дает разработчикам некоторые рекомендации относительно того, какой будет система без замораживания каких-либо требований. Объем может быть задокументирован в Изложение концепции.
Еще одна очень важная концепция этого метода - управление объемом. Объем необходимо контролировать на протяжении всего проекта, чтобы предотвратить ползучий прицел что приводит к задержкам. Объем будет определен заранее, и изменения в объеме (например, добавление дополнительных функций, которые сначала считались выходящими за рамки проекта) будут оценены и либо приняты, либо отклонены. В объем можно внести изменения, но это всегда будет зависеть от компромисса между функциями, ресурсами и временем.
Метод разработки, основанный на скорости интернета, сильно отличается от традиционных методов и поэтому использует принципы гибкого метода. Он ориентирован на адаптацию к требованиям и, как таковой, основан на основных принципах гибкой разработки программного обеспечения.
Интернет-разработка также фокусируется на использовании единой фиксированной архитектуры фреймворка, на основе которой создается продукт, и в значительной степени полагается на инструменты для увеличения скорости разработки.
Еще одна базовая концепция разработки со скоростью Интернета заключается в том, что она также ориентирована на использование небольших команд. Идея состоит в том, что все проекты можно разделить на более мелкие мероприятия, которые часто можно выполнять параллельно. Небольшие группы часто могут быть более сосредоточены на своей задаче, и легче определить подотчетность и отслеживать прогресс в рамках проекта.
Последняя концепция, обсуждаемая в этой статье, посвященная развитию со скоростью Интернета, - это концепция параллельной разработки. Эта концепция в основном означает, что вся разработка программного обеспечения выполняется параллельно как можно чаще. Это обеспечит очень быструю разработку и позволит небольшим командам максимально сосредоточиться на своих функциях, что дает хороший результат по качеству. Однако для того, чтобы небольшие команды работали вместе над созданием окончательной системы, необходимо часто синхронизировать их разработку. Это можно сделать с помощью ежедневные сборки Это означает, что все разработчики проверяют свой код в конце дня, после чего создается сборка, которая затем может быть оценена и протестирована для отслеживания прогресса. После того, как функция завершена, необходимо протестировать и доработать встроенную функцию, что иногда называется процессом синхронизации и стабилизации. Разработанные функции синхронизированы со сборкой и протестированы. После этих тестов все ошибки будут исправлены, и функция может быть улучшена для улучшения работы (что является частью стабилизации).
Разработка интернет-скорости основана на принципах гибкой разработки и, как таковая, имеет много общего с Экстремальное программирование, рациональный унифицированный процесс, DSDM и Разработка, управляемая функциями. Однако развитие скорости Интернета отличается от этих методов, поскольку оно также включает более обширное планирование управления рисками и имеет качество как очень важную цель проекта.[2] Этап разработки скорости Интернета также показывает некоторое сходство с программное обеспечение с открытым исходным кодом модель разработки, потому что многие разработчики по всему миру могут участвовать в процессе разработки благодаря общению через Интернет и использованию репозиториев для хранения кода и документации.
Этапы развития интернет-скорости
Модель этого метода выглядит так:
Рисунок 1: Фазовая модельЭта модель показывает пять основных этапов метода. Эти этапы будут объяснены в следующих разделах этой статьи. Это следующие этапы: видение, планирование, разработка, стабилизация и развертывание. После завершения этого цикла версия системы готова, и начинается новый цикл для создания новой версии. Фазы объяснены в следующих разделах и показаны через мета-моделирование техника. Более подробную информацию о множественности и концепциях в контексте проекта можно будет увидеть позже в общей модели данных.
Фаза видения
Фазу видения можно смоделировать следующим образом:
Рисунок 2: Представление фазы процесса / модели данных
| Мероприятия | Определение (источник) |
|---|---|
| Анализировать требования | На этапе планирования бизнес-требования должны быть идентифицированы и проанализированы. «Они более тщательно уточняются на этапе планирования». (Модель процесса MSF)[3] |
| Определите цели и ограничения | «Представление, создавая общее представление о целях и ограничениях проекта». (Модель процесса MSF)[3] |
| Форма Команда | Формирование основной команды. |
| Создать видение / объем | «Подготовка и доставка документа о видении / объеме работ». (Модель процесса MSF)[3] |
| Создать оценку рисков | «На этапе прогнозирования команда готовит документ о рисках и представляет основные риски». (Модель процесса MSF)[3] |
Таблица 1: Видение деятельности
Основные действия, выполняемые на этапе прогнозирования, - это анализ требований, формирование команды для проекта, определение рисков и объема проекта. На основе требований и целей проекта создается документ Vision / Scope. В этом документе описывается, каким будет продукт на момент доставки. Он не содержит очень подробных функций продукта.
| Концепция | Определение (источник) |
|---|---|
| ВИДЕНИЕ / ОБЪЕМ ДОКУМЕНТОВ | «Документ, определяющий видение и масштаб». (Модель процесса MSF)[3] |
| ЗРЕНИЕ | “Зрениебезграничный взгляд на то, каким может быть решение ». (Модель процесса MSF)[3] |
| ОБЪЕМ | “Объем определяет части видения, которые могут быть выполнены в рамках ограничений проекта ». (Модель процесса MSF)[3] |
| ДОКУМЕНТ ОЦЕНКИ РИСКА | «Стандартный документ для оценки рисков» (Дисциплина управления рисками MSF)[4] |
| ПРИОРИТЕТНЫЙ СПИСОК РИСКОВ | «Подробная информация о рисках, включая состояние проекта, контекст, основную причину и метрики, используемые для определения приоритетов (вероятность, воздействие, подверженность), часто записывается для каждого риска в форме заявления о рисках». (Дисциплина MSF по управлению рисками)[4] |
| ПЛАНИРОВАНИЕ РИСКОВ | «Перевод списка приоритетных рисков в планы действий». (Дисциплина управления рисками MSF)[4] |
| СТРУКТУРА ПРОЕКТА ДОКУМЕНТ | «Документ о структуре проекта включает информацию о том, как организована команда, кто какие роли и какие обязанности выполняет. В документе о структуре проекта также разъясняется цепочка подотчетности перед заказчиком и обозначенные точки контакта, которые команда проекта имеет с заказчиком. Они могут варьироваться в зависимости от обстоятельств проекта ». (Модель процесса MSF)[3] |
| КОМАНДА ОРГАНИЗАЦИИ | «Информация о том, как организована команда». (Модель процесса MSF)[3] |
| КОНТАКТНЫЕ ТОЧКИ | «Назначенные точки контакта, которые команда проекта имеет с заказчиком». (Модель процесса MSF)[3] |
| РОЛИ КОМАНДЫ | «Определение того, кто какие роли играет и имеет определенные обязанности». (Модель процесса MSF)[3] |
Таблица 2: Концепции на этапе прогнозирования
Фаза планирования
Рисунок 3: Процесс / модель данных фазы планирования
| Мероприятия | Определение (источник) | |
|---|---|---|
| Определить требования | На раннем этапе планирования команда анализирует и документирует требования в списке или инструменте. Требования делятся на четыре широкие категории: бизнес-требования, требования пользователей, эксплуатационные требования и системные требования (требования самого решения) ». (Модель процесса MSF)[3] | |
| Требования к трассировке функций | «По мере того, как команда переходит к разработке решения и созданию функциональных спецификаций, важно поддерживать прослеживаемость между требованиями и функциями. Прослеживаемость не обязательно должна быть индивидуальной. Поддержание прослеживаемости - это один из способов проверить правильность проектирования и убедиться, что проект соответствует целям и требованиям решения ». (Модель процесса MSF[3] | |
| Определить функциональную спецификацию | «Команда готовит функциональную спецификацию». (Модель процесса MSF[3] | |
| Создать планирование | Оценить риски | Команда создает оценку риска. |
| Оценить затраты | Команда составляет оценку затрат. | |
| Создавайте планы работы | Команда создает планы работы. | |
| Создать расписания | Команда составляет графики. | |
| Создать дизайн | Создать модель варианта использования | «Это начинается с систематического анализа профили пользователей (также называемые «персонами»), которые описывают различные типы пользователей и их должностные функции (операционный персонал также является пользователями). Многое из этого часто делается на этапе видения. Они разбиты на серию сценарии использования, когда пользователь определенного типа пытается выполнить какой-либо вид деятельности, например регистрацию на стойке регистрации в отеле или администрирование паролей пользователей для системного администратора. Наконец, каждый сценарий использования разбивается на определенную последовательность задач, известную как сценарии использования, который пользователь выполняет для завершения этого действия. Это называется «раскадровка». (Модель процесса MSF[3] |
| Создать концептуальный дизайн | Создание концептуального дизайна. | |
| Создать логический дизайн | Создание логичного дизайна. | |
| Создание физического дизайна | Создание физического дизайна. | |
| Создать архитектуру | Создание архитектуры продукта. | |
Таблица 3: Планирование мероприятийНа этапе планирования на основе требований создается функциональная спецификация. Выбранные функции включены в эту спецификацию ( Метод MoSCoW часто используется для функций, чтобы упростить их приоритизацию). Кроме того, на этом этапе создаются базовый дизайн и планирование. Однако дизайн на этом этапе не заморожен, так как изменения могут быть внесены на этапе разработки.
| Концепция | Определение (источник) |
|---|---|
| СПИСОК ТРЕБОВАНИЙ | Документация требований в списке или в инструменте ». (Модель процесса MSF[3] |
ПЛАН УПРАВЛЕНИЯ РИСКАМИ | Документ о том, как команда планирует реализовать процесс управления рисками в контексте проекта ». (Дисциплина MSF по управлению рисками[4] ) |
| ГЛАВНЫЙ ПЛАН ПРОЕКТА | Все планы синхронизируются и представляются вместе как план мастер-проекта ». (Модель процесса MSF[3] |
| ПЛАНЫ РАБОТЫ | План или планы результатов, которые относятся к роли и участвует в сессиях командного планирования ». (Модель процесса MSF[3] |
| ОЦЕНКИ ЗАТРАТ | Оценка стоимости проекта. |
| РАСПИСАНИЕ | Расчетные сроки и графики результатов ». (Модель процесса MSF[3] |
| ГРАФИК МАСТЕР-ПРОЕКТА | В затем различные графики синхронизируются и интегрируются в основной график проекта ». (Модель процесса MSF[3] |
| ФУНКЦИОНАЛЬНАЯ СПЕЦИФИКАЦИЯ | В функциональная спецификация подробно описывает, как каждая функция должна выглядеть и вести себя. Он также описывает архитектуру и дизайн всех функций ». (Модель процесса MSF[3] |
Таблица 4: Концепции на этапе планирования
Фаза разработки
Рисунок 4: Разработка фазового процесса / модели данных
| Мероприятия | Определение (источник) |
|---|---|
| Разработка функций | Сборка компонентов решения (документации и кода) ». (Модель процесса MSF)[3]Также включает тестирование после ежедневной сборки, исправление ошибок и оценку функций. |
| Создать ежедневную сборку | Создание билда после рабочего дня. |
| Завершить объем | На этом этапе все функции завершены, и решение готово для внешнего тестирования и стабилизации ». (Модель процесса MSF)[3] |
| Развивать инфраструктуру | Инфраструктура развита ». (Модель процесса MSF)[3] |
Таблица 5: Развивающие мероприятияНаиболее важной деятельностью на этапе разработки является разработка функций. Помимо реализации этих функций, на этом этапе также завершается объем работ. Во время разработки к продукту могут быть добавлены новые функции, но после того, как объем работ завершен, функции замораживаются и становятся готовыми для тестирования и стабилизации. Инфраструктура также разрабатывается на этом этапе, что означает идентификацию сетевых структур и определение серверов, таких как, например, сервер базы данных.
| Концепция | Определение (источник) |
|---|---|
| СЦЕНАРИИ УСТАНОВКИ И НАСТРОЙКИ КОНФИГУРАЦИИ ДЛЯ РАЗВЕРТЫВАНИЯ | Набор скриптов и настроек, необходимых для установки / запуска продукта. |
| СКРИПТЫ УСТАНОВКИ | Скрипты, необходимые для установки продукта. |
| НАСТРОЙКИ КОНФИГУРАЦИИ | Свойства конфигурации продукта. |
| ОПОРНЫЕ ЭЛЕМЕНТЫ | Элементы, поддерживающие производительность продукта (дополнительные базы данных, серверы и т. Д.). |
| ТЕХНИЧЕСКИЕ ХАРАКТЕРИСТИКИ И ИСПЫТАНИЯ | Спецификация тестов и контрольных примеров, используемых для проверки продукта. |
| ФУНКЦИОНАЛЬНАЯ СПЕЦИФИКАЦИЯ | Функциональная спецификация подробно описывает, как каждая функция должна выглядеть и вести себя. Он также описывает архитектуру и дизайн всех функций ». (Модель процесса MSF)[3] |
| ИСХОДНЫЙ КОД И ИСПОЛНИТЕЛИ | Комбинация исходного кода и исполняемых файлов. |
| ИСХОДНЫЙ КОД | Исходный код продукта. |
| ИСПОЛНИТЕЛЬНЫЙ | Исполняемый файл, созданный исходным кодом. |
Таблица 5: Концепции на стадии разработки
фаза стабилизации
Рисунок 5: Модель процесса / данных фазы стабилизации
| Мероприятия | Определение (источник) |
|---|---|
| Тестирование | Тестирование на этом этапе подчеркивает использование и работу в реальных условиях окружающей среды ». (Модель процесса MSF)[3] |
| Устранение ошибок | Команда фокусируется на устранении и сортировке (приоритезации) ошибок и подготовке решения к выпуску ». (Модель процесса MSF)[3] |
| Развернуть пилот | Как только сборка признана достаточно стабильной, чтобы стать кандидатом на выпуск, решение развертывается в пилотной группе ». (Модель процесса MSF)[3] |
| Рассмотрение | После рассмотрения и утверждения решение готово для полного развертывания в реальной производственной среде ». (Модель процесса MSF)[3] |
Таблица 6: Стабилизационные мероприятияОсновные виды деятельности - это тестирование и устранение ошибок. Как только версия сборки считается достаточно стабильной для пилотной версии, создается и развертывается пилотная версия. Из этого пилотного проекта он либо вернется в цикл тестирования / стабилизации, либо будет одобрен и рассмотрен.
| Концепция | Определение (источник) |
|---|---|
| РЕЗУЛЬТАТЫ ИСПЫТАНИЙ И ИНСТРУМЕНТЫ ДЛЯ ТЕСТИРОВАНИЯ | Сборник результатов тестирования и инструментов, используемых для тестирования. |
| РЕЗУЛЬТАТЫ ТЕСТА | Результаты выполненных тестов. |
| ИНСТРУМЕНТЫ ДЛЯ ТЕСТИРОВАНИЯ | Инструменты, используемые для тестирования. |
| ЗОЛОТОЙ РЕЛИЗ | Версия, использованная для окончательной проверки. |
| ЗАМЕТКИ О ВЫПУСКЕ | Примечания к выпускной версии. |
| ИСХОДНЫЙ КОД И ИСПОЛНИТЕЛЬНЫЙ | Комбинация исходного кода и исполняемых файлов. |
| ИСХОДНЫЙ КОД | Исходный код продукта. |
| ИСПОЛНИТЕЛЬНЫЙ | Исполняемый файл, созданный исходным кодом. |
| ОБЗОР ВЕХИ | Рассмотрение финальной версии и проектной документации. |
| ДОКУМЕНТЫ ПРОЕКТА | Сборник всех проектных документов. |
Таблица 7: Концепции фазы стабилизации
этап развертывания
Рисунок 6: Модель процесса / данных фазы развертывания
| Мероприятия | Определение (источник) |
|---|---|
| Разверните основные компоненты | Развертывание всех компонентов, необходимых для продукта (например, серверов баз данных, почтовых серверов и т. Д.) |
| Разверните решение на сайте | Для индивидуальных систем развертывание продукта происходит здесь (можно пропустить для программных продуктов). |
| Стабилизируйте развертывание | Привязка, мониторинг и улучшение развернутых компонентов. |
| Передать проект в эксплуатацию и поддержку | Передача всех документов и кода в группу эксплуатации и поддержки. |
| Получите окончательное одобрение от клиента | Заказчик должен согласиться с тем, что команда выполнила свои задачи, прежде чем она сможет объявить решение в рабочем состоянии и закрыть проект. Это требует стабильного решения, а также четко сформулированных критериев успеха. Для того чтобы решение считалось стабильным, должны быть созданы соответствующие операционные и вспомогательные системы ». (Модель процесса MSF)[3] |
| Просмотрите проект | Финальный обзор проекта. |
Таблица 8: Действия по развертываниюОсновное действие на этапе развертывания - это установка инфраструктуры, необходимой для работы продукта (развертывание серверов и т. Д.). Кроме того, документы дорабатываются и передаются в отдел эксплуатации и поддержки, создается база знаний, а продукт и проект проверяются заказчиком (если применимо) и командой проекта.
| Концепция | Определение (источник) |
|---|---|
| ПРОЦЕДУРЫ И ПРОЦЕССЫ | Сборник процедур и процессов. |
| ПРОЦЕДУРЫ | Сборник процедур, которые будут использоваться для установки и эксплуатации продукта. |
| ПРОЦЕССЫ | Сборник процессов, которые будут использоваться для установки и работы продукта. |
| БАЗА ЗНАНИЙ, ОТЧЕТЫ, ЖУРНАЛЫ | Сборник базы знаний, отчетов и журналов. |
| БАЗА ЗНАНИЙ | База знаний, связанная с продуктом. |
| ОТЧЕТЫ | Отчеты, связанные с продуктом. |
| ЖУРНАЛЫ | Журналы, связанные с продуктом. |
| ХРАНИЛИЩЕ ДОКУМЕНТОВ | Хранилище всех документов. |
| ОКОНЧАТЕЛЬНЫЕ ВЕРСИИ ВСЕХ ДОКУМЕНТОВ ПРОЕКТА | Окончательные версии проектной документации. |
| ИНФОРМАЦИОННЫЕ СИСТЕМЫ ЭКСПЛУАТАЦИИ И ПОДДЕРЖКИ | Системы, используемые группами эксплуатации и поддержки, связанными с продуктом. |
| ДАННЫЕ ОБ УДОВЛЕТВОРЕНИИ КЛИЕНТА / ПОЛЬЗОВАТЕЛЯ | Сбор данных от покупателя / пользователя о его удовлетворенности продуктом. |
| ОПРЕДЕЛЕНИЕ СЛЕДУЮЩИХ ШАГОВ | Описание следующих шагов, которые необходимо предпринять для развития продукта. |
| ОТЧЕТ О ЗАКРЫТИИ ПРОЕКТА | Заключительный отчет по продукту, проекту и передаче в эксплуатацию и поддержку. |
Таблица 9: Концепции на этапе развертывания
Общая модель данных
Рисунок 7: Общая модель данныхЭта модель данных показывает все концепции с множественностями и отношениями в полном контексте проекта.
Инструменты для использования с Internet-Speed Development
- Инструменты рисования (примеры: Microsoft Visio, Rational Rose, Dia ) Для построения диаграмм.
- Текстовые процессоры (примеры: Microsoft Word, OpenOffice.org Writer, AbiWord, Каллиграфические Слова ) Для создания текстовых документов, таких как заявление о видении или документ о содержании.
- Электронные таблицы (примеры: Microsoft Excel, OpenOffice.org Calc, Gnumeric, Каллиграфические Листы ) Для составления списков приоритетных рисков и расчета затрат.
- Инструменты проекта (примеры: Microsoft Project, OpenProj, Планировщик Gnome, Каллиграфический план ) Для планирования проектной деятельности.
- Инструменты базы данных и управления базами данных (примеры: MS SQL Server, MySQL, Oracle, PostgreSQL ) Для создания баз знаний.
- Инструменты автоматического тестирования (примеры: тестовые сценарии) Для выполнения тестов после каждой ежедневной сборки.
Смотрите также
- Гибкая разработка программного обеспечения
- Инкрементальная и итеративная разработка
- Платформа решений Microsoft
- Метод разработки динамических систем (DSDM)
- Метод MoSCoW
Примечания
- ^ Пекка Абрахамссон, Юхани Варста, Микко Т. Сипонен, Юсси Ронкайнен 2003
- ^ Как показано в статье Zuser, Heil и Grechening.
- ^ а б c d е ж грамм час я j k л м п о п q р s т ты v ш Икс у z аа ab ac объявление Белая книга решений Microsoft, июнь 2002 г.
- ^ а б c d Официальный документ по дисциплине управления рисками Microsoft
Рекомендации
- Microsoft июнь 2002 г. Microsoft Solutions Framework (Белая книга) Microsoft Press
- Microsoft июнь 2002 г. MSF Risk Management Discipline v.1.1 (White Paper) Microsoft Press
- Вольфганг Цузер, Стефан Хайль, Томас Гречениг 2005 Разработка и обеспечение качества программного обеспечения в RUP, MSF и XP - Материалы сравнительного исследования семинара 2005 года по качеству программного обеспечения
- Пекка Абрахамссон, Юхани Варста, Микко Т. Сипонен, Юсси Ронкайнен 2003 Новые направления гибких методов: сравнительный анализ ICSE
- Майкл А. Кусумано, Дэвид Б. Йоффи 1999 Разработка программного обеспечения в Internet Time 32 IEEE
- Баласубраманиам Рамеш, Ян Прис-Хидже 2002 Разработка программного обеспечения в Интернете: другой класс процессов Анналы разработки программного обеспечения 14 169–195