앞서 배운 것들을 활용해 이번에는 직접 유스케이스 다이어그램을 제작해 보았습니다.
수업이 끝나고 배운 내용을 복습하고 이해가 어려웠던 개념은 한번더 찾아보면서 유스케이스 다이어그램에 대해 제 나름대로 정리했습니다. 덕분에 수업 도중 제작했던 유스케이스 다이어그램은 유스케이스간의 관계가 명확히 구분되어 있지 않아 시각적으로 한눈에 이해하기 어려웠지만, 과제를 통해 다시 제작한 다이어그램은 보다 시스템의 기능과 과정을 이해하기 쉽게 표현할 수 있었습니다.
명확하게 필요한 시스템으로만 이루어진 해당 다이어그램을 통해 사용자가 시스템에 바라는 바를 표현함으로써 사용자의 시점을 빨리 이해하고 쓸모있고 쓸 수 있는 시스템을 만들 수 있도록 도움이 가능해 보였습니다.
특히 액티비티 다이어그램을 제작할때는 "아 이건 반드시 필요한 작업이다!"라고 생각했습니다.
직접 제작해보니 시스템의 필요 기능, 순서 및 다른 액터들과의 연관관계를 명확히 확인 할 수 있었습니다. 이러한 작업 없이 개발에 들어간다면 기능의 복잡함으로 다시 되돌아가는 수정 작업이 수도 없이 많을거라 생각했습니다. 무엇보다도 처음 기획에서는 생각하지 못한던 시스템이 다이어그램을 제작하면서 필수 시스템이 되는 경우도 있었습니다.
과제 도중 액티비티 다이어그램의 시스템 흐름이 플렛폼 안에서만 진행이 되어야 하는지 그 외에도 생각해야 하는지에 대한 고민이 있었습니다. 즉 오프라인에서 발생할 수 있는 사용자의 행동이 시스템의 흐름에 연관이 있는지에 대한 고민이였습니다. 곰곰히 생각해본 결과 그러한 플렛폼 외적인 행동의 흐름또한 충분히 액티비티 다이어그램 내의 행위로 대안을 생성할 수 있다고 생각했습니다.
마인드맵을 작성할 때는 아주 세세한 부분까지 작성해야 한다고 합니다. 만약 플랫폼 제작 후, 클라이언트의 요구사항이 전부 적용되지 않았다면 우리는 수 많은 부분을 고쳐야 할지도 모릅니다. 또는 고객의 겪을 사소한 문제를 플랫폼안에서 해결할 수 없다면 우리는 고객들의 불만사항을 해결하는데 많은 시간을 소비하게될 수도 있습니다. 그러므로 아주 세세한 부분까지 마인드맵에 작성해야 합니다. 심지어 팜업 차단 설정 오류 창까지도 작성해야 합니다.
액티비티 다이어그램은 어디까지 작성해야하는지도 의문이 생길 수 있습니다. 시스템의 구멍이 생기는 과정을 막는것이 중요합니다. 액티비티 다이어그램을 작성하면 시스템의 흐름을 파악할 수 있습니다. 그 과정에서 오류가 생길 시스템의 구멍, 다른 액터들과의 연관관계에서 생길 수 있는 구멍들을 모두 매꿀때까지 액티비티 다이어그램을 작성해야 합니다.
#프로젝트캠프 #프로젝트캠프후기 #유데미 #스나이퍼팩토리 #웅진씽크빅 #인사이드아웃 #IT개발캠프 #개발자부트캠프 #리액트 #react #부트캠프 #리액트캠프