버리기 위해 하나를 구축하고 두 번째 시스템 효과


15

한편으로는 "쓰러 뜨리기 위해 하나 짓기"라는 조언이 있습니다. 소프트웨어 시스템을 완성하고 최종 제품을 본 후에 만 ​​디자인 단계에서 무엇이 잘못되었는지 알고 실제로 어떻게해야하는지 이해합니다.

반면에 "제 2 시스템 효과"는 같은 종류의 제 2 시스템이 일반적으로 첫 번째 시스템보다 나쁘다고 말합니다. 첫 번째 프로젝트에는 적합하지 않은 기능이 많고 두 번째 버전으로 밀려 났으며 일반적으로 지나치게 복잡하고 과도하게 설계되었습니다.

이 원칙들 사이에 모순이 없는가? 문제에 대한 올바른 견해는 무엇이며이 둘 사이의 경계는 어디에 있습니까?

나는 이러한 "좋은 관행"이 Fred Brooks의 " The Mythical Man-Month "책에서 처음으로 홍보되었다고 생각합니다 .

이러한 문제 중 일부는 민첩한 방법론으로 해결된다는 것을 알고 있지만, 여전히 문제는 여전히 원칙입니다. 예를 들어, 라이브를 시작하기 전에 3 번의 스프린트로 중요한 디자인 변경을하지 않습니다.


3
개인적으로 나는 문제의 기본을 이해하기 위해 3 가지, 진보 된 것을 이해하기 위해 3 가지, 그리고 올바르게 이해하기 위해서는 3 가지가 필요하다고 생각합니다.
Wyatt Barnett

5
@Wyatt : 제 경우에는 "올바르게"올바른 숫자는 n + 1이며, n은 현재 반복입니다
mattnz

답변:


23

버리기 위해 하나를 짓는 것은 처음에 "알지 못하는 것을 모르는 것"에서 나온 것이므로, 처음 시작할 때해야 할 일을 배우면서 배우게됩니다.

두 번째 시스템 효과는 "지금 모르는 것을 아는 것, 그러나 여전히 모르는 것을 모르는 것"에서 비롯됩니다. 즉, 두 번째 시스템 효과는 지식 없이도 첫 번째 것보다 더 크고, 더 밝고, 복잡한 시스템을 만들려고합니다. 처음에 필요한-첫 번째 시스템에서 발생하는 것과 매우 흡사합니다.

따라서 두 번째 시스템 효과는 모순이 아닙니다. 첫 번째와 같은 기능으로 두 번째 시스템을 구축하는 것은 (내가 아는 한) 결코 수행되지 않습니다. 두 번째 시스템은 항상 "더 나은"상태 여야하므로 더 복잡하므로 첫 번째 시스템과 실질적으로 유사한 문제가 예상됩니다.

따라서 버리고 확장하고 스코프 확대없이 다시 빌드하면 두 번째 시스템 문제가 발생하지 않습니다. (이는 자주색 하늘, 분홍색 바다 및 날고있는 돼지가있는 행성에서 더 자주 수행되는 경향이 있습니다.)


"첫 번째 시스템은 버려 질 것"이 아닌가? 이것이 사실이라면, 내가 아는 한, 프로토 타입은 보통 tend 제품의 모든 기능을 가지고 있지 않습니다. 또는 최소한 폐기 프로토 타입과 관련하여.
m3th0dman

그렇기 때문에 이후 스프린트에서 크게 리팩토링해야하며 제품 백 로그에서 새로운 요구 사항이 발견 될 때 문제 해결을위한 초기 시도를 포기해야합니다.
Joeri Sebrechts

@Joeri Sebrechts Refactoring은 첫 번째 시스템을 버리는 것을 의미하지 않습니다. 또한 당신은 ... 잘못된 요구 사항이나 잘못된 구조를 리팩토링 수 없습니다
m3th0dman

명시 적으로 명확하게하기 위해이 답변에 추가해야 할 유일한 것은 두 번째 시스템이 두 번째 프로덕션 시스템을 참조한다는 것입니다.
토마스 오웬스

0

언급 한 문제는 여러 가지를 건너 뛰었고 결과 시스템이 잘못되었음을 의미합니다. 누락 된 단계 중 일부를 설명하겠습니다.

품질 관리-처음부터 제대로하십시오! 일시적인 해킹이나 일시적인 타협을 사용하지 마십시오. 재 작업이 필요하지 않다. 모든 리소스가 효율적으로 사용되며 모든 작업이 프로젝트에 적절하게 기여합니다.

타당성 분석-비즈니스 요구를 발견하십시오. 프로젝트의 비즈니스 사례를 만듭니다.

프로젝트 계획-초기 범위를 명확하게 정의하고 솔루션 제공 방법을 계획하고 기준을 작성하며 계획을 고수하십시오. 중요한 길에 있지 않은 것에 시간을 보내지 마십시오.

요구 사항 엔지니어링-비즈니스 요구 사항 도출 (예 : 비즈니스 프로세스를 캡처하고 컴퓨터 시스템이 지원해야하는 비즈니스 작업 결정, 1 : 1 비즈니스 작업을 시스템 사용 사례로 변환) 확인 및 확인! (우리는 올바른 것을 구축하고 있습니까? 우리는 올바른 것을 구축하고 있습니까?) 모든 요구 사항은 원래 비즈니스 요구와 연결되어야합니다.

소프트웨어 설계-사용 사례 및 도메인 모델을 컴포넌트 설계 및 솔루션 아키텍처로 변환합니다. 모든 구성 요소는 RE의 요구 사항에 링크되어야합니다.

구현-디자인과 같이 소프트웨어를 코딩하십시오. 모든 코드는 SD의 구성 요소에 연결되어야합니다.

유효성 검사-단위 테스트, 통합 테스트, 성능, ... (RE의 모든 사용 사례를 테스트해야 함)

이들은 소프트웨어 프로세스의 몇 가지 주요 측면입니다. 언급 된 활동은 소프트웨어 엔지니어링의 일부입니다. 이것이 바로 실제 비즈니스 요구에 적합한 소프트웨어 솔루션을 구축하고 예산에 맞춰 사양에 맞게 솔루션을 구축하는 방법입니다.

더 나은 소프트웨어를 구축하고 처음에 올바르게 사용하려면 다음 용어를 찾아보십시오.

  • 타당성 분석 (특히 비즈니스 사례 구축 방법)
  • 프로젝트 관리 (예 : 프로젝트 완화 계획 및 위험 완화를 통한 위험 등록)
  • 요구 공학 (정리, 분석, 사양, 검증)
  • 소프트웨어 디자인 (UML 및 컴포넌트 기반 소프트웨어 엔지니어링)
  • 소프트웨어 구성 (디자인 패턴, 프레임 워크, 방어 프로그래밍)
  • 소프트웨어 검증 (단위 테스트, UAT 등)

1
요구 사항이 변경되면 항상 재 작업이 필요합니다. 그러나 잘 설계된 시스템에서 이러한 재 작업은 관련없는 부품에 영향을주지 않고 점진적이고 깨끗하게 수행 할 수 있습니다.
JesperE

꿈꾸세요 고객이 원하는 것을 필요로 미리 알기를 기대합니다. 이것은 일어나지 않습니다. 그래서 우리는 민첩한 방법을 사용합니다.
Reinstate Monica-M. Schröder

즉, 회사의 비즈니스 프로세스가 변경되고 자주 발생하지 않는 경우 sw 만 변경하면됩니다.
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.