용's
[Chap 1] Introduction to Software Engineering 본문
[Chap 1] Introduction to Software Engineering
TaeYOng's 2014. 10. 17. 01:051. 소프트웨어 중심 사회
- 스마트폰이 일상의 필수가 되면서, 우리 일상을 변화 시킴.
- 그 중심에는 애플이라는 기업이 있는데, 이 애플은 모바일폰의 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 |