설계를 위해선..

하나의 프로젝트를 완성하기 위해서는 좋은 설계가 필요하다. 그를 위해선 여러가지 카테고리를 나눠 보고서를 작성해두는 것이 좋은 방법이지만, 설계를 뛰어넘고 바로 개발로 넘어가는 경우가 허다하다. (귀찮기도하고..)

오늘은 대학을 졸업하고도 잊지 않기 위해 보고서에 들어가야할 내용들을 메모해놓기로 했다.

물론 개인적인 생각으로 정리된 부분들이지만, 대학졸업작품 보고서에도(컴공과등) 해당형식을 맞춰준다면 좋아하실 교수님들이 꽤나 있을것이다.(아마..도..? 맞겠죠..?) 그래도 워낙 각 교수님들이 성격들이 다르시다보니.. 원하시고 추구하시는것도 다르시기에 그냥 참고만 했으면 좋겠다.

1. 제대로 된 Project명과 개발프로그램의 명칭.
예) Projcet.다원, app명:runplay

2. 개발 내용 : 이 프로그램은 무엇을 하는것인데 무엇을 하기위해서 어떠한 개발을 할것인지에 대한 내용.

3. 개발 동기 : 이 프로젝트를 개발하게 된 동기가 무엇인지

4. 개발 목표 : 이 프로젝트를 개발할때의 목표.

5. 기대 효과 : 해당 프로젝트를 진행하면 어떠한형식의 효과를 볼수 있는지.

6. 벤치 마킹(중요) : 벤치마킹을 무척이나 헐겁게 볼 수도 있는데, 자세히보면 벤치마킹안에는 다른 프로그램과 내가 만들 프로그램을 비교하면서 어떤 부분을 강점으로세우고 어떤부분을 지워서 해당프로그램을 조금 더 좋게 만들지를 뚜렷하게 들어나게 해준다. 자기가 무언가를 만든다고 생각을 하면 그것에따라 어떠한 형식으로 만들지 생각하기 전에 벤치마킹을 해두는것이 중요하다. 자신의 프로그램을 조금 더 좋게 만드는 하나의 방법이라고 생각한다.

7. 특징 및 장점 : 해당 프로그램의 특징과 장점. 어떠한 형식의 특징이 있으며 장점이 있는지. (물론 단점을 마구 얘기하진않겠지만..)

8. 문제설명서 : 사실 문제설명서라고하면 문제를 설명한다 라는의미에서 안좋게 받아들일 수 있는데 사실, 그게 아니고, 이 프로그램에 대한 설명이라고 보면되겠다. 쉽게 말해 설명서? 같은건데.. 해당은 나중에 기회가 되면 다시한번 더 자세히 다뤄보도록...

9. UI : 꼭 UI가 아니어도 좋다. 개발직전의 WireFrame을 보여줘도 되는데, 해당은 개발단계 거의 바로직전에 어떠한 형식으로 개발이 될지 틀을 잡아주기때문에 꼭 있어야하는 부분이다. 물론 설계에 있어 모든부분이 필요하겠지만, UI(WireFrame)같은 경우 설계를 잘해두면 나중에 개발할시에 시간을 단축시켜주기 때문에 디자이너와 잘 연계해서 설계해두면 편하다고 볼 수 있다.

10. 요구사항분석 : 자신의 프로그램에 필요한 요구사항들을 모아놓는것으로, 쉽게말해 어떤 기능들이 필요한지 모두 짜집기하는 부분이다. 해당이 있어야 함수등의 개발시에 어려움없이 조금이라도 더 쉽게 설계하여 개발할 수 있다.

11. 여러 다이어그램 : 해당은 자신이 무슨프로그램을 개발하느냐에 따라 제작해야하는 다이어그램이 조금씩 달라지는데, 내가 자주사용하는 다이어그램은 클래스 및 시퀀스 다이어그램이다. 

 - 클래스다이어그램 같은 경우 개발에 있어 어디 클래스에 어떠한 함수가 제작되어야하는 지를 명확하게 해주기때문에 설계단계에서 제대로 해줘야 개발시에 함수작성시에도 쉽고 편하게 개발할 수 있다.
 - 시퀀스다이어그램은 각 클래스나 함수에서 어떠한 형식으로 타임을 할당하고 실행이 되는지를 나타내는데 시퀀스 다이어그램을 제작하다보면 자신이 만들 프로그램에 대해서 좀더 체계적으로 개발할 수 있다고 볼 수 있다. (편하게 개발하는것과 체계적으로 개발하는것과는 전혀 다른차이. 꼭 알아둬야한다.)
 - ER다이어그램은 DB연동시에 꼭 필요한 부분이다. 프로그램에 DB가 들어가는데 ER다이어그램이 없다는건 개발을 할 마음이 없다는거다. 간략하게라도 ER다이어그램은 꼭 있어야하며, 추가적인 다이어그램은 추후에 기회가되면 설명하도록 하자.

12. 추가예정사항 : 자신이 프로그램을 만들고(혹은 런칭을 하고) 기능을 어떤것들을 추가할지를 작성한다. 주로는 프로그램을 업데이트를 하면서 어떤기능이 추가될지에 대해서를 작성.

13. 부록 : 해당 프로그램을 작성하면서 처음다루는 사람들을 상정해서 몇가지의 단어들이나, UI에 대해 짤막하게 정리해두면 좋다.

14. 여기서부터는 어플이나 웹프로그래밍등에 필요한 부분인데, 어쩌면 꼭 필요한 부분은 아니지만 알아두면 좋은 부분이다.
 - SITEMAP : 홈페이지나 어플을 작성할때 어떤식으로 각 액티비티들을 연결하고 연결이 될지가 나와있는 부분이다. 홈페이지 및 어플을 작성할때 꼭 필요한 부분.
 - Persona : 해당 홈페이지 및 어플을 이용하기 위한 가상의 인물을 만든다.
 - Context Scenario : 위 페르소나에 연동되는 부분 중 한부분으로, 가상의 인물이 자신이 개발할 홈페이지 및 어플을 어떠한 형식으로 이용하게 되었고 어떠한 느낌을 받았는지를 작성하는 부분이다.
위 두가지 경우에는 해당 어플 혹은 홈페이지를 어떠한 사용자가 사용할지 주요 타게팅을 잡을때 매우 편리하다.

15. 추가 : 벤치마킹을 할때에 홈페이지나 어플의 경우 Jacob Nielson's Heuristic Evaluation을 이용해 작성하면 매우 편리하다.
 - 1. Visibility of system status (사용자에게 시스템의 현재 상태를 시각화하여 보여준다.)
 - 2. Match between system and the real world (현실세계와 부합되도록 시스템을 설계한다.)
 - 3. User control and freedom (사용자에게 적절한 통제권을 부여한다.)
 - 4. Consistency and standards (일관성과 표준성을 높인다.)
 - 5. Error prevention (사용자의 실수를 미연에 방지할 수 있도록 설계한다.)
 - 6. Recognition rather than recall (사용자가 적은 인지적 노력으로 시스템을 사용할 수 있게 한다.)
 - 7. Flexibility and efficiency of use (사용자가 시스템을 유연하게 사용할 수 있도록 한다.)
 - 8. Aesthetic and minimalist design (심미적이고 간결한 시스템 디자인을 제공한다.)
 - 9. Help users recognize, Diagnose, and recover from errors (에러 발생시 사용자 스스로 문제를 파악하고 수정할 수 있도록 설계한다.)
 - 10. Help and documentation (사용자에게 충분한 도움말을 제공한다.)
또한 해당에 대한 평가가 따로 4가지로 나뉘어 존재하는데 해당은 나중에 기회가 된다면 추가하는걸로..

16. 개발기간 : 개발기간은 꼭 필요하다. 언제부터 언제까지 어떠한 기능을 구현하고 결국 언제 완성을 할것인지. 꼭 있어야하는부분. 이부분이 없다면 개발자들은 헤이하게 멍때리고 있을지도..(웃음)

17. 시연의 경우 있어도 되고 없어도 되지만 있으면 좋은게 해당 프로그램을 어떠한형식으로 실행하는지 타인들에게 좀더 이해력 높게 보여주기위해 있으면 좋다.

>> 사실 졸업작품을 개발할때 부랴부랴하느라 클래스도그렇고 함수들도그렇고 여기있을게 저기있고등등 아주 뒤죽박죽이다. 100점을 기준으로한다면 0점..
역시 개발은 설계를 확실하게 잡아두고 진전을해야 괜찮은 프로그램이 나온다고 생각할 수 있다. 다음부터는 꼭 설계를 착실하게하고 개발을 할 수 있도록 해야겠다.
기회가 된다면 뒤죽박죽으로 짜여진 졸업작품을 조금 더 다듬어보는것도 내 실력을 향상시킬 좋은 기회가 될 것 같다.