| Сегодня 22 января, среда |
      |
  
|
  
Какой рейтинг вас больше интересует?
|
Главная /
Каталог блоговCтраница блогера Software Design/Записи в блоге |
 |
|
Как делать эстимейты?
2011-02-13 14:09:00 (читать в оригинале)Нередко программисту приходится делать эстимейты, т.е. заранее оценивать, сколько времени займёт его работа, сколько времени придётся потратить на тот или иной проект.
В этой заметке я расскажу о нескольких подходах к созданию эстимейтов. Надеюсь, изложенная информация будет полезной.
Первый подход можно назвать "функциональной декомпозицией". Его суть заключается в том, что инженер "дробит" изначально большую задачу на ряд подзадач по функциональному основанию. Каждая из подзадач должна отвечать за выполнение некоторой полезной функции. Дробление следует осуществлять до тех пор, пока инженеру не станет понятно, сколько времени займёт реализация той или иной подзадачи.
Функциональная декомпозиция подходит как для грубой оценки проектов, так и для оценки отдельных задач в рамках конкретного проекта.
В общем случае, хочется дать такие рекомендации:
Дальше »
Почему дизайн должен быть функциональным?
2011-01-22 22:30:00 (читать в оригинале)Нередко разработчик проектирует систему, ориентируясь на что угодно, но только не на удобство её дальнейшего использования. Часто он даже не задумывается, что проектируемая система должна выполнять определённые обязанности.
Чтобы подчеркнуть мысль о том, что дизайн системы должен быть прежде всего функциональным, приведу три примера. Они взяты из разных областей человеческой деятельности, в том числе, и из software design'а.
Пример 1. Панель управления лифтом
В моём доме отремонтировали лифт. Внутри кабины сделали металлическую обшивку. После ремонта панель управления выглядит красиво, но номера этажей на кнопках не различить: цифры – слишком тусклые, а кнопки – через чур блестят.
Чтобы устранить проблему, сообразительные жильцы наклеили рядом с кнопками бумажки с номерами этажей.
Дальше »
Термины и понты: как оценивать опыт специалиста?
2011-01-15 17:22:00 (читать в оригинале)Один мой коллега, перейдя на работу в другую компанию, как-то с сожалением констатировал, что чувствует себя в новой команде "полным нубом". Далее между нами произошёл такой диалог:
Я: Что заставляет тебя оценивать себя так скромно?
Коллега: Меня окружают очень опытные люди.
Я: Почему ты так решил?
Коллега: По их разговорам и используемым терминам. Многие из терминов я просто не знаю...
Этому разговору можно было бы не придавать значения, если бы не обсуждения на программерских форумах, посвящённые тому, как оценивать квалификацию программиста, и не мой интерес к этому вопросу.
Предыдущие публикации и обсуждения смотрите здесь:
Первая публикация
Вторая публикация
Обсуждение
Зададимся вопросом: А как инженеры оценивают квалификацию других инженеров?
Кейс "Проектирование графического редактора"
2011-01-04 13:49:00 (читать в оригинале)Решил объединить свои посты, посвященные вопросам проектирования графического редактора, в отдельный кейс.
1. Общий взгляд на процесс проектирования.
Не смотря на то, что эта заметка описывает подход к собеседованию архитектора, она дает представление и о методике проектирования, изложенной далее.
2. Постановка задачи, декомпозиция задачи на части.
В заметке рассказывается о том, как изначально сложную и большую задачу можно разбить на ряд более конкретных и менее сложных подзадач. Приводится метод составления из этих подзадач плана работ.
3. Проектирование модуля редактирования.
Серия постов, посвященная проектированию ядра графического редактора, отвечающего за создание и редактирования векторного рисунка:
3.1. Создание функциональной модели.
3.2. Проверка и расширение функциональной модели.
3.3. Проектирование классов.
3.4. Проектирование реализации.
4. Проектирование взаимодействия с пользователем.
Несколько заметок, посвященных вопросам проектирования пользовательского интерфейса и механизма взаимодействия с пользователем.
4.1. Рисование фигур.
4.2. Редактирование фигур.
Пластический способ редактирования фигур
2010-12-16 00:52:00 (читать в оригинале)К проектированию взаимодействия с пользователем разработчик может подойти двумя путями:
Первый путь заключается в использовании уже готовых схем, разработанных для стандартных устройств ввода, например, для мыши.
Второй путь заключается в разработке особого механизма взаимодействия, рассчитанного на конкретное устройство ввода, например, мультитач экран.
Первый путь обычно выбирают, когда надо сэкономить время и деньги. Как правило, у разработчика уже имеется отлаженная и апробированная технология, и нужно ее перенести под конкретное устройство. Основное конкурентное преимущество продукта в этом случае заключается не в удобстве интерфейса пользователя, а в функциональном наполнении самого продукта и в скорости вывода его на рынок.
Второй путь выбирают, когда необходимо разработать продукт под конкретное устройство. В этом случае основным конкурентным преимуществом является не только и не столько функциональная наполненность самого продукта, сколько удобство взаимодействия с пользователем.
Дальше »
Категория «Природа»
Взлеты Топ 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 не имеет отношения к публикуемым в записях блогов материалам. Все записи
взяты из открытых общедоступных источников и являются собственностью их авторов.
взяты из открытых общедоступных источников и являются собственностью их авторов.