Нередко формулировка задачи, полученная от заказчика, вызывает у проектировщика шок:
"Спроектируйте графический редактор".
"Спроектируйте игру для девочек 4 – 8 лет".
"Спроектируйте GPS-навигационную систему для мобильного телефона".
Шок вызывает абстрактность формулировки, отсутствие конкретных требований, а также – непонимание с чего начать и как подступиться к задаче.
Не смотря на шок и кажущуюся сложность, подобные задачи могут быть решены и даже весьма успешно. Но для успеха важно, чтобы проектировщик выполнил определённую процедуру, которая поможет ему добиться трёх целей:
1) выполнить декомпозицию задачи на подзадачи;
2) оценить объём полученных подзадач;
3) составить план работы, упорядочив подзадачи во времени и распределив их между участниками команды.
Мне показалось, или суть процедуры сводится к построение трех квадратиков "Ввод"→ "Обработка"→"Вывод"?
А в целом, на 3-х страницах это не описать. Целые книги посвящены сбору и анализу требованию, описанию прецендетов (что в общем-то оно и есть) и т.п.
Здравствуйте, LeonidV, Вы писали:
LV>Мне показалось, или суть процедуры сводится к построение трех квадратиков "Ввод"→ "Обработка"→"Вывод"?
Можно начинать и с такой простой модели. Но важно потом продолжить и детализировать эти абстрактные действия дальше.
LV>А в целом, на 3-х страницах это не описать. Целые книги посвящены сбору и анализу требованию, описанию прецендетов (что в общем-то оно и есть) и т.п.
Полностью, конечно, всё не описать. Но можно описать подход.
Продолжил описание методики проектирования в новой статье:
Прежде чем проектировать структуры данных, разработчик должен построить функциональную модель проектируемой системы.
В умных книжках по OOA&D рекомендуют поступать наоборот: сначала выявлять классы и объекты и лишь затем – находить операции для этих классов и объектов. Автор данного блога рекомендует не верить умным книжкам и начинать проектирование с выявления функций.
У автора есть веские основания для такой рекомендации: любая техническая система создаётся для выполнения каких-то полезных функций. Если она их не выполняет, то такая система не нужна. Согласитесь, мало кому в быту будет полезен стул со сломанными ножками. Просто потому что на нём невозможно сидеть. В программной индустрии точно также. Если программа не делает нечто полезное, её можно удалить с компьютера, чтобы она не занимала место.
Направление проектирования должно быть задано однозначно: от функций к структурам данных, а не наоборот.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Нередко формулировка задачи, полученная от заказчика, вызывает у проектировщика шок:
КЛ>"Спроектируйте графический редактор". КЛ>"Спроектируйте игру для девочек 4 – 8 лет". КЛ>"Спроектируйте GPS-навигационную систему для мобильного телефона".
Я люблю интервьюирование — беседуем, в реалтайме выписывая значимое на 2 бумажки (ещё лучше — на доску):
1 — ключевые понятия предметной области заказчика и связи между ними.
2 — _цели_ заказчика и связанные с целями требования.
В результате и я, и заказчик узнаём много нового
Дальше — нудятина: описание требований в терминах предметной области, их сортировка по кластерам, примерная оценка трудоёмкости, встреча с заказчиком — уточнение приоритетов и подтверждение тз на текущий этап. И по кругу
Софтинки, не удовлетворяющие сами по себе никаких целей заказчика (кроме "продать и заработать") разрабатывать куда сложнее. В команду на ведущие роли обязательно нужны дизайнер UI + эксперт по юзабилити + тонна прототипов + опыт подобных разработок.
В любом случае, бросаться в построение функциональной модели/модели классов, не уяснив до конца нюансы предметной области несколько опрометчиво
Re[2]: Как правильно выполнять декомпозицию задачи?
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>В умных книжках по OOA&D рекомендуют поступать наоборот: сначала выявлять классы и объекты и лишь затем – находить операции для этих классов и объектов. Автор данного блога рекомендует не верить умным книжкам и начинать проектирование с выявления функций.
В каких именно?
Как я понимаю умные книжки, сначала выявляют кто будет пользоваться системой. Затем описываются сценарии (ну или преценденты), из которых выявляют модели предметной области. Потому уже при необходимости делают описания сценариев.
Здравствуйте, LeonidV, Вы писали:
LV>Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>>В умных книжках по OOA&D рекомендуют поступать наоборот: сначала выявлять классы и объекты и лишь затем – находить операции для этих классов и объектов. Автор данного блога рекомендует не верить умным книжкам и начинать проектирование с выявления функций. LV>В каких именно?
Мейер "OOA&D"
Нельсон "DDD"
Re[4]: Как правильно выполнять декомпозицию задачи?
Судя по названию OOA&OOD речь в книгах идет о проектирование архитектуры. Это следующий этап после сбора требований.
Про DDD ничего сказать не могу. Разве что процитировать wikipedia:
Domain-driven design is not a technology or a methodology. DDD provides a structure of practices and terminology for making design decisions that focus and accelerate software projects dealing with complicated domains.
Здравствуйте, LeonidV, Вы писали:
LV>Судя по названию OOA&OOD речь в книгах идет о проектирование архитектуры. Это следующий этап после сбора требований.
LV>Про DDD ничего сказать не могу. Разве что процитировать wikipedia:
LV>
LV>Domain-driven design is not a technology or a methodology. DDD provides a structure of practices and terminology for making design decisions that focus and accelerate software projects dealing with complicated domains.
Тут речь идет о том что пишут в конкретных книгах. Если ко всему подходить с умом, то проблем не будет.
Re[6]: Как правильно выполнять декомпозицию задачи?
Здравствуйте, gandjustas, Вы писали:
G>Тут речь идет о том что пишут в конкретных книгах. Если ко всему подходить с умом, то проблем не будет.
Может быть. Просто на мой взгляд автор (Кирилл Лебедев) пишет о достаточно очевидных вещах на достаточно примитивном уровне. Например, в описание прецендентов (хотя у него скорее процедуры описаны) должны быть указаны акторы. А их нет. Нет и цели. Ну и много чего другого.
Мне кажется, совершенно напрасно ожидать описания процесса проектирования в одном посте. Слишком уж объёмна и многогранна эта тема.
Тем не менее, и о работе с заказчиком, и о разбиении требований на кластеры и об уточнении приоритетов я уже кое-что написал.
S>Я люблю интервьюирование — беседуем, в реалтайме выписывая значимое на 2 бумажки (ещё лучше — на доску):
Об общении с заказчиком и выявлении целей немного написано здесь.
S>Дальше — нудятина: описание требований в терминах предметной области, их сортировка по кластерам, примерная оценка трудоёмкости, встреча с заказчиком — уточнение приоритетов и подтверждение тз на текущий этап. И по кругу
О разбиении задачи на подзадачи и об уточнении приоритетов написано здесь и здесь.
S>В любом случае, бросаться в построение функциональной модели/модели классов, не уяснив до конца нюансы предметной области несколько опрометчиво
Общий взгляд на процесс проектирования (что называется, с "птичьего полёта") изложен здесь.
Здравствуйте, LeonidV, Вы писали:
LV>Здравствуйте, gandjustas, Вы писали:
G>>Тут речь идет о том что пишут в конкретных книгах. Если ко всему подходить с умом, то проблем не будет. LV>Может быть. Просто на мой взгляд автор (Кирилл Лебедев) пишет о достаточно очевидных вещах на достаточно примитивном уровне. Например, в описание прецендентов (хотя у него скорее процедуры описаны) должны быть указаны акторы. А их нет. Нет и цели. Ну и много чего другого.
Да, пишет конечно простовато. Но учитывая что многие подходят к проектированию так как написано в книгах, не понимая зачем так делать, информация может быть полезной.
Re[3]: Как правильно выполнять декомпозицию задачи?
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, Sinix, Вы писали:
КЛ>Мне кажется, совершенно напрасно ожидать описания процесса проектирования в одном посте. Слишком уж объёмна и многогранна эта тема.
КЛ>Тем не менее, и о работе с заказчиком, и о разбиении требований на кластеры и об уточнении приоритетов я уже кое-что написал.
S>>Я люблю интервьюирование — беседуем, в реалтайме выписывая значимое на 2 бумажки (ещё лучше — на доску): КЛ>Об общении с заказчиком и выявлении целей немного написано здесь.
S>>Дальше — нудятина: описание требований в терминах предметной области, их сортировка по кластерам, примерная оценка трудоёмкости, встреча с заказчиком — уточнение приоритетов и подтверждение тз на текущий этап. И по кругу КЛ>О разбиении задачи на подзадачи и об уточнении приоритетов написано здесь и здесь.
S>>В любом случае, бросаться в построение функциональной модели/модели классов, не уяснив до конца нюансы предметной области несколько опрометчиво КЛ>Общий взгляд на процесс проектирования (что называется, с "птичьего полёта") изложен здесь.
Проблема в том что все эти части взаимосвязаны. По отдельности нельзя рассматривать сбор требований, выявление фич, проектирование, прототипирование и другие активности цикла разработки. Независимое выполнение этих этапов тут любят называть "waterfall" и очень сильно ругать.
Re[4]: Как правильно выполнять декомпозицию задачи?
Здравствуйте, gandjustas, Вы писали:
G>Проблема в том что все эти части взаимосвязаны. По отдельности нельзя рассматривать сбор требований, выявление фич, проектирование, прототипирование и другие активности цикла разработки. Независимое выполнение этих этапов тут любят называть "waterfall" и очень сильно ругать.
Нет смысла спорить, все эти вещи взаимосвязаны. Но если их описывать в одной статье, у нас получится не инструментальная, а описательная модель. Потому что иначе не получится справиться с объёмом материала, который придётся изложить.
К сожалению (или к счастью?), в реальной жизни практическую ценность носят именно инструментальные модели. Поэтому и приходится описывать методику проектирования по частям.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, gandjustas, Вы писали:
G>>Проблема в том что все эти части взаимосвязаны. По отдельности нельзя рассматривать сбор требований, выявление фич, проектирование, прототипирование и другие активности цикла разработки. Независимое выполнение этих этапов тут любят называть "waterfall" и очень сильно ругать.
КЛ>Нет смысла спорить, все эти вещи взаимосвязаны. Но если их описывать в одной статье, у нас получится не инструментальная, а описательная модель. Потому что иначе не получится справиться с объёмом материала, который придётся изложить.
КЛ>К сожалению (или к счастью?), в реальной жизни практическую ценность носят именно инструментальные модели. Поэтому и приходится описывать методику проектирования по частям.
В данном случае инструментальная модель слишком упрощена, примерно до той степени, где она теряет связь с реальным миром, ей как раз не хватает описательной части.
Re[5]: Как правильно выполнять декомпозицию задачи?
Здравствуйте, Кирилл Лебедев, Вы писали: КЛ>Нет смысла спорить, все эти вещи взаимосвязаны. Но если их описывать в одной статье, у нас получится не инструментальная, а описательная модель. Потому что иначе не получится справиться с объёмом материала, который придётся изложить.
Ну вы-то даете без привязки одного к другому.
Модель это представление объективной реальности. Что вы вкладываете в термины инструментальной и описательной модели и в чем разницам между ними?
Здравствуйте, LeonidV, Вы писали:
LV>Ну вы-то даете без привязки одного к другому.
Не согласен. Сначала был изложен общий взгляд на процесс проектирования, теперь — излагается детализация отдельных шагов.
LV>Модель это представление объективной реальности. Что вы вкладываете в термины инструментальной и описательной модели и в чем разницам между ними?
С точки зрения американского нейропсихолога Л. Сквайра термин "описательная модель" (или "декларативные знания") "означает, что человек имеет ясный и доступный отчет о своем опыте, чувство знакомства с этим опытом" (см. здесь).
"В отличие от декларативных знаний, человек, обладающий процедурными знаниями (инструментальная модель — К.Л.), знает, как нужно действовать" (см. здесь).
Здравствуйте, gandjustas, Вы писали:
G>В данном случае инструментальная модель слишком упрощена, примерно до той степени, где она теряет связь с реальным миром, ей как раз не хватает описательной части.
Что на Ваш взгляд имеет смысл добавить?
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, gandjustas, Вы писали:
G>>В данном случае инструментальная модель слишком упрощена, примерно до той степени, где она теряет связь с реальным миром, ей как раз не хватает описательной части. КЛ>Что на Ваш взгляд имеет смысл добавить?
1)Стоит добавить цели создания графического редактора (vision). Сейчас этих редакторов немеряно, если пытаться сделать лучше, то одной статьи не хватить даже чтобы описать чем он лучше будет.
2)Для каждого дизайнерсокого решения указывать на достижения какой цели оно направлено.
3)Указать итерационность процесса, выделить фичи, указать и обосновать приоритеты.
ЗЫ. Пока писал понял две вещи. Графический редактор слишком сложен для иллюстрации всех принципов, лучше навигационную систему брать. Наиболее интересно будет показать процесс проектирования (и всего остального) в рамках существующей методологии, будь то RUP, MSF или SCRUM.
