Развитие скорости Интернета
Интернет-скоростная разработка — это гибкий метод разработки программного обеспечения с использованием комбинированной модели спирали / каскада с ежедневными сборками, направленный на разработку продукта с высокой скоростью.
Он был разработан в конце девяностых годов, поскольку разработка программного обеспечения быстро менялась. У компаний были проблемы с поставкой продуктов, отвечающих правильным требованиям, в сроки, запланированные для проекта, и поэтому они переходили на более гибкие методы разработки программного обеспечения. Более подробную информацию о том, как был разработан метод скорости интернета, можно увидеть на эволюционной карте в статье Абрахамссона. [1]
Основные идеи развития скорости Интернета
[ редактировать ]Часто одной из самых больших проблем в разработке программного обеспечения является то, что требования быстро меняются, и метод разработки со скоростью Интернета был создан, чтобы адаптироваться к этой ситуации. Идея состоит в том, чтобы объединить два основных стандарта моделей разработки программного обеспечения, а именно спиральную модель и водопадную модель, в новую модель и основать новый метод разработки программного обеспечения на этой новой модели. Основным недостатком водопадной модели было то, что она была очень жесткой и не очень гибкой при изменении требований, а недостатком спиральной модели было то, что она была не очень структурированной. Идея разработки скорости Интернета заключается в том, что комбинация этих моделей приведет к созданию метода, который не имеет этих недостатков и является лучшим методом для использования в ситуациях, когда требования могут быстро меняться, но проект должен выполняться в структурированном виде. способ.
Цель метода
[ редактировать ]Цель метода разработки со скоростью Интернета — позволить разработчикам программного обеспечения выполнять проект структурированным образом, но при этом иметь возможность адаптироваться к потребностям клиента. Целью компании является создание программного продукта в короткие сроки посредством интенсивной разработки. Этот метод предоставляет средства для создания полностью реализованной системы, а также позволяет определять ход проекта посредством использования контрольных точек. Одна из основных версий этого метода создана Microsoft и называется Microsoft Solutions Framework.
Концепции, лежащие в основе метода развития скорости Интернета
[ редактировать ]Первая концепция, которая очень важна для развития скорости Интернета, — это создание видения и масштаба (управление проектом) . Это означает, что в начале проекта создается общее определение системы, которое объясняет, какой должна быть система, что входит в ее объем, а что нет. Это один из фундаментальных шагов, поскольку он дает разработчикам некоторые рекомендации относительно того, какой будет система, не замораживая при этом никаких требований. Объем может быть задокументирован в заявлении о видении .
Еще одна очень важная концепция этого метода — управление объемом. Объемом необходимо управлять на протяжении всего проекта, чтобы предотвратить расползание объема , что приводит к задержкам. Объем будет определен заранее, а изменения в объеме (например, добавление дополнительных функций, которые сначала считались выходящими за рамки проекта) будут оценены и либо приняты, либо отклонены. Можно внести изменения в объем, но на это всегда будут влиять компромиссы между функциями, ресурсами и временем.
Метод разработки со скоростью Интернета сильно отличается от традиционных методов и поэтому использует принципы гибкого метода. Он ориентирован на адаптацию к требованиям и поэтому основан на основных принципах гибкой разработки программного обеспечения.
Разработка со скоростью Интернета также фокусируется на использовании одной фиксированной архитектуры платформы, на основе которой создается продукт, и в значительной степени опирается на инструменты для увеличения скорости разработки.
Другая базовая концепция развития скорости Интернета заключается в том, что она также ориентирована на использование небольших команд. Идея состоит в том, что все проекты можно разделить на более мелкие действия, которые часто можно выполнять параллельно. Меньшие команды часто могут быть более сосредоточены на своей задаче, и в них легче определить ответственность и отслеживать прогресс в рамках проекта.
Последняя концепция, обсуждаемая в этой статье о развитии скорости Интернета, — это концепция параллельной разработки. Эта концепция по сути означает, что вся разработка программного обеспечения выполняется параллельно как можно чаще. Это обеспечит очень быструю разработку и позволит небольшим командам максимально сосредоточиться на своей собственной функции, что дает хороший результат по качеству. Однако, чтобы гарантировать совместную работу небольших команд над созданием окончательной системы, необходимо часто синхронизировать их разработку. Это можно сделать с помощью ежедневных сборок , что означает, что все разработчики проверяют свой код в конце дня, после чего создается сборка, которую затем можно оценить и протестировать для отслеживания прогресса. После того, как функция завершена в сборке, ее необходимо протестировать и доработать, что иногда называют процессом синхронизации и стабилизации. Разработанные функции синхронизируются со сборкой и тестируются. После этих тестов любые ошибки будут исправлены, и функция может быть улучшена для лучшей работы (это часть стабилизации).
Разработка со скоростью Интернета основана на принципах гибкой разработки и поэтому имеет много общего с экстремальным программированием , Rational Unified Process , DSDM и разработкой на основе функций . Однако развитие скорости Интернета отличается от этих методов, поскольку оно также включает в себя более обширное планирование управления рисками и качество является очень важной целью проекта. [2] Фаза разработки со скоростью Интернета также демонстрирует некоторое сходство с моделью разработки программного обеспечения с открытым исходным кодом , поскольку многие разработчики по всему миру могут участвовать в процессе разработки благодаря общению через Интернет и использованию репозиториев для хранения кода и документации. .
Этапы развития скорости Интернета
[ редактировать ]Модель этого метода выглядит следующим образом:
Рисунок 1: Фазовая модель
Эта модель показывает пять основных этапов метода. Эти этапы будут объяснены в следующих разделах этой статьи. Этапы: планирование, планирование, разработка, стабилизация и развертывание. После завершения этого цикла версия системы готова и начинается новый цикл создания новой версии. Эти этапы объясняются в следующих разделах и демонстрируются с помощью метода метамоделирования . Более подробную информацию о множественности и концепциях в контексте проекта можно увидеть позже в общей модели данных.
Фаза представления
[ редактировать ]Фазу представления можно смоделировать следующим образом:
Рисунок 2. Представление фазовой модели процесса/данных
| Активность | Определение (источник) |
|---|---|
| Анализ требований | На этапе планирования необходимо определить и проанализировать бизнес-требования.
«Они более тщательно уточняются на этапе планирования». (модель процесса MSF) [3] |
| Определите цели и ограничения | «Предвидение, путем создания общего представления о целях и ограничениях проекта».
(модель процесса MSF) [3] |
| Сформировать команду | Формирование ядра команды. |
| Создать видение/объем | «Подготовка и предоставление документа о видении/объеме проекта».
(модель процесса MSF) [3] |
| Создать оценку риска | «На этапе планирования команда готовит документ о рисках и представляет основные риски».
(модель процесса MSF) [3] |
Таблица 1: Планирование мероприятий
Основные действия, выполняемые на этапе планирования, — это анализ требований, формирование команды проекта, определение рисков и масштабов проекта. На основании требований и целей проекта создается документ «Видение/Объем». В этом документе описывается, каким должен быть продукт при доставке. Он не содержит очень подробных функций продукта.
| Концепция | Определение (источник) |
|---|---|
| ДОКУМЕНТ О ВИДЕНИИ/ОБЪЕМЕ ОБЪЕМА | «Документ, определяющий видение и сферу применения».
(модель процесса 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: Общая модель данных
Эта модель данных показывает все концепции с множественностью и отношениями в полном контексте проекта.
Инструменты для использования при разработке скорости Интернета
[ редактировать ]- Инструменты рисования (примеры: Microsoft Visio, Rational Rose, Dia ) Для создания диаграмм.
- Текстовые процессоры (примеры: Microsoft Word, OpenOffice.org Writer, AbiWord , Calligra Words ) Для создания текстовых документов, таких как заявление о концепции или документ о содержании.
- Электронные таблицы (примеры: Microsoft Excel, OpenOffice.org Calc, Gnumeric , Calligra Sheets ) Для составления списков приоритетных рисков и расчета затрат.
- Инструменты проекта (примеры: Microsoft Project, OpenProj , Gnome Planner, Calligra Plan ). Для планирования деятельности проекта.
- Базы данных и инструменты управления базами данных (примеры: MS SQL Server, MySQL , Oracle, PostgreSQL ) Для создания баз знаний.
- Инструменты автоматического тестирования (примеры: тестовые сценарии). Для выполнения тестов после каждой ежедневной сборки.
См. также
[ редактировать ]- Гибкая разработка программного обеспечения
- Поэтапная и итеративная разработка
- Платформа решений Microsoft
- Метод разработки динамических систем (DSDM)
- МОСКОВСКИЙ метод
Примечания
[ редактировать ]- ^ Пекка Абрахамссон, Юхани Варста, Микко Т. Сипонен, Юсси Ронкайнен 2003
- ^ Как показано в статье Цузера, Хайля и Грехенинга.
- ^ Jump up to: а б с д и ж г час я дж к л м н тот п д р с т в v В х и С аа аб и объявление Технический документ по решениям Microsoft, июнь 2002 г.
- ^ Jump up to: а б с д Технический документ Microsoft по дисциплине управления рисками
Ссылки
[ редактировать ]- Microsoft, июнь 2002 г. Microsoft Solutions Framework (информационный документ) Microsoft Press
- Microsoft, июнь 2002 г., «Дисциплина управления рисками MSF», версия 1.1 (информационный документ) Microsoft Press
- Вольфганг Цузер, Стефан Хайль, Томас Грехениг, 2005 г. Разработка и обеспечение качества программного обеспечения в RUP, MSF и XP - сравнительное исследование. Материалы семинара 2005 г. по качеству программного обеспечения.
- Пекка Абрахамссон, Юхани Варста, Микко Т. Сипонен, Юсси Ронкайнен, 2003 г. Новые направления в гибких методах: сравнительный анализ ICSE
- Майкл А. Кусумано, Дэвид Б. Йоффи, 1999 г. Разработка программного обеспечения в Интернете, 32 IEEE.
- Баласубраманиам Рамеш, Ян Прис-Хедже, 2002 г. Разработка программного обеспечения в Интернете: другой класс процессов Анналы программной инженерии 14 169–195