나는 William Pietri의 답변을 많이 좋아하지만 (+1) 추가해야한다고 생각합니다. 시스템이 의미하는 바는 전적으로 소프트웨어로 구성되어 있다고 가정합니다.
그러나 그것의 고기에 들어가기 전에, 나는 도울 책을 모른다. 다음에 오는 모든 것들은 경험에서 배웠습니다 (윌리엄이 세 가지 점을 의미 함).
당신이 말하는 것은 최소한 네 가지 광범위한 역할에 걸쳐 있습니다. 때로는 한 사람이 중소 규모의 프로젝트에 대해 모든 역할을 수행 할 수도 있지만 대규모 프로젝트를 시작할 때는 최소한 그 역할을 분리해야합니다. 모든 사람이 의미있는 방식으로 전문가가 되기는 어렵습니다.
비즈니스 분석가
고객과 대화하고 요구 사항을 건축가가 이해할 수있는 것으로 해석하는 사람입니다. 기본적으로 올바르게 구성된 요구 사항 목록 여기에는 명백한 기능 요구 사항 (이 시스템이 제공해야하는 것)과 비 기능 요구 사항 (시스템이 충족해야하는 일반적인 특성은 무엇입니까? 여기에는 보안, 안정성, 가용성, 복원력, 용량, 성능, 견고성 및 사용자 관점에서의 다른 요구 사항).
이것은 시스템이 무엇을해야하는지에 대한 첫 번째 단계이며, 진지한 사고의 시작입니다.
시스템 아키텍트
이 사람은 작업 할 수있는 고급 기술 프레임 워크를 생성합니다. 그들은 개요 일치 계획을 제공합니다. 일반적인 도구, 기술, 구성. 그들은 전체 시스템을 더 작은 구성 요소로 나누고 서로 어떻게 어울리는 지, 외부 세계와 어떻게 어울리는 지 ...
이것은 여러 가지면에서 생각해야 할 사항을 개선하는 데 도움이됩니다. 비즈니스 분석가가 작성한 요구 사항에 대해 해당 단계에서 종종 문제가 발견됩니다. 그들이 원하는 것에 대한 이해와 표현에 대한 이해를 향상시키기 위해 반복을 위해 그들에게 돌아갑니다.
시스템 디자이너
이 역할은 모든 기능을 수행하는 방법에 관한 것입니다. 이것은 한 사람의 쇼보다 더 많은 팀워크 일 수 있습니다. 그러나 전체 시스템 설계를 감독하는 리드 디자이너가있을 수 있습니다. 이 사람은 세부 사항을 파고 건축가의 시야가 실제로 구축 할 수있는 것이어야합니다.
시스템 아키텍처와 비즈니스 분석의 추가 개선이 필요합니다.
테스트 관리자
이 역할은 종종 잊혀집니다. 그러나 하루가 끝나도 테스트 할 수 없다면, 그것을 만들 수 있다는 것을 어떻게 증명할 수 있습니까? 모든 단계의 결과에 대한 검토가 필요합니다 : 테스트에 능숙한 사람에 의한 비즈니스 분석, 아키텍처 및 설계 : 결함을 강조하고 코드를 작성하기 전에 조기에 정정 할 수있는 사람.
간단한 요약입니다.
그 녀석 / 놈들은 체인에서 밀 사람들이 일반적으로 운영하는 것에 대해서만 생각해야합니다.
대규모 은행 업무 또는 우주 응용 프로그램과 같은 복잡한 프로젝트의 경우 두 가지 예 (수백에서 수천 명에 이르는 인력) 만 고려하면 모든 단계에서 프로젝트를 검토하고 지원하기 위해 많은 주제 전문가가 있습니다. 이러한 역할에는 보안 분석, 시스템 크기 조정, 용량, 성능, 데이터베이스, 클러스터링 및 정밀한 비즈니스 영역을 포함한 기타 좁은 전문 영역이 포함됩니다. 다양한 역할은 시스템의 크기와 복잡성에 따라 다릅니다.
모든 것을 시도하고 알면 안된다고 말하면 안됩니다. 그러나 전체적인 그림과 작은 프로젝트를 파악할 수 있습니다. 복잡성의 수준이 더 둥글게되어 있기 때문에 큰 프로젝트보다 훨씬 더 많은 것을 탐구 할 수 있습니다.
시스템 설계 방법을 알고 싶다면 상자 밖에서 생각하여 질문을 시작해야합니다. 고객의 입장에서 충분한 노력을 기울이고 무엇이 잘못 될 수 있으며 무엇을 테스트해야하는지 생각해보십시오. 그런 다음 실제 고객과 함께 모여 필요한 시스템의 범위와 한계를 설명하도록합니다. 또한 '고객'이라고 말할 때마다 여러 다른 사람들이 여기에 해당한다는 것을 이해해야합니다. 하루 종일 시스템을 사용하도록 설계된 사람이 있습니다. 운영자, 기술 지원, 보고서 또는 기타 보고서가 필요한 관리자, 감사 자, 인프라 팀, 비용을 지불 한 이해 관계자, 시스템을 테스트 할 수단이 필요한 품질 관리자가 있습니다. 그들은 한 사람이고 한 번에 하나씩 모든 모자를 착용하도록 요청하십시오.) 필요한 것을 모두 요청하면 시스템 요구 사항이 무엇인지 알 수 있습니다. 거기에서 아키텍처와 디자인을 파생시킬 수 있습니다.
복잡한 시스템의 경우 (소프트웨어 만 또는 가장 일반적인 의미로 하드웨어와 통합하는 경우) 위에 나열된 네 가지 역할 각각에 대해 한 사람만으로는 충분하지 않을뿐만 아니라 시스템이 무엇을 정의해야하는지에 대한 정의도 프로젝트 관리해야합니다. 다른 단계는 물론입니다.
HPH, asm.