Докладывали Ведерникова и Шадрина на тему 4 "Организация общения с заказчиком и разработки IT проектов"
мне доклад понравился, докладчики ссылались на "правильные" источкники
классическую книгу Брукса "Мифический человеко-месяц" и "PMBook" (который кстати к своему стыду не осилил пока я сам, хотя девчёнки довольно интересно рассказали оттуда про управление рисками). Кроме того по предмету я бы настоятельно рекомендовал Йордана "Путь камикадзе". Всю перечисленную литературу легко найти в сети в электронном виде на русском языке.
Весьма странно что совсем по их словам не нашли материала на тезис "оценка трудозатрат"
сеть кишмя кишит этой информацией, начиная от разъяснений "на пальцах", вроде:
http://www.rsdn.ru/Forum/?mid=591793
до вполне себе систематических и полунаучных вроде:
http://www.rsdn.ru/Forum/?mid=2693782
http://zhurnal.gpi.ru/articles/2008/030.pdf
http://www.osp.ru/cio/2002/07-08/172220/
http://itc.ua/node/25631
я бы ориентировался на источники.
кроме того у каждого в практическом задании стоит пункт "Оценка трудозатрат".
который у нас тупо и без выдумки будет строиться по следующей простейшей схеме
1) сколько времени ушло на написание ТЗ (смого задания)
2) сколько времени планируется потратить на уровень работы с данными и общую внутреннюю структуру
3) для каждого окошка или странички (экранных форм) которые упомянуты на этапе проектирования интерфейса (именно поэтому важно прописать заранее всё что может понадобиться) посчитать сколько оценить займёт его изготовление (обычно 3-16 часов пишут в зависимости от сложности, но бывают и гораздо более трудоёмкие экранные формы). Для окошек "с закладками" обычно каждую закладку оценивают. То же самое для печатных форм.
4) отдельно оценивается всякая нетривиальная задача или взаимодействие с внешними модулями
5) время на развёртывание или на написание инсталлятора, если требуется
6) время на написание документации, если требуется
7) прикинуть время на тестирование как какой то процент от суммы пунктов 2-4 (10-50 %)
оценки (estimation) составленные в таком стиле обычно выглядят понятными для заказчика (т.е. именно перечисленные "функциональные точки" заказчик понимает)
Далее, докладчики записали экспертов в команду разработчиков (что на самом деле бывает крайне редко) и не упомянули пользователей программы на стороне заказчика вообще.
Значит докладчики получили 5 несмотря на то что не раскрыли один пункт и драматически не уложились по времени. По крайней мере привлекли достаточно обыширный материал и поразбирались в проблеме.
Остальная группа получила следующие оценки за контрольные вопросы по теме (фаимлия, номер вопроса, оценка):
Ботов 9 5
Ившина 6 2
Гиззатова 24 4
Дементьев 16 2
Киселёв 26 4
Копкова 14 5
Злобин 7 3
Каримов 5 5
Белякова 20 2
Вахрушев 23 2
Шалыгина 19 5
Исмагилова 11 5
Леонтьев 22 2
Романова 4 3
Щелчков 3 4
Средняя оценка без учёта пропустивших - 3, с учётом пропустивших - 3.5
Отсуствовали Зиновьева, Серебрянников, Пишков, Пушин.
Кроме того, в начали пары при задержке с докладом попытались исправить двойки за "Тема 1. Проектирование схемы данных" со следующими результатами (фаимлия, номер вопроса, оценка):
Гиззатова 1 5
Злобин 21 2
Вахрушев 11 3
Злобин заявил что нормализация базы данных не всегда доводится до конца потому что это долго.
Несмотря на то что доказанная временная сложность алгоритма нормализации (
http://www.kgau.ru/istiki/teis/ch14s07.html ) - имеет вполне себе полиномальную скорость