Планирование применительно к основным

факторам практичности

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

Полезное правило. Для каждой области проекта, представленной в план – графике , предусмотрите по меньшей мере две недели дополнительного времени.

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

Полезное правило. Бригада программистов должна уметь выполнять оценки в терминах SMOP-единиц (Small Matter of Programming Units — небольшие програм­мистские вопросы), где

• 1SMOP = пол овина рабочего дня программиста (4 часа);

• 1 неделя = 32 программистских часа.

Распределение задач реализации. При календарном планировании эта­пов UDCUT необходимо учесть некоторую форму пересмотра высокоуровневых про­ектных решений и спецификации. Попросите бригаду разработчиков продукта на­звать реальные даты этапов UDCUT. Это заставит бригаду реализации мыслить в тер­минах осуществления непрерывных этапов

• проектирования для ПИ и реализации (UD — User Interface Design);

• реализации (С - Construction - Code);

• модульного тестирования (UT — Unit Testing).

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

Полезное правило. Перекрытие задач проектирования в принципе возможно, однако планировать следует последовательные задачи реализации.

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

Продолжение обсуждения проекта:

составление плана

Идет вторая неделя проекта и рабочая лихорадка продолжается. Лидер проекта сдержал обещание предоставить предварительную оценку, план-график проекта и оценки возможных ресурсов для проекта. На вас возложена общая ответственность за ПИ, практичность и коллектив людей, вовлеченных в разработку. Вам поручено на­писать план разработки ПИ и план проекта, ориентированного на пользователя (User-Centered Design — UCD), а также план-график для проекта в целом.

План и план-график для ПО, не относящегося к ПИ, составляет ваш коллега по бригаде; он заверил вас, что требования будут поддержаны без всяких вопросов с его стороны. Предположим, что его намерения и заверения реальны.

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

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

• Необходимые ресурсы и навыки.

• Возможный план-график (на следующие две недели, на следующие 90 дней, на все время проекта).

• Потенциальная последовательность этапов по реализации возможностей, включая первоочередную поставку Web-компоненты.

• Области риска для продукта, пользовательского интерфейса и практичности.

• Вероятное количество итераций и плановое время осуществления каждой из них.

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

Позаботьтесь о том, чтобы провести поиск информации в Internet, которая могла ; бы оказаться потенциально полезной при планировании и разработке проекта. ; Вопросы?

Ссылки

Brooks F. The Mythical Man Month, Addison-Wesley: New York, 1995.

Cantor M.R. Object-Oriented Project Management, Wiley & Sons: New York, 1998.

Gould J. et al. Making Usable, Useful, and Productivity Enhancing Computer Applications, Communications of the ACM, Jan. 1991.

A Guide to Software Usability, IBM Corporation: Purchase, NY, SC26-3000. > Karat С Cost-Benefit Analysis of Iterative Usability Testing, ACM/SIGCHI Tutorial, May 1991. i McConnellS. Rapid Development, Microsoft Press: Redmond, WA, 1996.

MayHew D. Managing the Design of the User Interface, ACM/SIGCHI Tutorial, May 1991.

Nielsen J. The Usability Engineering Life Cycle, Computer Magazine, Mar. 1992.

RettigM. Interface Design When You Don't Know How, Communications of the ACM, Jan. 1992.

Torres RJ. User Interface Design and Development, Westlake Reflections, 1991.