Большая картина цикла разработки ПО
Пример
Допустим, у нас есть
• мама (продюсер),
• сын 7 лет (программист, тестировщик, релиз-инженер и служба поддержки),
Цикл разработки ПО
123
• папа (пользователь) и
• неограниченное количество разнообразных деталей конструктора для строительства игрушечного дома.
Мама говорит сыну: "Давай сделаем папе приятное и построим для него одноэтажный дом (идея), который должен выглядеть вот так и вот так (дизайн продукта)".
Сын собирает отдельно
крышу,
стены,
двери и
окна (кодирование).
Потом происходит соединение всех частей (интеграция), в результате которой крыша оказалась меньше, чем нужно, выпуклости дверей не совпадают с выпуклостями стен, а окна не подходят по цвету. Сын переделывает компоненты, успешно соединяет и начинает пинать домик ногами, бросать вниз с семнадцатого этажа и оставлять на ночь в наполненной ванной (тестирование). В результате обнаруживаются некоторые недоработки (баги), которые постепенно устраняются (фиксирование багов). Когда все нормально, домик передается папе (релиз), который иногда просит (е-мейл/звонок в службу поддержки пользователей), чтобы некоторые проблемы, такие, как неровности крыши, с которой падает кружка с пивом (пострелиз-баги), были немедленно исправлены (фиксирование пострелиз-багов).
Вернемся к нашему www.testshop.rs.
Давайте рассмотрим большую картину цикла разработки ПО в динамике.
Сначала обобщим знания об игроках, их ролях и стадиях цикла с их участием.
|
|
|
| Игрок | Роль | Стадия |
| Маркетолог | Генерирует идеи и составляет MRD | Идея |
| Продюсер | Разрабатывает и документирует дизайн продукта | Дизайн и документация |
| Программист | Переводит дизайн продукта на язык программирования | Кодирование |
| Ремонтирует баги | Тест и ремонт | |
| Тестировщик | Готовится к исполнению тестирования | Кодирование |
| Исполняет тестирование | Тест и ремонт |
124
Тестирование Дот Ком. Часть 1
1.Итак, начнем с бара, вернее, с идеи версии 1.0, которая в этом баре пришла.
2. После того как идея v. 1.0была принята за путеводную звезду для первого релиза, наступила стадия дизайн и документация v. 1.0этой идеи. Основное действующее лицо — продюсер.
А в это время
• маркетолог тоже не сидит без дела, а генерирует идеи для следующего релиза на стадии идея v. 2.O.
3. После того как дизайн и документация v. 1.0 завершены, наступает стадия кодированиеv. 1.0.Основное действующее лицо — программист.
А в это время
• тестировщик планирует, как он будет тестировать код, разрабатываемый сейчас программистом;
• продюсер работает уже над стадией дизайн и документация v. 2.0,переданной после стадии идеяv. 2.0;
|
|
|
• маркетолог работает над стадией идея v. 3.0.
Цикл разработки ПО
125
4. После того как кодированиеv. 1.0завершено, наступает стадия тестирование и ремонт v. 1.0.Основное действующее лицо — тестировщик. После завершения стадии тестирование и ремонт v. 1.0в одну из лунных ночей происходит релизv. 1.0, после чего тестировщик бросается на v. 2.0, начав подготовку к тестированию кода, разрабатываемого сейчас программистом на стадии кодирование v. 2.0.
А в это время
• программист пишет код на стадии кодирование v. 2.0;
• продюсер разрабатывает дизайн продукта на стадии дизайн и документацияv. 3.0;
• маркетолог, идущий, как всегда, в авангарде, обдумывает идеи на стадии идеяv. 4.O.
Таким образом, мы рассмотрели полностью цикл разработки версии 1.0 проекта www.testshop.rs. Дальше все идет по аналогии.
126
Тестирование Дот Ком. Часть 1
| Итак, большая картина цикла разработки ПО. |
Большая картина — это всего лишь модель, и в реальной жизни все так гладко, красиво и гармонично не бывает. Например, во время стадии идея v. 2.0 маркетолог может генерировать как краткосрочные идеи цикла v. 2.0, так и долгосрочные цикла v. 4.0 и v. 5.0.
В завершение беседы о цикле разработки ПО давайте • поставим акцент на паре важных моментов,
|
|
|
Цикл разработки ПО
127
• сделаем одну оговорку,
• остановимся на одной ценной мысли и
• ответим на практические вопросы.
Пара важных моментов:
1. Процедуры, стандарты, спеки, тест-кейсы и контактная информация должны быть задокументированы (пусть даже в электронном виде) и доступны на интранете.
2. Такие вещи, как утверждение спека, рассмотрение тест-кейсов или инспекция кода, — это не какие-то полицейские мероприятия, призванные подрезать крылышки творческим и свободным личностям. Совершенно наоборот — это средства, позволяющие
• улучшить качество,
• прикрыть спину,
• стать хорошим людям еще лучше.
Оговорка:
Ваквариумах интернет-компаний кроме продюсеров, программистов, тестировщиков и начальников обитает еще много других разновидностей не менее полезных особей, таких, как
• веб-дизайнеры;
• системные администраторы и администраторы баз данных;
• народ из службы поддержки и маркетинга;
• бухгалтеры (хлещущие чай);
• спецы по железу (хлещущие пиво) и др.
Мы их всех любим, ценим и, как видите, не забываем. Просто нужно было сделать допустимое упрощение для удобства восприятия нового материала и, например, свести написание кода только к программистам, в то время как JavaScript-кол обычно пишется веб-дизайнерами.
|
|
|
Ценная мысль:
Акт планирования, будь то спек, дизайн кода, тест-кейс или документ о неотложном ремонте бага, — это возможность посмотреть в будущее, предугадать и предотвратить возможные проблемы и/или баги.
Эффективное планирование — это одна из важнейших составляющих процесса разработки ПО.
128
Тестирование Дот Ком. Часть 1
Дата добавления: 2018-05-02; просмотров: 377; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!