Перейти к содержимому

Фотография

Вопрос на собеседовании на который не смог найти ответа.


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 30

#21 FreeMan1

FreeMan1

    Новый участник

  • Members
  • Pip
  • 28 сообщений

Отправлено 20 сентября 2012 - 21:43


3. Создание эмулятора потоков входных данных - например, java, генерация данных в нужном формате и сохранение, возможно, запуск эмулятора по таймеру. Написание, отладка, тестирование.

нравится идея.


То что я написал отменяю, удалил.


Почему все удаляют свои ответы)? Ваш ответ тоже было интересно читать , да и другим может быть полезно если у них на собеседовании будет такой вопрос.
  • 0

#22 Arkady

Arkady

    Активный участник

  • Members
  • PipPip
  • 94 сообщений
  • ФИО:AAA
  • Город:Белоруссия

Отправлено 21 сентября 2012 - 12:43

- Почему все удаляют свои ответы)?

я удалил из-за озабоченности мнением. Потому что написал по быстрому и не догадался о таком решении как у ann, показалось что мое предложение глупое по сравнению с ann.

- что оценку в часах (а от меня требовали конкретное время в часах) дать не возможно. Т.к. мало входных данных. Оценить можно относительно. На задание давалось 30 минут. За 30 минут можно пофантазировать о том что бы я включил в тест план, но давать результат в часах нереально.

почему нереально? вполне можно оценить примерное максимальное время со всеми возможными издержками. И отметить что время будет подкорректировано в течении нескольких дней после начала тестирования.

- Сама формулировка "оценить время тестирования по разработанному тестовому плану" некорректна, т.к. без этого разработанного плана ничего реально оценить невозможно. А разработка плана может занять от нескольких , часов, до нескольких дней, в зависимости от ресурсов, сложности объекта тестирования, персонала и многих других начальных условий.

Можно сделать начальную версию плана (каркас) за 20 минут и за 10 минут оценить время. А потом уже доработать план до полноценного потратив несколько часов и уточнить время.

То есть задача на мой взгляд корректная. По тому как ее будут решать можно посмотреть уровень мышления человека.
Другое дело неизвестно кто судьи. Не исключено, что те кто проводили собеседование неадекватно оценивали человека решавшего задачу по каким-то формальным признакам.
  • 0

#23 kitsune

kitsune

    Активный участник

  • Members
  • PipPip
  • 137 сообщений
  • ФИО:Полина Антипова
  • Город:Санкт-Петербург

Отправлено 21 сентября 2012 - 13:35

Другое дело неизвестно кто судьи. Не исключено, что те кто проводили собеседование неадекватно оценивали человека решавшего задачу по каким-то формальным признакам.


Ну это вообще для любого собеседования справедливо.
  • 0

#24 ShortLegged

ShortLegged

    Постоянный участник

  • Members
  • PipPipPip
  • 155 сообщений
  • Город:Moscow

Отправлено 21 сентября 2012 - 18:06

Как-то так: http://www.xmind.net/m/ZXRB/

Хотя данных действительно мало, очень многое зависит от реализации.
  • 2

#25 Gepard_AD

Gepard_AD

    Новый участник

  • Members
  • Pip
  • 3 сообщений
  • ФИО:Сергей

Отправлено 11 января 2013 - 14:36

Если еще актуально, могу предложить свой вариант. Подобные задачки люблю. В свое время на собеседовании мне дали еще более скупые входные данные: Электрочайник. Как вы будете его тестировать?

Теперь по сабжу: поскольку в исходных данных не сказано про документацию начинаем с малого.
1. Тестирование по черному ящику. Отключаем программу-сборщик, закидываем входные данные на любой поток, проверяем ftp на приход данных. Включаем сборщик, проверяем таблицу и её формирование. Закидываем скопом данные остальных 58 потоков, проверяем бегло 58 таблиц. На все - 8-12 часов чистого тестирования.

2. Уточняем про документацию и начинается интересное: Как очень подробно описала anr и оценила в 50-90 часов тестирование, это отлично! Но при этом раскрывать и усложнять стратегию тестирования и масштабировать тестовую модель можно очень долго. Нагрузочное тестирование - рабочий месяц включая ночи и выходные. С разворачиванием стенда под (если это биллинг для сотового оператора - миллионы запросов в сутки) миллионы пользователей на нагрузочном тестировании и функциональном на том же стенде, время с 50-90 часов можно увеличивать до 300 чеоловекочасов. Из них: Анализ логов после суточного нагрузочного-performance тестирования - 10-20 часов. После stress-нагрузочного тестирования на выходных - еще 20-30. Ручное full-regress тестирование функционала 20 часов. Плюс анализ документации (крупные системы - 100-200 страниц на Техническую спецификацию для каждого компонента), написание тестовой модели для ФТ и НТ.

3. Теперь работодатель пускай уточняет стартовые данные и получит более реальные сроки и цифры.

Если подвести итог-ИМХО: Работодатель как правило задает подобные задачки для понимания насколько человек способен понимать минимально необходимый набор исходных сущностей для разработки стратегии, плана тестирования и тестовой модели. Понимает ли человек, что ему потребуется для работы, что требовать с разработчиков и что ждут от него.

Меня работодатель прервал на 3-ей минуте изложения вариантов проверки электрочайника. В рамках тестов чайник еще не наполняли водой и не включали в сеть.
  • 1

#26 LOLWUT

LOLWUT

    Новый участник

  • Members
  • Pip
  • 22 сообщений
  • ФИО:Lol Wut

Отправлено 25 января 2013 - 12:32

Вопрос на собеседовании-

Дано - есть 59 потоков данных которые в бинарном виде падают на ftp, специальная программа забирает, преобразовывает и сохраняет в 59 таблиц.
1 поток - это один тип услуги. Примеры: 1Смс, 2звонок в дом сети, 3в роуминге, 4заказ услуги по короткому номеру. Для каждого потока 1 таблица.

Задача - 1)описать, как ты будешь тестировать. Перечислить этапы, основные идеи, направления.
2)оценить время тестирования по разработанному тестовому плану.

Задача хорошая для собеседования автоматизатора.

Уложился в 45 минут во время обеда. Поскольку письменно - на реальном собеседовании бы успел описать концепцию куда четче, написать примеры тесткейсов для валидатора + нарисовать схемы системы.

Сначала.
1. Входящие данные - 59 типовых потоков, отличающихся только параметром услуги, несложные. Уточнить спецификацию протокола.
2. Система 3х компонентная. Компонента один - генератор контента (источник потока), компонента два - хранилище, куда падают данные и джоб, который выхватывает данные и ложит в таблицы бд, компонента 3 - сама бд и структура ее таблиц.
3. Варианты приложения - хайлоад(большие потоки данных) или мелкое приложение (раз в 10 сек по какому-то из каналов пролетает пакет из 3х полей вида "вася послал смс пете".

Тестирование.
Необходимо протестировать следующие вещи:
а) Верификация данных в потоках. Необходим эмулятор источника данных. В качестве приемника - автотест, который вызывается параллельно джобу укладки в бд. Автотест банально восстанавливает объекты из бинарных данных и валидирует поля согласно документации и спецификации протокола (если нет - пинать программистов, писать доки). Для скорости разработки проще всего упереть кусок кода из укладчика - он декодирует также, велосипед писать не надо. Для эмулятора - вытащить энкодер из самого приложения(если есть доступ к исходникам кода). Уточнить сетевые параметры - как приложение обрабатывает таймауты, пакетлоссы, какова инфраструктура сети, где это будет(уже) разворачиваться. Если надо - добавить эмуляцию потери связи в автотесты.

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

в) Уточнение объема передаваемых данных. Если приложение хайлоад с кучей данных - заранее заложить в эмулятор данных архитектуру, позволяющую использовать их для генерации нагрузки (многопоточное решение, оптимизация и тп). Предусмотреть логгирование отправленных пакетов в эмуляторе, чтобы потом убедиться, что все валидные данные, отправленные эмулятором, оказались в бд(скриптом, можно запускать параллельно нагрузке для экономии времени). Создать сценарии нагрузочного тестирования, предусматривающие отправку как валидных пакетов, так и не валидных, а также сетевые проблемы на сегментах системы. Предусмотреть в валидаторе данных и их укладки в базу работу в режиме поддержки нагрузочного тестирования в реал тайме - валидировать не все данные, а выборочно, случайно выбирая блоки данных из разных потоков, а потом искать их в базе и валидировать.

д) Проверки форс-мажоров. Как система ведет себя(функционально и с точки зрения лоада) на кратковременную недоступность базы данных или джоба сборщика (джоб не помрет, не захлебнется и тп), недоступность фтпшника (уточнить, как потоки данных должны вести себя в этом случае).

Расчеты времени.
1) Эмулятор для бинарного протокола. Если все самому писать + функционал нагрузочного тестирования + нет доков и писавший код программист уволился - 16 часов. Если спереть код и не надо хайлоада - часа 4. Если в итоге имелся ввиду не кастомный протокол, а протобаф какой-нибудь - это час. С учетом отладки, форсмажоров и использования моих наработок - берем 16 часов.
2) Валидатор данных, он же набор автотестов. Выполняет декодирование данных, валидацию данных, поход в таблицу, валидация данных из таблицы. Для хайлоада прибавляется система сохранения промежуточных данных (в память такие объемы лучше не совать), и рандомная проверка кусков в реалтайме (опционально). Плюс скрипт для сравнения логов эмулятора(лайв приложения) с данными в бд (заодно им же можно базу на лоад проверить, если его сделать многопоточным). Плдюс время на отладку(код ревью, если есть кому). Без хайлода - 32 часа. С хайлоадом - 48 часов.
3) Стенд. Все зависит от наличия железа, админа и их вменяемости. Моих работ там на 4 часа, админа и техников ДЦ - лимит у них 32 часа времени, пока я код пишу. Если не хайлоад - за денек админ сам все поднимет, я за час свое барахло настрою. Желательно 2 стенда - один для автовыкладки приложения и прогона автотестов на нем, второй куашный для полного цикла тестов включая полноценную нагрузку.
4) CI(далее СИ). Берем СИ конторы и прикручиваем к нему свои штуки. Нет СИ и приложение хайлоад? Заканчиваем собеседование, уровень вопроса не совпадает с уровнем компании-нанимателя. 4 часа если знакомая СИ. 8 плюс помощь зала если незнакомая. Без СИ придется самому из коммандной строки свое хозяйство запускать, смотреть логи и тп - потери времени.
5) Писанина и говорильня. Написать тестпланы, показать особо умному менеджеру, дописать доки, отписать всем письма, посетить кучу очень важных митингов и прочее. Также сюда включаем походы к программистам для выяснения данных и спецификаций. 8 часов (если контора нормальная), 4 часа(если все прекрасно).
6) Непосредственно тестирование. 8 часов функционального - пересекается с пунктами 1 и 2, так как процессе написания и отладки можно(и нужно) найти много багов, и продолжая отладку их уже будут фиксить.
Функциональное - 20 минут на билд(включая интерпретацию), тестируем покомпонентно. Интеграционное еще минут 20. Лоад (синтетический, сравниваем результаты с предыдущими билдами) - 30 минут. Округляем до полутора часов на полный цикл. Первые запуски будут дольше - отладка, вагон багов и тп.
Конкретно мое время после всех зависимостей - 8 часов(интерпретация результатов, фикс багов в тест системе, походы к програмистам, работа с багтреккерами и тп).
Нагрузочное(если надо) - все зависит от конкретных значений, инфраструктуры сети, статуса приложения (уже работает, или можно перед запуском на лайв площадке провести серию тестов), количества тестовых площадок и кучи всего. Наугад скажу 32 часа в среднем, но тут реально все очень зависит от системы и прочих факторов.
7) Анализ доков и спек. Если их нет - общение с погромистами на предмет "как ваша ботва работает". 8 часов (судя по предварительному описанию задачи).

Порядок выполнения работ:
1) Анализ приложения, документации и планов по развитию приложения. Уточнение технических деталей задачи
2) Тестплан, список тесткейсов, выбить железяки для сред.
3) Пишем код эмулятора и фреймворка для валидации. Попутно даем задание админам разворачивать тестовые среды
4) Запускаем прототипы на первой подготовленной тестовой среде(если все печально - на своем компе и демо среде разработчиков) и билде приложения. Записываем вагон ошибок приложения в треккер. Правим вагон ошибок в своем эмуляторе и валидаторе.
5) По мере разворачивания сред добавляем все это(прототипы, выкладку приложения) к СИ. Проводим первые запуски. Отлаживаем тесты.
6) Расширяем функционал тестов, переносим все из тестплана в код, допридумываем забытое. Автотесты по коммиту разработчиков уже работают, и чего то находят.
7) Завершаем работы с функциональными и интеграционными тестами, если надо - прикручиваем синтетический тест билда на нагрузку (сравниваем результаты нового билда с предыдущими).
8) Нагрузочное тестирование приложения в сборе на среде, максимально приближенной к лайву(желательно на лайве перед запуском приложения в коммерческую эксплуатацию).

Итого:
Максимум (сложное, высоконагруженное приложение, кривые доки, безумные менеджеры): 132 часа(хорошее качество продукта + проверка на нагрузку + налаженная система автотестов для работы с новыми билдами).
Минимум(поделие, отсылающее пару сотен сообщений в день об оказании услуг мелким интернет провайдером): 60 часов(некоторые активности идут параллельно (хорошее качество продукта + налаженная система автотестов для работы с новыми билдами).

Риски: +16 часов для минимума, +32 часа для максимума. В основном риски заключаются в наличии документации в необходимом объеме, оценке сложности системы, человеческом факторе (админ заболел, программист уехал на Аляску в отпуск и тп).

P.S. Секьюрити специально не трогал, так как текущая задача описывает внутреннюю систему-сервис компании, где безопасность реализуется в основном администраторами (аккаунты, фаерволлы). Почему? Если от клиента к вам идет нешифрованный, неподписанный бинарный поток, который молча укладывается в табличку в базе - у вас фэйл на уровне архитектуры системы.
  • 2

#27 Layza

Layza

    Новый участник

  • Members
  • Pip
  • 2 сообщений
  • ФИО:Азовцева Е.В.
  • Город:Томск

Отправлено 06 февраля 2013 - 03:28

В поисках работы и мне "посчастливилось" попасть на собеседование видимо той же организации, однако задание видоизменилось, но суть та же:
Есть система X, которая берет данные в бинарных файлах с FTP сервера, обрабатывает и записывает в таблицы MS SQL. Каждому файлу соответствует 1 тип записи. Всего типов записей – 59. В MS SQL есть, соответственно, есть 59 таблиц.
Систему Х модернизируют так, чтобы она смогла работать с новым поставщиком бинарных данных. Известно, что типы записей могут расшириться до 62, при этом может измениться набор полей в старых типах записей. Новая система разработана, установлена в тестовой среде, берет данные с тестового FTP. Теперь ее необходимо протестировать.
Необходимо:
1) Кратко описать стратегию тестирования – что и как будет проверяться, в какой последовательности
2) Создать 2 тест-кейса
3) Оценить время (в часах) на создание плана тестирования (с тест-кейсами), который после позволит провести тестирование силами другого тестировщика
4) Оценить время (в часах), которое потребуется на тестирование по этому тестовому плану
Если какой-то информации не хватает, то необходимо ввести предположения, с учетом которых будут даны ответы.
Ответы на вопросы необходимо дать в течение 60 минут с момента получения задания.


нашла интересную статью с разбором примеров на данную тему: Моя ссылка

Сообщение отредактировал Layza: 06 февраля 2013 - 03:36

  • 1

#28 LOLWUT

LOLWUT

    Новый участник

  • Members
  • Pip
  • 22 сообщений
  • ФИО:Lol Wut

Отправлено 08 февраля 2013 - 12:08

В поисках работы и мне "посчастливилось" попасть на собеседование видимо той же организации, однако задание видоизменилось, но суть та же:

В этой формулировке задача больше менеджерская, куда более простая и 60 минут - это как то слишком много времени на нее.
  • 0

#29 Mac

Mac

    Новый участник

  • Members
  • Pip
  • 43 сообщений

Отправлено 08 февраля 2013 - 15:23

В этой формулировке задача больше менеджерская, куда более простая и 60 минут - это как то слишком много времени на нее.


Мда. Попадись мне, тест-менеджеру с 8-летним опытом работы, эта задача на собеседовании, ответ был бы выдан за 10 секунд. "Спасибо, до свидания".
  • 1

#30 FreeMan1

FreeMan1

    Новый участник

  • Members
  • Pip
  • 28 сообщений

Отправлено 02 марта 2013 - 01:12


Вопрос на собеседовании-

Дано - есть 59 потоков данных которые в бинарном виде падают на ftp, специальная программа забирает, преобразовывает и сохраняет в 59 таблиц.
1 поток - это один тип услуги. Примеры: 1Смс, 2звонок в дом сети, 3в роуминге, 4заказ услуги по короткому номеру. Для каждого потока 1 таблица.

Задача - 1)описать, как ты будешь тестировать. Перечислить этапы, основные идеи, направления.
2)оценить время тестирования по разработанному тестовому плану.

Задача хорошая для собеседования автоматизатора.

Уложился в 45 минут во время обеда. Поскольку письменно - на реальном собеседовании бы успел описать концепцию куда четче, написать примеры тесткейсов для валидатора + нарисовать схемы системы.

Сначала.
1. Входящие данные - 59 типовых потоков, отличающихся только параметром услуги, несложные. Уточнить спецификацию протокола.
2. Система 3х компонентная. Компонента один - генератор контента (источник потока), компонента два - хранилище, куда падают данные и джоб, который выхватывает данные и ложит в таблицы бд, компонента 3 - сама бд и структура ее таблиц.
3. Варианты приложения - хайлоад(большие потоки данных) или мелкое приложение (раз в 10 сек по какому-то из каналов пролетает пакет из 3х полей вида "вася послал смс пете".

Тестирование.
Необходимо протестировать следующие вещи:
а) Верификация данных в потоках. Необходим эмулятор источника данных. В качестве приемника - автотест, который вызывается параллельно джобу укладки в бд. Автотест банально восстанавливает объекты из бинарных данных и валидирует поля согласно документации и спецификации протокола (если нет - пинать программистов, писать доки). Для скорости разработки проще всего упереть кусок кода из укладчика - он декодирует также, велосипед писать не надо. Для эмулятора - вытащить энкодер из самого приложения(если есть доступ к исходникам кода). Уточнить сетевые параметры - как приложение обрабатывает таймауты, пакетлоссы, какова инфраструктура сети, где это будет(уже) разворачиваться. Если надо - добавить эмуляцию потери связи в автотесты.

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

в) Уточнение объема передаваемых данных. Если приложение хайлоад с кучей данных - заранее заложить в эмулятор данных архитектуру, позволяющую использовать их для генерации нагрузки (многопоточное решение, оптимизация и тп). Предусмотреть логгирование отправленных пакетов в эмуляторе, чтобы потом убедиться, что все валидные данные, отправленные эмулятором, оказались в бд(скриптом, можно запускать параллельно нагрузке для экономии времени). Создать сценарии нагрузочного тестирования, предусматривающие отправку как валидных пакетов, так и не валидных, а также сетевые проблемы на сегментах системы. Предусмотреть в валидаторе данных и их укладки в базу работу в режиме поддержки нагрузочного тестирования в реал тайме - валидировать не все данные, а выборочно, случайно выбирая блоки данных из разных потоков, а потом искать их в базе и валидировать.

д) Проверки форс-мажоров. Как система ведет себя(функционально и с точки зрения лоада) на кратковременную недоступность базы данных или джоба сборщика (джоб не помрет, не захлебнется и тп), недоступность фтпшника (уточнить, как потоки данных должны вести себя в этом случае).

Расчеты времени.
1) Эмулятор для бинарного протокола. Если все самому писать + функционал нагрузочного тестирования + нет доков и писавший код программист уволился - 16 часов. Если спереть код и не надо хайлоада - часа 4. Если в итоге имелся ввиду не кастомный протокол, а протобаф какой-нибудь - это час. С учетом отладки, форсмажоров и использования моих наработок - берем 16 часов.
2) Валидатор данных, он же набор автотестов. Выполняет декодирование данных, валидацию данных, поход в таблицу, валидация данных из таблицы. Для хайлоада прибавляется система сохранения промежуточных данных (в память такие объемы лучше не совать), и рандомная проверка кусков в реалтайме (опционально). Плюс скрипт для сравнения логов эмулятора(лайв приложения) с данными в бд (заодно им же можно базу на лоад проверить, если его сделать многопоточным). Плдюс время на отладку(код ревью, если есть кому). Без хайлода - 32 часа. С хайлоадом - 48 часов.
3) Стенд. Все зависит от наличия железа, админа и их вменяемости. Моих работ там на 4 часа, админа и техников ДЦ - лимит у них 32 часа времени, пока я код пишу. Если не хайлоад - за денек админ сам все поднимет, я за час свое барахло настрою. Желательно 2 стенда - один для автовыкладки приложения и прогона автотестов на нем, второй куашный для полного цикла тестов включая полноценную нагрузку.
4) CI(далее СИ). Берем СИ конторы и прикручиваем к нему свои штуки. Нет СИ и приложение хайлоад? Заканчиваем собеседование, уровень вопроса не совпадает с уровнем компании-нанимателя. 4 часа если знакомая СИ. 8 плюс помощь зала если незнакомая. Без СИ придется самому из коммандной строки свое хозяйство запускать, смотреть логи и тп - потери времени.
5) Писанина и говорильня. Написать тестпланы, показать особо умному менеджеру, дописать доки, отписать всем письма, посетить кучу очень важных митингов и прочее. Также сюда включаем походы к программистам для выяснения данных и спецификаций. 8 часов (если контора нормальная), 4 часа(если все прекрасно).
6) Непосредственно тестирование. 8 часов функционального - пересекается с пунктами 1 и 2, так как процессе написания и отладки можно(и нужно) найти много багов, и продолжая отладку их уже будут фиксить.
Функциональное - 20 минут на билд(включая интерпретацию), тестируем покомпонентно. Интеграционное еще минут 20. Лоад (синтетический, сравниваем результаты с предыдущими билдами) - 30 минут. Округляем до полутора часов на полный цикл. Первые запуски будут дольше - отладка, вагон багов и тп.
Конкретно мое время после всех зависимостей - 8 часов(интерпретация результатов, фикс багов в тест системе, походы к програмистам, работа с багтреккерами и тп).
Нагрузочное(если надо) - все зависит от конкретных значений, инфраструктуры сети, статуса приложения (уже работает, или можно перед запуском на лайв площадке провести серию тестов), количества тестовых площадок и кучи всего. Наугад скажу 32 часа в среднем, но тут реально все очень зависит от системы и прочих факторов.
7) Анализ доков и спек. Если их нет - общение с погромистами на предмет "как ваша ботва работает". 8 часов (судя по предварительному описанию задачи).

Порядок выполнения работ:
1) Анализ приложения, документации и планов по развитию приложения. Уточнение технических деталей задачи
2) Тестплан, список тесткейсов, выбить железяки для сред.
3) Пишем код эмулятора и фреймворка для валидации. Попутно даем задание админам разворачивать тестовые среды
4) Запускаем прототипы на первой подготовленной тестовой среде(если все печально - на своем компе и демо среде разработчиков) и билде приложения. Записываем вагон ошибок приложения в треккер. Правим вагон ошибок в своем эмуляторе и валидаторе.
5) По мере разворачивания сред добавляем все это(прототипы, выкладку приложения) к СИ. Проводим первые запуски. Отлаживаем тесты.
6) Расширяем функционал тестов, переносим все из тестплана в код, допридумываем забытое. Автотесты по коммиту разработчиков уже работают, и чего то находят.
7) Завершаем работы с функциональными и интеграционными тестами, если надо - прикручиваем синтетический тест билда на нагрузку (сравниваем результаты нового билда с предыдущими).
8) Нагрузочное тестирование приложения в сборе на среде, максимально приближенной к лайву(желательно на лайве перед запуском приложения в коммерческую эксплуатацию).

Итого:
Максимум (сложное, высоконагруженное приложение, кривые доки, безумные менеджеры): 132 часа(хорошее качество продукта + проверка на нагрузку + налаженная система автотестов для работы с новыми билдами).
Минимум(поделие, отсылающее пару сотен сообщений в день об оказании услуг мелким интернет провайдером): 60 часов(некоторые активности идут параллельно (хорошее качество продукта + налаженная система автотестов для работы с новыми билдами).

Риски: +16 часов для минимума, +32 часа для максимума. В основном риски заключаются в наличии документации в необходимом объеме, оценке сложности системы, человеческом факторе (админ заболел, программист уехал на Аляску в отпуск и тп).

P.S. Секьюрити специально не трогал, так как текущая задача описывает внутреннюю систему-сервис компании, где безопасность реализуется в основном администраторами (аккаунты, фаерволлы). Почему? Если от клиента к вам идет нешифрованный, неподписанный бинарный поток, который молча укладывается в табличку в базе - у вас фэйл на уровне архитектуры системы.


Вот это я понимаю ответ! Браво и спасибо! Можно использовать как пособие.
Я бы наверное такой план написал бы за часа 4, всегда долго думаю над текстами.
Почерпнул для себя кое-что интересное из вашего поста.
  • 0

#31 lego

lego

    Новый участник

  • Members
  • Pip
  • 3 сообщений
  • ФИО:горчилин илья

Отправлено 01 июня 2013 - 03:52

Я думаю,вас просто продинамили.
  • 0


Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных