| Сегодня 22 января, среда |
      |
  
|
  
Какой рейтинг вас больше интересует?
|
Главная /
Каталог блоговCтраница блогера Software Design/Записи в блоге |
 |
|
Проектирование: как выполнять декомпозицию задачи?
2010-10-31 21:58:00 (читать в оригинале)Нередко формулировка задачи, полученная от заказчика, вызывает у проектировщика шок:
- "Спроектируйте графический редактор".
- "Спроектируйте игру для девочек 4 – 8 лет".
- "Спроектируйте GPS-навигационную систему для мобильного телефона".
Шок вызывает абстрактность формулировки, отсутствие конкретных требований, а также – непонимание с чего начать и как подступиться к задаче.
Не смотря на шок и кажущуюся сложность, подобные задачи могут быть решены и даже весьма успешно. Но для успеха важно, чтобы проектировщик выполнил определённую процедуру, которая поможет ему добиться трёх целей:
- выполнить декомпозицию задачи на подзадачи;
- оценить объём полученных подзадач;
- составить план работы, упорядочив подзадачи во времени и распределив их между участниками команды.
Рассмотрим эту процедуру на примере проектирования графического редактора.
Дальше »
Литература
2010-10-27 22:54:00 (читать в оригинале)Решил систематизировать некоторые свои публикации по четырём темам:
1) Ошибки в программировании
2) Проектирование игр и программ
3) Продвижение программ и услуг по их разработке
4) Проектирование нового продукта (hard & soft)
Общение с заказчиком: переходим на язык задач и проблем
2010-10-22 17:17:00 (читать в оригинале)Прежде чем приступать к решению задачи, грамотный проектировщик должен сначала её поставить...
Мне часто приходилось слышать о том, что неправильный дизайн системы существенно увеличивает затраты на разработку. Это действительно так. Думаю, немногие попытаются опровергнуть данное утверждение. Согласно моему опыту неправильная архитектура может увеличить затраты на 50, 80 и даже 90 процентов.
Такой перерасход бюджета является серьёзной проблемой, но не катастрофой. Последствия плохой архитектуры могут быть частично скомпенсированы хорошим менеджментом (== грамотным распределением задач) и, наоборот, плохой менеджмент может быть частично скомпенсирован хорошим дизайном. Почему? Потому что хороший дизайн вызывает меньше проблем и, как следствие, уменьшает нагрузку на менеджера.
Более страшной – в плане затрат– является неправильная постановка задачи. Потому что она увеличивает расходы в разы. (Запросто может увеличить бюджет в 2, в 3 и даже в 4 раза.) Здесь я имею в виду ситуацию, когда разработчики делают не то, что клиенту нужно, а реализуют то, что клиент говорит.
Проектирование архитектуры программы: постановка задачи
2010-10-17 15:07:00 (читать в оригинале)Первоначально я хотел продемонстрировать, как следует ставить задачи проектирования, на другом примере. Но поскольку на RSDN.RU возникло обсуждение задачи из моего блога, я решил не увеличивать число сущностей сверх необходимого и использовать уже готовый пример. :)
В своём сообщении коллега Undying сформулировал такие требования к кандидату:
С виду в задаче нет ничего уникального. От кандидата требуется иметь опыт реализации высоконагруженных серверных приложений работающих в режиме 24 * 7. Сложность только в том как понять, что человек не просто участвовал в разработке такой системы, а играл в этом ключевую роль. По идее проще всего это выяснить в беседе о том какие проблемы были встречены при реализации, как их решали, как производилось расширение и добавление функциональности.
На мой взгляд, эти требования вытекают из общих соображений. Такая тактика нередко используется заказчиками. Она действительно имеет право на жизнь, но часто не приносит положительных результатов. Почему?
Дальше »
Собеседование с архитектором: методические рекомендации
2010-10-14 20:09:00 (читать в оригинале)Предположим, существует идеальная методика, которая позволяет эффективно решать задачи проектирования.
Предположим также, что с точки зрения методики совершенно неважно, какого рода приложения будут проектироваться – консольные игры или высоконагруженные сервера. Методика помогает для каждой ситуации выявлять необходимые задачи и их решать.
Тогда процедура проверки квалификации архитектора сводится к проверке следованию им методике:
(1) Если архитектор в процессе проектирования следует рекомендациям методики, то мы считаем его квалифицированным.
(2) Если архитектор в процессе проектирования не следует рекомендациям методики, то мы упрощаем себе жизнь и считаем его неквалифицированным.
Попробуем предположить, какой должна быть эта методика.
Категория «Природа»
Взлеты Топ 5
 | ||
|
+402 |
425 |
MODRA_NEST |
|
+368 |
444 |
Zoxx.ru - Блог Металлиста |
|
+361 |
432 |
Kitten |
|
+318 |
438 |
RouxAngel |
|
+301 |
339 |
Painter-boy |
Падения Топ 5
 | ||
|
-1 |
107 |
ZA7GORAMI.RU |
|
-1 |
135 |
Смотреть мир с Google Планета Земля |
|
-2 |
148 |
Фотолаборатория: портретная и тематическая фотосъемка |
|
-3 |
165 |
TURMIR - ВЗГЛЯНИ НА МИР ПО ДРУГОМУ |
|
-9 |
4 |
Novov.Ru/Блог |
Популярные за сутки
Загрузка...
BlogRider.ru не имеет отношения к публикуемым в записях блогов материалам. Все записи
взяты из открытых общедоступных источников и являются собственностью их авторов.
взяты из открытых общедоступных источников и являются собственностью их авторов.