소프트웨어공학 레포트 - 찾을 수 있는 소프트웨어 개발 방법론을 조사하여 각각에 대한 간략한 설명과 의견을 정리하시오.

I. 서론

팀 과제로 만든 도서 교환 프로그램은 실행됐지만 친구가 책을 구하기는 어려웠다. 우리는 등록 화면을 멋지게 만드는 데 시간을 썼고, 이미 교환된 책을 검색 결과에서 어떻게 처리할지는 늦게 정했다. 컴퓨터공학과 수업에서 기능을 나누어 맡으면 개발도 자연스럽게 정리될 줄 알았는데, 각자 완성한 화면을 연결한 날부터 일이 더 늘었다.

개발 방법론을 조사하며 관심이 간 지점은 이름의 새로움보다 잘못된 선택을 언제 알아차릴 수 있는가였다. 요구가 바뀌지 않는다고 약속하는 방법과 자주 확인하며 바꾸는 방법은 부담을 서로 다른 곳에 둔다. 나는 방법론을 순위로 고르기보다 지금 해결해야 할 불확실성이 무엇인지 밝혀 주는 약속으로 이해한다. 문서가 필요한 상황에 회의만 늘리는 것도, 빠른 확인이 필요한 상황에 문서 승인만 기다리는 것도 개발을 어렵게 만든다.

II. 본론

1) 설계를 굳히는 폭포수와 검증을 짝짓는 V모델

폭포수 모델은 요구 분석과 설계 등 개발 단계를 구분하고 앞 단계의 결과를 바탕으로 뒤 작업을 진행한다. IBM의 개발 생명주기 설명에서도 단계의 순차성과 요구의 안정성이 핵심으로 제시된다. 무엇을 언제 확정했는지 추적하기 쉬워 결과물과 검토 책임을 분명히 하기 좋다. 반면 사용자가 완성품 가까운 모습을 늦게 접하면 초기에 놓친 요구가 뒤늦게 드러난다. 문서를 완성했다는 사실과 문제가 제대로 이해됐다는 사실을 같은 것으로 취급하지 않아야 한다.

나는 입력과 출력의 규칙이 분명한 자료 변환 도구라면 폭포수 모델의 계획성이 유용하다고 본다. 파일 형식과 오류 처리 기준을 합의한 뒤 구현하면 불필요한 변경을 줄일 수 있다. 도서 교환처럼 사용자가 화면을 써 보고 요구를 바꾸는 서비스에는 그대로 적용하기 어렵다. 승인 절차가 있다고 변경을 금지할 일은 아니지만 변경에 드는 설계 수정과 재검증의 부담을 일찍 알리는 장치는 필요하다.

V모델은 개발 단계마다 대응하는 검증 활동을 연결한다. 사용자 요구에는 인수 기준을, 전체 설계에는 통합된 동작을 확인할 시험을 준비하는 식이다. 코드를 다 쓴 뒤 무엇을 시험할지 고민하는 습관을 줄인다는 점이 좋다. 요구 문장에 실제 확인 가능한 조건이 있는지 설계 중에 묻게 되기 때문이다. 다만 그림의 왼쪽과 오른쪽을 연결했다고 시험이 충분해지는 것은 아니다. 요구가 잘못 정해졌다면 시험을 통과한 프로그램도 쓸모가 없을 수 있다.

학생 실습에서도 빠르게 작동한다는 요구보다 검색 결과가 없을 때 어떤 안내를 해야 하는지 적는 편이 시험에 도움이 된다. 나는 V모델을 모든 개발을 경직시키는 틀로 보기보다 요구와 시험의 연결을 놓치지 않는 기준으로 활용하고 싶다. 안전과 관련된 프로그램은 정상 상황뿐 아니라 입력이 잘못되거나 통신이 끊긴 상황도 검토해야 한다. 반복 개발을 선택하더라도 변경된 요구와 시험의 관계를 남기는 원칙은 유지할 수 있다.