[소프트웨어공학] 22장 Project Management

project의 plan을 세울 때 가장 중요한 것

-> 얼마만큼의 인원으로 얼마만큼의 비용을 들여서 얼마만큼의 시간을 들여서 수행할지

ex. IBM에서 데스크톱 컴퓨터를 만듦 -> CPU는 인텔, OS MS를 가져다 사용함 -> 하드웨어는 만들었지만 다른 애플과 MS의 OS가 큰 성공을 거두자 이에 따라 OS/2라는 운영체제를 만듦(윈도우즈와 유사) - 덩치가 너무 컸음 -> 기술적으로 많은 투자를 했지만 크게 실패한 사례임 -> 이전까지 배웠던 것처럼 개발되어온 소프트웨어가 무조건적으로 성공하는 것은 아님

 

ex. Multics -> multi user, performs, process(완전히 망함)

-> 이것을 기반으로 unix운영체제가 만들어졌습니다.

>>프로젝트가 수행되었다고 해서 무조건 성공하는 것이 아니고 실패하는 프로젝트도 반드시 존재한다. -> 이러한 프로젝트에서 교훈을 얻을 수 있다.

>>계획을 세우는 것 역시 쉽지 않음 -> 특히 에이자일 방식과 waterfall방식에 계획을 세우는 것에는 많은 차이가 있다.

 

ex. 특급 가상 프로젝트 (Microsoft Office Project2007로 거북선을 만들어 보자)

거북선을 만드는 것 자체가 너무 큰일이기 때문에 일정관리 계획이 쉽지 않음 -> WBS(Work Break-down Structure) - 프로젝트의 추진 목표를 통제 가능한 수준으로 분류한 작업 목록을 말합니다.

왜구들의 동태를 살펴 일정이 당겨야 함을 주장함 -> 주공정(Critical Task) - 일정을 가능한 한 빨리 또는 제 때에 마치기 위해서 통제해야 하는 작업을 말합니다.

작업하는 일이 많아 졌는데 일정은 지켜야 하는 상황 -> 작업량 고정 – 투입 인력을 예측할 수 있습니다.

다른 오피스와 연동이 가능하여 리포트를 만드는 것에 이점이 있다.

>>주 키워드 간트차트, WBS, 주공정, 작업량

-> 프로젝트 관리

 

Man-Month – 한 달에 몇 명이 필요한지(작업량)

-1 full person per month is 1 M/M(1사람이 1달 동안 꾸준히 해야하는 일)

-1 full person per year is 12 M/Ms(1사람이 12달 동안 해야하는 일)

 

Adding manpower to a late software project makes it later

-> Man-Month의 오류 -> 지연되고 있는 소프트웨어 프로젝트에 사람을 더 투입한다고 해결되는 것이 아니다.

-> 간단하고 평이한 일이라면 가능하겠지만 소프트웨어 개발에는 맞지 않을 수 있다.

 

The Mythical Man-Month – Man-Month관련 서적

-> 지연된 과제에 사람을 추가하는 것은 그 과제를 더 느리게 만든다.

-> second-system effect - 두 번째 시스템에 너무 많은 것을 포함하려고 하지마라

-> 브룩스라는 저자가 실제로 IBM에서 OS/360를 만들면서 했던 실수들을 기반을 책을 서술함 -> 프로젝트가 지연되자 사람들을 더 투입했고 프로젝트는 더 어려워졌음

ALGOL -> 과학 계산을 위한 프로그램(사람을 더 투입하면 기간이 줄어들지 않았음)

 

소프트웨어 프로젝트에서 Man-Month를 사용하는 것이 옳지 않다 -> 이유 : complex함

-> 소프트웨어 작업이 일정하게 떨어지는 규칙이 있는 것이 아님 매일 변화가 진행되며 그것을 받아들이는 것 역시 지속적으로 변해감 -> 그러나 Man-Month는 공장처럼 프로젝트가 진행된다는 가정에서 프로젝트 계획을 세움...

-> but 소프트웨어 프로젝트에서는 사람이 추가되는 것은 대화가 더 많이 이루어져야하는 양이 더 많아지고 현재 소프트웨어를 파악하는 것에도 시간이 들고 여러모로 더 많은 것들이 많이 소요됨 -> 소프트웨어 개발은 칼로 자르듯 딱 떨어지는 것이 아님

-> 확률적으로 새로운 사람이 온다면 그것은 교육, 대화 등의 측면에서 이루어져야 할 과정들을 더 복잡하게 할 가능성이 높아진다.

-> 따라서 프로젝트 과정이 느려질 것이다.

-> 소프트웨어 프로젝트에서는 에이자일 기법을 고려할 때 사람이 더 붙는 것은 옳지 않다.

>>소프트웨어 개발 단가를 Man-Month기반으로 이루어진다는 점에서 개개인의 특징을 반영하지 못한다. -> 비용을 개발 인원에 따라 정해지게 함.

소프트웨어에는 만능키 같은 것이 없음 -> 정해진 한 가지 방법은 없음

-> 어떤 개발방법론을 사용한다고 할 때 그 팀의 상황을 고려해서 고민을 하고 필요한 부분은 받아들이고 수정이 필요한 부분은 고쳐 사용하는 것이 맞음. -> 가져온 기법을 그냥 사용할 수는 없음(오픈소스를 가져와 무조건적으로 딱 맞는 것이 아님 -> 자신의 소프트웨어에 맞게 커스텀 해야 함) -> 사용하는 사람들이 상황에 맞게 변형시켜 사용해야함

 

second-system effect -> 첫 번째 시스템을 거쳐 다음 시스템을 만든다면 첫 번째에서 못했던 것 아쉬웠던 것들을 모두 다 집어넣으려는 행동은 옳지 못함.

-> 상당히 많은 프로젝트들이 다음 시스템을 만들 때 많은 것을 담으려고 하다 보니 느려진다.

 

버그가 없는 시스템은 존재하지 않는다.

프로그램에는 버그가 존재한다. -> 치명적인 에러를 없애고 자잘한 에러의 수준을 일정 수준을 넘지 않게 유지하는 것이 중요하다.

 

 

Progress tracking(진행률 추적)

에이자일 -> 스크럼 기법(매일 아침 15분씩 회의하기)

Brooks wrote

질문 : 어떻게 그렇게 1년이 늦어질 수 있니?

답 : 하루하루 늘어나다 보면 그렇게 1년이 늘어날 수 있어.

>>우리가 주기적으로 microscopic하게 세세한 이야기 들을 촘촘하게 대화를 나눠가면서 해결해 왔다면 이렇게 늦어지지는 않았을 것이다.

Brooks : 이런 식의 일정 지연이 일어나는 것을 방지하기 위해서는 조그마한 일의 단위로 끊임없이 지속적으로 만나라. ->한 달, 주에 한번 이런 식으로 회의를 하는 것에서 조금씩 해야할 일이 늘어나는 것에 따라 지연이 발생하는 것이다.

-> 소프트웨어 개발을 할 때 스크럼 기법이 사용되는 이유는 이렇게 해야지만 복잡한 상호작용, 테스크, 워커들 간의 관계를 수시로 점검해가면서 혹시라도 발생할 수 있는 큰 지연을 막을 수 있다.

 

Conceptual integrity(개념 무결성, 조직 문화)

>만약에 우리가 프로그램과 같은 것을 만들 때 무엇을 넣고 뺄 것인지 이런 부분에 대해서 고민해보는 것

>가장 좋은 시스템은 사용하는 사람이 교육받지 않아도 사용할 수 있는 시스템이다. (직관적인 시스템) -> 따라서 우리가 만드는 소프트웨어가 실패하지 않으려면 사용자가 사용하기 굉장히 쉬워야함. -> 구조적, 개념적으로 명확하고 단순화되고 순수해져야 한다. -> 이렇게 되려면 누군가가 철학(방향성)을 정의해야함

-> 그래서 나온 것이 결국 우리가 만든 시스템을 사용하고자 하는 자가 어떤 생각으로 우리 것을 사용하게 될 것인지 어떻게 만들어야지 사용자가 쉽게 장점을 극대화해서 사용할 것인지 누군가는 방향성/철학을 제시해야한다.(꼭 지켜야할 방향성이 존재해야한다.)

-> 그러한 철학을 팀원들 역시 동일하게 가지고 있는 것이 중요하다. -> 그 철학에 맞춰서 팀원들 개개인이 본인 스스로 결정을 할 수 있어야 함. -> 독자적 결정 능력(Conceptual integrity – 설계철학)

 

The manual -> 누군가는 자세한 규격을 써야함(만들 소프트웨어의 요구사항)

최근 들어 문서화를 많이 하지는 않지만 극단적으로 지양하지는 않는다. -> 팀원이 함께 인지해야 될 부분이 존재함. -> 그것을 워드로 치건 화이트보드에 그림을 그리는 행위 역시 specifications of the system을 매뉴얼 화하는 작업임.(사용자에게 비춰지는 측면 내부적으로 구체화하는 작업을 해라)

-> 이것이 고정된 것이 아니고 사용자로부터 팀원들 간에 피드백을 통해 계속 수정되고 진화함.

 

pilot system -> 상용으로 무언가를 내보내기 전에 기술이 가능한지 우리가 지향하는 목표가 실제로 맞는 것인지 판단하는 시스템(정량적 정성적인 것들을 확인하는 장치)

-> 결국 버려질 것임 -> 우리가 만들 것을 전부 구현하는 것이 아닌 필수적인 것만 구현해 보는 것 -> 제공될 시스템을 스마트 시스템이라고 함(이전에 개선을 도모할 수 있음)

->가능하다면 pilot system을 만들어서 미리 확인해보는 것이 좋음

>Formal documents – 문서를 만드는 것에 대한 딜레마가 있지만, 0 or 1로 완전히 갈라지는 것은 아님

-> 개발 구현에 대한 부분들도 있지만, 우리 프로젝트는 무엇을 목표로 하며 어떻게 성취하고 누가 이것을 성취할지 고민해보고 언제까지 할지에 대한 큰 마일드스톤들, 얼마의 경비가 소요될지 와 같은 프로젝트에 대한 이해가 가능하게 하기 위한 용도임.

>>깃허브 같은 곳에 문서적으로 프로젝트를 설명하는 부분이 별도로 있음 -> 보는 사람이 프로젝트에 대한 이해를 가능하게 해줌

>>누군가가 아주 명확하게 기술해둘 필요는 있음

>>에이자일이라고 해서 문서가 아예 없는 것은 아님 이런 것은 받아들여짐

 

Project estimation

man-month와 비슷한 개념 -> 일정을 잡을 때 소프트웨어를 이해한 상태에서 일정을 잡을 필요가 있음

-> 간단한 프로그램을 짜는 것과 프로그램 툴 컴파일 프로그램을 짜는 것은 다른 이야기임 -> 결국 우리는 소프트웨어 관련 지식을 가지고 그 일에 계획을 세우는 것이 필요함.

-> 스크럼을 할 때에는 아침에 15분만을 진행함 -> 회의를 할 때 무의미하게 버려지는 것들을 최소한으로 해서 효율성을 높이는 방법을 생각해서 계획을 세울 필요가 있음

 

Communication

-> 대화가 필요하다. -> 떨어져 있더라도 메신저 등을 통해서 원활한 커뮤니케이션을 보장해야 한다. -> 모르는 것이 있다면 명확하게 만들 수 있게 물어보고 예측해서 하는 행위를 지양해야한다.

-> 이를 통해 불필요한 지연과 불필요한 오류를 제거할 수 있다.

 

surgical team

-> 외과 수술 팀에서 한명의 실력자가 전체 팀의 보조를 받으며 임무를 마치고 더불어 그 사람이 다른 사람들을 조율하는 것처럼 소프트웨어를 개발하는 팀에서도 한명의 우수한 사람이 있는 것이 대단히 도움이 됨.(man-month가 통용되지 않는 이유 – 모든 사람의 생산성이 같지 않음)

 

Code freeze and system versioning

->시간을 보내며 결과물을 만들어 중간 중간 사용자에게 보내어 피드백을 받음

->프로그램은 한 번에 쭉 진행되는 것이 아닌 사용자, 개발자들의 피드백에 의해 이루어지는 것임

에이자일 스크럼(스프린트를 뜀)에서 했던 것처럼 어느 시점에 요구사항을 만족할 수 있는 경우가 되는데 이후에 릴리즈를 해야 할 경우가 되는데 이때 더 이상의 코드 수정이 없다고 판단을 내리는 것 -> code freeze -> 최종적으로 저장이 되는 것, 의미 있는 결과가 나왔을 때 저장하는 것

 

 

Specialized tools(도구) -> 훌륭한 도구는 프로젝트를 진행하는데 있어 다양한 이점을 가져다줌. -> 도구를 항상 만들어라 -> 대부분의 우수한 개발자들은 도구개발을 많이 함.(수작업으로 하는 일을 자동화 시키는 일)

 

Lowering software development costs -> 소프트웨어 개발 비용을 줄여라(2가지)

당시에는 waterfall방식으로 소프트웨어를 개발했었음

waterfall 방식에서는 단계별로 진행되기 때문에 단계별로 사람을 구함, 처음부터 다구하지는 마라(에이자일에서는 무의미)

가장 좋은 방법은 소프트웨어를 만들지 마라 -> 살 수 있으면 사서 대체하는 것이 좋음

-> 직접 짜지 말고 오픈소스를 찾아봐라

 

Summary

-> 에이자일과 오픈소스에 많이 접근함

>Man-Month

>Ghant-Chart

>WBS

-> 상황에 따라 이전의 방법들을 만날 수도 있음 이럴 경우 잘 판다해서 해결해 나아가자!

>>이전까지의 절차들을 잘 파악해서 현재의 문제들을 잘 해쳐나가자

 

책 추천

-유닉스의 탄생(저자 : 커닝함, c언어를 처음 만든 사람 -> c언어의 탄생 : 유닉스 운영체제를 만들기 위해서임)

-Masterminds of Programming -> 프로그램 언어를 만든 사람들에 대한 인터뷰 형식임

-Iwoz -> 워즈니악의 자서전 -> 애플컴퓨터를 실제적으로 만든 사람

-닌텐도 이야기

-The Phoenix Project -> 소프트웨어 개발팀의 이야기가 나와 있음(읽어보자)

-The Unicorn Project

-Software Engineering at Google -> 소웨공에서 배운 내용들이 구글에 적용된 내용이 나와 있음

>>O’REILLY에서 볼 수 있음 -> 학교 홈페이지에 나와 있음