개발방법론 강의정리

오전 2:08 2008-04-30

- 문서는 커뮤니케이션 수단이다.
- 문서화 하기전에 개발하고 싶은 욕구를 눌러라. 일단 해보면 맛든다.
- 프로젝트 포기도 기술이다.(물고기는 그물에 잡히는 이유는 고난을 뚫고 나가려한다. 후진을 하지 않는다.)
- 보고서를 쓸 때 가장 먼저 써야할 것. -> 결론

0. 개발프로세스 이전 활동
- RFP -> 고객의 목소리를 들어라.
- 나는 이런 프로그램을 만들고 싶다.
- 고객의 요구사항을 듣고 문서로 만들어라. 샘플 작성법
- FROM 어디서 TO 어디로 HOW 어떻게 만들것인가?
- 제안서 작성
- 고객은 언제나 걸리고 얼마짜리인가? 기간, 비용,
- 그러나, 이건 개발 진행전이기 때문에 엄청나게 틀릴 수 있다.
- 고객에 대한 개발방법론 교육 -> 고객 신뢰확보
- 어떻게 진행되는지, 위험 요소들을 미리 미리 알려줄 필요가 있다.

A. 기초조사 -> 문제가 찾아왔을 때 문제를 정의하는 과정, 기능으로 정의하자, 필요한 기능을 하나씩 정리
- A.0. 요구사항 명세서
- A.1. 기초조사 -> 우리가 만들 시스템은 어떤것인가?
- 1. 개요
- 2. 기능분석 -> 뭐뭐하기식으로 한줄씩 작성하자. (구조적분석-정적, 동적)
- 3. 구성도 -> 시스템의 구성
- 4. 업무흐름 -> 어떤식으로 업무를 진행하고 있는지 알아야 조사가 진행됨.
- A.2. Class Diagram -> 기능분석 중 구조분석의 확대
- A.3. Object Diagram
- A.4. Job Flow
- A.5. 기술분석
- 1. 연계 가능한 솔루션 -> 나중에 써먹을 수 있지 않겠나.
- 2. 구현기술 -> 필요한 기술을 나열하자.
- 2.1. 보유기술 -> 우리가 이미 가지고 있는 기술
- 2.2. 개발 가능한 기술 -> 사오는거 보다 비용 적은 프로젝트 기간 중 적은 비용으로 개발가능.
- 2.3. 도입기술 -> 사와야하는 기술, 피해갈 수 있는 방법 필요.
- A.6. 시장조사 -> 개발자 기준 B는 영업적 측면 비슷한 제품 성공이유, 실패이유(기술, 콤포넌트 등)
- 1. 유사제품 벤치마킹
- 2. 시장 요구사항 및 동향
- Z.3. Review 보고서 -> 매주 보고 싸인하면 다음으로 넘어간다. 싸인안하면 안넘어감. 결론을 먼저 써라.

B. 상황분석 -> 마케팅과 기술
- B.1. 상황분석
- 1. 현재 상황 분석 -> 현재의 문제점 파악
- 2. 개발 목표 설정 -> 고객은 전체를 원하지만, 하나씩 중요한 목표를 확실히
- 3. 개발 방법 확정
- 3.1. 인력 동원 및 팀 구성
- 3.2. 자금 및 시간 계획
- 3.3. 적용 기술 검증 -> 기술을 미리 미리 검증하지 않으면 문제가 됨
- 4. SWOT 분석 Strenths강점 좋은 내부, Weaknesses약점 좋은 내부, Opportunities기회 나쁜 외부, Threats위험요소 나쁜 외부
(제품을 만들 때 고객을 생각해서 좋은 점 나쁜 점 등을 미리 파악해서 진행하라)
- B.2. 시장분석 -> 마케팅 어떻게 팔아 먹을 것인가? 개발자는 별로 신경 쓸 필요는 없다.
- 1. 유사 제품 분석
- 2. 시장 요구 사항 분석
- 2.1. 현재 상황
- 2.2. 문제점 및 발전 방향
- 2.3. 해결 방안
- 3. Critical Sussess Factor -> 별두개 이걸 성공하기 위해서는 이거이거는 반듯이 지켜줘야한다. 나중에 계속 추가
(고객의 사장단까지 결재 반듯이, 책임 회피 문서는 아니다. 책임을 다할 수 있게 하는 문서이다.)
- B.3. 전략계획 확정 -> 중요한 문서
기대 효과 -> 만들고 나면 이런 효과가 있다. 고객이 대단히 만족한다.

최종 목표 -> 이런 최종 결과물이 나올 것이다. 고객과 공유할 수 있다면 성공이다.
(만들기 전에는 뭘 만들지 모르고 있다가, 만들어 주고 나면 이게 아니네 한다.)
단계1 --> 단계2 --> 단계3 .... -> 단계를 설정하는 대단히 중요하다.(스티브 맥코넬의 나선형 개발방법)
-> 단계1 은 가장 중요한 기능(불편, 인터페이스 무시 찰흙으로 만들고 나서 뼈대를 넣을 것인가)
-> 단계2 는 프로그램의 실제 문제가 뭔지 파악하는 단계
-> 단계3 .... 마일 스톤을 만드는 것이 매우 중요하다.
- B.4. 프로젝트 추진 일정 수립 -> 언제까지 머하고.. 매단계마다 재보고, 일정은 며느리도 모른다.
(최고의 팀도 최초 적중율은 40% 미만이다. 나중에는 정확한 일정 제공가능하나, 책임회피 아님 정확한 현실을 반영함, 고객의 권익을 보호하기 위함.)
- Z.3. Review 보고서 -> 사장단까지 보고가 필요함.

C. 업무분석
- C.1. 업무처리 분할도 -> 업무를 분할해야한다. TopDown 분석을 한다. Process Breakdown Sheet, Process Divide Sheet, Work Divide Sheet
(Process Tree) -> 트리 구조로 만들면 프로그램이 보인다. 마지막이 하나의 화면이 되게끔.
맨 아래까지 내려가면 해야할 일이 됨.
그 마지막껄 가지고 얼마나 걸릴까 계산 전체합산하면 일정 최소한의 경우 최악의 경우 얼마나 걸릴까
다하고 나면 Process List 가 만들어 지고 누가 할지 정하고 일정을 세운다.
게시판을 활용해서 해달라고 하면 등록하고 누가할 지 정하고
X = (sigma Best + 4*sigmaE + sigma Worst) / 6
- C.2. 데이터 분석 -> 입력 처리 출력 미리 작명을 다한다는 말이군. 덩어리로
(Process Specification or CGI Action Layout)
- C.3. Job Flow -> 동적 분석 -> 고객과 커뮤니케이션시 상당한 도움 -> 매번 그림
- C.4. Navigation Diagram -> 인터페이스가 복잡할 때 어디서 어디로 옮겨다니는건지 화면 모음 -> 매번그림
- C.5. Class Diagram
- C.6. Object Diagram
- C.7. Process List
- C.8. 업무분석 보고서 -> 양식은 없지만 중요, 이럴 때 어떡하지 등. 업무분석 시간을 많이 가져라. 우리가 만드는게 문제는 없나 판단하고 피해가자.
- Z.3. Review 보고서

D. 시스템 설계
- D.1. ERD
- D.2. Table Layout
- D.3. SQL Scripts
- D.4. Schema List
- D.5. 시스템 구성도(System Configuration)
- D.6. Screen Layout -> 대표적인 화면 몇개 커뮤니케이션 수단
- D.7. Report Layout -> 출력물 이건 모두 다, 고객에게 원하는 거랑 똑같은 것 반듯이 요구
- D.8. Job Flow -> DFD는 동적 분석, Job Flow로 해결한다.
- D.9. Class Diagram
- D.10 Object Diagram
- Z.3. Review 보고서

E. 시스템 구축
- E.1. Job Flow
- E.2. Class Diagram
- E.3. Object Diagram
- Z.3. Review 보고서
* 시스템 구축 순서
1. 단위 개발
- 프로토타입 개발 -> 대충만들어서 리뷰
- 모듈 별 담당자 및 완료기한 리스트 작성
- 코딩
2. 단위 테스트 -> 고객을 끌여들여라
- Case List 작성
- 담당자는 각 Item 마다 성공여부/개선사항/문제점/해결방안 제시
3. 통합 테스트 -> 고객을 끌여들여라
- Case List 작성
- 모든 개발자는 모든 모듈에 대하여 각 Item 마다 성공여부/개선사항/문제점/해결방안 제시
4. 인수테스트
- 인수자의 평가/개선사항/문제점 작성

F. 프로젝트 종료
- F.1. 매뉴얼 작성
- F.2. 사용법 교육
- Z.3. Review 보고서

G. 유지/보수

Z. 기타
- Z.0. 프로그램 개발계획서
- Z.1. 용어사전
- Z.3. Review 보고서
- Z.5. 요구사항 변경 기록
- Z.10. Story Board
- Z.11. 프로토콜 기능설계
- Z.12. 프로토콜 정의서