Построить один, чтобы выбросить против эффекта второй системы

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

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

Разве здесь нет противоречия между этими принципами? Каков правильный взгляд на проблемы и где находится граница между этими двумя?

Я полагаю, что эти «хорошие практики» были впервые представлены в оригинальной книге Фреда Брукса «Мифический человеко-месяц ».

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

Создание того, что нужно выбросить, происходит из-за того, что вы «не знаете, чего не знаете» с самого начала, поэтому по ходу дела вы узнаете, что должны были сделать в начале.

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

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

Так что создайте один, чтобы выбросить, выбросить его и построить его снова без увеличения объема, и у вас не будет второй проблемы с системой. (Это обычно делается на планетах с фиолетовым небом, розовым морем и летающими свиньями.)

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

Управление качеством - сделай правильно с первого раза! Никогда не используйте временные взломы или временные компромиссы. Там не должно быть никаких переделок. Все ресурсы используются эффективно, и все, что вы делаете, является правильным вкладом в проект.

Анализ осуществимости - выявление потребностей бизнеса. Создайте экономическое обоснование для проекта.

План проекта - Четко определите свою начальную область, спланируйте, как будет доставлено решение, создайте базовую линию, придерживайтесь плана. Не тратьте время на то, что не находится на критическом пути.

Разработка требований - выявление бизнес-требований (т.е. захват бизнес-процессов и определение того, какие бизнес-операции должны поддерживаться компьютеризированной системой, перевод бизнес-операций 1: 1 в варианты использования системы). Подтвердите и подтвердите! (Правильно ли мы строим? Правильно ли мы строим?) Все требования должны быть связаны с первоначальной потребностью бизнеса.

Разработка программного обеспечения - преобразование вариантов использования и модели предметной области в дизайн компонентов и архитектуру решения. Все компоненты должны быть связаны с требованиями RE.

Реализация - код программного обеспечения, как в проекте. Весь код должен быть связан с компонентами из SD.

Валидация - модульное тестирование, интеграционное тестирование, производительность, ... (теперь необходимо протестировать все варианты использования от RE)

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

Посмотрите эти условия, чтобы создать лучшее программное обеспечение и понять его с первого раза:

• Анализ осуществимости (особенно, как построить бизнес-кейс)
• Управление проектом (особенно План проекта и Реестр рисков с уменьшением риска)
• Разработка требований (выявление, анализ, спецификация, проверка)
• Разработка программного обеспечения (UML и разработка программного обеспечения на основе компонентов)
• Построение программного обеспечения (шаблоны проектирования, фреймворки, защитное программирование)
• Проверка программного обеспечения (модульное тестирование, UAT и т. Д.)