RDD분석 순서

(1)프로젝트 정의와 계획


(2)RDD Design

참고한곳:Overview of Responsibility-Driven Design
Posted by 전용우

댓글을 달아 주세요

  1. 이벤트 2007.01.09 03:54  댓글주소  수정/삭제  댓글쓰기

    진도가 많이 나갔네요.
    위의 항목 또는 순서가 반드시는 아니라는 것을 우선 이해해야 할 것 같습니다. 예를 들면 1.system을 분석한다는 것이 어려울 때가 있습니다. 그러면 2번을 먼저 하기도 하며, 1.을 만들 수 있다는 것은 개념적으로 파악을 한 것이므로 진도가 그래도 나갔다고 할 수도 있습니다. 간단하게 메모 형태의 유스케이스를 만들어 보는 것도 좋은 방법입니다. 이것은 내가 취하는 방법이기도 합니다.

    사용자의 포괄적인 요구사항을 듣거나, 제안요청서, 품의서 등을 보고 마음속으로 그림을 그리면서 이것을 유스케이스에 메모 형태로 작성합니다. 이때 경험(훈련)이 발휘되는 것입니다. 그래도 이 정도를 하고 나야 사용자와 조금 더 상세하게 요구사항에 대해 대화를 나눌 수가 있습니다.

    위의 글을 보니 이 책을 쓴 사람도 유저 인터페이스를 매우 중요하게 여기고 여기서 해법을 찾으려고 하고 있는 것 같습니다. 이 부분은 나하고 생각이 매우 비슷한 것 같습니다.

    UML은 필수가 아니라 선택입니다. 물론, 어느정도 요구사항이 정의되면, OOD를 해야하니 필요합니다만, 그 전에 글을 쓰는 것이 중요합니다. 글을 쓴 것을 액티비티 다이어그램 등을 그려가면서 분석가가 생각했던 것을 정리하다 보면 모자라는 부분이 보이므로 문서에 다시 작성합니다.
    상호보완이라는 표현이 더 적절할 것 같군요.

    UML은 그림이라서 의사전달의 오해가 발생할 가능성이 있으며, try는 되는데, catch에 접근하는 것에 걸림돌이 있습니다. 왜냐하면 그림이 길어지기 때문입니다. 그러나, 품질은 catch 문에서 결정됩니다. 따라서 문서에 이것을 자세하게 정리해야 합니다.

    실패하는 프로젝트의 대부분이 catch문을 작성하지 않거나 등한시 해서 그렇습니다. 분석가의 부주의라고 할 수 있습니다. catch라고 해서 에러가 발생한 것에 대한 처리를 의미하는 것이 아닙니다. 꼼꼼하고 분석적인 if 문을 의미합니다.

    방향을 설정해가는 모습이 좋아 보입니다. 나도 2장까지 보았습니다만, 지금 정도의 개념적인 측면에서 접근하는 것이 좋을 것 같습니다. 우선 나무보다 숲을 보는 것이 중요하니까요. 하지만, 나무를 보는 것은 쉬워도 숲을 보기는 어렵습니다. 왜냐하면 산 정상에 올라가야 숲이 보이기 때문입니다.

    끝으로 이해가 안된다고, 양에 안찬다고 스트레스 받지 말기 바랍니다. 책 몇권으로 요구분석에서 설계까지 이해가 된다면 얼마나 좋겠습니까...
    그렇다고 안 할 수 없는 것이니, 선택은 매우 잘했다고 생각합니다. 어렵지만, 숲을 보려고 노력하세요...

    • Favicon of http://mixed.tistory.com BlogIcon 용우 2007.01.09 09:07  댓글주소  수정/삭제

      장문의 글감사합니다.:)
      이벤트님 말대로 저도 이번엔 모든것을 알려고 하지않고
      일단 전체적으로 어떻게 진행되는지 크게 생각해보고
      중심은 3장부터로 생각하고 있습니다.
      조금은 걱정이 됩니다.이벤트님이 있으면
      좀더 재미있는 스터디가 될텐데 아쉽네요.
      잘될지는 모르지만 열심히 할렵니다.:)
      자주 오셔서 조언 많이 해주세요^^

  2. Favicon of https://px.tistory.com BlogIcon 김민재 2007.01.09 12:49 신고  댓글주소  수정/삭제  댓글쓰기

    음,, 잘 봤습니다.

    • Favicon of http://mixed.tistory.com BlogIcon 용우 2007.01.09 14:09  댓글주소  수정/삭제

      제가 영어와 국어가 짧아서 제가 봐도 무슨 내용인지 모르는 내용이 많은데..ㅎㅎ;

      잘봤다니 다행이네용^^