Day_05. 시험 공지 & 단계 계획 수립 시작

Chp-12 단계 계획 시작
=가작 노력이 드는 부분
=프로젝트 진척도를 추적하기 위한 상세 마일스톤을 작성 해야 한다
=여기서 상세 - Binary – 2지선다 형으로 진행이 완료 되었는지 아닌지 파악하는 체크 형식


표현의 문제
=”상세 설계서” 는 좋은 표현이 아니다, 어떻게 되어야 완성인지 알수 없기 때문이다
=상세 설계서 – 처럼 큰 형태를 묘사하는게 아닌 “class가 있는지 등의 구체적 내용이 적혀야 한다”
=”기준을 2주” 형식으로 표현 해야 한다
=PM이 설계를 쪼개는게 아니라 개발자가 쪼갠다 – 진척도를 알 수 있기 때문이다
=가이드는 PM 이 제공해야 한다


상세 마일스톤은 세부적 관리
=상세 마일스톤을 모르는 사람은 타인에게 설명할 방법이 없다


형식 갖추기
=형식 – Class / Sequence Diagram 작성
=개발자 숙련도 & 프로젝트 난이도의 비율을 고려
==만약 난이도가 높은데 숙련도가 낮은 인력이 투입되면 많은 형식의 문서가 필요하다


필수로 해야하는 Review 종류
=요구사항 – 개발 기준
=계획서 – Risk 식별
=소스코드
=설계서 – 왜 해당 방법을 선택 하였나


Chp-14 구축
=코딩 관리 포인트 – 누적 코드 량
=일일 빌드(daily build) – 이때 build 는 IDE 에서 Build 의 의미보다 Jenkins 등의 script로의 build
=build fail 시 원인 파악이 필수
=smoke test - 기능이 잘 되는지 확인하는 Test – 에러 처리는 smoke test라고 볼 수 없다


Chp-15 시스템 test
=구축과 병행 하거나 절반을 남기고 실시
=”결함 할당제” 를 사용하면 효과적이다
=결함 할당제 구성원의 평균적 업무 Process
==Test라는 것을 모르는 사람들을 데리고서 Test하는 방식
===UI/UX 등의 기본적 결함 ->입출력 결함 ->Spec 기준 만족 확인 ->Test 전략 공유 ->가용성&성능 확인


시스템 Test
=찾아야 할 결함의 개수를 지정해서 활동한다
=전문 / 비전문가 모두 인당 20개 등으로 수치를 제시하면 효과적


Chp-16 S/W Release
=각 단계를 종료할 때마다 Release를 가능하게 해야한다
=실제 Release 시작 시기는 Release 체크 List를 통과해야 가능하다
=Release 체크 List는 매번 단계와 시기마다 업데이트 해야 한다
=”bug cumulative graph” 를 활용해 Release를 시도 하는게 좋음 (통계적 방법론이다)

bug cumulative graph

==**S/W 가 Release 할만한 상태인지 직관적으로 결정하기 어렵다***


Release와 Demo 의 차이
=demo 는 개발자 pc에서 진행
=Release 는 “실사용자” 환경에서 실시한다
=**모든 환경에서 Release는 가능해야 한다**


Release 주의점
=Mission Critical software – 자주 Release 하기 어렵기 때문에 Technical Review를 빡세게 진행해야 한다


Inspection 방식의 review가 필수
=요구사항
=계획서


Work through 방식도 허용
=Code Review

Chp-17 단계 마감
=”경험적 지식” 을 얻고 정확한 “추정” 을 할수있다
=최고 Review 의 중점은 fact가 아니라 “느낌” 이 더 중요하다 ex)이번 project는 재미있었다 등
=fact < feeling


Chp-18 –전체 프로젝트 이력
=객관화된 data가 남을 수 있게 관리하라