01. 시스템 공학과 소프트웨어

프로그램 vs 소프트웨어

소프트웨어는 금융, 노트북, 스마트폰, 의료, 항공기 등을 서비스하는데에 쓰인다.

그렇다면 프로그램과 소프트웨어의 차이는 무엇일까??

프로그램은 원시코드만으로 이루어져있다. 반면에 소프트웨어는 매우 포괄적인 개념이다. 원시코드뿐만 아니라 단계마다 생산되는 문서, 사용자 메뉴얼, 각종 산출물(자료구조, DB구조, 테스트 결과 등)으로 이루어져있기 때문이다.

 

 

 

 

소프트웨어의 특징

• 소프트웨어는 제조가 아닌 개발이다
  제조는 정해진 틀에 맞춰 일정하게 생산하는 것으로, 많은 인력이 필요하며 결과물 차이가 거의 없다.
• 소프트웨어는 소모되는 것이 아니라 품질이 저하되는 것이다
  하드웨어는 오래 사용하면 부품이 닳고 기능이 떨어지는 등 소모품에 해당하는데, 소프트웨어는 닳지 않고 기능도 동일하다.

 

 

 

H/W 실패 곡선 vs S/W 실패 곡선

• H/W 실패 곡선(욕조 곡선)
  초기 실패율 높음 → 오류 해결 → 오랜 기간동안 사용 → 주변 환경 문제 발생(먼지, 진동) → 다시 실패율 증가
  
  

• 이상적인 소프트웨어 실패 곡선
  개발 완료 후 변경사항(업데이트 X), 환경변화(PC 환경)가 없는 이상적인 환경이어야함.
  기능과 결과물이 일정함.
  발견되지 않은 오류로 초기 실패율이 높음 → 오류 해결 → 오랜 기간동안 사용

• 실제 소프트웨어 실패 곡선
  초기 실패율 높음 → 오류 해결 → 실패율 낮음 → 변경 발생(기능 추가 및 수정) → 변경으로 인한 부작용 → 실패율 급격히 증가 → <변경 발생 → 부작용 → 실패율 증가> 반복
  문제가 해결되지 않는다면 차라리 새로운 소프트웨어를 개발하는게 낫다.

 

 

 

 

소프트웨어의 문제

• 발전 속도가 느림
  H/W의 발전에 비하면 느리다.
• 새로운 소프트웨어에 대한 사용자의 요구 증가
  S/W가 H/W의 발전을 못따라간다.
  H/W는 검정받은 부품을 조립하는 형식이지만 S/W는 처음부터 만들어야하므로(오류가 많고 완성체가 되려면 오래걸림) 차이가 생길 수밖에 없다.
• 관리 기술의 부분적 활용
  기계는 닦고 조이는 등의 수리를 하면 수명이 연장된다.
  S/W 개발도 이와 같은 적극적인 프로젝트 관리가 필요하다.(비용, 일정, 개발자 관리)

 

 

 

소프트웨어 개발이 어려운 이유

• 개발 과정이 복잡함
• 참여 인력이 많음 (의사 결정 오래걸림, 협력 어려움)
• 개발 기간이 긺 (일정, 비용 관리 어려움)

 

 

 

자연과학 vs 공학

자연과학은 자연의 법칙을 탐구하는 것이고, 공학은 자연과학이 발견한 자연의 법칙을 응용하여 인류의 편익을 위해 무언가를 만드는 전문분야이다. 공학은 한정된 기간과 비용의 제약을 받는다.

 

 

 

시스템 공학 vs 소프트웨어 공학

시스템은 어떤 목적과 기능을 수행하기 위하여 유기적인 관계를 맺으며 함께 작용하는 요소들의 집합을 말한다. 필요한 기능을 실현시키기 위해 관련 요소를 법칙에 따라 조합한 것이다.

ex) 사람 / 내장기관들이 유기적으로 동작하고 함께 작용하여 사람이라는 시스템이 만들어짐.

 

시스템 공학은 시스템의 개발과 운영, 유지보수를 합리적으로 행하기 위한 사고방법, 절차, 조직 및 기법을 총칭한 것을 말한다. 기술적 측면+관리적 측면으로 방법론을 만들어내는 것이다.

ex) 건축 공학 / 설계회사, 시공회사, 감리회사, 사용자(사용 및 유지보수) 등 역할이 분리되어있다.

 

소프트웨어 공학

품질 좋은 소프트웨어를 경제적으로 개발하기 위해 계획을 세우고, 개발하고, 유지 및 관리하는 전 과정에서 공학, 과학 및 수학적 원리와 방법을 적용하여 필요한 이론과 기술 및 도구들에 관해 연구하는 학문이다. 소프트웨어공학이라고 불리는 범위가 매우 넓다.

개발 과정에서 최소의 비용으로 주어진 기간 안에 개발하여 생산성을 향상시키고, 고품질의 소프트웨어를 생산하여 사용자 만족도를 올리는걸 목표로 한다.

단계적 프로세스, 품질 보증, 프로젝트 관리가 활발하게 될 수 있도록 소프트웨어를 개발해야한다.

대형 소프트웨어 개발을 다룬다.(개발 시간이 길지만 오래 사용)

 

 

 

소프트웨어 개발 과정

1. 프로젝트 계획
   프로젝트 관리에서 가장 중요하게 여겨지는 과정으로, 프로젝트 실행과 통제의 지침이 된다.
   이 단계의 결과물은 계획과 문서이다. 고객이 제안요청서를 쓰고 개발회사가 제안서를 작성한다.
   제안서는 개발 계획서의 일부이며, 문제 해결의 답을 제시하는게 아닌 시스템의 필요 사항을 명시해둔 것이다. 이것은 문제 이해의 시작점이자 공식적인 계약이 된다.
   제안 → 승인 → 계획 
2. 요구사항 분석(기간, 비용까지 고려)
   무엇을 어떻게 할건지 분석하는 과정이다. 이때 어떻게 그 기능을 수행할건지에 대한 고민은 하지 않는다.(기술자들의 몫)
   ex) 파리를 잡는 시스템 / 무엇을? 파리잡는 기능 / 어떻게? 파리채로
   요구사항 규명, 타당성 조사, 비용과 일정에 대한 제약 설정, 요구사항 정의 문서화(요구사항 명세서)를 하는 과정이다.
3. 설계
   설계 원리: 분할과 정복, 추상화, 단계적 분해, 모듈화, 정보은닉
   응집도와 결합도로 모듈을 평가한다.
   
4. 구현
   표준 코딩 규칙을 지켜야한다.
5. 시험
   목적, 사용자, 품질 특성, 개발 단계에 따라 분류한다. 
6. 유지보수
   수정, 적응, 기능보강, 예방 등의 유지보수가 있다.

 

계획 → 요구사항 분석 단계에서 알아두어야할 것

• 프로젝트를 계획 및 계약할때 제안서에 추상적인 시스템의 목적을 기록해둔다.
• 제안서에는 구체적인 요구사항이 모두 들어가기 어렵고 완벽하지 않다.
• 제안서는 시스템 개발 과정에서 헌법에 해당한다고 볼 수 있다.
• 제안서를 통해 공식적인 계약이 이루어진다.
• 이때 개발 비용, 기간이 계약서에 명시되어야한다.
• 제안서는 요구사항 분석을 위한 초기 단계의 문서이다.
• 제안서만 가지고 시스템을 시험하지 못한다.
• 대부분의 제안서는 검증할 수 있을 정도로 구체적이지 않다.
• 따라서 시스템의 요구사항을 검증할 수 있는 구체적인 법률이 필요한데, 이를 시스템의 요구사항 명세서라고 한다.

 

실제 소프트웨어 개발이 이루어지는 과정 및 주의사항

• 제안서에 의해 계약이 이루어지면 구체적인 목표 없이 그대로 개발을 시작한다. (이렇게 하면 실패 가능성이 높으므로 계획서를 작성하여 구체적인 목표를 세우고 요구사항 분석단계에 들어가야함)
• 설계와 프로그래밍을 하는 과정에서 새로운 요구사항이 나타나면 요구사항을 수정한다.
• 위와 같은 경우, 어디가 잘못되었는지 구분하기 위한 기준이 없으므로 고품질의 제품이 생산되기 어렵다. 또한 개발이 지연되고 예산이 초과되는 등의 문제가 생긴다. 따라서, 요구사항을 점검하는 과정이 반드시 필요하다. 요구사항 명세서는 품질을 측정하는 기초가 되는 동시에 소프트웨어 공학이 추구하는 고품질 소프트웨어를 만든다는 단일 목표에 접근하게 해준다.
• 사용자의 관점과 엔지니어의 관점이 섞여있으면 프로젝트 관리도 어렵고 좋은 품질의 제품도 만들 수 없다. 따라서 관점을 분리해야한다.
• 프로그래머가 아닌 소프트웨어 엔지니어가 되어야한다. 프로그래머는 단순히 구현을 잘하는 사람이고 소프트웨어 엔지니어는 개발의 모든 과정을 이해하고 수행한다. 프로그래머가 소프트웨어 공학을 배우면 엔지니어가 될 수 있다.

 

'모든 것은 두번 창조된다'

첫째는 마음속에서 창조(무엇을?)하는 것이고, 두번째는 실제적으로 만드는 것(어떻게?)이다.

첫번째 창조의 결과는 사용자 관점에서 시스템의 모습을 논리적으로 나타낸 것이며(논리적 모델) 응용분야의 용어로 기술되어야한다.

두번째 창조의 결과는 엔지니어의 관점에서 소프트웨어의 모습을 물리적으로 나타낸 것(물리적 모델)이며, 소프트웨어 용어로 기술될 수 있다.