[architecture] 소프트웨어 디자인과 소프트웨어 아키텍처 비교

SDLC (Software Development Life Cycle)에 대한 일부 설명에서 그것들은 상호 교환이 가능하지만, 그것들은 서로 다르다는 결론입니다. 그들은 동시에 서로 다른 (1) 단계 , (2) 책임 영역 및 (3) 의사 결정 수준입니다 .

• 아키텍처 는 더 큰 그림입니다. 프레임 워크, 언어, 범위, 목표 및 높은 수준의 방법론 ( Rational , Waterfall , Agile 등) 선택.
• 디자인 은 더 작은 그림입니다. 코드 구성 방법에 대한 계획; 시스템의 다른 부분 간의 계약이 어떻게 보일지; 프로젝트 방법론과 목표의 지속적인 구현 . 이 단계에서 사양이 작성됩니다.

이 두 단계는 서로 다른 이유로 혼합되어있는 것 같습니다 .

1. 소규모 프로젝트는 계획을 단계적으로 분리 할 수있는 범위가 충분하지 않은 경우가 많습니다.
2. 프로젝트는 더 큰 프로젝트의 일부일 수 있으므로 두 단계의 일부가 이미 결정되었습니다. (기존의 데이터베이스, 규칙, 표준, 프로토콜, 프레임 워크, 재사용 가능한 코드 등이 이미 있습니다.)
3. SDLC에 대한 새로운 사고 방식 ( 민첩한 방법론 참조 )은이 전통적인 접근 방식을 다소 재정렬합니다. SDLC 전체에서 설계 (아키텍처의 범위가 작음) 가 의도적으로 발생 합니다. 전체 프로세스가 계속 반복 되는 반복 횟수 가 더 많습니다 .
4. 소프트웨어 개발은 ​​복잡하고 어쨌든 계획하기가 어렵지만, 클라이언트 / 관리자 / 영업 사원은 일반적으로 중간 단계에서 목표와 요구 사항을 변경하여 더 어렵게 만듭니다. 계획이든 아니든 프로젝트 후반에 설계 및 건축 결정을 내려야 합니다 .

책임의 단계 나 영역이 서로 섞여서 모든 곳에서 발생하더라도, 어떤 수준의 의사 결정이 이루어지는 지 항상 아는 것이 좋습니다. (우리는 이것으로 영원히 갈 수 있습니다. 요약을 유지하려고 노력하고 있습니다.) 다음으로 끝날 것입니다 : 프로젝트에 공식적인 건축 또는 설계 단계 / AOR / 문서가없는 것 같더라도 누구나 의식적으로하고 있는지 아닌지 아무도 아키텍처를 결정하지 않으면 기본 상태가 좋지 않을 수 있습니다. 디자인을위한 디토. 공식적인 단계가없는 경우 이러한 개념은 거의 더 중요 합니다.

답변