#title 소프트웨어 공학의 영역
[[TableOfContents]]

소프트웨어 공학은 __클라이언트의 니즈를 만족__시키는 __결함이 없는__ 소프트웨어를 __주어진 예산 범위내에서__, 그리고 __시간에 맞추어 생산__하는 것을 목적으로하는 학문 분야이다. (__사용자의 니즈가 변경되었을 때에 쉽게 수정될 수 있어야__ 한다. ) 소프트웨어 공학은 폭넓은 학문이므로 다섯 가지 측면에서 살펴본다. 

==== 역사적인 측면 ====
280,000개의 프로젝트 중 2,000개만 완료된 것으로 보고됨. (1/4은 성공, 3/4는 실패)

||28%||성공적||
||23%||취소||
||49%||예산초과, 늦게 완료, 불완전(기능이 완전하지 못함)||
{{{* 2001년}}}

Cutter Consortium(2002)이 수행한 조사에 의하면,
 * 정보기술 조직의 78%가 법원에 피소 or 소송이 계류 중이라는 사실.
 * 이들 경우 67%는 인도된 소프트웨어 프로덕트들의 기능성이나 성능이 소프트웨어 개발자들의 주장과 일치하지 않는다는 사실.
 * 이들 경우 56%는 계야된 인도 날짜를 몇 배 지연시켰다는 사실
 * 이들 경우 45%는 결함들이 너무 심각하여 소프트웨어 프로덕트를 사용할 수 없다는 사실

소프트웨어 위기가 알려진지 35년이 지났지만 여전히 우리 앞에 존재하는 문제이며 두 가지 사실을 알려준다. 
 * 소프트웨어 프로덕션 프로세스는 많은 점에서 기존의 공학을 닮았지만 자신만의 고유한 특성과 문제점을 갖는다. 
 * 소프트웨어 위기가 오래 지속되고 있고 또 나쁜 전망으로 인해 소프트웨어 기능저하(Software depression)라고 개명되어야 한다는 점.

==== 경제적인 측면 ====
||현재 코딩기법 CT,,old,,를 사용하고 있는 소프트웨어 조직이 CT,,old,,로 코드를 작성할 때 보다 시간은 단지 9/10 정도만 사용하고, 비용도 9/10 정도만 사용하는 새로운 코딩기법 CT,,new,,를 발견했다고 가정하자. 일반적으로 CT,,new,,가 적합한 기법이라고 생각한다. 그래서 일반적인 기준으로 보면 빠른 기법을 선택하는 것이 당연하지만 소프트웨어 공학의 경제학적인 측면에서 보면 그 반대가 될 수 있다.||

 * 비용측면
  * 담당 조직에  새로운 기술을 도입하는데 소요되는 비용(새로운 CT,,new,,기법 교육에 드는 비용을 회수하려면 적어도 2~3개의 프로젝트를 완료해야 한다.)
  * 개발자가 CT,,new,, 교육에 참석하는 동안 생산적인 일을 할 수 없다. 
  * 새로운 코딩 기법 CT,,new,,에 익숙해지려면 여러 달 동안 CT,,new,,를 연습해야 한다. (아주 터무니없는 학습 곡선)
 * 유지보수 측면
  * CT,,new,,의 사용은 유지보수하기가 어려운 코드로 작성될 수가 있어 프로덕트의 전체 생명주기에 CT,,new,,의 비용이 더 많이 소요될 수 있다. (물론 인도 후 유지보수를 책임지지 않는다면 해당사항 없다)

소프트웨어 공학에 경제 원칙을 적용시키는 것은 클라이언트가 __장기적인 비용을 절감__시키는 기법을 선택하도록 요구 한다. 

==== 유지보수 측면 ====
'''고전적 프로덕트의 인도 후 유지보수'''
 * 수정적 유지보수(Corrective Maintenance): 내재된 결함들을 제거
 * 기능향상(Enhancement)
  * 완전적 유지보수(Perfective Maintenance): 응답시간 감소와 같은 프로덕트의 효율성 개선작업
  * 적응적 유지보수(Adaptive Maintenace): 변경된 운영환경을 적응시키기 위한 변경 작업

'''고전적 개발-유지보수 모델은 오늘날 비현실적''''
 * 개발 중 요구사항이 변경되면 변경된 요구사항을 반영하기 위해 명세문서를 변경해야 한다. 만약 설계가 다 끝난 시점이라면 완료된 설계부분도 수정되어야 한다. 개발자들은 프로덕트가 설치가 되기도 전에 "유지보수"를 수행한다. 
 * 소프트웨어 재사용은 이제 일반화된 방법이다. 그러므로 개발-유지보수 모델은 부적합하다. 

'''유지보수의 정의'''
소프트웨어가 문제점이나 개선 또는 적응에 대한 필요 때문에 코드와 연관된 문서에 수정을 가할 때 발생하는 프로세스(ISO/IEC 12207, 1995)

'''현대적 유지보수'''
현대적 유지보수(Modern Maintenance) 또는 단순 유지보수라는 정의는 언제나 수행되는 수정적, 완전적, 적응적 활동들이다.

==== 인도 후 유지보수의 중요성 ====
||기간||개발비용||유지보수비용||
||1976년~1981년||33%||67%||
||1992년~1998년||25%||75%||

약 30년 전에도 전체 소프트웨어 비용의 약 2/3는 인도 후 유지보수에 소요되는 것을 보여준다. 보다 새로운 데이터는 보다 많은 부분이 인도 후 유지보수에 투여된다는 사실을 보여준다. 인도 후 유지보수는 매우 중요하기 때문에 소프트웨어 공학의 주요 측면은 인도 후 유지보수 비용을 절감시켜주는 기법, 툴, 실무들로 구성된다. 

참고: [http://www.ciobiz.co.kr/news/articleView.html?idxno=4902 "IT비용 70% 넘는 운영비 줄여 혁신에 투자를"] 기사에 따르면 아직도 유지보수 비용이 70%다. 
==== 요구사항, 분석, 설계 측면 ====
결함에 대한 수정비용은 개발 초기 단계일수록 적게 든다. 개발 후기 단계일수록 결함을 수정하는 데 필요한 비용이 가파르게 상승하는데, 그 이유는 결함 수정시 수행하는 일과 관련이 있다. 예를 들어, 

 * 초기단계: 프로덕트를 문서상으로만 존재하기 때문에 문서만 수정하면 된다. 
 * 유지보수: 문서와 개발된 프로덕트까지 수정(재교육등 많은 비용 발생)

그러므로 우리는 반드시 결함을 빠른 시간내에 발견해야 한다. 그렇지 않으면 비용이 많이 든다. 그러므로 우리는 요구사항과 분석(명세) 페이즈동안 겸함들을 발견하는 기법을 가지고 있어야 한다. 또한 연구 결과에 의하면(Boehm, 1979), 대규모 프로젝트들에서 발견된 결함의 약 60~70%가 요구사항, 분석, 설계 결함들이었다. 

==== 팀 개발 측면 ====
큰 프로젝트의 경우 팀을 이루어야 한다. 예를 들어, 어떤 프로덕트가 18개월 내에 인도되어야 하는데 한 명의 프로그래머가 15년간 개발해야 된다면 반드시 팀을 구성해서 개발해야 한다. 하지만 팀 개발은 코드 컴포넌트들 간의 __인터페이스 문제__와 __팀 맴버들간의 커뮤니케이션 문제__를 야기 시킨다. 

 * Jeff의 모듈(A)은 Juliet의 모듈(B)를 호출한다. 인수는 5개지만 순서가 틀린다. 몇몇 소프트웨어 툴은 이러한 타입 위반(Type Violation)을 발견해 준다. 하지만 이러한 툴도 단지 사용되는 인수들의 타입이 다를 때만 가능하다. 만약 인수들이 같은 타입이라면 그 문제가 발견되는데는 오랜 시간이 걸린다. 
 * 어떤 프로덕트를 한 명의 개발자가 1년만에 완성했다고 가정하자. 만약 같은 작업에 세 명의 프로그래머들로 구성된 팀이 수행한다면 그 작업을 완성하는 데 소요되는 시간은 4개월이 아니라 1년에 가까운 시간이 걸리고, 그 결과로 생성되는 코드의 품질도 해당 작업을 한 명이 수행했을 때보다 좋지 않을 수가 있다. 

예를 들어, 10일 안에 딸기를 100kg을 따야 한다고 가정해 보자. 혼자서도 딸 수 있을 것 같아서 혼자따기 시작했다. 하지만 혼자서는 딸기를 하루에 1kg밖에 따지 못한다는 것을 5일 후에야 발견했다. 이제 5일 남았다. 그러면 95kg을 따기 위해서 95명을 더 투입하면 된다. 하지만 코끼리가 새끼를 낳는 일과 같은 경우는 이미 코끼리가 새끼를 밴상태에서 다른 코끼리를 투입하다고해서 정해진 시간내에 원하는 새끼(마리 수)를 얻을 수는 없다. 
==== 계획수립, 테스팅, 문서화 ====
고전적 페이즈에는 계획수립, 테스팅, 문서화가 없다. 이유는.. 생략.. 중요한 것은 __계획수립, 테스팅, 문서화 페이즈가 다른 활동들과 더불어 꼭 있어야 하는 활동들이라는 것!!__ 계획수립, 테스팅, 문서화는 고전적 페이지에서는 없고, 이 과정들은 프로젝트 전과정에서 시행된다. 

'''문서화의 이유'''
 * 소프트웨어 산업에서 담당자가 이직하는 경우가 많다. 
 * 이전 페이즈의 문서화를 완성하고, 수정하고, 최신의 건으로 갱신하지 않으면 해당 페이즈의 단계를 수행하는 것은 거의 불가능하다. 
 * 소프트웨어 프로덕트가 어떻게 수행되는지 설명한 무너를 이용할 수 없다면 소프트웨어 프로덕트가 정확하게 어떻게 작업을 하는지 테스트 할 수 없다. 
 * 프로덕트의 현재 버전이 무엇을 수행하는지 명확하게 서술해 놓은 완전하고 명확한 문서가 없다면 유지보수 자체가 불가능해진다. 

==== 객체지향 패러다임 ====