2022. 6. 10. 03:39ㆍ강의 내용 정리/소프트웨어 공학
Project Management
탑다운에 기반한 내용이기에 최근 소프트웨어 개발 방법론인 Agile과는 다른 면이 있어 논란의 여지가 있을 수 있다.
- Project Planning 이전의 단계이지만 WaterFall 방식과 Agile 방식의 차이점이 너무 크기 때문에 이를 중심으로 Project Management를 설명하고자 한다.
1. Ice break
- 프로젝트는 시작된다고 해서 모두 성공하는 것은 아니고, 망해가는 프로젝트를 통해 교훈을 얻을 수 있다. 이후 이러질 Project Planning을 하는 것이 매우 어렵고 WaterFall 방식과 Agile 방식의 차이점도 매우 크고, man-month라고 하는 투입되는 사람에 대해 차이점이 있다. 또한 프로젝트가 망해가는 것에 대한 특징을 보고 이를 느끼고 피해야한다. 특히 회사에 들어가면 개발을 하는 실질적인 개발팀이 있지만 이를 잘 모르는 관리 팀이 존재한다. 왜 관리팀은 개발에 대해 잘 이해하지 못하는지 등에 대한 설명을 진행하고자 한다.
1) OS2
IBM이 만든 운영체제
- IBM는 지금 SI 업체가 되었다. 본인이 요구하는 하드웨어와 소프트웨어 등등을 SI 업체에게 요청하면 여기서 하드웨어, 소프트웨어 등을 구해서 납품한다. 이때 직접 개발하거나 납품하기보다는 외주를 준다. 원래 IBM은 SI 업체가 아닌 모든 것을 다 만들어서 납품하는 제조 회사였다. 하지만 몇몇 프로젝트에 실패했다. IBM는 맥캔토시가 성공해서 데스크탑에서 많이 팔리자 이에 자극을 받은 IBM은 데스크탑 컴퓨터를 만든다. 이때 본인이 직접 만드는 부분은 한정지어서 CPU는 intel, 운영체제는 마이크로 소프트 도스를 가져다가 사용했다. 데스크탑 컴퓨터 시장은 무시했기 때문에 하드웨어인 컴퓨터는 만들었지만 프로세서는 인텔, OS는 마이크로소프트 도스를 사용했다. 하지만 데스크탑 시장이 성장하고 IBM은 늦게나마 운영체제를 만들고자 해서 나온 것이 OS2이다.
- 화면 구성 및 느낌이 윈도우즈와 비슷하다. IBM이 OS2를 실패하고 이를 만들 때 같이 작업한 마이크로소프트가 OS2의 상당량의 기술을 가져다가 본인들의 윈도우즈를 만들었다. 이때 기술적으로는 실험적인 것들이 많았지만 너무 크기가 커서 망했다. 이때 OS2의 실패가 IBM에게는 충격적으로 다가왔다.
- 앞에서 유지보수까지 오면서 소프트웨어 개발 등에 대한 얘기를 했는데 이렇게 하더라도 모두 성공하는 것은 아닐 뿐더러 어떠한 이유로 거대한 프로젝트가 망하는지를 알아야한다.
2) Multics
- 멀티로 작업할 수 있는 운영체제라는 슬로건을 들고 나왔다.
- 통신장비를 만들고 운영하는 회사의 연구소에서 나왔다. 1969년에 개발되었다.
- 리눅스와 비슷하다.
- 쉽게 말해 복수의 유저가 동시에 작업하고 각각의 유저는 서로 다른 작업을 동시에 수행할 수 있으니 현재 유저로 따지면 멀티 유저, 멀티 퍼포즈, 멀티 프로세싱을 할 수 있게 된다.
- 지금은 완전 망했다. 하지만 이러한 시행착오와 철학을 보고 만들어진 운영체제가 유닉스이다. 현재 맥캔토시에 들어간 맥OS도 유닉스 계열이다.
2. 프로젝트 관리
1) 개념
(1) 간트 차트
- 액션, 대분류, 중분류, 소분류로 나누고, 이에 대한 각 일정과 담당자의 이름이 있고, 선수, 후수관계가 존재한다.
(2) WBS (work break-down structure)
- 프로젝트의 추진 목표를 통제 가능한 수준으로 분류한 작업 목록
(3) 주공정 시뮬레이션
- 일정을 가능한 빠르고 제때 맞추기 위해서 통제해야하는 작업
(4) 작업량
- 인적 자원의 시간적 총 투입량
2) Man Month
하나의 프로젝트를 하기 위해 한달에 몇 명이 필요한가
(1) 특징
- 한 사람이 한달 동안에 할 수 있는 일은 1 M/M(Man Month)라고 한다.
- 한 사람이 하루의 반만 한달 동안 투입하는 일은 0.5 M/M라고 한다.
- 특별한 기술이 없는 경우에는 Man Month를 사용하는 경우에는 맞다.
(2) 부정적인 의견
"Adding manpower to a late software project makes it later."
- 너무 쉽게 산술로 평가한다는 점에서 Agile에서의 부정적인 의견이 있을 수 있다.
- 12 M/M인 경우에 24명을 투입하면 0.5달에 문제를 해결할 수 있다고 판단한다. 이때 투입되는 사람들의 머릿수만 중요하게 고려하기에 Agile인 이에 대해 부정적인 의견을 가지고 있다. 즉, 소프트웨어를 만드는 입장에서는 맞지 않는 부분이 있을 수 있다.
3. Mythical Man-Month
1) 개요
- IBM에서 OS/360 운영체제를 만든 사람의 에세이
- 지연된 과제에 사람을 추가하는 것은 더 느리게 만든다는 주제를 가지고 얘기한다.
- Man Month대신 프로토타입이나 second-system effect를 통해 앞에서 미진했던 것이나 앞에서 하고싶었지만 못했던 것을 버전 2에서 하지마라는 것을 강조한다.
- OS/360을 만들다가 일정이 지연되었기에 개발자를 더 투입시켰지만 일정이 더 느려져서 이에 대한 이야기를 쓴 에세이이다.
- 과학 계산을 위해 나온 알골이라는 언어를 IBM 컴퓨터에 올리기 위한 컴파일러를 개발했는데 사람을 더 투입하던 말던 애시당초 6개월정도 시간이 걸리는 작업이었다. 즉, 사람을 얼마나 투입하던지 개발 기간은 동일했다는 것이다.
- 45년이 지난 이 시점에서도 수 많은 사람들이 읽는 책이다.
2) 내용
- 소프트웨어 프로젝트에서 Man Month를 얘기하는 것이 허구라고 주장한다. 소프트웨어 작업을 Man Month로 측정한다는 것은 있을 수 없다고 한다. 왜냐하면 소프트웨어 개발 작업이 Complex하기 때문이다. 소프트웨어 개발 작업은 명확하게 딱딱 진행되지 않기도 하고, 개발자와의 커뮤니케이션이 없으면 불가능하기도 하다. 매일매일 회의를 통해서 일이 없어질 수 있고, 생겨날 수도 있지만 이를 미리 고려해서 사람을 투입하는 것이 어렵다. 더불어 일 작업과 이를 수행하는 사람을 연결하는 작업도 어렵다. 일을 사람에게 할당할 때는 사람의 역량에 따라 일을 할당한다. 하지만 Man Month는 이를 고려하지 않는다.
- 결국 경험 상으로 프로그래머를 늦어진 프로젝트에 추가하면 더 늦어진다는 것을 알게되었다. 새로운 사람이 추가되면 커뮤니케이션의 대상이 늘어나고 결국 더 많은 사람들과 대화를 해야하기에 그 사람이 어느 수준인지, 어떤 사람인지 등 알아야하니 N명이 있는 개발자가 있는 팀이 있을 때 N명의 개발자가 대화를 나눠야 하는 숫자는 n(n-1) / 2만큼이기에 더 많은 시간이 소모된다.
- 가장 중요한 것은 소프트웨어 개발의 작업은 파티션을 무자르듯이 나누기도 어렵고, 대화의 양이 늘어난다. 또한 이 사람이 뭘 하는지 알아야 일을 할 수 있기에 일이 느려질 수 있다.
- 그러나 만약 위의 조건에 부합하는 사람의 경우 조금 더 빠르게 일을 할 수도 있지만 이에 맞는 사람은 거의 없기에 대부분의 경우에는 팀원을 추가하면 일이 더 느려질 수 있다.
- Man Month는 소프트웨어를 수주받는 경우에는 소프트웨어 개발 단가를 사람의 머릿수로만 고려할 수 있다는 문제점 또한 있다.
3) No silver bullet
- 소프트웨어에는 기본적으로 그때 그때 상황에 맞춰 도구나 개발 방법론 등을 조절해야하기에 정해진 한 가지 방법은 없다.
- 오픈 소스 소프트웨어를 잘 활용한다는 것은 수정이 필요한 부분은 수정을 잘 하는 것을 의미하듯이 만능인 무언가가 있는 것은 아니다.
4) Second-system Effect
- 첫번째 시스템은 아쉬운 부분이 존재할 수 있다. 이후 두번째 시스템을 만들 때 이전에 담지 못한 기능을 모두 집어넣는 경우에는 거대해지고, 경쟁력이 없어질 수 있고, 비효율적이게 될 수 있다.
- 출시한 소프트웨어에 대해 다음 버전을 만들 때 over-engineering을 하진 않았는지 확인해보는 것이 중요하다.
5) bug
- 99개의 사소한 버그가 코드 내에 있을 때 패치를 한번 하는 경우에는 버그가 늘어날 수 있다.
- 프로그램은 결국 버그가 존재할 수밖에 없다. 이 버그가 치명적이지 않도록 자잘한 버그가 일정 수준 이하로만 유지되어야한다.
- 에러를 아예 없애고자한다면 더 많은 에러가 발생할 수 있다.
6) Progress tracking
- Agile Scrum과 관련이 있다.
- 주기적으로 micro한 범위에 대해 세세하게 얘기한다면 일정이 늦어지지않을 것이다.
- 조그마한 마일스톤 단위로 끊임없이 지속적으로 만나는 것이 중요하다. 이때 너무나도 쉽게 하루, 이틀 정도 늦어질 수 있다. 사람들이 scrum을 해야지만 수시로 점검해가면서 혹시라도 발생할 수 있는 큰 지연을 방지할 수 있다.
7) Conceptual intergrity
- 프로그램을 만들 때 어떤 것을 넣고, 어떤 것을 뺄지 고민하는 것
- 좋은 시스템이라고 하는 것은 사용하는 사람이 교육받지 않아도 사용할 수 있어야한다. 따라서 우리가 만드는 시스템이 실패하지 않게하기 위해서는 사용하기 쉬워야하고 복잡해지기보단 구조가 명확하고, 단순화되어야한다.
- 누군가가 프로그램의 일종의 방향성, 철학을 정의해야한다. 결국 사용자가 어떤식으로 사용할 것인지 정해야한다. 이 것에 부합하지 않으면 기능을 쳐내야한다.
- 개발철학, 설계철학은 구성원들이 함께 동일하게 가지고 있어야한다. 개발을 하다보면 생각치도 못한 상황이 발생할수밖에 없는데, 이를 일일이 대응해줄수는 없다. 이에 따라 모든 구성원들은 철학을 함께 가지고 가고, 이에 맞춰 스스로 결정을 내릴 수 있어야한다.
- 소프트웨어를 설계하고 개발하는 과정에서 사용자의 효율을 극대화하기 위한 철학을 공유하고, 이에 맞지 않으면 스스로 자를 수 있는 독자적인 능력까지 갖춰야한다.
8) Manual
- 프로그램에 대한 상세한 내외부의 규격을 작성해야한다. 만들 소프트웨어의 요구사항을 작성하는 것이다.
- 최근에는 작동하는 소프트웨어에 초점을 맞추고 있지만 최소한 팀으로 작업을 할 때는 우리 모두가 함께 인지해야하는 부분이 존재한다. 이것이 워드프로세스로 치던, 구체화하는 작업을 하던 역할을 해야한다. 이는 계속 수정되고 진화되어야한다.
- Agile은 문서를 자제하는 것을 얘기하지만 이분법적으로 구분할 수 없다.
9) Pilot system
- 실제로 고객님 앞에 주지 않고, 이것은 대부분 기술이 가능한지, 우리가 지향하는 목표가 실제로 맞는지 확인하기 위한 고민 등을 비슷하게 구현함으로서 이것이 맞는지 틀린지 확인하기 위한 용도의 시스템이다.
- 이후에 버려질 시스템이기에 우리가 만들 것의 가장 중요한 것을 구현하는 것이다.
- 이 경험을 거친 뒤에는 고객에게 전달할 시스템에 대해 개선해 제공할 수 있게된다.
- 이렇게 제공되면 스마터 시스템이 될 것이고 이 과정을 거치지 않으면 파일럿 시스템 수준의 시스템이 제공될 것이고, 결국 고객 신뢰를 망칠 수 있다. 따라서 소프트웨어는 가능하다면 파일럿 시스템을 만들어서 우리가 생각한 철학이 그럴듯한지, 맞는지 등 미리 확인해보는 과정이 필요하다.
10) Formal documents
- 개발 구현에 대한 부분도 있지만 목적, 누가 이를 할지, 마일스톤, 비용 등 프로젝트에 관한 내용들을 작성한다.
- 이를 한번 만든 뒤에는 누군가가 새로운 사람이 왔을 때 우리 프로젝트에 대한 이해와 개념을 항상 터득할 수 있도록 돕는다. 누군가가 명확하게 프로젝트 개발에 대해 기술할 필요가 있다. 문서가 아예 없을 수 없다.
11) Project estimation
- 프로젝트 일정을 잡을 때 소프트웨어에 대해 이해를 하고 일정을 잡는 것을 의미한다.
- 소프트웨어 관련된 지식을 가지고 일의 난이도, 복잡도 등에 대해 고민을 해야한다. 이를 충분히 이해한 상태에서 일정을 잡아야한다.
- Scrum을 할 때는 아침에 15분을 해야한다. 기술적이지 않거나 그다지 필요없을 것 같은 미팅 등과 같은 것들도 고려해서 일정을 짜야한다.
12) Communication
- 물리적으로 떨어져있어도 협업을 할 수 있다. 커뮤니케이션은 원활해야한다. 이메일, 전화 등 회의 등등 다양하게 사용해서 커뮤니케이션을 원활히 할 수 있도록 해야한다.
- 항상 만나서 컨펌받고, 대등한 관계로서 원활한 커뮤니케이션을 가져야 불필요한 지연을 없앨 수 있다.
13) Surgical team
- 외과수술 팀에서 한명의 실력 좋은 사람이 전체 인원의 보조를 맞추고, 조율하는 것처럼 굉장히 능력이 좋은 프로그래머가 팀에 한명 존재하는 것이 일을 수월하게 처리하는데 큰 도움이 된다.
- 좋은 프로그래머는 다른 사람보다 5배에서 10배 이상 생산성을 가지고 있다.
14) Code freeze and system versioning
- 시간을 들여서 프로그램을 만들고, 피드백도 받고 의견도 받는 등의 과정을 거친다. 그러다보면 Scrum에서 했던 것처럼 어느 시점에서는 목표한 바를 이룰 수 있다. 혹은 스프린트를 완료할수도 있다. 이후 릴리즈를 하면 더이상의 수정은 없다!라고 하는 것이 code freeze이다. 이를 언제까지 할지, 혹은 지금 시점 이후로는 freeze한다고 정한다. 이를 중간중간 버저닝하고, 의미있는 버전이 나왔을 때 이를 프리징하고, 관리하는 역할을 꼭 해야한다.
15) Specialized tools
- 훌륭한 도구는 굉장히 좋은 생산성을 향상시켜서 개발 속도도 높이고 성능도 향상시킬 수 있다.
- 팀이 필요로 하는 일이 있다면 우리가 필요로 하는 기능이 없는 경우 도구를 만드는 과정이 필요할 수도 있다.
- 대부분의 회사에서 시니어 엔지니어는 도구개발팀에 있는 경우가 많다.
- 결국 수작업에 필요한 것을 자동화로 짜는 것이 중요하다.
16) Lowering software development costs
- 소프트웨어 개발 비용을 낮춰라.
- 당시에는 waterfall 방식으로 개발했기에 아키텍쳐가 완성되었을 때 개발자를 구하는 것이 비용을 줄일 수 있다고 설명한다. Agile인 경우에는 무의미할 수 있다.
- 소프트웨어를 만들지 않고, 상용품을 사는 것도 비용을 줄일 수 있는 방법일 수 있다.(off the shelf) 혹은 오픈소스를 찾아보는 것도 중요하다.
'강의 내용 정리 > 소프트웨어 공학' 카테고리의 다른 글
| 소프트웨어 공학 (14), Quality Management (0) | 2022.06.14 |
|---|---|
| 소프트웨어 공학 (13), Project planning (0) | 2022.06.14 |
| 소프트웨어 공학 (11), Software Evolution (0) | 2022.05.26 |
| 소프트웨어 공학 (10), Software Testing (0) | 2022.05.18 |
| 소프트웨어 공학 (9), Implementation (0) | 2022.04.25 |