1. 소프트웨어 프로세스 정의
(*** 필자주석) 프로세스의 정의는 매우 중요한 주제이다. 잘못 이해함으로써 소프트웨어 회사에 막대한 피해를 끼칠 수 있다. 실제 국내 소프트웨어 회사에서 많은 비용과 시간을 낭비하는 것을 보아 왔다. 프로세스라는 용어는 매우 추상적인 단어이다. 이 정의는 아무리 잘 한다고 해도 역시 추상적이다. 결과적으로 모든 사람이 "프로세스" 라는 용어를 다르게 해석한다. 혹은 다르게 느낀다. 각자 자신이 경험한 범위 내에서만 이해가 가능하다. 경험하지 않은 것을 정확하게 이해할 수 있는 최고의 통찰력은 극히 소수의 사람만이 가지고 있는 역량이다. 여기 SWEBOK에서도 정확한 정의를 주기 위해 많은 노력을 한 흔적이 보인다. 하지만 글자가 현실을 설명할 수 있는 한계가 있다. 필자는 많은 개발 경험으로 프로세스라는 용어에 대한 거부감도 전혀 없고 1인 회사를 해도 프로세스를 적용한다. 반면에 잘못된 프로세스를 경험한 대부분의 국내 개발자들은 프로세스 혹은 더 나아가 소프트웨어 공학에 대한 느낌이 부정적으로 되었다. 이런 감정을 바꾸기에는 많은 시간이 필요할 것이다.
국내 대부분의 개발자들은 자수성가하거나 이론가들로부터 프로세스를 이론적으로 접하게 된다. 미국회사가 프로세스가 잘되어 있거나 소프트웨어 공학에서 중요하다고 하는 등 이런 저런 단편적인 사실을 잘못 이해하고 결과적으로 잘못된 프로세스를 경험하게 된다. 여기서 조심해야 할 것은 옳은 프로세스도 없지만 틀린 프로세스도 없다. 잘못된 프로세스는 잘못 적용된 프로세스이다. 즉 아무리 잘 만들어진 미국 국방부의 프로세스라고 해도 대부분의 회사에게는 나쁜 프로세스이다. 필자는 실리콘밸리의 2개 회사에서 거대한 프로세스를 경험했다. 그 프로세스가 그 회사들에는 적합하다고 생각하지만 나는 그런 회사에서 일하기를 선호하지는 않는다. 다행히도 실리콘밸리의 99% 회사와 국내 회사들은 그런 거대한 프로세스를 따라 할 필요가 없다. 그런데 이론적으로 접근하다 보면 자연적으로 거대한 프로세스가 만들어지기 쉽다. 그 것이 가장 그럴듯하게 보이기 때문이다. 그래서 필자가 말하기를 한국 소프트웨어에 독약으로 작용할 수 있는 것이 바로 프로세스이다. 적당히 사용한다는 것도 가장 추상적인 단어이기 때문에 구체적인 케이스는 불가능하다. 이런 경험의 영역이야 말로 진정한 소프트웨어 공학의 영역이며 건강식품과 같이 사기꾼들이 성행하는 분야이라는 것을 항상 주지하여야 한다.
이 주제는 소프트웨어 프로세스, 소프트웨어 프로세스 관리와 소프트웨어 프로세스 기반시스템과 관련되어 있다.
소프트웨어 프로세스는 입력되는 산출물을 다른 출력되는 산출물로 변형시키는 일련의 행위와 업무이다. 최소한도의 경우에도 필수 입력물, 변화시키는 행위, 생성되는 산출물이 있다. 약간 복잡해 지면 entry와 exit criteria, 그리고 행위(Activity)를 잘게 쪼갠 task 로 나눈다. Task는 관리의 대상이 되는 가장 작은 단위이다. 프로세스는 Event에 의해서 시작될 수도 있고 다른 프로세스의 Output이 이 프로세스의 Input이 될 수도 있다. 프로세스가 시작하기 위해서는 초기 전제조건(Input Criteria)이 만족되어야 한다. Output 산출물의 완수조건을 포함한 모든 조건이 만족되어야지만 프로세스가 완료되었다고 말할 수 있다.
프로세스는 하위프로세스(Sub-Process)를 포함하기도 한다. 예를 들면 Requirement Validation(검증)은 소프트웨어 개발을 시작하기 위해 충분한 정보가 있는지를 검증하는 프로세스인데 이는 Requirement Analysis의 하위 프로세스이다. Requirement Validation 프로세스의 Input은 Software Requirement Specification(SRS) 와 validation을 수행하기 위한 인력과 시간, Validation을 위해 사용할 도구이다. Requirement Validation 활동은 SRS의 검토, 프로토타이핑, 모델 검증 등을 포함할 수 있다. 이런 활동은 개인이나 팀 같이 행위의 주체에게 업무가 할당될 것이다. Validation 프로세스의 Output은 검증된 SRS이며 이런 SRS는 다음 프로세스인 설계와 테스트 단계에 사용된다.
(*** 필자주석) 마지막 문장 중에 눈치 채기는 어렵지만 매우 중요한 내용이 들어 있다. "검증된 SRS가 설계와 테스트 단계에 사용된다" 라는 말에서 보면 테스트 단계가 설계단계와 함께 진행된다는 것을 인식해야 한다. 나중에 테스트 chapter에서 부가적으로 설명하겠지만 V-Model에서 보면 가장 위쪽에 SRS와 같은 수준에 Acceptance Test Plan이 위치해 있다. 결론만 간단히 얘기하자면 SRS (1page건 1000page이건 어떤 형태가 되었던 상관없다)가 있으면 테스트계획과 테스트 케이스를 만들 수 있어야 한다. SRS가 부실하면 필연적으로 테스트도 부실해 진다. 여기서 인과의 법칙에 예외를 적용하는 실수를 하지 않기 바란다.
Requirement Analysis의 하위프로세스인 Requirement Validation이나 다른 하위 프로세스들은 흔히 겹치기도 하고 반복되기도 한다. 즉 하위 프로세스들은 입구와 출구를 드나들면서 몇 번 씩 되풀이 되기도 한다.
(*** 필자주석) 이 한 문장이 바로 Iterative 개발 방법론 또는 Agile 개발방법론과 같은 의미를 얘기한다. 실리콘밸리의 99%의 프로젝트는 Water Fall 방법론을 사용하지 않는다. 즉 완벽하게 SRS를 적고 한 번의 프로세스 만에 개발하려는 환상적인 생각은 용과 같이 거의 전설 속에서만 존재하는 것이다. 그런 면에서 혹시라도 미국 소프트웨어 회사는 거대한 프로세스를 사용하고 있다는 근거 없는 착각은 하지 말기 바란다. 가장 실용적인 방법으로 개발하고 있는 실리콘밸리가 상식적으로 Water Fall 방법론을 사용할 리가 없다. 실리콘밸리가 Agile 방법을 가장 잘하고 있는 것이다. 또 관련 주제가 나왔을 때 자세히 설명하겠지만 빨리 개발하겠다고 Agile 방법론이라는 이름으로 엉터리로 개발하는 것을 합리화하지 말기 바란다. "프로세스" 와 마찬가지로 "Agile 방법론", "Lean 개발"도 매우 조심해야 적용해야 할 단어이다.
소프트웨어 프로세스를 더 자세히 부연해서 설명하자면 IT 지원조직의 유무, 소프트웨어공학 기법과 도구, 업무 환경, 프로세스 수행의 효율성을 측정하기 위한 평가지수(KPI) 등과 같이 보조 역할과 역량까지도 포함된다. 더 나아가 여기저기 기술적 역량이 필요하기도 하고 다른 부서와 협력해야 하기도 하고 관리하기 위한 활동도 포함될 수 있다. 표기법은 자연어 텍스트의 형태로 설명한 활동들의 목록, Data Flow Diagram, State Charts, BPMN, IDEF0, Petri nets and UML activity 다이어그램 등으로 표현된다.
프로세스내의 변환(Transforming) 업무는 Checklist와 같이 순서적으로 정의된 Procedure의 집합으로 정의된다.
항상 강조해야 할 점은 "가장 좋은 프로세스"는 없다는 것이다. 소프트웨어 프로세스는 선택되어야 하고 조정되어야 하고 각 프로젝트와 조직의 목적에 맞게 적절히 응용되어야 한다. 이상적인 프로세스는 존재하지 않는다.
(*** 필자주석) 추상적이긴 하지만 위에서 열심히 정의해 놓고 여기 와서 이상적인 프로세스는 없고 적절히 사용해야 한다는 말을 한다. 결국 따라 해야 할 수 있는 구체적인 방법은 얘기하지 못한다. 그게 현실이고 본질이다. 결국 경험한 만큼만 이해한다는 지식의 저주와 비슷하다.
다음 포스트에서는 아래 1.1.과 1.2.를 적는다.
1.1 소프트웨어 프로세스 관리 (Management)
1.2 소프트웨어 프로세스 구조 (Infrastructure)
2. 소프트웨어 생명주기 (SW Life Cycles)
2.1 소프트웨어 프로세스의 분류 (Categories)
2.2 소프트웨어 생명주기 모델 (Life Cycle Models)
2.3 소프트웨어 프로세스 적용 (Adaptation)
2.4 현실적인 고려 (Practical Considerations)
3. 소프트웨어 프로세스 평가와 개선( SW Process Assessment and Improvement)
3.1 소프트웨어 프로세스 평가 모델 (Assessment Models)
3.2 소프트웨어 프로세스 평가 방법 (Assessment Method)
3.3 소프트웨어 프로세스 개선 모델 (Improvement Models)
3.4 연속적, 단계적 소프트웨어 프로세스 등급 (Continuous and Staged SW Process Ratings)
4. 소프트웨어 측정 (SW Measurement)
4.1 소프트웨어 프로세스와 제품 측정 (Process and Product Measurement)
4.2 평가결과의 품질 (Quality of Measurement Results)
4.3 소프트웨어 정보 모델 (SW Information Models)
4.4 소프트웨어 프로세스 측정 기술 (Measurement Techniques)
5 소프트웨어 공학 프로세스 도구들 (SW Engineering Process Tools)
댓글 없음:
댓글 쓰기