Какие важные артефакты дизайна вы производите?[закрыто]

Question

Какие важные артефакты дизайна вы создаете в ходе жизненного цикла разработки программного обеспечения?Что делает их важными для вашей практики?

Проект, над которым я сейчас работаю, находится в производстве более 8 лет.Это веб-приложение за это время активно улучшалось и поддерживалось.Хотя у нас есть политики и процессы, основанные на CMMI, а некоторые части нашей практики четко определены, этап проектирования по большей части упускается из виду.Лучшие практики, кто-нибудь?

Answer 1

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

Для общего серверного «корпоративного приложения» я бы хотел, чтобы минимальный минимум был примерно таким:

• Подробный документ функционального дизайна (он же спецификация).В общем, что-то вроде Джоэла. Пример спецификации WhatsTimeIsIt, хотя, вероятно, с некоторыми диаграммами вариантов использования UML.
• Документ технического проекта программного обеспечения.Не обязательно подробно для 100% покрытия системы, но подробно во всех ключевых областях и со всеми проектными решениями.Будучи немного помешанным на UML, было бы неплохо увидеть множество изображений в виде диаграмм пакетов, диаграмм компонентов, диаграмм классов ключевых функций и, возможно, некоторых диаграмм последовательности, добавленных для наглядности.
• Документ проектирования инфраструктуры.Вероятно, с диаграммой развертывания UML для концептуального проектирования и, возможно, с сетевой диаграммой для чего-то более физического.

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

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

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

Answer 2

Рабочий код... и рисунки на доске.

:П

Answer 3

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

Я фотографирую доски и сохраняю файлы JPEG в систему контроля версий.Это одни из моих лучших дизайнерских документов!

Answer 4

В нашей модели (которая достаточно специфична для приложений бизнес-процессов) артефакты проектирования включают в себя:

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

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

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

Answer 5

Это не проектный документ как таковой, а наш модульные тесты служат двойной цели: «описывают», как должен функционировать тестируемый ими код.Самое приятное в этом то, что они никогда не устарею, поскольку для успешной сборки наши модульные тесты должны пройти успешно.

Answer 6

Я не думаю, что что-либо может заменить старую добрую спецификацию дизайна по следующим причинам:

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

Мне нравится видеть различную информацию в спецификации дизайна:

• Общее объяснение вашего подхода к решению поставленной задачи.
• Как вы будете контролировать свое приложение?
• Каковы проблемы безопасности и как они решаются?
• Блок-схемы/диаграммы последовательности
• Открытые вопросы
• Известные ограничения

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