02. 소프트웨어 개발에 대한 오해와 실체

소프트웨어에 대한 사소한 정보들

• 절반 정도의 개발 비용이 프로그래밍(구현) 이전단계에 소요된다.
  - 요구사항 분석과 설계가 제대로 되는 경우(품질), 프로그래밍은 단순히 기계적인 일이다. 
• 프로그래머의 생산성이 그렇게 좋지는 않다.
  - 평균 하루에 10줄의 코드를 작성한다. 특히 통신이나 운영체제 소프트웨어는 다른 소프트웨어보다 4배 이상의 비용이 소요된다. 왜 이런걸까? 품질보증 때문이다.
  품질과 생산성의 관계를 생각해보자. 소프트웨어는 하드웨어나 시스템의 부속이라는 인식이 강하며, 소프트웨어에 들어가는 비용은 제품 가격에 미포함되는 경우가 많다. (ex) 휴대폰에 있는 기본앱에 따른 비용은 없음) 높은 품질의 소프트웨어 개발을 위해 제도와 인식의 변화가 필요하다.
• 제품이 완성되고나서 발견되는 오류는 평균 4개 이하이다.
  - 이것은 수정하기 어려운 오류로, 정정 후 재배포하기 부담되며 보통은 설계 단계에서 문제가 있었던 것이다.

 

 

 

소프트웨어의 위기와 원인 그리고 해결책

-소프트웨어의 위기

• 생산성이 좋지 않음
• 개발 기간, 비용을 예측하기 어려움
• 생산기술과 관리 기술이 부족함. 따라서 개인의 역량에 의존하면 안됨
• 품질 유지 어려움
• 유지보수 비용이 엄청남

-위기의 원인

• 소프트웨어 생산성이 사용자들의 서비스에 대한 요구를 따라가지 못함. 즉, 사용자들의 요구 트렌드가 굉장히 빠르게 변함.
  - 고객들의 기대치는 커지지만 생산성은 증대되지 않음
  - 제안서만 가지고는 사용자의 구체적인 요구사항을 알기 어려움
  - 프로젝트의 확실한 요구사항과 목표를 세우기 어려움
  - 사용자와 개발자 사이에 의견 교환이 미흡
• 소프트웨어 품질이 향상되기 어렵고 유지보수가 힘듦
  - 작동하는 시스템은 개발 후반부에 가서야 얻을 수 있음
  - 주요 결점들이 후반부에 발견됨
  - 소프트웨어 품질관리는 하드웨어보다 어려움
  - 소프트웨어에 드는 비용은 하드웨어에 드는 비용보다 훨씬 많음
• 관리자, 엔지니어들이 새 기법보다는 과거의 경험에 의존하여 코딩하는 경우가 많음
  - 대부분 새 기술에 대한 훈련을 받지 않거나 새 기법의 존재를 모르고 있음
  - 체계적인 접근 방법이 많지 않음
• 개발 일정, 소요비용 예측이 매우 부정확함
  - 개발 역사가 짧아 다른 공학에 비해 과거의 경험과 역사적 자료가 적음
  - 중견 관리자들이 소프트웨어 개발에 대한 공학 지식과 경험이 부족함

- 위기의 해결책

• 원인과 문제점에 대해 정확히 인식한다
• 기술적인 문제뿐만 아니라 관리적인 측면에서 조직적으로 문제를 극복하려는 노력을 요구한다
• 참여하는 모든 사람들이 문제점에 대한 정확한 인식과 목표를 가지고 문제를 해결하기 위한 방법과 과정을 공유한다.

 

 

 

 

소프트웨어에 대한 오해

 

- 관리자 (의사결정을 하고 실무자들의 기술력을 향상시키는 동시에 성장을 지원해주는 역할)

Q1. 소프트웨어 개발에 유용한 책이 있고 책 안에 개발 표준과 단계가 제시되어있어 필요한 모든 정보를 얻을 수 있는가?
A. 대부분은 책을 사용하지 않는다. 또한 요리책을 보고 요리를 배워도 실제 실습해보지 않으면 못하는 것과 같다. 개발 방법론이 도입되어도 조직의 개발 문화와 맞지 않을 수 있다.

Q2. 개발자들에게 필요한 최신 기계나 CASE 도구(자동화 도구)를 도입하면 좋은 제품을 빠른 시일 내에 만들 수 있나?

A. 개발은 인간공학적 측면이 강하다. 따라서 좋은 도구나 기계가 사람을 대신하진 못한다. 가장 중요한 것은 기계나 도구를 사용하기 위한 공학적 관점과 기본 개념의 정립이다.

Q3. 요구분석은 생산적이지 못한 일인가?

A. 생각하고 분석하는 단계는 반드시 필요하다. 이게 없으면 개발을 체계적으로 하지 못한다.

Q4. 공정이 지연될 경우 인력을 더 투입하면 해결되는가?

A. 소프트웨어 개발은 중간에 인력이 늘어나면 새로온 사람들을 교육 시켜야하므로 시간이 더 소요된다.

Q5. 목표를 대략적으로만 정해도 되는가?

A. 보통 제안서를 포함한 계약서에 의해 프로젝트가 시작된다. 여기엔 대략적인 목표만 기술되어있고, 요구사항을 분석하는건 사용자가 아닌 개발팀의 임무이다.

 

- 고객

Q. 사용자의 요구사항은 계속 변하는 것이며 소프트웨어는 유연성이 있어 쉽게 변경할 수 있는가?

A. 소프트웨어가 유연성이 있는건 맞지만 이걸 남용하면 안 된다. 요구사항은 변할 수 있지만 변경요구를 언제 하냐에 따라 프로젝트에 큰 영향을 미친다. 구체적인 요구사항을 초기에 끌어낼 수록 시스템 수정은 최소화되고 좋은 품질의 시스템이 만들어진다.

 

- 엔지니어 ( 보통 과거의 경험에 의지하여 프로그램을 작성함)

Q1. 일단 프로그램이 만들어지고 작동하기만하면 엔지니어의 역할은 끝나는가?

A. 사용자에게 배달되어 사용되어야하는 것까지 봐야한다. 또한 시스템이 배달되고 사용되는것은 새로운 임무의 시작이다. 기술의 효용이 오래가도록 설계하고 확장성이 용이한지 자문한다.(프로와 아마추어의 차이)

Q2. 시스템을 작동하기 전까지는 품질을 평가할 수 없는가?

A. 품질은 마지막 테스팅에 의해 얻어지는 것이 아니다. 각 공정 과정마다 공식 기술 검토회를 거치는게 바람직하다. 가장 중요한 것은 요구사항 명세서에 대한 것. 품질 보증과 향상은 책임의 소재가 명확할 때 얻어진다.

Q3. 프로젝트의 결과는 작동하는 프로그램뿐인가?

A. 프로그램은 프로젝트 결과물 중 하나다. 개발 단계마다 나오는 문서는 중요한 결과물이다. 문서는 다음 단계를 성공적으로 끝내기 위해 필요하며 유지보수를 하려면 필수적이다.