용's

[Chap 1] Introduction to Software Engineering 본문

Computer Science/Software Engineering

[Chap 1] Introduction to Software Engineering

TaeYOng's 2014. 10. 17. 01:05

1. 소프트웨어 중심 사회

- 스마트폰이 일상의 필수가 되면서, 우리 일상을 변화 시킴.

- 그 중심에는 애플이라는 기업이 있는데, 이 애플은 모바일폰의 10% 생산, 40% 매출, 70% 이익을 가지고 있는 기업

=> 이런 애플(Apple)이 성공할 수 있었던 요인은? 

-> 컴퓨터 회사로서 SW 능력 보유

-> 모마일 폰을 컴퓨터로 해석

-> 플랫폼 비지니스를 이해(AppStore를 통한 외부 개발자를 활용 또는 iTunes같은 Apple 통합 컨텐츠 제공)

- 소프트웨어 능력으로 경쟁의 법칙을 바꾸고 기존 시장 질서를 파괴하며 시장을 석권

=> 이는 소프트웨어 혁명을 일으킴

- 스프트웨어 혁명을 통해 변해가고 있는 산업들이 많음

예) 자동차 산업, 항공 산업, 영화 산업, 금융, 빅데이터, 유통 산업(아마존)

=> 이러한 소프트웨어의 혁명은 소프트웨어가 모든 산업의 기반 기술이 된다는 것을 보임.


2. 소프트웨어 공학

- 1967년 NATO 단체에서 Software Engineering 이라는 단어가 나옴. 당시 크고 복잡한 프로그램들을 만드는데 있어 큰 어려움을 겪던 시기라, 이런 소프트웨어 위기(Software Crisis)를 해결하기 위해 Software Engineering이 사용되어야 한다고 결론

- 당시는 소프트웨어 개발에 있어 요구되는 비용, 노력, 시간을 예측하기 어려웠으며, 그 소프트웨어의 질(Quality)도 좋지 못함. 또한 유지보수(Maintenance)의 역할을 중요해지고 있었으며, 더 크고 더 복잡한 소프트웨어의 수요는 점차 증가하고 있었으나, 하드웨어가 더 중요했던 시기. 


2-1. Software Crisis(소프트웨어 위기)

- 높은 비용, 늦은 보급, 부족한 성능, 불안정성, Backlog(밀린 작업), 매우 높은 유지보스 비용 또는 불가능한 유지보수

=> 소프트웨어 위기(Software Crisis)를 가져옴


예) DoD(미국 국방부)의 1980년도 소프트웨어 프로젝트들을 보면, 

약 45%는 완벽히 성공하지 않았지만 보급

 30%는 돈은 지급됬지만, 보급되지 않음


- 대규모 프로젝트가 어려운 이유는 3가지 큰 이유가 있음

=> 수백명의 개발자: 의사소통 및 상호 협력의 어려움, 조직 및 팀 구조

=> 오랜 개발 시간: 프로젝트 관리의 어려움, 비용 및 효과의 산정

=> 모호하고 복잡한 요구사항: 수백 페이지의 요구사항, 빈번한 요구사항의 변화


2-2. 소프트웨어 공학의 목표 및 중요성

- 목표

=> 소프트웨어 시스템의 좋은 질(Quality)을 위해

=> 낮은 예산으로 비용을 효율적으로 사용하기 위해

=>사용자의 요구를 제때 만족시키기 위해

-중요성

=> 최근 시스템의 비용은 Software의 비용에 의해 결정되므로, 우리는 이 소프트웨어 개발의 비용을 최소화

=> 최근엔 유지보수의 비용이 개발의 비용보다 더 크게 든다. 따라서 이 소프트웨어 공학을 통해 우린 유지보수 비를 최소화 할 수 있어야 겠다.


2-3. 소프트웨어 공학의 특징

- 소프트웨어는 프로그램 + 다큐먼트(문서) + 데이터 들을 포함한 Configuration 형태들의 집합이라 볼 수 있음.

- 소프트웨어는 개발 또는 공학되어(engineered)지지, 제작(manufactured)되지 않음.

- 많은 소프트웨어들은 custom built(주문 제작 형식) 임.

- 소프트웨어는 닳지 않음.   

=> 하드웨어는 시간이 지남에 따라 닳음(Failure rate가 높아짐)

=> 반면, 소프트웨어는 이상적이라면 닳지 않지만 계속해서 새로운 기능이 생겨남으로써 failure rate가 높아질 수도 있음

- 문서화 작업이 정말 중요한 요소로 작용. 


2-4. 소프트웨어 개발이 어려운 이유

- 이는 곧 소프트웨어 특징과 연결된다. 

=> 소프트웨어는 눈에 보이지 않음(invisibility)

=> 내재된 복잡성이 줄어들지 않음(complexity)

=> Mostly one-off systems(conformity)

=> 완성되었다고 하더라도 계속해서 진화함(changeability)

- 위의 것들 외에도, 역사가 짧고, 또 완전 자동화가 되어있지 않다는 점, 등등

- 테스팅의 어려움도 있음

=> 테스트하는 테스터의 능력에 따라 소프트웨어가 달라짐. 


3. 소프트웨어 개발의 비용들

- 70년대, Testing(40%) / Analysis & Design(40%) / Coding(20%) 로서 Testing의 비율이 높은 것이 특징임.

- 시대별 소프트웨어 개발에 있어 중요시 여기던 비중은 다음과 같다.

연도 

요구사항 분석 

 1차 설계

디테일한 설계 

코딩 & Unit Testing

 통합 testing

시스템 testing 

 1960s - 1970s

 10%

 80%

10% 

 1980s

20% 

60% 

20% 

 1990s

40% 

30% 

30% 

=> 1980년대에는 소프트웨어 공학의 중요성이 대두하기 시작하지만, 여전이 Coding의 비율이 높음

=> 1990년대에는 분석과 설계 부분의 비중이 월등히 높음. 그에 일조한 것이 Coding에서 많은 부분을 Tool이 도움


- 소프트웨어의 유지보수 비용은 일반적으로 개발 비용의 두배이다!

=> 이것은 소프트웨어가 사용되는 기간이 개발 기간보다 길기 때문이라고 함

=> 따라서, 소프트웨어의 생산이 주 목적이 아니라 유지보수가 중요한 이슈가 되었음.


3-1. 소프트웨어 에러 비용(Cost to fix)

- 에러는 일찍 발견될수록 좋다.(개발의 단계가 점차 진행됨에 따라 에러 발견에 의한 비용은 급수적으로 커짐)

- 많은 에러들은 개발자들 보다 유저나 테스터들에 의해 더 잘 발견된다. 


4. 소프트웨어 응용분야

- 시스템 소프트웨어 (Operating System, Drivers, File Manager, etc)

- Real Time Software

=> 실제 세계에서 일어나는 일들을 모니터링과 분석, 제어하는 프로그램에서 자주 쓰이며, 시간제약에 엄격히 응답하는 소프트웨어(군 시스템에서 자주 쓰임)

- 비지니스 소프트웨어

- 공학과 과학분야의 소프트웨어(CAD, etc)

- 임베디드 소프트웨어


5. 소프트웨어공학의 기술 추세

- 1960년대 이전, 기계어로 구연된 SW탄생

- 1960~1980년, SW 생산성 양산(대형화된 프로젝트의 효율성 양상)

- 1980~2000년, SW 품질 개선(SW개발에 프로세스 기반의 관리 방법론 정립)

- 2000년대 이후, SW 가치 창출(SW의 서비스와 가치를 창출)



'Computer Science > Software Engineering' 카테고리의 다른 글

[Chap 6] Object-Oriented Concepts  (0) 2014.12.05
[Chap 5] Behavioral Modeling  (0) 2014.12.04
[Chap 4] Requirements Engineering  (0) 2014.10.22
[Chap 3] Software Process  (0) 2014.10.21
[Chap 2] Software Quality  (0) 2014.10.19
Comments