1. Introduction(2)

Costs of Software Development

위에 그림은 S/W 각각의 개발 단계에 소모되는 비용의 양이다. 개발 예산이 100을 잡혔을때, 분석과 설계에 전체의 40%, 테스팅에 40%, 코딩에 20% 들어 간다. 여기서 생각해 볼 수 있는것은, 보통 S/W 개발 기업이 코딩 부분을 아웃소싱을 하게 된다. 즉 자국내 중소 기업에다가 하는 경우도 있지만 보통 인도나 중국 같이 보다 저렴한 비용으로 하청을 둘 수 있는 곳으로 한다. 허나.. 이것이 맹점인줄 누가 알았으랴. 자세한건.. 조엘 블로그인가? 아니면 다른거였는지.. 기억이 나질 않지만 조엘블로그를 쓴 저자의 책에서 읽어본것 같다. 아웃소싱의 위험도라는것을.

Development vs. Maintenance

 둥근 원을 어떠한 System이라고 봤을때, 그 시스템을 개발하는 것과 유지보수하는 것 두 가지로 표현한 그림이다. 여기서 확실히 알 수 있는것은 개발 보다 유지보수가 훨씬 많은 부분이 할당 되있다고 볼 수 있다. 우리 엔지니어들과 기업들은 S/W를 배포함과 동시에 끝나는 것이 아니라, 지속적으로 유지보수를 해줘야 하는것이다. 옛 기억을 떠올려 봤을때, SoftMax와 손노리는 배포시 상당한 버그를 포함하고 있었지만 재빨리 버그수정 패치를 내놓았던 기억을 해본다. 그래도 욕먹는건 마찬가지 이지만.. 여담이지만 게임피아에서 소맥(softmax) 개발이사가 했던 이야기가 생각나서 긁적여 본다. "현재 우리나라으 개발 수준은 외국기업의 10년 전 수준입니다. 저희는 그 수준을 좁히기 위해서 2년 개발할 것을 1년안에 개발하기 때문에 많은 버그를 포함하고 있습니다. 유저들의 마음을 모르는 것은 아니지만 저희가 이렇게 해야만 외국의 수준을 1년씩 따라 갈 수 있기 때문입니다."

Sources of Errors in Software Developments

위에 그림은 S/W 개발 절차 단계들 마다 발생되는 Error의 분포를 나타낸 것이다. 가장 큰 순서로 나타내자면, 문서와 그외에에서 35%로 가장 많은 오류를 발생한다. 두 번째로는 코딩이며, 세번째는 설계단계에서의 이해도 미숙으로 발생되는 오류, 마지막으로 기능분류시 이해도 미숙으로 오류이다. 여기서 궁금한것은 문서와 그외 것들이다. 우리는 보통 문서라는 것을 무시하는 경향이 있다. 하지만 나중에 refactoring을 하기 위해선 문서화는 필수있다. 우리가 어떻게 설계했는지, 구현된 코딩들의 모듈들이 어떠한 기능을 내포하고 있는지, 객체지향이라면 메시지 전달 흐름은 어떻게 되는지, 구조적이라면 어떠한 흐름으로 모듈을 호출하는지 등을 기록해 둬야 나중에 업데이트할때나, 따로 떼어내서 다시 사용할 수 있도록 해준다. 도와주는 것이 아니다. 이것으 필수이다.

Failure Curve

위의 두 그림이 있다. 위의 그림은 H/W의 오류발생 곡선이고 아래 그림은 S/W 오류발생 곡선이다.
H/W 곡선과 S/W곡선에는 많은 차이가 있다. 둘다 초기에 배포될 시에는 비슷하다. H/W는 시간이 흐를수록 오류발생빈도가 높아지는데 그 이유는 역시 노후화(낡았다)되었기 때문이다. 하지만 노후화 되기 전까지는  낮은 오류를 유지한다. 그리고 S/W 같은 경우 change가 발생할 경우 급격히 오류빈도가 증가한다. 여기서 change는 client의 요구사항 변경이거나, 설계시 구조나 객체의 잘못된 선택, 또는 일정 수정등 System을 개발할때 발생되는 모든 변경들이다. 여기서 알 수 있는것은 H/W는 배포가 되면 일정 수준의 오류빈도를 발생시킨다. 즉 이것은 오류를 다 잡아내고 99% 가까운 완성품을 출시 한다는 것이다. 하지만 S/W같은 경우 99% 완성품을 목표로 한다지만, 현실적으로 그러진 않다. 예시를 들며 이야기를 해주고 싶지만, 짬이 짬인지라;;;

Software Characteristics

S/W는 H/W와 어떻게 다를까?(한번쯤 생각해보자)

S/W는 개발되거나, engineer 된 것이다. 즉, S/W는 제작되는 것이 아니다.
 - 개발 절차에 초점을 맞춰라
 - 사람들에 의해 활동되는것에 초점을 맞춰라

대부분 S/W는 주문대로 만드는것이다. 다시 말하자면 현존하는 component들로 합쳐진 것이다.
 cf) S/W factory : 도구들의 자동완성기능

Software Applications
System S/W
Real-time S/W
Business S/W
Engineering / scientific S/W
Embedded S/W
PC S/W
AI S/W
Web-based S/W

Programming Paradigm Evolution

PL이 개혁을 일으킨 세대별로 나타낸 그림이다. 맨처음 어셈블리가 나오고 절차지향 언어가 나왔으며 객체지향이 대두되었고 현재 Component 기반의 언어들이 나오기 시작하였다. PL의 진화적 목표는 생산성과 Quality 향상을 꾀하는 것이다.

Emerging Software Technology & Trends
Service 지향 구조
S/W를 하나의 Service처럼
Software On-Demand(네트워크를 통해 필요한 정보를 제공하는 방식)
소스를 파는 market
Energy와 친환경 S/W
국외 Outsourcing

What is software Engineering
"The application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software"(IEEE, 1991)
Systematic, disciplined, quantifiable 같은 S/W의 운영과 유지보수 개발 접근 방법이다.

What you do when you have two or more people working on a project(Inst, for Information Technology, NRC Canada, 1997)
당신이 Project에서 두명 또는 여러 사람과 무엇인가 하는것.

What Software Engineers do(Industri-Matematik International, 1997)
S/W Engineer들이 하는것.

Forces Behind the Emergence of S/W Engineering
S/W 개발의 비용과 시간, 노력을 예측하는 경영진의 무능력.
S/W 싸구려 Quality
H/W와 S/W 비용의 비율 변화
유지보수의 역할의 중요성의 증대
H/W의 발달
S/W 기술의 발달
증가되는 S/W의 수요
수요는 커지고 S/W System은 보다 복잡해져간다.

Goal of Software engieering
1. 사용자들의 요구들을 정해진 예산안에서 정해진 날짜안에 S/W quality를 생산한다.
2. S/W의 생산성과 quality를 향상시킨다.
3. System, 제품의 생산성과 quality를 향상시킨다.
4. Business 능력을 향상시킨다.

Summary and Discussion
S/W Engineering의 정의
 - Systematic, disciplined, quantifiable
 - Development, operation and mintenance
Goals of Software Engineering
 - Quality improvement

Explain the PROCESS of software development?
What is the engineering ACTIVITIES in the software development process?