명세서 작성
2011년 1월 15일 토요일
오후 3:13
무엇을 만들지 알지 못하는 데 어떻게 만들지?
명세서는 무엇을 만들지 결정하는 과정의 결과물입니다. 이 명세서에 대해서 이야기 해 보려 합니다.
이 글의 구성
1. 명세서가 뭐지?
2. 좋은 명세서는?
3. 작성 시에 참고하세요
4. 명세서 작성용 도구들
명세서가 뭐지?
2011년 1월 15일 토요일
오후 3:16
What & How
명세서란 What & How에 집중하는 작업입니다.
우리가 만들 프로그램에 무엇(What)을 넣어야 할 지 고민해서 적고,
그리고 그것들이 어떻게 동작할지(How)를 결정합니다.
명세서 작성은 무엇을 어떻게 만들어야 할 지 결정하는 매우 중요한 과정입니다.
명세서의 종류
한 파일에 작성하지만, 명세서는 다음과 같은 두 가지 종류의 내용을 담게 됩니다.
1. 기능 명세서 : 철저하게 어떻게 만들지(구현할지)가 배제된 명세서입니다. 사용자의 입장에서 프로그램을 바라봤을 때 생길 수 있는 일들을 적습니다.
예) 시작하기 버튼을 누르면 새로운 게임이 시작된다. 저장하기 버튼을 누르면 사용자가 과거에 저장해 놓았던 파일들을 열어 이어서 게임을 진행할 수 있다.
2. 기술 명세서 : 개발자의 입장에서 프로그램을 바라봤을 때에 대한 명세서입니다. 구현 방법적인 면이 많이 들어가게 됩니다. 에러 처리라든지, 알고리즘, 객체들에 대한 소개, 데이터베이스 스키마 등등이 들어갑니다.
명세서에 들어가야 할 것들
1. 프로그램의 여러 가지 기능들
2. 그리고 그 기능들의 작동 방식
3. 기능들에 대한 예외 처리
4. 마지막으로 기능들을 만드는 데 필요한 다른 모든 것들
명세서를 어떻게 작성하는 지 알고 싶으시다면, 예제를 참고하세요.
명세서의 예 : Tetris
2011년 1월 15일 토요일
오후 5:23
예를 들어 설명하면?
알기 쉽게 예를 들어서 , 문명의 혜택을 받은 사람이라면 한 번 쯤은 해 봤을 테트리스에 대한 명세서를 작성해 볼 까 합니다.
소개
우리는 간략한 Tetris를 만들어 볼 생각입니다. 이 Tetris를 통해서 많은 분들이 명세서가 무엇인지, 명세를 어떻게 작성하는지 이해할 수 있는 시간을 가져 보고자 합니다.
구성
이 명세서는 다음과 같지 구성되어 있습니다.
1. Tetris에 들어갈 기능들
2. 화면 구성
3. 기술적 요구사항
목표 사항
1. 예제로서 적절하고, 재미있는 Tetris 만들기
2. 사용자의 도전 정신을 자극하는 Tetris 만들기
비목표
1. 온라인 게임은 만들지 말 것
2. 돈 받고 팔려면 저작권 문제가 있으니, 돈 받고 팔 생각 하지 말 것.
Tetris의 기능들
1. 벽돌들을 회전시켜서 한 줄을 다 채우면, 그 줄을 없애고 위에 있던 벽돌들을 아래로 내리고 점수를 줍니다.
1.1 벽돌
① 벽돌은 1개부터 8개까지 한 번에 붙어 있는 것을 지원합니다. 그 이상 있는 것은 보기에 별로일 것이라 판 단됩니다.
② 벽돌은 좌회전과 우회전을 전부 다 지원합니다.
1.2 점수
① 점수는 줄 수에 따라서 피보나치 수열을 적용합니다.
예) 1줄 : 10점 2줄 : 20점 3줄: 30점, 4줄 : 50점
참고 피보나치 수열 :
1.3 한 줄은 4개, 8개, 16개로 사용자가 지정할 수 있도록 합니다.
2. 여러 가지 모드를 지원해야 합니다.
2.1 심플 모드 : 그냥 열심히 줄 채우면, 그 줄대로 점수를 주는 모드입니다. 가장 간단합니다.
2.2 타임 어택 : 시간을 정해 놓고, 그 시간 내에 몇 점을 채울 수 있는가 결정하는 모드입니다.
시간은 2분, 5분, 10분으로 합시다.
2.3 아이템 모드 : 특수한 블록을 정해진 시간 내에 깨면 아이템을 주고, 아이템을 사용하여 게임을 진행합니다.
3. 명예의 전당을 만듭시다.
각각의 모드에 대해서 최고 점수를 등록한 사람의 이름과 점수를 등록할 수 있게 합시다.
화면 구성
점수 : 310
남은 시간 : 7분 30초
아이템
北
모든 벽돌 없애기
참고 : 대강 구성만 보기위해 그렸습니다.
기술적 요구사항
1.
명세서에 들어가야 할 사항들
2011년 1월 16일 일요일
오후 3:19
간략한 소개
지금 프로그램이 뭘 하려는 프로그램이고, 어디에 쓰일 프로그램인지에 대한 간략한 소개를 합시다. 꼭 프로그램 명세 처음에만 존재하는 것이 아니라, 프로그램 내부의 한 모듈에 대해서 적어도 무방합니다.
목표
어떤 것을 만들지에 대한 목표입니다. 어떤 생각을 가지고 이 프로그램 또는 기능을 개발할지 적어 주시면 됩니다.
비목표 사항
어떤 것을 만들지 말 지에 대한 목표입니다. 하지 말아야 할 것을 적습니다. 생각보다 이것 역시 중요합니다.
Screen clipping taken: 2011-01-16 오후 3:53
기능적 요구사항
프로그램에 어떤 기능들이 있으며 그 기능들이 어떻게 동작하는지에 대한 내용입니다. 행복하고 정상적인 경로뿐만 아니라, 비정상적이고, 암울한 경로까지도 체크해 보아야 합니다.
비기능적 요구사항
프로그램이 어떤 기능이 있는지, 어떻게 작동하는지와는 관련이 없지만, 그래도 중요한 사항들입니다.
· 국제화 : 어떻게 프로그램을 다른 나라 말로 제공할 수 있을 지 여부.
· 이식성 : 다른 운영체제 및 환경에서도 작동하게 할 수 있을지 여부.
· 성능 : 프로그램이 갖춰야 할 적절한 성능에 대한 여부
· 안전성 : 프로그램이 시스템이나 기타 사용자의 다른 프로그램에 손상을 주어서는 안 됩니다.
· 보안 : 우리가 만든 프로그램에 의해 사용자의 정보를 다른 사람에게 넘겨주게 되는 불상사가 생기면 안됩니다.
· 가용성 : 프로그램이 얼마나 고장 없이 가동 가능하냐에 대한 이야기입니다.
· 유지보수성 : 프로그램이 얼마나 고치기 쉬운가 여부입니다.
· 신뢰성 : 프로그램이 얼마나 믿음직스럽게 자신의 일을 하는가 입니다.
· 정확성 : 프로그램이 얼마나 사용자의 요구사항을 정확하게 수행하는가 여부.
· 유연성 : 프로그램이 요구 사항의 변경에 얼마나 유연한지에 대한 설명입니다.
그림과 주석
설명을 쉽게 하기 위해서 언제나 그림과 주석을 동원하도록 합시다.
Screen clipping taken: 2011-01-16 오후 3:55
좋은 명세서란?
2011년 1월 15일 토요일
오후 6:56
들어가며
사실 여기서부터 이야기하는 내용은 상당히 당연한 내용들입니다. 하지만 당연하다고 해서 지키기 쉽다는 것이 아님을 명심하시기 바랍니다.
"건강하려면 어떻게 해야 합니까?"에 대한 정답은
"규칙적인 생활 하시고, 나쁜 것 먹지 마시고, 열심히 운동하세요"입니다.
이 말이 얼마나 지키기 어려운 것인지는 설명 안 해도 아실 것입니다. 그만큼 듣고 이해하기는 쉽지만 지키기 어려운 것이 이 내용입니다. 잊지 마세요.
명세서는 읽기 쉬워야 합니다.
어려운 단어나 어려운 표현은 삼갑시다. 그리고 어려운 내용이 있다면 그에 대한 설명은 꼭 남겨 주는 습관을 갖도록 합시다.
명세서에는 빠진 것이 없어야 합니다.
명세서를 읽으면 뭘 만들고 싶은지 정확하게 감이 와야 합니다. 누구든지 그 명세서를 읽었다면 거의 동일한 프로그램을 만들어 낼 수 있어야 합니다.
명세서는 재미 있어야 합니다.
압니다. 재미있게 글 쓰기 어렵다는 것. 저 역시 이야기꾼은 아닙니다. 그래도 한 번 노력해 봅시다. 재미있게 쓰기 위해서. 불면증 치료제를 만들지 않기 위해 노력해 봅시다.
저 역시 재미있는 이야기를 많이 알고, 많이 하는 그런 재미있는 사람은 아닙니다만, 그래도 재미있게 써 보기 위해 노력할 것입니다. 같이 노력해 봅시다.
(어이, 거기! 뒤에! 이렇게 진지하게 이야기하고 있는데 졸면 되나? 재미가 없어서 그렇다구? 미안해...ㅜㅜ)
예외 사항 역시 잘 적어 줍시다.
세상에 행복한 일만 있으면 참 좋을 것입니다. 하지만 우리 세상 살이가 그렇지 않습니다. 모두가 기본적으로 쿼드코어에 RAM 4기가를 꽂고 살지 않습니다. 꼭 잘못된 경로로 파일을 읽는 함수를 호출하는 사람들 있습니다.
이런 불행한 일들 역시 예상해 봅시다. 그리고 대처합시다. 그래야 사용자가 행복하게 프로그램을 쓸 수 있습니다.
참고 사항
2011년 1월 15일 토요일
오후 7:20
참고 사항이라고 쓰여져 있긴 합니다만 참고만 하기에는 아쉬울 정도로 중요한 이야기들입니다.
명세서 작업은 설계 작업과 겹칠 수 있습니다.
명세서를 작성하다 보면, 이제 이 정도면 다 적었다 싶을 때가 있습니다. 이제 이 때 설계로 넘어갑니다. 하지만 설계를 하시다 보면 알겠지만, 그 명세서가 다 작성된 것이 아니라는 것을 알게 되실 것입니다. 그 때 다시 와서 명세를 다듬어 줍시다. 그렇게 계속 다듬어 줄수록 좋은 명세가 나타나게 됩니다.
완벽한 명세는 없습니다.
명세는 조금씩 발전해 나갑니다. 조금씩 조금씩 조금씩 조금씩. 그리고 완벽하게 코드와 동일한 명세를 작성하는 것은 벌레 하나 없는 프로그램 만드는만큼이나 비용이 많이 들고 어려운 일입니다. 분명 언젠가는 설계를 하고 구현을 시작해야 합니다. 이 점을 잊지 마세요.
언제든 고쳐질 것이라고 예상을 합시다.
명세서는 고쳐질 수 있습니다. 바뀔 수 있습니다. 그 점은 항상 기억해 두어야 합니다.
아래와 같은 순서로 작성하면 조금 더 편하게 작성하실 수 있습니다.
1. 뭘 적을 지 생각해 보기 : 명세서에 들어갈 내용을 나열해 봅시다.
2. 목차 정하기 : 명세서를 어떻게 구성할 지 순서를 나열합시다.
3. 각 항목 적기 : 이제 목차에 따라 각 항목을 적어 나갑시다.
3.1 행복한 일부터 생각하기 : 세상 만물이 이상적으로만 돌아갈 때에 있어야 할 일들을 적어 봅시다. 이것들이 기본적인 기능적 요구사항이 됩니다.
3.2 예외 상황 생각해 보기 : 세상에는 행복한 일만 있지 않습니다. 언제든지 악당들이 우리의 프로그램에 침투할 수 있습니다. 착한 분들이 실수로 우리 프로그램을 잘못 건드릴 수 있습니다. 이 모든 부분을 생각해 봅시다. 그리고 그에 대한 상황을 적어 나갑시다.
3.3 그 외 중요한 사항 적기 : 이 부분은 성능이 중요할 수 있습니다. 이 부분은 다른 운영체제로의 이식성을 중요시 해야할 수 있습니다. 이런 부분들에 대해 적어 나갑시다.
설계하기
2011년 1월 17일 월요일
오전 10:51
설계란 무엇인가?
설계는 명세에서 만들기로 한 내용을 어떤 구조로 만들려고 하는 지에 대한 내용을 담고 있습니다. 명세가 What과 How에 집중한다면 설계는 모양에 집중한다고 보면 되겠습니다.
http://news.chosun.com/site/data/html_dir/2010/12/11/2010121100059.html
Screen clipping taken: 2011-01-17 오전 10:55
어떤 모양의 건물을 만들지 고민하는 것처럼, 어떤 모양의 프로그램을 만들지 고민하는 것이 설계입니다.