혼돈 모형

컴퓨팅에서 혼돈 모델은 소프트웨어 개발의 구조다.L.B.S. 라쿤이라는 필명을 사용한 크리에이터는 Spiral 모델과 폭포 모델과 같은 프로젝트 관리 모델들은 스케줄과 직원 관리를 잘하면서도 버그를 고치거나 다른 기술적 문제를 해결할 수 있는 방법을 제공하지 않았다고 지적했다.^[1]동시에, 프로그래밍 방법론은 버그를 수정하고 기술적 문제를 해결하는 데는 효과적이지만, 마감일을 관리하거나 고객의 요청에 응답하는 데는 도움이 되지 않는다.그 구조는 이 간극을 메우려 한다.혼돈 이론은 이러한 문제들을 이해하는 데 도움을 주는 도구로 사용되었다.^[2]

소프트웨어 개발 수명 주기

혼돈 모델은 라이프사이클의 단계가 전체 프로젝트에서 개별 코드 라인에 이르기까지 모든 수준의 프로젝트에 적용된다는 점에 주목한다.

• 프로젝트 전체를 정의, 구현 및 통합해야 한다.
• 시스템은 정의, 구현 및 통합되어야 한다.
• 모듈을 정의, 구현 및 통합해야 한다.
• 기능은 정의, 구현 및 통합되어야 한다.
• 코드 라인은 정의, 구현 및 통합된다.

한 가지 중요한 관점의 변화는 프로젝트를 전체 단위로 생각할 수 있는지, 아니면 조각조각으로 생각해야 하는지 여부다.아무도 한 번에 수만 줄의 코드를 쓰지 않는다.그들은 작은 조각들이 작동하는 것을 확인하면서 한 줄씩 작은 조각들을 쓴다.그리고 거기서부터 쌓인다.복잡한 시스템의 동작은 더 작은 빌딩 블록의 결합된 동작에서 나타난다.

혼돈 전략

혼돈 전략은 혼돈 모델을 바탕으로 한 소프트웨어 개발 전략이다.항상 가장 중요한 문제를 먼저 해결하는 것이 주된 규칙이다.

• 문제는 불완전한 프로그래밍 작업이다.
• 가장 중요한 문제는 크고, 긴급하고, 그리고 강건한 것의 조합이다.
  • 큰 문제는 사용자에게 작업 기능으로서의 가치를 제공한다.
  • 긴급한 문제는 그렇지 않으면 다른 일을 떠맡는다는 점에서 시기적절하다.
  • 해결되면 신뢰할 수 있고 테스트할 수 있는 강력한 문제그러면 개발자들은 안전하게 다른 곳에 주의를 집중할 수 있다.
• 해결한다는 것은 그것을 안정의 경지에 이르게 하는 것을 의미한다.

혼돈 전략은 프로그래머들이 수정해야 할 버그 리스트와 생성해야 할 특징을 가지고 있을 때 프로젝트의 끝을 향해 작업하는 방식과 닮았다.보통 누군가는 남은 일의 우선순위를 정하고, 프로그래머들은 그것들을 한 번에 하나씩 고친다.혼돈 전략은 이것이 그 일을 할 수 있는 유일한 유효한 방법이라고 말한다.

혼돈 전략은 바둑 전략에서 영감을 얻었다.^{[citation needed]}

혼돈 이론과의 연관성

혼돈 이론에 얽매이는 여러 가지가 있다.

• 혼돈 모델은 소프트웨어가 왜 그렇게 예측할 수 없는 경향이 있는지를 설명하는 데 도움이 될 수 있다.
• 아키텍처와 같은 높은 수준의 개념을 낮은 수준의 코드 라인과 독립적으로 취급할 수 없는 이유를 설명한다.
• 혼돈 전략 측면에서 다음에 무엇을 해야 할지를 설명하는 고리를 제공한다.

참고 항목

• V-모델

참조

추가 읽기

• Roger Pressman(1997) 소프트웨어 엔지니어링: A Practical's Access 4번째 판, 29~30페이지, McGraw Hill.
• 너구리(1995) ACM 소프트웨어 엔지니어링 노트 20권 1번 55~66쪽 1995년 1월 ACM 프레스에서 혼돈 모델과 혼돈 라이프 사이클