Разработка метрик проектирования и генерации модулей

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

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

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

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

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

Составьте предварительный перечень модулей, выберите средства, при помощи которых их нужно реализовать (на данном этапе это ни к чему не обязывает), назначьте каждому модулю средство и укажите сложность. Не изобретайте восемь или девять уровней сложности, а используйте максимум четыре:

простой;

средний;

сложный;

очень сложный.

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

Что же такое метрики? Это просто таблицы плановой трудоемкости (в Щ человеко-днях) для каждого уровня сложности и каждого средства разработ- I ки, которое будет использоваться при программировании. В табл. 17.1 мы разбили метрики на три задачи: проектирование программы, генерация и автономное тестирование.

Таблица 17.1. Примерные метрики для Oracle Forms 4.0/4.5

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

стабильность модели данных в процессе проектирования и генерации модулей;

соответствующий уровень квалификации разработчиков;

пригодность выбранного комплекта средств разработки;

использование (или неиспользование) генераторов кода;

соответствие среды разработки (аппаратные средства, программное обеспечение, сеть);

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

К сведению

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

Средства разработки 3-ro поколения

Средства УРП

Сложность

Рис. 17.1. Влияние сложности на трудоемкость в зависимости от типа средства разработки

Как и на многих подобных графиках, на нем подозрительно отсутствует масштаб осей. Тем не менее, из графика все-таки видно, что если уж дела начинают идти плохо, то при использовании средств разработки некоторых типов они идут очень плохо.

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

Изгнание мегамодулей

в следующих разделах мы опишем, в каких формах проявляется влияние мегамодулей. Грустно, но мегамодульная экранная форма, или форма-суие;>-мен, - весьма распространенная особенность интерактивных систем. В этих случаях часто обнаруживается, что одной формой поддерживается несколько прикладных функций. Например, в одном знаменитом приложении на базе Oracle Forms нам посчастливилось быть свидетелями того, как все DML-операции (кроме операций сопровождения справочных таблиц) содержались в одном триггере ON-COMMIT дьявольской сложности. В качестве оправдания говорилось, что так нужно пользователям. Однако причиной появления одного из нас на этом узле являлись постоянные жалобы пользователей на плохую производигтельность и недостаточную надежность этой экранной формы. В результате первым этапом нашей работы стало выяснение того, что пользователи хотят, чтобы приложение работало не так. Другой случай: один гордый разработчик показал нам приложение, разработанное в одной форме Oracle с 70 экранными страницами!