Эд Салливан - Время — деньги. Создание команды разработчиков программного обеспечения

Здесь есть возможность читать онлайн «Эд Салливан - Время — деньги. Создание команды разработчиков программного обеспечения» весь текст электронной книги совершенно бесплатно (целиком полную версию без сокращений). В некоторых случаях можно слушать аудио, скачать через торрент в формате fb2 и присутствует краткое содержание. Город: М., Год выпуска: 2002, ISBN: 2002, Издательство: Русская Редакция, Жанр: Программирование, Деловая литература, на русском языке. Описание произведения, (предисловие) а так же отзывы посетителей доступны на портале библиотеки ЛибКат.

Время — деньги. Создание команды разработчиков программного обеспечения: краткое содержание, описание и аннотация

Предлагаем к чтению аннотацию, описание, краткое содержание или предисловие (зависит от того, что написал сам автор книги «Время — деньги. Создание команды разработчиков программного обеспечения»). Если вы не нашли необходимую информацию о книге — напишите в комментариях, мы постараемся отыскать её.

В этой книге ветеран индустрии программных средств Эд Салливан делится найденными в результате нелёгкого труда принципами, приёмами и методиками разработки коммерческого ПО. В книге раскрыты фундаментальные принципы, позволяющие выпускать качественные программы в срок в любых обстоятельствах. Вы узнаете о реальном опыте успешной разработки коммерческого ПО в начинающей компании, о том, как выбрать нужных специалистов, инструментальные средства разработки, настроить технологию, планировать и выполнять проект, своевременно обнаруживая и решая возникающие проблемы.
Книга состоит из 15 глав и предметного указателя.

Время — деньги. Создание команды разработчиков программного обеспечения — читать онлайн бесплатно полную книгу (весь текст) целиком

Ниже представлен текст книги, разбитый по страницам. Система сохранения места последней прочитанной страницы, позволяет с удобством читать онлайн бесплатно книгу «Время — деньги. Создание команды разработчиков программного обеспечения», без необходимости каждый раз заново искать на чём Вы остановились. Поставьте закладку, и сможете в любой момент перейти на страницу, на которой закончили чтение.

Тёмная тема
Сбросить

Интервал:

Закладка:

Сделать

Надёжная и простая в использовании процедура установки будет полезна для всех членов команды, а не только для тестировщиков. Каждый сможет установить продукт для своих собственных целей. Техническим писателям потребуется установка для создания описания функций продукта, разработчикам — для отслеживания «жучков», проблем с производительностью и оценки пользовательского интерфейса. Ваша команда должна работать с продуктом, а не бороться с его установкой.

Из собственного опыта

Не забудьте о процедуре удаления! В NuMega команды разработчиков и тестировщиков оценили значимость процедуры удаления. Ведь она позволяет получить чистую систему и не тратить время на ручное удаление записей реестра и файлов из системного каталога.

Тестирование при стабилизации и интеграции

До этого момента в цикле разработки тестирование было направлено на проверку отдельных функций. Но в период стабилизации и интеграции внимание уделяется:

• завершению всех отложенных тестов отдельных функций;

• проверке интеграции функций;

• проверке текущей производительности и нагрузки;

• исправлению всех серьёзных ошибок, изъянов проекта или архитектурных проблем;

• тестированию бета-версий и кандидатов на выпуск.

Завершение каждого из этих этапов очень важно для начала работы над следующей частью проекта. Давайте подробнее рассмотрим каждый из них.

Завершение тестирования отдельных функций

Задача номер один — завершение всех тестов, которые могли быть отложены. Это вполне нормально, когда какой-то оперативной команде для завершения всех тестов требуется больше времени, даже после 4-6 недель упорной работы. Используйте это время для выполнения всех тестов, которые ещё не были выполнены, так вы сможете поддерживать параллельное тестирование до самого конца проекта.

Проверка интеграции

Тестирование интеграции должно быть определено заблаговременно как часть плана тестирования. Лучший способ сделать это — создать набор примеров использования, предпочтительно с точки зрения пользователя, описывающих, как различные функции должны работать вместе. Перед тестированием вы должны быть уверены, что заданные функции находятся в рабочем состоянии и в принципе могут использоваться вместе. Именно сейчас время их совместной проверки, и если они не станут работать, то настанет время исправления ошибок.

Тестирование производительности и нагрузки

Хотя конечный продукт нельзя оценить до тех пор, пока вся система не будет собрана воедино, для оценки прогресса или его отсутствия в цикле разработки могут проводиться наблюдения и предварительные измерения.

Не забудьте создать набор тестов, которые будут служить в качестве эталонных тестов для продукта, и выполнять их регулярно в цикле разработки. Выполняйте стрессовые тесты и оценивайте производительность системы по завершении определённых этапов и в моменты синхронизации и интеграции. Именно для этого разработка разбита на этапы. Выполнение тестов в эти моменты — лучший способ раннего обнаружения ошибок и их исправления до того, как вы продолжите строить ваш продукт на фундаменте, содержащем ошибку.

Из собственного опыта

Во время разработки BoundsChecker одной из главных проблем была производительность. Ничего не стоило полностью поменять характеристики производительности продукта, добавив несколько строчек кода в критичные функции. Чтобы обнаружить источник проблем с производительностью, мы использовали несколько тестовых приложений, которые нагружали BoundsChecker до предела. Одно из таких приложений называлось Torture. Оно создавало 256 параллельных потоков и запрашивало и освобождало десятки тысяч блоков памяти в куче. В течение всего периода разработки мы запускали Torture (и подобные программы), чтобы определить, не снизилась ли производительность продукта. Так как мы хотели видеть результат сразу, мы стали каждую ночь запускать Torture как часть наших автоматических регрессивных тестов и сравнивать показатели производительности. С таким уровнем контроля мы обычно могли определять снижение производительности в сборке предыдущего дня. Весьма неплохо!

Коррекция после тестирования

Период стабилизации и интеграции также позволяет исправить серьёзные ошибки до перехода к следующему набору функций. Тестирование функций и их интеграции выявит множество ошибок, а это именно то, что нужно. Вы сможете заранее устранить эти ошибки, что увеличит продуктивность дальнейшей работы. Но время на поиск и исправление этих ошибок должно быть учтено в графике.

Читать дальше
Тёмная тема
Сбросить

Интервал:

Закладка:

Сделать

Похожие книги на «Время — деньги. Создание команды разработчиков программного обеспечения»

Представляем Вашему вниманию похожие книги на «Время — деньги. Создание команды разработчиков программного обеспечения» списком для выбора. Мы отобрали схожую по названию и смыслу литературу в надежде предоставить читателям больше вариантов отыскать новые, интересные, ещё непрочитанные произведения.


Отзывы о книге «Время — деньги. Создание команды разработчиков программного обеспечения»

Обсуждение, отзывы о книге «Время — деньги. Создание команды разработчиков программного обеспечения» и просто собственные мнения читателей. Оставьте ваши комментарии, напишите, что Вы думаете о произведении, его смысле или главных героях. Укажите что конкретно понравилось, а что нет, и почему Вы так считаете.

x