1. Introduction(1)

What is Software?
Software란 Item 또는 Object의 집합이다. 다시 말하자면, Program, 문서, 자료등이 포함된 것이라고 할 수 있다.

How to produce Software?
- 고객들의 요구들, 코딩, 디버깅등. 그외에 무엇이 있을까?

Business Implication of Software?
- 사실상 현시대의 모든 Business는 S/W의 능력에 의존하고 있다.

왼쪽의 그림을 보도록하자. Business적으로 아무리 좋은 Item과 Idea를 가지고 Business를 시작하였다고 하여도, 그 Business를 뒷받침 해주는 S/W가 늦게 개발된다면, Business를 실질적으로 사용하기위해서 S/W를 기다리는 기간동안에  Risk가 생기게된다. 예를들자면, 보험회사가 인터넷을 기반으로 하는 아주 좋은 Business Item을 개발하였다고 하자. 그래서 모든 준비가 끝나 Open을 하면 되는데,
S/W가 개발이 되지 않았다면, S/W가 개발될 때 까지의 시간이 곧 비용이 낭비되기 때문이다.

오른쪽의 그림을 보면 S/W가 Business를 앞지르고 있다. 즉, S/W가 먼저 개발이 된다면 사업적으로 보다 낳은 Item을 생각 해 볼 수 있는 그런 기회가 생긴다는 것이다.

Software Crisis

S/W가 개발이 되면 그냥 배포하거나, 개발 후에 약간의 수정을 거친경우와 배포는 하였으나 완벽하게 사용할 수 없는 상품등등 과거 SE를 적용하기 전의 개발된 상품들이다. 과거에 얼마나 무분별하게 S/W가 개발되 배포되었는지 알 수 있다.

Why Softwre Project Fail?
- S/W Engineering Mind가 부족하였고, S/W Project 관리가 충분하지 않았으며 SE 기술 사용능력이 충분하지가 않았다.
 결국 다시 말하자면 S/W 개발자로서 장인 정신이 부족하였으며, 자원들을 관리하지 않고, 도구를 사용할 줄 몰랐다라고 생각하면 될것이다.

Why is Software Development so Difficult?
- 의사소통, 순차적인 System의 특징, 개발, Project의 특징, Team Member들의 개성, 관리 성과등 여러 요인들이 있다.

 고객과 개발자들간의 의사소통이 원할 하지 않다면?, 개발자들간의 의사소통이 원할하지 않다면? Project는 전혀 고객의 요구와는 다르게 엉뚱한 방향으로 흘러 갈것이다.
 우리가 흔히 사용하는 system같은 경우 병렬처리가 되지 않기 때문에 한단계씩 밟아 가면서 Project를 진행해야 한다. 고객들의 요구사항을 받아들여서 실현이 가능한지 판단하고, 실현이 가능하다면 요구사항을 분석하고, 설계하고, Testing을 해야하기 때문이다. 즉 요구사항 분석이 잘못된다면, 그 영향이 다음 단계에 미치기 때문이다.

그리고 Project가 우리가 늘 접하는 분야가 아닌 다른 분야라면 요구사항 수집 부터 힘들것이다. Project를 진행하는 동안 Team member들 간에 의견충돌이 일어날 수 도있다.

전체적으로 Project 관리가 소홀하다면, 고객이 요구하는 시기에 배포할 수 없게 된다. 시간은 곧 돈이다. 관리에 필요한 문서들이 존재하며 또 Project가 배포된 뒤에 유지보수를 위해서 그에 따른 문서가 필요하기 때문이다.(코딩보다, 문서작업에 더 많은 시간이 소요된다 ㅜㅜ)

Software Myths
manager -
우리는 S/W를 개발하기 위한 Standars와 Procedure가 있다. 그러므로 개발자들은 그것들을 알 필요가 있다.
우리는 최신의 개발 도구를 가지고 있다.
만일 우리가 계획된 일정보다 늦어진다면, 보다 많은 Programmer들을 데려 오면된다.
좋은 Manager는 어떤 Project도 관리할 수 있다.

여기서 Manager들의 편견과 아집들을 볼 수 있다.(너무 확대해석했나 ㅡ.ㅡ;)
관리자들은 모든 정보들을 수집해서 가지고 있으니 개발자들을 그것에 대해서 다 알고 있어야 한다는 것은, 역할 분담을 하지 않고 모두다 시키겠다는 생각이다.(맞는지 모르겠다. 틀렸다면 즉시 지적을!)
그리고 최신 개발 도구가 모든것을 해결해 주지는 않는다. 즉 최신 개발도구는 Programmer들이 좀더 편히 작업할 수 있도록 해주는것 뿐이다.(내가 아는 사람은 메모장으로 코딩하고 컴파일러도 따로 가지고 있더라.)
일정에 맞출 수 없다고 인력을 늘린다고 맞출 수 있는게 아니다. Project 중간에 데려온 사람은 Project의 전반적인 이해도가 떨어지기 때문이다.
좋은 관리자는 어떠한 project도 할 수 있다라는 오만한 자신감.!

Client's
목적의 일반적인 설명은 Program 작성을 시작하기에 충분하다. - 나중에 자세히 설명할 수 있다.
요구사항 변경은 받아들이기가 쉽다. 왜냐하면 S/W는 Flexible하니까!!

이런 고객이 있다면 우리 개발진들은 정말 짜증이 나겠다-_- 얼마나 얄미울까. 지 멋대로인, 상관보다 더 열받는다능. ㅋㅋ

Practitioners
일단 Program을 작성하고 실행시키기만 하면 우리의 일은 끝난다.
Program의 작동까지 Quality를 평가할 수 있는 방법은 없다.
S/W Project를 배포한다는것은 오직 Program을 작동시킨다는 것이다.

허어... 이런 날로 먹을 녀석들 ㅡㅡ; S/W의 최종 배포판이 나와서 배포를 한후 유지보수가 가장 힘든
일이거늘...... Quality를 평가 할 수 있는 방법은 얼마든지 있거늘... 있나? ㅡ.ㅡ;;;;

오타 및 제가 잘못 이해하고 있는 부분이 있다면 지적해 주십시오.
감사합니다^^