3단원을 한 문장으로
프로그램을 만드는 일은 코드를 쓰는 일이 아니라, 문서를 하나씩 넘겨 가며 판단을 확정해 가는 일이다.
이 단원에서 만든 문서는 넷이다. 그리고 앞 문서가 뒤 문서의 입력이었다.
여덟 차시 동안 만든 문서와, 그것이 다음 단계로 넘어간 흐름.자체 제작
정리 ① 기획과 요구 사항 (프그03-01)
되돌아갈 곳: 1차시 무엇을 만들지 정하기 — 기획과 요구 사항 도출 · 2차시 요구 사항을 문서로 정리하기
정리 ② 구조 설계와 알고리즘 (프그03-02)
되돌아갈 곳: 3차시 프로그램 구조를 설계하다 · 4차시 설계한 프로그램의 알고리즘 작성
정리 ③ 구현과 통합 (프그03-03)
되돌아갈 곳: 5차시 설계를 코드로 옮기다 · 6차시 나눠 만든 것을 합치다
정리 ④ 테스트와 고쳐 내기 (프그03-04)
되돌아갈 곳: 7차시 단위 테스트와 통합 테스트 · 8차시 시스템 테스트와 고쳐 내기
1단원에서 배운 것이 여기서 어떻게 쓰였나
3단원은 1단원의 개념을 실제로 한 번 돌려 본 단원이다.
스스로 점검하기
| 확인할 것 |
아직 |
대체로 |
설명할 수 있다 |
되돌아갈 차시 |
| 기획에서 답해야 할 네 가지 질문을 말할 수 있다 |
☐ |
☐ |
☐ |
1차시 |
| 요구를 끌어내는 네 가지 방법과 각각의 강점을 구분한다 |
☐ |
☐ |
☐ |
1차시 |
| 판정할 수 없는 요구 사항을 판정할 수 있게 고쳐 쓸 수 있다 |
☐ |
☐ |
☐ |
2차시 |
| 기능 요구와 비기능 요구를 나눌 수 있다 |
☐ |
☐ |
☐ |
2차시 |
| 기능 목록을 부품으로 쪼개고 겉모습을 못 박을 수 있다 |
☐ |
☐ |
☐ |
3차시 |
| 부품의 「실패하면」을 스스로 채울 수 있다 |
☐ |
☐ |
☐ |
3차시 |
| 부품의 알고리즘을 의사 코드로 적을 수 있다 |
☐ |
☐ |
☐ |
4차시 |
| 예외 상황을 찾는 네 가지 물음을 던질 수 있다 |
☐ |
☐ |
☐ |
4차시 |
| 손으로 따라가며 기대 결과를 미리 낼 수 있다 |
☐ |
☐ |
☐ |
4차시 |
| 껍데기부터 만들어 하나씩 채우는 순서로 구현한다 |
☐ |
☐ |
☐ |
5차시 |
| 설계와 달라진 부분을 기록한다 |
☐ |
☐ |
☐ |
5차시 |
| 합칠 때 어긋나는 네 자리를 말할 수 있다 |
☐ |
☐ |
☐ |
6차시 |
| 단위·통합·시스템 테스트의 차이를 설명할 수 있다 |
☐ |
☐ |
☐ |
7·8차시 |
| 경계값을 짝으로 넣는 이유를 설명할 수 있다 |
☐ |
☐ |
☐ |
7차시 |
| 재현 방법이 들어간 결함 보고서를 쓸 수 있다 |
☐ |
☐ |
☐ |
8차시 |
단원 평가 문제
3단원 평가 문제
보기를 누르면 바로 채점된다. 틀려도 해설을 읽으면 된다.
'학교 생활을 편하게 해 주는 앱을 만들자'는 회의에서 가장 먼저 해야 할 일은?프그03-01
사용자와 해결할 불편이 정해지지 않으면 요구 사항이 나오지 않는다. 사용자를 좁힐수록 요구 사항이 구체적으로 바뀐다.
다음 중 판정할 수 있는 요구 사항으로 바르게 고쳐 쓴 것은?프그03-01
숫자로 바꾸어야 나중에 지켰는지 대조할 수 있다. '아주', '절대', '누구나'는 정도를 강조할 뿐 판정 기준을 만들지 못한다.
비기능 요구가 기능 요구보다 위험한 이유는?프그03-01
5권으로 시험할 때는 잘 되던 도서 대출 프로그램이 8,400권에서 40초가 걸린 사례가 그렇다. 기능 요구는 빠뜨리면 바로 티가 나지만 비기능 요구는 늦게 드러나 되돌리기 어렵다.
점수 범위를 판정하는 일을 별도 부품으로 떼어 내는 기준으로 알맞은 것은?프그03-02
입력받을 때와 통계를 낼 때 모두 쓰인다. 두 곳에 같은 조건을 적으면 범위를 바꿀 때 한 곳만 고치게 되고, 그 결과가 6차시에서 다룬 '같은 일의 사본' 문제다.
부품의 겉모습에서 '실패하면' 칸을 채우지 않으면 생기는 일은?프그03-02
0을 돌려줄지, 없음을 돌려줄지, 오류를 낼지는 설계에서 정할 일이다. 정하지 않으면 사람마다 다르게 만들고 통합에서 문제가 된다.
다음 알고리즘에서 반드시 있어야 할 줄은? '합계를 인원으로 나누어 평균을 낸다'프그03-02
인원이 0이면 0으로 나누게 되어 프로그램이 멈춘다. 나눗셈이 있는 곳마다 나누는 값이 0이 될 길을 막았는지 확인하는 것이 예외를 찾는 네 가지 물음 중 하나다.
책상 검사에서 손으로 낸 결과를 보관해 두는 이유는?프그03-02
프로그램이 낸 값을 기대 결과로 삼으면 프로그램이 틀렸을 때도 통과한다. 손으로 미리 낸 값이 있어야 대조에 뜻이 생긴다.
여러 부품을 합칠 때 하나씩 붙이고 붙일 때마다 실행하는 이유는?프그03-03
여러 개를 한꺼번에 붙이면 어긋난 곳이 겹쳐 원인을 가릴 수 없다. 하나씩 붙이면 방금 붙인 것을 되돌려 보는 것만으로 진단이 끝난다.
C에서 정수 합계를 정수 인원으로 나눌 때 (double) 로 바꾸지 않으면 어떤 요구를 못 지키게 되는가?프그03-03
정수끼리 나누면 소수 부분이 잘려 419 ÷ 5 가 83이 된다. 설계에는 없던 문제가 언어를 고른 뒤에 생긴 경우이며, 이런 것을 발견하면 기록해 문서에 반영한다.
단위 테스트를 통과한 부품들로 통합 테스트를 할 때 얻는 이점은?프그03-04
확인이 끝난 부품은 의심 목록에서 뺄 수 있다. 원인을 좁히는 것이 테스트를 단계로 나누는 목적이다.
시스템 테스트에서 반드시 지켜야 할 조건으로 알맞은 것은?프그03-04
만든 사람은 자기가 정한 방식대로만 쓰고, 자기 컴퓨터에는 필요한 것이 이미 깔려 있다. 실제 환경에서 다른 사람이 명세서를 짚어 가며 확인해야 비기능 요구와 예상 밖의 사용이 드러난다.
결함을 고칠 때 '그 결함을 잡는 테스트 사례를 먼저 추가한다'를 건너뛰면 생기는 일은?프그03-04
사례를 추가해 두면 나중에 다른 수정으로 같은 문제가 되살아났을 때 회귀 테스트에서 자동으로 잡힌다. 고칠 때마다 테스트 사례가 하나씩 늘어나는 것이 정상이다.
이 단원을 마치며
프로그램을 만드는 절차는 프로그램에만 쓰이지 않는다. 무엇을 만들지 정하고, 크기를 줄이고, 나눠 맡고, 확인하고, 고쳐 내는 흐름은 축제를 기획할 때도 실험을 계획할 때도 같다. 이 단원에서 남는 것은 코드가 아니라 그 순서 감각이다.