Блин классные заметки. Все как в жизни. Спасибо SALar.

Вы не указали сложность сайтов. Приведите хотя бы некоторые из величин:
1) число вариантов использования
2) число функциональных точек
3) цикломатическая сложность кода

Если ваш сайт имеет один единственный ВИ "показать контент" (сайт визитка), то все сводится к тому "а как я сверстал?". Как мы понимаем в этом случае отладка резко отличается от варианта, когда на тонком клиенте реализована складская система на полтысячи ВИ. Не так ли?

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

К сожалению таких умных определений я не знаю (число функциональных точек, цикломатическая сложность кода) и ответить точно на вопрос не могу, да и не доконца понимаю зачем это сейчас топикстартеру. У нас сложность как правило определялась наличием модулей (каталог товаров, интернет магазин), сложностью доработок в стандартных наработанных модулях под конкретно этот сайт и существованием модулей которые надо будет писать "с нуля". Могу сказать что сложными сайтами для нас были http://asiastroy.kz/ и http://www.gostudygo.kz/.

Когда я занимался разработкой Интернет-сайтов отладка занимала примерно 15-30% от времени разработки. Но тут надо учитывать специфику - сайты строятся на уже отработанных модулях => почти не тратится время на разработку сценариев тестирования и как правило сталкиваешься с типичными багами. Чем сложнее сайт тем больше в % отношении отводилось на тестирование.

Созданная Вами тема довольно таки обширна (управление изменениями, управление проектами, взаимодействие с заказчиком и т.д.) и вместить все в 3-и вопроса-ответа точно не получиться smile.gif

Я понимаю. Это больше похоже на начало моего пути и хотелось бы посоветоваться у бывалых с чего начать.

Добрый день, уважаемые коллеги.

Дано: автоматизированная банковская информационная система (АБИС). Она состоит как из внутренних разработок, так и сторонних приложений. Все это работает в одной связке. так же есть набор пожеланий от людей которые непосредственно работают с этой системой, требования центрального банка, налоговой и т.д. Пожелания формализованы в виде служебных записок. Сейчас для управления изменениями мы используем MS Project.

Вопрос 1: С чего можно начать изучения такой области как "Управление изменениями" в разрезе моей специфики?
По сути изменения - это отдельные проекты, но со своей спецификой. В источниках как правило описана организация работы HelpDesk (однотипные задачи) или последовательное развитие какой-то программы (определяют как изменения войдут в следующую версию продукта). В изменениях банковского ПО такой подход не совсем удобен т.к. мы не можем себе позволить ждать внедрение какого-нибудь отчета до следующей версии всей системы (изменения делаются в 1-2 модулях) и изменения не однотипные.

Вопрос 2: С чего можно начать изучения такой активности как "Определение важности задач" в разрезе моей специфики?
Запросы на изменения поступает из разных источников (около 30 бизнес-владельцев т.е. более 200 доработок постоянно "в обойме"), сами изменения часто совсем разношерстные и каждый просит сделать именно его доработку быстрее. Хотелось бы разработать механизм определения важности. Была попытка создать подобную систему основанную на предполагаемой финансовой отдачи от изменения, но она потерпела неудачу т.к. не всегда удается все измерить деньгами.

Вопрос 3: Есть ли что-то более удобное для управления изменениями нежели MS Project?
Основные требования удобство создания и изменения планов, удобство просмотра хода проекта (состояние, %), настраиваемые оповещения.

Думаю со временем круг вопросов расшириться на более подробные. Поэтому буду благодарен за Ваши советы.