프로젝트위험신호

프로젝트 위험 신호는 이러한 현상이 보이면 대체로 프로젝트가 실패할 확률이 높아진다는 것을 의미한다.

• 아키텍쳐가 현재의 조직에 맞추도록 강요되었다.
• 아키텍쳐 상에 25개 이상의 Top-level컴포넌트가 존재한다.
• 프로젝트 규모에 비해 너무 복잡하다는 것을 의미한다. 프로젝트의 규모에 따라 컴포넌트의 Size는 달라질 수 있으나, 대체로 중/소규모 이하의 개발 프로젝트에서 컴포넌트는 Tier/Layer구분정도로 이해 할 수 있으며, 대형(100억이상) 프로젝트에서는 연동되고 있는 개별 시스템(CRM, 인사, 생상등등)이 될 수도 있다
• 하나의 요구사항이 남은 디자인 전체를 결정한다.( 또는 요구사항이 결정되어야 디자인이 진행)
• 아키텍쳐가 O/S선택에 의존적이다.
• 컴포넌트 정의가 하드웨어 구성에서 유도되었다.
• 시스템의 신뢰성에 도움이 되지않는 필요 없는 아키텍쳐 요소 존재하고 있다.
• 디자인이 예외사항에 기초하고 있다.(exception driven)
• 개발팀이 자신을 리딩하는 아키텍트를 모르거나 존재하지 않는다.
• Architect 혹은 PM이 아키텍쳐를 위한 관련당사자(stakeholder)를 정의하지 못한다.
• 개발자가 두개의 컴포넌트를 연결하는데 너무 많은 선택을 가지고 있다.
• 아키텍쳐 산출물을 요구했을 때 클래스 Diagram만을 가져 온다.
• 아키텍쳐 산출물을 요구했을 때 엄청난 양의 자동 생성된 문서들을 들고 온다.
• 관련 당사자(stakeholder)가 명확하게 정의되지 않았다.
• 업무 전문가가 Team내에 없다.
• 프로젝트에 PM/leader가 없다.
• 프로젝트 plan/schedule이 없다
• 프로그램 배포일자가 비현실적이다.
• 성공여부를 측정할 뭔가가 정의될 필요가 있다.
• S/W Architect가 없다.
• 각 영역(layer)을 위해Architect가 있는데, 전체 아키텍쳐를 총괄하는 Architect가 없다.
• 전체 아키텍쳐에 대한 계획이 문서화되지 않았다
• 기반시스템(H/W, OS..) 설치 계획이 명확하지 않다.
• 품질을 담당하는 조직이 없다
• 시스템 테스트 계획이 수립되지 않았다.
• End User가 만족하는 성능 목표가 없다
• 성능 데이터가 수집되지 않았다 (레거시, 유사 싸이트)
• 시스템 부하(traffic)에 대한 예상치가 없다
• Transaction 응답 시간이나 처리량에 대한 측정 메커니즘이 없다
• H/W Capacity에 대한 확신이 없다