• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
프로젝트 Xxx에 적용하고 싶은 개발방법
 

프로젝트 Xxx에 적용하고 싶은 개발방법

on

  • 2,359 views

소프트웨어 개발 프로젝트 XXX에 적용하고 싶은 개발 방법을 기술. 행복하게 개발하기가 목적.

소프트웨어 개발 프로젝트 XXX에 적용하고 싶은 개발 방법을 기술. 행복하게 개발하기가 목적.

Statistics

Views

Total Views
2,359
Views on SlideShare
2,227
Embed Views
132

Actions

Likes
2
Downloads
29
Comments
0

4 Embeds 132

http://aploit.egloos.com 66
http://intranet.digigroove.co.kr 35
http://m.intranet.digigroove.co.kr 29
http://www.hanrss.com 2

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    프로젝트 Xxx에 적용하고 싶은 개발방법 프로젝트 Xxx에 적용하고 싶은 개발방법 Presentation Transcript

    • 프로젝트 XXX에 적용하고 싶은 개발방법
      임도형
      2010/04/21
      dh-rim@hanmail.net
    • 본 문서의 목적
      프로젝트 XXX를 진행할 때 적용할 개발 방법을 제안합니다.
    • 적용하고자 하는 방법의 목적
      모두가 행복하기 위하여
      개발자
      개발 다운 개발
      관리자
      일정 잘 맞추고, 개발자 관리 좋고, 유지보수 좋고
      회사
      잘 팔리고, 1인당 매출액 좋고, 유지보수 비용 적고
      고객
      저렴한 가격에, 성능/기능 좋고, 기능 개선과 버그 픽스 빠르고.
    • 행복하기 위한 각 관련자의 역할
      개발자
      최대한 제대로 개발할 수 있도록 노력
      관리자
      개발자가 제대로 개발할 수 있도록 지원
      회사와의 일정 조율
      회사
      적절한 일정 제시
    • 실천 항목
    • 실천 항목
      분석/설계 시에 팀원의 참여
      충분한 분석/설계
      GUI 개발도 설계를 기반으로
      충분한 테스트 케이스
      자동화된 빌드, 테스트
      가독성을 최상의 품질 요소로
      1일 빌드, 자동 테스트 실행
      모든 산출물의 리뷰
      scrum 적용
      진행 상황에 따른 일정 조절 및 개발 범위 조정
      팀원이 선택 가능한 업무 배분
      계획과 회고에 따른 시스템 개선
    • 분석/설계 시에 팀원의 참여
    • 잘 팔리는 제품.
      품질 속성만 만족하면 잘 팔릴까
      기능, 성능, 안정성, 유지보수성, 확장성
      잘 팔릴 만한 제품을 고민하는 것은 누구의 몫? 기획자?
      언제나 기획은 불충분하다. 불충분할 수 밖에 없다.
      소프트웨어에 기획자+개발자의 구도가 적당할까?
    • 가치 창조하기
      고객이 감동할 수 있는 가치를 찾아내야 한다. 제품에 불어넣어야 한다.
      개발팀에서 해야 한다.
      ideation을 통해 구체화 된다. 상상하고, 끄집어 내고, 검토하고, 정의하고.
      프로젝트 관련자 모두가 참여하는 것이 바람직하다.
      이러한 ideation은 분석단계에서 진행되며, 작업 결과는 보통 요구사항의 형태로 정리된다.
      즉 요구사항정의 시에도 팀원 전원의 참여가 필요하다.
    • 소프트웨어 개발에서의 생각
      개발에서 생각하는 것은 분석/설계에 관련된 것이다.
      코딩은 단지 그 결과를 코드로 구현하는 것 뿐이다.
      생각을 하게 하지 않는 개발업무는 개발자의 의욕을 꺽는다. 개발자를 생각하게 하여야 한다.
    • 분석/설계의 구분
      3가지로 구분된다.
      시스템 구조 분석/설계
      기반 분석/설계
      기능 컴퍼넌트 분석/설계
    • 시스템 구조 분석/설계
      각 기능을 제공할 컴퍼넌트의 정의와 컴퍼넌트 간의 관계 정의
      각 컴퍼넌트들마다의 기능 요구사항을 정의하고, 각 컴퍼넌트의 인터페이스까지 정의한다.
      기술적인 측면 보다는 시스템 전체적인 흐름을 이해하기 위하여 팀원 모두가 참여하는 것이 바람직하다.
      이 단계를 참여하지 못한 개발자는 전체적인 시스템을 이해하기 어렵다.
      업무의 백업이 어렵다.
      업무의 선택이 어려워 진다.
      지엽적인 개발이 될 수 밖에 없다.
    • 기반 분석/설계
      일반적인 시스템에서 필요로 하는 기능을 제공한다.
      예 : 컴퍼넌트 로딩, 로그, 통신 방법
      성능에 많은 영향을 끼친다.
      기술적인 난이도가 있다.
      타 컴퍼넌트의 개발에 기반이 되며, 선행되어야 한다.
      보통 Application Server, framework이 대신하기도 한다.
      모든 팀원이 참여하기 곤란하다.
    • 기능 컴퍼넌트 분석/설계
      구조 설계에서 정의한 각 컴퍼넌트 자체를 구현하기 위한 것.
      특정 업무 담당자가 진행한다.
      구현할 기능과 타 컴퍼넌트와의 인터페이스는 구조 설계에서 정의되어 있다.
    • 실 적용 사례
      6개월 일정의 프로젝트에서 3개월을 분석/설계로 진행했으며, 코딩, 테스트, 패키징에 각각 1개월씩이 소요됨.
      코딩 1개월 때는 고민할 사항 없이 깔끔하게 진행되었고, 이후 테스트,패키징에서도 문제가 발생하지 않았다.
      설계된 사항이 크게 변경되는 것이 없었으며, 이러한 이유로 프로젝트 완료와 유시보수 시에도 문서가 살아있었다.
      버그픽스는 설계와 관계없는 것이고, 기능 추가는 설계서에 추가하면 되고.
    • 충분한 분석/설계
    • 분석/설계와 코딩
      개발의 실체는 고민이다.
      고민 과정이 분석/설계이고, 코딩은 그 구현일 뿐이다.
      코딩 시에 고민하게 되면 삽질이 필수적이다.
      코딩 시에는 고민을 하지 않아야 한다. 최대한 지양하여야 한다.
      어차피 고민해야 하는 것을 분석/설계에서 마무리하고 코딩으로 들어가야 한다.
      모든 분석/설계는 리뷰를 통해 구현 전에 검토하는 것을 원칙으로 한다.
    • GUI개발도 설계를 기반으로
    • GUI 개발의 특징
      GUI에 대한 평가가 제품 전체에 대한 평가로 적용되기도 한다.
      까다로운 사용자 편의성을 제공해야 한다.
      또한 디자인적인 요소도 포함되어야 하기에 단순 개발역량만으로는 안된다.
      그러나 개발 과정 자체는 단순 노가다에 가깝다.
      개발 자동화도 어렵다.
      테스트 자동화도 어렵다.
      무척 중요하지만 어렵고도 지치게 한다.
    • GUI의 분석과 설계
      가장 문서화하기 힘든 부분이다.
      더불어 가장 삽질을 많이 하는 부분이다. 또한 삽질의 크기가 큰 부분이다. 그렇기 때문에 설계가 더더욱 중요하다.
      설계된 결과의 형태는 중요하지 않다. 종이에 그리건, 툴로 그리건.
      중요한 것은 설계가 되어야 하고, 검토 후에 구현되어야 한다는 것이다.
    • 설계의 의미
      개발중의 고민이 설계이다.
      코딩하기 전에 고민을 충분히 하지 않으면, 코딩 중에 뒤엎기가 발생한다.
      GUI 개발도 코딩이며, 역시 충분히 고민해 놓지 않으면 뒤엎기가 발생한다.
      GUI 특징으로 인해 설계는 그림으로 그려져야 하고, 이는 다른 부분의 설계보다 손이 많이 간다.
      하지만 그렇더라도 설계가 충분히 되어야 한다. 설계를 뒤엎는 것이 코드를 뒤엎는 것보다 낳다.
      설계된 결과는 상상할 필요 없이 눈으로 확인되어야 한다.
    • GUI 설계 참여자
      GUI는 단지 view가 아니다. 시스템 전체의 기능을 눈으로 보여준다.
      GUI 개발자도 시스템 전체를 이해해야하고, 타 부분 개발자도 GUI를 파악하고 있어야 한다.
      전체 시스템의 이해를 포기하는 순간, 생각을 배제하는 개발자 즉 코더임을 자청하는 것이다.
      GUI의 이해를 포기하는 순간, 전체 시스템 파악을 포기하는 것이다.
    • 테스트 케이스
    • why must 테스트 케이스
      영향도 분석은 실제적으로 불가능하다. 대충하기도 무척 어렵다.
      특정 부분을 변경 했을 때 기존의 것이 모두 제대로 동작하는지를 확인하는 유일한 방법은 충분한 테스트 케이스 뿐이다. 요걸 회귀테스트라 한다.
      수정에 의한 감추어진 버그는, 테스트 케이스가 없다면 몇 달 뒤에 고객이 찾아 줄 것이다.
      방금 수정한 것에 의한 버그를 테스트 케이스가 잡아준 경우와, 몇 달 뒤에 고객이 발견하여 등록된 경우 둘 사이의 버그 픽스의 공수, 난이도는 비교가 안된다.
    • 어느 정도 양의 테스트 케이스
      최소한 본 코드의 양과 동일한 라인 수의.
      최소한 작업한 본 코드의 메소드 수와 동일한 개수의 테스트 케이스 개수.
      최소한 본 코드의 사용예를 볼 수 있는.
      컴퍼넌트 단위의 테스트 케이스는 충분히 꼼꼼하게.
      시스템 단위의 테스트 케이스는 QA팀에서도 활용할 수 있게. 혹은 QA팀에서 실행하는 테스트 항목 수 정도로. 혹은 QA팀에서 테스트 케이스를 직접 작성할 수 있도록.
    • 자동 실행
      모든 테스트 케이스는 한방에 실행 될 수 있어야 한다.
      사람 손으로 일일이 실행하는 테스트 케이스는 제대로 활용되지 못한다. GUI 테스트는 그래서 더 어렵고 허술하다.
      GUI와 같이 자동실행하기 어렵더라도, 최선의 방법을 찾아내야 한다.
    • 테스트 케이스와 생산성
      테스트 케이스 작성 역시 공수가 필요하다.
      임도형이 파악하는 구현 시의 공수 증가는 1.5배정도.
      임도형이 파악하는 유지보수 시의 공수 이득은 10배 정도.
      개발 비용과 유지보수 비용을 1:2로 했을 때
      비적용 공수 : 3 ( = 1+2 )
      적용 공수 : 1.7 ( = 1*1.5 + 2*0.1 )
      테스트 케이스 작성을 먼저 할 경우 해당 로직의사용예를 먼저 구현해 보는 효과가 있어서, 삽질을 많이 방지하게 한다.
      구현 시의 공수는 유지보수 시에 발견될 버그를 구현 시에 픽스하는 것으로 생각할 수 있다.
    • 테스트 케이스와 유지보수
      타인이 개발한 부분을 파악할 때, 살펴 보기 가장 좋은 부분은 테스트 케이스이다.
      컴퍼넌트 기반의 코드는 그 진입점을 찾기도 어렵다.
      테스트 케이스 자체가 코드의 사용 예가 된다.
      테스트 케이스 코드에는 대상 코드가 사용되는 입력값과출력값의 예도 있다.
      새로운 기능을 추가하거나 버그를 수정하기 위해서는 로직을 전부 파악하고 목적에 맞는 샘플을 작성해야 한다. 기존에 테스트 케이스가 있으면, 이를 참조하기 넘 좋다.
    • 테스트 케이스와 리팩토링
      리팩토링은 기능은 그대로 유지한 채 내부의 구조를 개선하는 것이다.
      시스템이 커질 수록 리팩토링의 필요성은 절대적이다.
      테스트 케이스가 없이는 리팩토링은 불가능하다. 기존의 기능이 그대로인 것을 어떻게 보장하는가.
      클래스의 이름 변경, 엔티티의 이름 변경과 같은 사소한 리팩토링 조차도 테스트 케이스 없이는 많은 손이 가고 힘들다.
      테스트 케이스 없이는 구조 변경이나 뒤엎기는 큰 비용을 감수해야 한다.
    • 그 외 효용
      만약 어떤 컴퍼넌트가 테스트 케이스를 작성하기 어려운 경우라면, 시스템의 구조가 적절하지 않은 것이다.
      테스트 케이스 작성이 용이하도록 하다보면 시스템의 구조가 좋아진다. 컴퍼넌트 간의 종속성이 줄어든다.
    • 실 적용 사례
      약 30개의 컴퍼넌트, 400개의 클래스로 이루어진 시스템에 약 2000개의 테스트 케이스가 있었다.
      각 컴퍼넌트는 개별적으로 테스트 가능하였다.
      릴리즈 이후 1년 간 최대 미 처리 버그수가 5개를 넘지 않았다. 유지 보수에 들어간 공수가 미미. 별도의 유지보수 인력 배정 불필요.
      유지 보수 시에 어느 부분을 수정 후에 어느 테스트 케이스에서 실패하면 안도감이 느껴진다. 무엇을 선택할 것인가?
      modify & pray
      cover & improve
      고의적으로 삽입된 버그의 검출률이80% 이상이 되도록 유지되었다.
    • 가독성
    • 가독성과 유지보수성
      가장 좋은 코드는 읽기 쉬운 코드이다.
      유지보수?
      기능을 추가하거나 버그를 픽스하는 것.
      주석을 읽어야 하거나, 문서를 읽어야 하거나, 로직을 파악하기 힘들면 유지보수가 힘들어 진다.
      읽기 어려운 코드라면 주석을 잘 달거나, 문서를 잘 만들거나 별도의 노력을 해야 한다. 하지만 잘 안 된다. 이건 경험적 진리이다.
      가독성이 떨어지면, 적지 않은 경우, 다시 개발한다.
    • 가독성과 성능
      일반적으로 가독성이 좋은 코드는 실행 시에 오버로드를 요구한다. (예: 별도로 뽑은 메소드, 인터페이스 사용)
      성능 문제는 튜닝으로 처리해야 한다.
      튜닝은 비정규화 작업이다. 정형화된 코드를 비정형화 하는 것은 쉽지만, 비정형화된 것을 정형화하는 것은 무척이나 어렵다.
      전체 시스템의 성능에서 특정 부위가 좌우하는 비중을 가늠하는 것은 거의 정확하지 못하다.
      가독성 없는 코드를 정리하는 것은 무척이나 어렵지만, 가독성 좋은 코드를 성능 튜닝하는 것은 할만하다.
    • 가독성과 생산성
      가독성 향상으로 인한 개발 시의 생산성 저하는 미미하다.
      타이핑 시간이 생산성에 영향을 주지 않는다.
      그보다는 유지보수성이 좋아지기 때문에 전체적인 생산성은 좋아진다.
    • 가독성을 위한 실천 항목
      단어의 축약 엄금.
      축약은 가독성의 상극이다.
      클래스명, 메소드명,변수명을 확실하게.
      이름 짓기가 어렵다면 개념이 불확실한 것이다. 설계가 부족한 것이다.
      주석 지양.
      코드 자체로 이해가 되도록 한다. 주석은 이런 코드가 될 수 밖에 없는 사항을 설명하거나, 입출력의 예를 명시할 때만 사용한다.
      하나의 블록은 50 line이 넘지 안게
      indent는 3개까지만
    • 자동화된 빌드/테스트
    • 자동화
      머리로 생각하는 개발에 집중하게 하자.
      반복되는 것, 기계적인 업무의 것들을 자동화 하자.
      빌드 자동화
      빌드 스크립트.
      daily build
      테스트 자동화
      모든 테스트는 사람이 손이 아닌 한방에 가능하게.
      자동화를 위한 툴이나 환경을 위한 개발이 필요할 수도 있다. 이런 것도 개발이며, 업무에 포함된다.
    • 일일 빌드
      보통 CI(Continuous Integration)이라고도 한다.
      프로젝트 내내 빌드되고 테스트 성공하는 것을 보장한다.
      이것이 없이는 빌드성공하고 테스트 성공하는 것에 대한 강제성이 없어진다.
      빌드가 안되거나 테스트가 실패한 코드는 타 팀원의 업무를 진행하지 못하게 한다.
      목숨처럼 지켜야 하는 것.
    • 리뷰
    • 리뷰 방법
      모든 업무 결과를 리뷰한다.
      정규적 혹은 비정규적으로 진행한다. 대신 2주 이상을 넘기면 안된다.
      하나의 업무에 대한 리뷰 시간은 30분 정도로 하고, 최대 1시간을 넘지 않는다.
      프로세스 상에 언급된 산출물의 경우 리뷰 자체를 업무로 진행한다.
    • 코드 리뷰 대상
      리뷰 대상은 문서, 테스트 케이스, 본 코드이다.
      문서
      외부와의 인터페이스
      그렇게 로직을 구성한 이유
      이외의 모든 고민이 담겨 있어야 한다.
      테스트 케이스
      중점 리뷰 사항
      테스트 케이스 양의 적절함
      테스트 케이스 안의 코드 샘플의 적절함
      본 코드
      일반적인 가독성
      상식적인 품질
    • SCRUM 적용
    • 스트럼의 개요
      한달 정도의 주기로 개발을 진행
      각 주기별로 계획, 실천, 회고를 반복.
      각 주기별로 구현할 개발 항목을 선정
      개발자가 개발할 항목을 선택
      매일 마다 진행 사항을 공유
      자세한 사항은 별도로 소개
    • 효과
      일정 예측이 용이해 진다.
      일정 조정이 용이해 진다.
      팀원이 원하는 업무를 선택할 수 있다.
      팀 개발 환경 자체의 개선이 가능하다.
      업무 백업이 자연스럽게 된다.
    • SCRUM 효과 - 일정 예측이 용이해 진다.
      스토리 포인트를 사용하여 각 업무별 크기를 결정한다.
      스토리 포인트
      관련자들이 모두 모여 크기를 투표한다.
      최대치와 최소치를 제시한 자가 생각을 설명한다.
      만장일치 될 때까지 반복한다.
      소수가 어렴풋이 산정한 일정보다는 정확하다.
      산정된 업무의 크기와 실제 진행된 크기를 가지고 팀의 개발 속도를 구할 수 있다.
      첫 번 째 주기 이후에는 이 개발 속도를 가지고 진행할 수 있는 업무 범위를 비교적 정확하게 추정할 수 있다.
    • SCRUM 효과 - 일정 조정이 용이해 진다.
      돌발성 업무가 발생한 경우 초과되는 스토리 포인트만큼의 업무를 우선순위에 따라 배제한다.
      이미 빡박한 일정에서 끼어드는 돌발성 업무에 합리적으로 대처할 수 있다.
      관리자에게 중요한 것은 어느 시점에서 특정 업무의 완료 여부를 예측할 수 있는 지이다.
    • SCRUM 효과 - 팀원이 원하는 업무를 선택할 수 있다.
      업무를 팀장의 결정에 의한 할당이 아닌, 나열된 업무 중에 개발자가 선택하게 한다.
      이러한 점은 개발자 동기 부여에 크게 영향을 끼친다.
    • SCRUM 효과 - 팀 개발 자체의 개선이 가능하다.
      계획, 실행, 회고의 과정을 통하여 보다 합리적이고, 효율적이고, 참여할 수 있는 시스템으로 개선할 수 있다.
      소프트웨어 개발의 가장 중요한 요소는 개발자이다.
      개발자의 동기 부여가 프로젝트 성공을 결정한다.
    • SCRUM 효과 - 업무 백업이 자연스럽게 된다.
      특정 분야의 업무는 특정 개발자가 담당하는 것이 아니라, 희망자가 선택하게 되어 자연스럽게 업무의 백업이 이루어진다.
      팀 전체의 업무를 알게 된다.
      기술적 기반이 다른 경우가 아니라면 자연스럽게 업무를 순환할 수 있다.
    • 위험성
    • 위험성 항목들
      지체되는 일정
      팀원의 무관심
      미검증 기술
    • 위험성 – 지체되는 일정
      분석과 설계에 팀원 모두가 참여할 경우 진행이 늦어진다.
      방안
      분석/설계 단계의 기간을 충분히 갖는 것이지 전체 프로젝트가 지연되는 것이 아니다.
      더욱이 유지보수가 쉬워진다.
    • 위험성 - 팀원의 무관심
      팀원이 무관심할 경우 일반적인 개발방법보다 프로젝트 진행이 위험할 수 있다.
      방안
      능동적으로 개선할 수 있는 것으로 의욕을 고취하여야 한다.
    • 위험성 – 미검증 기술
      구현 단계에서 미검증된 기술의 문제로 인해 프로젝트가 위험하게 될 수 있다.
      방안
      분석/설계 기간 중에 검증하거나 대안을 찾는다.
    • 실천 항목 요약
    • 요약된 실천 항목
      분석/설계에 중점
      자동화
      테스트 케이스
      리뷰
      SCRUM
    • 상상
    • 구현 시의 개발자의 모습
      아침에 출근하여 daily build가 잘못된 것이 있는지 확인한다. 있으면 이를 최우선으로 처리한다.
      standup 미팅에 참석하여 팀의 진행 사항을 파악한다. 고민되고 있다는 타인의 문제에 대해서 도움을 주어야 겠다고 언급. 나의 진행 상황은 별 특이사항이 없어서 패스한다.
      새로운 컴퍼넌트 구현의 업무를 선택한다.
      구현할 컴퍼넌트에 대한 정의를 시스템 설계서에서 확인한다.
      어떻게 구현할 지를 이리 저리 고민하고, 그 결과를 문서로 작성한다.
      그 문서를 리뷰 받는다.
      정의된 인터페이스를 구현한 껍데기 컴퍼넌트를코딩한다.
      이를 사용한 테스트 케이스를 작성한다.
      껍데기 컴퍼넌트의로직을 완성하고, 테스트 케이스가 성공함을 확인한다.
      전체 테스트 케이스가 동작함을 확인한다.
      커밋하고 로그를 남긴다.
    • 유지보수 시의 개발자 모습
      아침에 출근하여 daily build의 결과를 확인한다.
      standup 미팅에서 버그를 업무로 선택한다.
      대상 버전의 소스를 다운로드한다.
      버그를 재현하는 테스트 케이스를 작성한다.
      작성한 테스트 케이스가 성공하도록 본 코드를 수정한다.
      기존 모든 테스트 케이스가 성공하는 것을 확인한다.
      본 코드와 테스트 케이스를 커밋하고 버그 트랙킹 시스템에 메시지를 남긴다.
    • 기타
    • 개발 환경 안 for Java
      Eclipse for IDE
      JUnit for test framework
      maven for build tool
      SVN for SCM
      TRAC for issue tracking system
      Hudson for daily build & auto test
      SpingNote for documentation share
      <<TODO : ? >> for flex test framework
      JBoss for WAS
    • 고민되다 언급하지 않은 실천 항목
      야근 금지
      자기 계발 의무
      일정 버퍼링
    • Special Thanks!
      Are There Any Other Questions?