소프트웨어 개발에 대한 오해와 실체
Preface
2장 부터는 본격적인 소프트웨어 공학에 관한 내용을 배우기 시작했다.
이번 장을 공부하며 한 가지 놀란 점은 소프트웨어를 개발하는 것 보다 유지보수하는 데 더 많은 비용이 든다는 것이다.
내가 재학중인 학교는 작년 1학기 부터 코로나로 인한 비대면 수업을 실시하고 있다.
그런데 온라인 강의가 탑재된 웹사이트가 다운되는 일이 종종 발생한다.
그때마다 나는 "우리 학교는 학생들 등록금을 시스템 업데이트에 안쓰고 어디에 쓰는거야?!"라고 생각하며 웹사이트 관계자들을 마음 속으로 비난했었다.
소프트웨어 유지보수에 사용되는 비용이 만만치 않다는 것을 미리 알았더라면...
그분들도 최대한 노력하고 있다는 것을 이해했더라면...
그래도 아마 온갖 짜증을 내며 욕을 했을 것 같다 ㅎㅎ
또 한가지 새롭게 알게 된 사실은 개발 도중 인력을 증원하면 개발 시간이 증가하고 생산성이 감소된다는 것이다.
나는 인력과 생산성은 당연히 정비례 관계에 있을 것이라고 생각했다.
그러나 실무 상황을 예시로 접한 이후 내가 너무 일차원적으로 생각하고 있었다는 것을 깨달았다.
우리는 조금 더 넓은 시야를 통해 세상을 바라보는 관점이 필요하지 않을까?
1. 소프트웨어와 관련된 질문
- 소프트웨어 공학 : 체계적인 공법을 적용하여, 최적의 비용으로 고품질의 소프트웨어 시스템을 개발하는 것
- 소프트웨어 시스템 : 물리적 요소 < 논리적 요소
| 소프트웨어 개발 비용 | |
| 프로그래밍 | 20% |
| 요구사항 분석 및 디자인 | 40% |
| 테스팅 | 40% |
- 프로그래머는 하루 평균 10줄 정도의 프로그램을 작성하지만, 시스템의 크기와 응용 분야의 난이도에 따라 큰 차이가 있다.
- 개발과정에서의 오류는 1,000줄 당 50~60개, 배달된 후 발견되는 오류는 평균 4개 미만이다.
- 최근들어 품질 문제는 개발의 생산성과 동등하게 중요시된다.
- 오류의 발견이 늦어질수록 수정 비용이 증가한다.
- 리콜(recall)제도 : 제품에 결함이 있을 때 제조 회사가 스스로 시정하거나 정부가 강제로 수거, 파기 명령을 내리는 제도
| 개발 비용과 유지보수 비용 | |
| 개발 비용 | 33% |
| 유지보수 비용 | 67% |
2. 소프트웨어의 위기
- 소프트웨어 위기 : 생산성이나 개발 방법에서의 뚜렷한 전환점이 없이 점진적 변화만 있음
- 이유
① 소프트웨어 생산성이 사용자의 요구 충족 불가
② 소프트웨어 품질 향상과 유지보수의 미흡
→ 확실한 요구사항과 목표 설립의 어려움
→ 부족한 의견 교환
→ 공정 후반부에 발견되는 주요 결점
→ 체계적인 접근방법의 부재
③ 프로젝트 개발 일정 및 소요 비용 예측의 부정확성
④ 개발 기술의 낙후성과 전문 인력의 부족
3. 소프트웨어 위기의 해결책
- 소프트웨어 위기의 원인과 문제점에 대한 정확한 인식
- 확실한 목표 설정과 프로젝트 참여 인원간의 능동적인 활동
4. 소프트웨어에 대한 오해
- 개발체계나 도구를 습득한 이후 실무에 적용시켜보며 자신의 것으로 만들어야 한다.
- 좋은 도구나 기계가 사람을 대체할 순 없다. (인간공학적 측면↑)
- 브룩스의 법칙 : 개발 도중 인력을 증원하면 개발 시간의 증가와 생산성의 감소를 초래함
- 변경 사항이 늦게 요구될수록 수정 비용은 증가한다.
- 직업적인 소프트웨어는 장기적인 안목을 통해 바라보아야 한다.
- 소프트웨어 품질 보증(QA : Quality Assurance) 방법
① 품질 여과(quality filtering)
② 공식기술검토회(formal technical review) : 요구사항 명세서에 모두가 서명
→ 분명한 책임 소재, 목표에 대한 구체적 규명
- 개발 단계마다 나오는 문서는 다음 프로젝트의 완성과 이후의 유지보수에 있어 필수적이다.
참고 문헌 : 윤청, 『소프트웨어 공학 에센셜』(생능출판), 2019, p.42~59.