제안서(2) (프로젝트 성공률 1% 높이기)

제안서 프로세스

지난번 내용 중 제안서를 위한 일반적인 프로세스 6단계에 대해서 대략 정리하였는데 이를 좀 더 자세히 알아보자. 우선 제안서는 설득의 글이다. 다시 말해 단편적 지식의 나열이나 하나에 집중하기보다는 전체적인 맥락을 이해하고 하나의 이미지로 접근해야 한다. 그 중심엔 고객이 있다. 고객이 결정되고 나면 그 고객의 모든 것에 대해 알아야 한다. 
 
모든 것을 알기 위해선 먼저 기준이 필요하다. 그 기준의 부합 여부에 따라 전략, 전술이 달라진다. 기준은 가설에 따라 설정된다. 가설을 세우고 가설을 검증하는 과정을 반복하면서 우리는 고객에 좀 더 가깝게 접근할 수 있다. 물론 준비된 고객들도 있지만 대부분은 강한 니즈와 문제의식을 가지고 있으면서도 그래서 무엇을 하고 싶은지를 명확히 표현하지 못하는 경우가 많다. 
 
이 부분은 문제에 대해서는 잘 알지만, 문제점, 즉 원인을 파악하지 못하는 경우다. 문제와 문제점은 다르다. 가설을 세우고 검증하는 과정은 문제에서 문제점으로 접근하는 최단의 경로이다. 이를 통해 고객은 문제점을 인식하고 제대로 원하는 것이 무엇인지 표현할 수 있다. 제안서는 이를 도와주는 설득의 도구이다.
 
 

1️⃣ 정보 수집, 분석 및 가설 설정

가설을 세울 때 필요한 것이 무엇인가? 그것은 정보이다. 많은 정보를 획득할수록 제대된 가설 또한 수립할 수 있다. 물론 고객에 대한 정보가 아주 완벽하게 수집되었다 해도 이런 정보들을 친절히 알려주고 가르쳐 주는 고객은 거의 없다. 따라서 한정된 정보 속에서 우리는 실마리를 찾아내야 하는 것이다.
 
여기서 제대로 된 가설은 없을 수 있다. 가설이 맞고 틀리고가 아니고 당연히 잘못되어 있을 수도 있다. 하지만 가설을 통해 고객이 정말 중요하게 생각하는 점을 그려보는 것이 진짜 중요한 일이다. 가설이 없다면 중구난방 횡설수설할 수 있으며 정보의 중요도도 알아내지 못할 수 있다. 요구사항 아래 잠재적 요구사항을 끄집어내는 일 또한 우리의 일이다.
 
정보는 관점이 중요하다. 수집하되 하나의 단면만 보면 안 된다. 즉 고객, 경쟁사, 고객의 고객 및 거래처의 관점이 필요하다. 이를 통해 제대로 된 요구사항을 확인해 볼 수 있다. 또한 정보는 숨어있는 부분도 많다. 그래서 일반적인 정보와 더불어 고객에게서 입수해야 할 정보도 꼼꼼하게 챙겨야 한다.
 
수집, 획득된 정보는 면밀한 분석이 필요하다. 그와 동시에 가설을 준비한다. 가설은 정보수집의 관점들을 토대로 고객의 장단점 및 기회와 위기를 참작한다. 또한 제약조건은 두지 않고 고객의 눈높이 맞춰 설정해야 한다. 가설은 검증(사실임을 증명할 가능성, 거짓임을 증명할 가능성, 결과에 대해서는 재현 가능성)할 수 있어야 하며 더 간단하거나 정확한 방법을 설명할 수 있다면 다시 설정해야 한다.
 
 

2️⃣ 요구사항 정리

요구사항 정리는 가설의 정리라고도 할 수 있으며 일종의 사전 제안서 형태로 할 수 있다. 여기에는 설정한 가설을 구체적으로 기술하고 고객 요구사항과의 일치성, 또한 어느 부분이 잘못되었는가를 확인하고자 함이다. 이를 통해 수집된 정보를 제대로 분석했고 이해했는지, 잠재적 요구사항들이 도출되었는지도 가려낼 수 있다.
 
이러한 사전 제안서는 가설검증의 도구라고 보면 된다. 그렇기 때문에 세밀하고 구체적인 내용으로 정리해야 한다. 명확하지 않으면 안 된다. 그래서 정성적인 부분도 정량화하는 노력이 필요하다. 또한 하나의 사실에 대한 주변 인터페이스를 살펴야 한다. 누구에 의해서, 누가 작성했고 어디에 쓰이는지, 그 결과는 무엇인지를 명확히 알아야 한다. 정보의 객관화가 여기서 필요하다. 정보의 논리 근거가 필요하다.
 
 

3️⃣ 인터뷰 및 가설 검증

준비된 자료를 바탕으로 가설이 맞는지 검증하는 단계이다. 이때 주된 방법은 인터뷰이다. 다만 목적을 명확하게 하는 인터뷰를 준비하여야 한다. 경청을 기본으로 알고 싶은 내용을 관계자에게 질의응답 방식을 통해 정보를 확인하고 알아내기 위함이다.
 
우리가 대화 속에서 정보를 획득하는 것이 쉬워 보일 수도 있지만 이는 대단히 어려운 일 중 하나다. 그래서 관련한 여러 기술들을 참고해 볼 수도 있는데 그래서 많은 경험 또한 필요한 부분이다. 특히 인터뷰의 목적을 명확히 하는 것은 여러 인터뷰 방식 중 우리는 정보수집을 위한 인터뷰를 하려 하기 때문이다. 이를 중심으로 설득 또한 같이 진행하게 된다.
 
인터뷰는 인터뷰 대상자를 선별한다. 대상자가 누구냐에 따라 그 결과는 천차만별이다. 그러므로 아무나 대상자로 하면 시간과 비용만 낭비된다. 실무자인지 관리자인지 혹은 경영자층인지에 따라 정보의 양과 질이 다르다. 그래서 수집된 정보의 분석이 필요한 것이다. 대상자가 선별되었다면 질문을 준비해야 한다. 질문의 목적을 통해 다양하게 준비하고 리스트를 만들어 관리한다. 
 




 

4️⃣ 결과정리

인터뷰가 진행된다. 앞서 언급했듯이 그 목적이 중요한 만큼 인터뷰 대상자에게 목적을 알리고 최대한 협조할 수 있는 분위기를 조성한다. 이 부분은 의사소통의 스킬을 기반으로 대상자에게 어떠한 부분에 관심이 있는지, 그들의 입장이 무엇인지, 그리고 대답하기 곤란하지 않은지 면밀히 살펴야 한다.
 
인터뷰가 끝나면 그 내용을 제안에 반영하기 위해 가설을 검증하고 수정을 진행한다. 만약 가설이 고객의 요구사항과 일치하면 상관이 없지만 그렇지 않다면 계속 반복, 피드백하여야 한다. 그러기 위해선 인터뷰 내용을 잘 정리한다. 별도 회의록을 만들어 작성하고 필요시 녹취 등을 통해 정보의 유실을 막는다. 
 
인터뷰 내용을 기술할 때 가장 중요한 점은 인터뷰에 참석하지 않은 인력이 그 내용을 보더라도 당시의 내용은 물론 상황까지도 알 수 있도록 쉽게 써야 하는 것이다. 그러기 때문에 답변의 뉘앙스까지도 잡아내야 한다. 그러한 미묘한 차이점이 중요한 의미를 지니고 궁극엔 결과도 다르게 나타날 수 있기 때문이다.
 
정리된 회의록을 통해 가설 검증을 수행하고 문제가 있다면 수정작업을 진행한다. 이는 why, what, where를 명확히 하는 작업이다. why와 what이 명확해질 때까지 계속 확인을 하며 이를 통해 제안범위가 최종적으로 확정된다. 이 세 부분이 스스로 납득이 간다면 이제 최종적인 제안서 작성에 들어갈 준비가 된 것이다.
 
 

5️⃣ 제안서 작성

제안서는 템플릿이 많다. 하지만 고객사가 제공하는 경우도 있을 수 있기 때문에 큰 제약이 되지는 않는다. 형식도 중요하지만, 내용이 더 중요하기 때문이다. 그래서 작성에 많은 신경을 써야 한다. 다른 것도 마찬가지지만 제안의 제목은 확정이 되었기 때문에 제일 어려운 장애물은 제거되었다.
 
그다음 할 일은 목차를 작성하는 것이다. 사실 제목과 목차가 전부이다. 대부분은 제안서에서 제목과 목차가 차지하는 비중은 80%이다. 나머진 사전 제안서를 바탕으로 내용을 채워 넣는 일이기 때문이다. 목차를 통해 스토리를 구성하고 조립한다. 소설처럼 극적인 장치도 마련할 수 있다. 이런 부분은 물론 충분한 논의와 사유가 있어야 하지만 목차 구성만으로도 우린 상대를 설득할 수 있어야 한다.
 
제안서는 그 범위와 경중 등에 따라 혼자 쓸 수도 있고 팀으로 작성할 수도 있다. 최대한 간결한 표현으로 간단하게 이해할 수 있도록 작성해야 한다. 오해가 없어야 하며 사실에 근거하여 기술한다. 여기서 금물은 많이 써봐서 혹은 잘 쓰기 때문이라는 과신이나 선입견이다. 그래서 다양한 관점의 검토가 필요하다. 작성된 제안서는 반드시 객관적 입장에서 평가를 할 수 있는 사람에게 검토받아야 한다.
 
 

6️⃣ 발표

큰일이 모두 끝났다. 하지만 대미를 장식할 더 큰 일, 발표가 있다. 제안은 발표로 완결된다. 제아무리 훌륭하게 작성된 제안서도 어떻게 발표하느냐에 따라 그 결과는 달라진다. 다르게 이야기하면 미흡한 제안서라 할지라도 훌륭한 발표를 통해 제안 기회의 불씨를 살릴 수도 있다는 것이다. 
 
이렇게 중요한 발표는 제안서를 완전히 체화한 발표자를 중심으로 열의와 의욕을 불태워야 한다. 당연히 기술력을 기반으로 고객에게 신뢰를 주어야 하며 요구사항을 제대로 충족시켜 주어야 한다. 고객의 혼란을 야기할 정보들은 정리가 되어야 하며 누구에게 제안하는지, 왜 무엇을 하는지를 확실히 하고 넘어간다. 이를 통해 작성된 스토리에 고객이 동감하고 감동하며 진실한 태도에 고개를 끄덕일 수 있다.
 
 
 
 
※ 무늬만 대표자? 
정말 힘들게 작성한 제안서를 들고 가서 보기 좋게 말아먹는(?) 발표자가 있다. 이는 제안에 참여한 모든 이들을 배신하는 것이다. 그런데 그것을 잘 모르는 발표자가 많다. 대부분은 아니지만, 발표자라면 제안서를 완전히 씹어 먹고 내 것으로 만들지 못한다면 절대 발표하면 안 된다. 왜냐면 발표하면서 내가 얼마나 이 제안에 진심인지가 낱낱이 드러나기 때문이다. 고객도 당연하지만 발표하는 자기가 가장 잘 안다. 발표자 자신이 직급이 있다고, 대표성이 있다고 자신할 것도 아니다. 혼자 잘난 체할 것도 아니다. 남이 다 차려놓은 밥상에 숟가락을 올리지 말고 그 밥상 차림에 일조하길 바란다. 이 자리를 위해 고생하고 애쓴 사람들을 봐서라도..

PMBOK (프로젝트 성공률 1% 높이기)

프로젝트 지식관리체계: PMBOK(Project Management Body of Knowledge)

프로젝트 관리를 위한 지침. 어떠한 분야라도 바이블과 같은 핵심 기초서가 있는데 특히 IT/SW 분야에서는 PMBOK이 그중 한몫을 담당하고 있다. 이는 PM과 팀원들이 프로젝트에 참여하여 계획, 실행, 통제, 성과 평가를 하는 데 필요한 각종 표준과 가이드라인을 제시한다.
 
PMBOK은 미국 프로젝트 관리협회(PMI: Project Management Institute)에서 개발했다. PMI는 프로젝트 관리의 발전과 보급을 위해 설립된 비영리 단체로 1969년에 설립, 현재는 전 세계 약 170여 개국에 포진해 있으며 수많은 회원을 보유하고 있다. PMI는 프로젝트 관리 교육, 자격 인증(PMP: Project Management Professional), 각종 연구 및 전문가 교류 등 다양한 활동으로 프로젝트 관리의 발전에 기여하고 있다.

PMBOK은 1987년 첫 번째 판이, 2021년 7월 7판까지 나왔다. 그 이력을 살펴보면 다음과 같다.
🔹PMBOK 1판 (1987년): 1983년 첫 개발 후 최초 출판. 프로젝트 관리 영역 정의, 주요 개념과 용어 설정
🔹PMBOK 2판 (1996년): 두 번째 개정판. 프로젝트 관리 영역의 상세 설명과 구체적 정의
🔹PMBOK 3판 (2004년): 프로젝트 관리 영역뿐만 아니라 프로그램 관리와 포트폴리오 관리 개념 도입
🔹PMBOK 4판 (2008년): 프로세스 그룹과 지식영역 첫 도입 및 프로젝트 관리 지식 조직화
🔹PMBOK 5판 (2013년): Agile 방법론 도입 및 프로세스 그룹과 지식영역의 구성 일부 변경
🔹PMBOK 6판 (2017년): Agile 방법론과 예측적 방법론 간 상호작용 보강 및 프로젝트 관리 지식, 기술 지속 갱신
🔹PMBOK 7판 (2021년): 최신 프로젝트 관리 동향과 기술적 진보 반영. Agile과 성과 중심의 접근 방식 강조
🔹PMBOK 8판 (2025년 하반기 예정): AI 등 최신 기술, 트랜드 등 반영 예상 (= 6판 + 7판)
 
개발자라면 한 번씩은 찾아봤을 지침이고 경력상 PM에 뜻이 있다면 자격증 공부도 많이 했을 PMBOK은 최근 7판에서 기존과 다른 많은 변화가 있었다. 이는 그간의 기술 발전과 환경들을 실제로 반영하면서 현장에서는 다소 혼란이 있기도 한 상황이지만 이 또한 엔지니어로서 감내하고 받아들여야 할 부분이 아닐까 싶다.
 
 

PMBOK 주요 특징

PMBOK은 프로젝트 관리의 핵심 원칙과 프로세스를 집약하였고 6판까지는 아래와 같이 5가지 프로세스 그룹과 10가지 지식 영역으로 나눠 있다.

✔️프로세스 그룹
  1. 시작(Initiating)
  2. 계획(Planning)
  3. 실행(Executing)
  4. 모니터링/통제(Monitoring and Controlling)
  5. 종료(Closing)

✔️지식 영역
  1. 프로젝트 통합관리(Integration)
  2. 프로젝트 범위관리(Scope)
  3. 프로젝트 시간 관리(Schedule)
  4. 프로젝트 비용관리(Cost)
  5. 프로젝트 품질관리(Quality)
  6. 프로젝트 자원관리(Resource)
  7. 프로젝트 의사소통 관리(Communication)
  8. 프로젝트 위험관리(Risk)
  9. 프로젝트 조달관리(Procurement)
  10. 프로젝트 이해관계자 관리(Stakeholder)

 

 
다음은 최근에 나온 7판을 6판과 비교하여 간략하게 차이점을 살펴본다.
 
🚩 체계/구조 변화
: 6판은 전통적 프로젝트 관리 방식에 중점을 두며 5개 프로세스 그룹과 10개 지식 영역으로 구성되어 있다. 그러나 7판은 프로젝트 성과 달성 중심으로 이를 위한 12개 원칙과 8개 성과 영역으로 나뉘어 있다.
 
🚩 Agile 및 하이브리드 방법론 강화
: 6판은 Agile 방법론의 기초적인 내용만 다룬다면 7판은 변화와 불확실성이 높은 현실 프로젝트 환경에서 복잡성의 증가에 대응하고 시간과 비용을 절감하기 위해 Agile 및 하이브리드 프로젝트 관리 기법을 상세히 다룬다. 
🚩 최신 기술 동향 및 도구 반영
: 7판은 데이터 분석, 인공지능, 원격 협업 및 전자 문서 관리와 같은 최신 기술, 도구 및 실천을 다루며 PM 들이 새로운 도구와 기술을 활용, 더욱더 효과적으로 프로젝트를 관리할 수 있도록 지원한다.
🚩 유연성/적응성 향상
: 6판은 프로젝트/프로세스 중심의 접근 방식을 따르나 7판은 원칙/프로젝트 성과 도달에 초점을 맞추어 적응력이 뛰어난 방식의 프로젝트 관리가 가능하도록 지원한다.
 
🚩 조직 가치 창출 중점
: 7판은 PM과 팀이 프로젝트 이해당사자들과 협업, 조직 가치의 향상을 목표로 프로젝트 관리 및 프로젝트 실천 방법을 최대한 활용하도록 한다. 
🚩역할, 책임 및 관련성의 명확성 향상
: 7판은 PM과 팀원 역할, 책임 및 기대치를 명확히 정의, 설명하여 다양한 프로젝트 상황에 따라 업무를 조율할 수 있도록 지원한다. 
 
위와 같이 7판은 그 이전 판에 비해 PM과 팀원이 프로젝트 상황과 조직의 가치에 따라 유연하게 대응할 수 있도록 원칙과 성과 영역이 추가되었고, 특히 가장 큰 차이점이라고 볼 수 있는 Agile 방법론과 하이브리드 프로젝트 관리 방법론을 강화하고 프로젝트 체계와 구조를 개선했다. 또한 최신 기술 동향을 반영한 새로운 내용으로 보다 효과적인 프로젝트 관리를 지향한다. 이는 빠르게 변화하는 사업 환경에서 프로젝트를 성공시키기 위한 필요 지식과 능력을 확보하는 데 도움을 준다.
 
 

PMBOK Guide 6th, 7th edition

 

그렇다면 공통점은 뭘까?
PMBOK은 모든 프로젝트 관리에 필요한 핵심 원칙, 진행 과정, 지식 영역 등 전반을 다루며 프로젝트 관리에 대한 총체적인 이해와 능력향상을 목적으로 한다. 이는 버전과 무관하게 프로젝트 관리에 대한 기본 개념, 이해의 통일성과 안정성을 강조하고 정해진 기준에 따른 프로젝트 관리 지식 영역 및 과정 그룹 구성을 통해 일관성을 유지하는 것이다.
 
✔️ 프로젝트 관리 개념론
: 프로젝트 관리 개념, 관리 요소, 관리 주도 및 이해당사자 등 주요 개념과 프로젝트 관리 이론 포괄

✔️ 프로젝트 관리 과정 그룹 및 지식 영역

: 프로젝트 전개 과정의 5개 프로세스 그룹 및 10개 지식영역을 다룸

✔️ 프로젝트 성과

: 프로젝트 성과 평가와 기록, 프로젝트 평가 인프라 및 관리 도구, 기술, 학습, 지속적 개선, 보안 등 기타 제반 사항을 다룸

 

PMBOK 7판에서 추가된 Agile과 Hybrid

7판의 가장 특징적인 2가지는 Agile 방법론과 하이브리드 프로젝트 관리 방법론이다. 이는 Agile 방법론이 IT 프로젝트뿐만 아니라 다양한 분야의 프로젝트에서도 많이 사용되고 있는 점과 프로젝트 관리 도구와 기술이 점점 다양화되고 있기 때문에 앞으로도 그 방법과 내용들이 계속 강화될 것으로 보인다.

♾️ Agile 방법론
: 기존의 예측적 방법론들과는 달리 반복적, 적응적인 접근 방식을 강조한 것으로 이는 빠른 변화와 불확실성이 많은 프로젝트에 적합하다는 평이며 Scrum, Kan ban, Extreme Programming 등이 대표적인데 다음과 같은 특징이 있다.

– 반복 주기: 프로젝트를 여러 개 짧은 주기로 나누어 진행, 각 주기는 실행, 검토, 조정 등의 단계 포함
– 고객 중심: 고객 요구사항을 최우선으로 요구사항이 변경될 수 있는 가능성을 열고 유연하게 대응
– 자기조직화 팀: 팀원들 간 협력으로 문제를 해결하고 프로젝트 목표를 달성하기 위해 자력으로 조직화
– 반복적 검토와 개선: 각 반복 주기의 끝에서 프로젝트 결과물 검토, 필요한 개선 반영

 
♾️ Hybrid 프로젝트 관리 방법론
: Agile 방법론과 기존 방법론을 혼합 사용한다. 이는 특정 프로젝트에 가장 적합한 방식을 찾아 사용하고자 하는 것으로 모든 프로젝트가 상이하기 때문에 필요에 따라 유연하게 적용하는 것에 방점을 둔다. 

– 유연성/적응성: 프로젝트 특성 및 요구사항에 따라 최적의 접근 방식 선택, 높은 프로젝트 성공률 확보
– 통합적 관리: Agile과 예측적 방법론 통합, 프로젝트를 효율적으로 관리하고 이해관계자들과의 의사소통 개선
– 자원 활용 최적화: 각 프로젝트에 가장 부합하는 방법론 선택, 자원의 효율화 추구

 

PMBOK 8판?

8판은 6판과 7판을 합친 내용으로 예상하는데 주요 내용은 다음과 같다. 자세한 것은 좀 더 있어봐야겠다.
 
– Adopt a holistic view
– Focus on value
– Embed quality into processes and deliverables
– Be an accountable leader
– Integrate sustainability within all projects areas
– Build on empowered culture
 
– 프로젝트 정의: A temporary initiative in a unique context undertaken to create value.
 
 
 
 
※ PM은 복이 있어야..
PM은 여러 지식과 자질을 겸비해야 한다. 특히나 태도를 갖추고 예의를 갖춘, 덕장이자 용장, 지장이면서 복(福)장이길 희망한다. 그 기저에는 복(BOK)을 갖추고서 준비를 해야한다. 어렵지만 이 길을 가고자 한다면 사람에 대한 공부, 나에 대한 성찰 그리고 복이 있고 복이 있길 바란다.

테일러링 (프로젝트 성공률 1% 높이기)

테일러링(Tailoring) 이란?

소프트웨어 개발은 소프트웨어를 생성하고 유지하는 과정으로 다양한 방법과 기술이 사용되며 프로젝트의 특성에 따라 최적화된 방법과 기술을 선택하는 것이 매우 중요하다. Tailoring은 특정 프로젝트의 요구 사항에 대하여 소프트웨어 개발 프로세스나 방법론을 적절하게 조정하고 필요 활동을 가감하는 것이다. 다시 말해, 소프트웨어 개발 프로세스는 규모, 복잡성, 요구사항, 조직 문화 및 프로세스 등 여러 제약 조건에 따라 달라지는데 이러한 요소를 고려하여 프로젝트에 가장 적합한 프로세스를 선택, 조정하는 것을 의미한다.
 
이런 조정의 조치는 소프트웨어 개발 프로젝트의 성공에 핵심적인 요소이다. 모든 것이 목표를 지향하고 나아가지만 100% 수행될 수는 없다. 그래서 프로젝트 진행 중에 발생하는 각종 위험을 줄이고, 품질을 향상하며, 시간과 비용을 단축할 수 있는 방법으로 우리는 Tailoring을 한다. 그래서 Tailoring은 프로젝트 초기 단계에서 고려하고 실시하여야 한다. 프로젝트가 시작되면 진행 중 반드시 새로운 요구사항이 나올 수 때문에 Tailoring을 통해 이러한 요구사항을 미리 반영하는 것이다.
 
 

Tailoring 종류

Tailoring에는 몇 가지 종류가 있으며 이를 통해 부분별로 최적화를 진행할 수 있다. 이는 프로젝트의 특성, 목적, 예산, 일정, 규모, 복잡성, 기술적/사업적 요구사항, 개발역량, 도구, 조직문화 및 각종 제약조건에 따라 고려되고 선택될 수 있다.
 
🚩프로세스 Tailoring
: 소프트웨어 개발 프로세스는 소프트웨어를 개발하기 위한 일련의 단계와 활동으로 구성되어 있는데 이 특성에 맞게 소프트웨어 개발 프로세스를 조정하여 프로젝트 규모에 따라 단계와 활동을 강화 또는 제거하여 효율적인 운영을 하는 것이다.
 
🚩 기술 Tailoring
: 프로젝트 기술 또한 프로젝트의 특성에 맞춘다. 무조건 고급기술을 지향하는 것이 아니라 요구 성능에 적절한 기술을 도입하여 반영하고 운영하는 것이다. 이럼으로써 불요한 기술 비용 등을 줄일 수 있다.
 
🚩 사람 Tailoring
: 소프트웨어 개발 프로젝트의 인력은 프로젝트의 특성에 맞게 조정해야 한다. 개발 프로젝트 난도가 높다면 고경력의 인력을 보다 많이 투입할 수 있는 것이다.
 
 

Tailoring 절차

Tailoring은 개발 프로젝트의 특성을 고려하여 프로젝트의 목표, 범위, 일정, 예산, 인력 및 기술에 따라 어떤 방법과 기술이 필요한지를 판단해야 한다. 이를 위해 다음의 단계를 거친다.
 
✅ 요구 사항 분석

: 프로젝트의 목표와 요구 사항을 분석하고 이해한다. 이를 위해 이해당사자들과의 의사소통, 현장 조사, 문서 검토 등을 수행하여 요구 사항을 명확히 이해하고 프로젝트의 고유한 요소를 파악한다.

✅ 방법론 선택
: 요구 사항 분석을 토대로 조정이 필요한 영역을 파악하고 이에 따른 방법론을 선택한다. 이는 기준이 되는 표준 방법론에서 일부 요소를 선택하거나 다른 방법론을 조합할 수도 있다. 

✅ 프로세스 조정

: 방법론을 조직과 프로젝트에 맞게 조정한다. 이 과정에는 수명주기 단계 추가 또는 제거, 프로세스 세부 조정, 가이드라인과 절차 수정 등이 포함될 수 있다.

✅ 도구와 기술 선택

: 조정된 방법론에 맞는 도구와 기술을 선택한다. 프로젝트에 필요한 특정 기능을 구현하기 위해 특정 개발 도구나 프레임워크를 도입할 수도 있다. 어느 하나를 끝까지 고수할 필요는 없다.

✅ 팀 구성원 역할 및 책임 조정

: 조정된 방법론에 따라 팀 구성원의 역할과 책임을 조정한다. 팀 구성원은 방법론에 맞게 업무를 수행해야 하고 원활한 의사소통과 협업을 진행해야 한다. 팀원들의 역량과 역할에 따라 재조정 또는 새로운 역할을 부여할 수 있다.

✅ 프로젝트 관리 및 모니터링

: Tailoring 된 방법론으로 프로젝트를 관리, 모니터링한다. 이는 일정 관리, 리스크 관리, 품질 관리, 의사소통 관리 등을 포함으로써 프로젝트 진척 상황을 주기적으로 검토하고 필요한 조정을 수행하여 프로젝트 목표 달성을 보장한다.

✅ 지속적 개선

: Tailoring은 프로젝트 진행 중에도 지속해서 개선되어야 한다. 이를 통해 방법론의 효과성과 프로세스의 개선점을 도출하고 반영한다. 
 




 

Tailoring 효과

소프트웨어 개발은 정말 복잡한 과정이다. 이러한 개발 프로젝트를 성공적으로 수행하려면 다양한 요소를 고려해야 하는데 Tailoring이야말로 최상의 결과가 나오도록 모든 것을 잘 매만져 주는 일이다. 이를 통해 프로젝트는 프로젝트의 특성에 맞게 최적화될 수 있고 그 효과는 여러 가지로 나타난다.
 
✔️ 요구 사항 충족
: 프로젝트 특정 요구사항을 위해 방법론이 조정되면 큰 틀에서 매우 효과적인 방법론의 채택을 통해 프로젝트의 속도를 향상한다. 이때 방법론을 처음부터 끝까지 고집할 필요가 없으며 필요 부분에 대해서만 다른 방법론을 활용할 수도 있다.
✔️ 조직 맞춤화

: 고유한 사업적 요구 사항과 제약 조건을 가진 조직은 Tailoring으로 인하여 조직 내 체계를 활성화하고 조직에 맞는 색깔을 찾아 입힐 수 있다. 이에 따라 살아 움직이는 조직으로 보다 유연한 관리가 가능하다.

✔️ 자원 최적화

: 프로젝트 규모와 복잡성에 따라 초기 계획을 지속 관리하고 필요한 자원과 비용을 효과적으로 조절할 수 있다. 즉, 불필요한 자원의 집행을 사전에 확인, 관리할 수 있는 역량을 갖추어 비용과 시간을 절감할 수 있다.

✔️ 프로젝트 성공

: 프로젝트를 성공시킬 수 있는 확률이 높다. 방법론의 수정으로 조직과 프로젝트에 최적화되고 보다 더 적절한 접근 방식에 따라 위험을 완화하고 품질을 향상할 수 있다. 이는 궁극적으로 고객 만족도를 높인다.
 
 
 
※ Tailoring 한계
어떻게 보면 프로젝트 시작과 함께해야 할 Tailoring. 그만큼 중요하다는 것을 알지만 이를 실제로 수행하는 프로젝트나 조직은 매우 드물다. 물론 하기는 하지만 공식적인 형태를 갖추고 제대로 하는 곳이 별로 없단 이야기다. 꼭 이렇게 부르지 않더라도 모든 단계, 조직에서 Tailoring을 하는데 이것이 왜 힘들까? 일단 시간이 없다. 모두 바쁘다. 프로젝트가 본격 궤도에 오르면 앞만 보고 가기에도 힘겹다. 또한 사람이 없다. Tailoring을 제대로 하려면 전문가가 필요하다. 프로젝트와 방법론 전반을 꿰찬 인력은 갈수록 부족하다. 그러다 보니 결국엔 돈이다. 그런데 이런 예산을 기획 단계에서 고려하여 잡아주는 프로젝트가 과연 얼마나 되는가? 결국 핑계? 핑계여서 하지 못한다 한들 해야한다. 누군가는..

PMO (프로젝트 성공률 1% 높이기)

PMO와 역할

PMO(Project Management Office)는 프로젝트와 관련한 관리 프로세스를 표준화하고 자원, 도구, 기법 및 방법론의 공유를 용이하게 하는 관리체계조직이다. PMO는 그 특성과 기능이 조직마다 다르고 같은 조직 내에서도 상이할 수 있으며 프로젝트 작업 지원 방법 또한 다를 수 있다.
 

PMO의 여러 형태와 유무를 떠나 중요한 한 가지는 일정, 비용, 품질, 위험 등의 측면에서 프로젝트 관리를 개선함에 그 역할과 책임이 있다. PMO는 업무를 전략적 목표에 맞추는 데 있어 이해당사자들의 참여와 협업, 인재 개발, 프로젝트 투자 가치 실현 등 많은 역할을 수행한다. 

🚩 프로젝트 포트폴리오를 감독한다. 감독에는 프로젝트 시작을 위한 사례 요구, 프로젝트 제공을 위한 재정 및 자원 할당, 프로젝트 범위 또는 활동 변경 요청 승인과 같은 활동이 포함될 수 있다. 이는 프로젝트의 중앙관리를 지원하고 여러 프로젝트를 담당하여 관리하는 조직에 도움이 될 수 있다.
 
🚩 프로젝트 전달 방법의 일관성을 지원하는 프로젝트 관리 지침을 제공한다. 이는 교육 및 코칭과 함께 여러 지침, 템플릿 및 사례를 제공할 수 있다. 프로젝트에서 표준화된 접근 방식과 도구는 공통된 목적을 더욱더 촉진하고 프로젝트 문제의 의사 결정을 쉽게 한다. 

🚩 계획 활동, 위험 관리, 프로젝트 성과 추적 및 활동을 위한 프로젝트 지원 서비스를 제공한다. 이러한 서비스는 프로젝트에 대한 보다 직접적인 관리를 유지하고 지원을 원하는 독립적이거나 다양한 사업 단위가 있는 조직에서 활용한다.

🚩 평면적이고 고객 중심적인 접근 방식을 갖춘 조직에는 ACoE(Agile Center of Excellence) 이나 VDO(Value Delivery Office) 형태의 조직을 제언할 수 있다. 이들은 관리 감독 기능이 아닌 지원 멘토링 중심의 역할을 수행한다. 

 

주요 기능

PMO는 프로젝트 관리 표준을 제시하고 이를 프로젝트에 적용하며 전체 시스템의 일부로서 지원한다. 이는 프로젝트팀이 결과를 제공하기 위해 특정 기능이 필요한 것처럼 PMO도 마찬가지라고 볼 수 있다.
 
🚩 Big Picture 관점
프로젝트의 목표에 충실히 하는 것은 성공의 핵심 요소이다. 그렇지 않다면 프로젝트는 여러 사유로 목표를 벗어날 수 있다. 이를 위해선 지속적인 목표와 목적을 알리고 공유하며 조직의 전반적 성공을 위한 작업관리 및 평가로 다양한 의사결정을 도와줄 수 있는 정보와 지침을 제공한다.

🚩 성과 지향 역량 확보
프로젝트 관리 기능을 전문적으로 육성한다. 이를 통해 내외부 조직의 여러 이해당사자에 대한 평가를 진행하며 품질의 결과를 신속하고 효과적으로 생성하기 위해 프로젝트의 고유한 특징들을 바탕으로 성과가 더 나올 수 있도록 한다.

🚩 지속적 개선과 변경 관리
정기적인 프로젝트 결과를 공유한다. 이로써 프로젝트에서 얻은 귀중한 지식을 전파하며 참여한 팀원들에 대한 깊이 있는 학습 및 공유 활동으로 역량을 개선한다. 또한 세심한 변경 관리로 프로세스 업데이트, 기능 향상 및 프로젝트 관리를 지원하는 새로운 기술과의 연계를 구축하고 유지한다.

 




 

PMO의 진보

기업환경은 큰 불확실성, 빠른 변화, 더 치열해진 경쟁 구도, 더 많은 권한을 가진 고객으로 조직이 점점 더 복잡해지는 환경에서 기업가치를 창출해야 하는 어려움에 직면해 있다. 이는 수행되고 있거나 계획된 모든 프로젝트에 많은 영향을 끼치며 PMO를 통한 환경개척과 성공적 프로젝트를 위한 차별화된 변화를 원한다. 그에 따라 PMO도 변화를 해야 한다.

🚩 중요 동기 집중
프로젝트 동기는 조직과 프로젝트의 미래, 이해당사자와의 관계 및 역량에 상당한 영향을 미칠 수 있다. 이에 PMO는 그 역할이 관리 감독에서 의사소통을 조율하는 것으로 바뀌고 있다. 이러한 변화는 중요한 전략적 대응에 영향을 미칠 수 있는 프로젝트 성과, 위협 및 기회에 대한 정확한 통찰력을 제공하고 새로운 문제에 대한 명확성과 진로 수정을 촉진하고 사업적 결과를 최대한 실현한다.

🚩 효과적 프로세스 구축
PMO는 낭비적인 단계를 추가하거나 가치 창출 프로세스를 무시하지 않고도 효과적인 의사소통과 협업, 지속적인 개선을 가능하게 하는 충분한 프로세스 및 관행 규칙을 설정하여 조직의 역량을 적절하게 조정한다. 여기에는 퍼실리테이터 중심의 조직화가 필요하고 명확한 R&R을 수행하도록 적극 지원한다.

🚩 핵심 인재 역량
재능 있는 팀원을 모집하고 유지하는 데 보다 적극적인 역할을 수행한다. 인력은 프로젝트를 성공으로 이끄는 가장 중요한 요소 중 하나로 프로젝트 및 조직 전체에서 기술, 전략, 관리 및 리더십 기술을 개발하고 육성한다. 이렇게 길러진 인력은 핵심 인재가 되고 인력풀에서 중장기적으로 관리하고 자산화한다.

🚩 변화 장려
조직의 경쟁 차별화 요소로서 조직의 성과 및 변화 관리에 대한 지원을 부족하지 않게 한다. 이는 모든 구성원에 대한 효과적인 동기부여이자 조직이 살아 움직일 수 있는 근간을 제시하고 그 맨 앞에 PMO가 서 있다. 이를 위해 다양한 이벤트와 정량적, 정성적 활동을 통해 관리 프로세스를 유기적으로 연계한다.

 
 
 
 
※ 그들만의 리그
신경을 쓰지 않는 팀원들이 다수이지만 그들이 누구냐고 묻는다면 그저 사무실 한쪽 방을 차지하고 있는, 맨날 문서만 들고 다니며 회의만 하는 사람들이라고들 한다. 물론 직접 만날 일도 별로 없을뿐더러 대부분 연장자이거나 상사들이기 때문에 내 관심밖에 머물 수 있다. 하지만 그들이 내어놓는 결과물들은 프로젝트 진행에 매우 중요한 역할들을 한다. 그러니 멀리 있더라도 내 관심 영역 안으로 끌어들여 볼 필요가 있으며, 그 사무실에 앉아 있는 ‘그들’도 밖으로 나와 볼 필요가 있다. 정작 필요한 의사소통이 여기에서 제대로 되고 있는지 살펴볼 일이다.

구조적 분석 (소프트웨어 공학)




구조적 분석

소프트웨어 개발에 있어 요구분석 단계는 중요하고도 어려운 단계이다. 많은 정보가 수집되어야 하며 의사소통의 어려움도 극복해야 하는 숙제 중 하나다. 이러한 작업을 증명하기 위한 방법은 매우 다양하다. 그중 프로세스 사이의 데이터 흐름을 파악하여 요구사항과 시스템을 파악하는 방법으로 구조적 분석이 있다. 구조적 분석(Structural Analysis)은 시스템의 기능적 요구사항을 구조화하고 조직화하는 단계이다. 이를 통해 요구사항 간의 관련성과 의존성을 이해하고 분해된 요구 모듈 간 관계를 분석하여 시스템의 구조를 설계할 수 있다. 구조적 분석은 데이터 흐름 다이어그램(DFD), 상태 전이 다이어그램, 클래스 다이어그램 등의 모델링 기법을 활용하여 수행된다. 전통적 방법으로서 이 단계에서는 요구사항이 어떻게 상호작용하고 구성되는지를 시각화하여 파악한다.

소프트웨어 개발 프로젝트 초기 단계부터 요구사항을 명확하게 이해하고 효과적으로 관리할 수 있는 구조적 분석은 궁극적으로 프로젝트의 성공 확률을 높일 수 있다. 이 방법은 크게 다음과 같은 단계로 수행되고 여기에 쓰이는 도구도 확인한다.

  • 요구사항 분해
  • 요구사항 상호 연계
  • 요구사항 계층 구조화
  • 요구사항 흐름도

 

  • 데이터 흐름도(Data Flow Diagram, DFD):
    • 사용자 요구사항 기반으로 데이터가 시스템 내에서 어떻게 흐르는지 도식화하며 프로세스(원 또는 둥근 사격형), 외부 엔티티(사각형), 저장소(열린 사각형), 데이터 흐름(화살표) 등을 기호로 하여 시스템 데이터 흐름을 구조화
    • 시스템 모델링에 중요한 추상화와 단계적 분해의 원리를 적용하여 하향식 분할을 통해 복잡한 문제를 작고 독립적 문제로 나누어 하나씩 해결할 수 있는 방법으로 접근
    • 서로 다른 단계 사이 자료 흐름은 표현에 일관성이 필요하고 완벽성 검사와 일관성 검사 시행
    • 크기가 너무 커진다면 프로세스를 그룹화하여 단계적으로 표현하며 하나의 분석에서 한 계층의 DFD만 작성하고 프로세스는 7개 전후로 포함되도록 함
  • 자료 사전(Data Dictionary): 시스템 내에서 사용되는 데이터 항목의 정의, 형식, 구조를 문서화하며 자료 사전은 데이터 항목들의 호환성과 일관성을 확인하고 중복을 제거
    • 일반적 언어사전과 형식은 동일
    • 자료요소 이름이 여러 단어 구성 시 자료사전 표제어에 밑줄 연결
    • 수식은 자료요소와 연산자(+, [], |, ”, 등)로 구성
  • 질의-응답 목록(Question and Answer List): 사전에 정해진 항목에 따라 요구사항을 구체화하는 도구로 시스템과 사용자의 상호작용을 정확하게 이해하고 구조화
    • 질문: 이해 관계자에게 특정 요구사항에 관한 질문 포함
    • 답변: 이해 관계자로부터 받은 답변 기록. 이 답변은 해당 요구사항에 대한 정보와 이해 관계자의 의견 표시
    • 질의자: 각 질문에 대한 원래 질문자 또는 요구사항 분석을 수행한 사람의 이름 기록. 의문 사항이 생길 경우 해당 정보의 출처 확인용
    • 날짜: 각 질문이나 답변이 만들어진 날짜 기록. 문서 갱신/추적용
    • 참고: 다른 문서나 자료와의 연결 표시
    • 상태: 질문이나 답변의 상태 표시, 추적
    • 비고: 해당 질문이나 답변에 대한 추가 설명이나 주석 기록
  • 유스케이스(Use Case): 사용자와 시스템 간의 상호작용을 나타내는 시나리오 기반 기술로 특정 목적 달성을 위한 사용자 관점에서 시스템과의 상호작용 과정 기술
    • 액터(Actor): 시스템 내에서 주요 기능을 수행하는 역할 또는 시스템과 상호작용하는 주체로 시스템 사용자, 다른 시스템, 외부 장치 등
    • 유스케이스 명(Use Case Name): 특정 기능 또는 시나리오의 간결하고 명확한 이름으로 유스케이스를 식별
    • 설명(Description): 유스케이스의 목적과 내용을 간단 설명
    • 사전조건(Preconditions): 유스케이스가 시작되기 전에 충족되어야 하는 조건 설명
    • 주요 시나리오(Main Scenario): 유스케이스의 핵심적인 동작과 순서 설명으로 시스템과 액터 간의 상호작용을 순차적으로 나열
    • 대안 시나리오(Alternative Scenarios): 주요 시나리오 이외의 다양한 상황에 대한 시나리오를 설명하며 주로 예외 상황이나 오류 처리 사용
    • 결과(Results): 유스케이스의 완료 후 기대되는 시스템의 상태 변화나 출력물 등 결과 기록

 




분석 과정

구조적 분석의 세부적인 과정은 크게 4단계로 나눠볼 수 있다. 

🚩 단계 1: 요구사항 수집 및 문서화

시스템에 대한 요구사항을 수집하고 구조화 및 문서화한다. 이 요구사항은 고객, 사용자, 도메인 전문가 등과의 인터뷰, 설문조사, 관찰 등 다양한 방법으로 얻을 수 있으며 최종적으로 기능적 요구사항(시스템이 수행해야 하는 작업)과 비기능적 요구사항(성능, 안전성, 보안 등)으로 구분될 수 있다. 이 과정을 통해 모호한 내용을 명확히 하고 요구사항 간의 관련성과 의존성을 파악, 중복되거나 충돌하는 요구사항을 논리적 블록으로 그룹화, 해결한다.

 

🚩단계 2: 데이터 흐름 다이어그램 작성

명세화된 요구사항을 기반으로 소프트웨어의 핵심 문제를 파악하고 분석할 수 있는 구조로 정리한다. 이때 데이터 흐름도(DFD), 자료사전, 프로세스 명세 등의 도구를 활용한다.

  – 주요 프로세스 식별: 수집된 요구사항을 기반으로 시스템 내의 주요 기능적 프로세스 식별하며 DFD로 표현 (시스템의 입력, 출력, 처리 과정 포함)
  – 데이터 흐름 식별: 프로세스 간에 주고받는 데이터(정보) 흐름 식별
  – 데이터 저장소 식별: 시스템 내 사용되는 데이터 저장소를 식별하는데 이는 데이터의 정의, 속성, 구조 등을 포함하고 이를 데이터 요소 간의 관계와 종속성을 파악

 

🚩단계 3: 데이터 흐름 다이어그램 작성 및 분석

분석된 요구사항이 사용자의 기대와 일치하는지 검증하여 문제가 없는지 확인하는 단계로 사용자와 지속적인 의사소통으로 유스케이스 테스트나 프로토타입 방식을 사용하여 실제 사용자의 반응을 수집할 수 있다. 특히 요구사항과 부합하며 일관성 있는 모델을 구축하는 것이 중요한데 이 결과를 바탕으로 소프트웨어의 전체적인 아키텍처를 설계할 수 있다. 특히 모듈화, 계층화, 컴포넌트 구조 등을 고려하여 시스템 구조를 결정한다.

  – 0레벨 DFD 작성: 주요 프로세스, 데이터 흐름, 데이터 저장소 등을 기반으로 0레벨 DFD를 작성하며 이 다이어그램은 시스템의 전체 구조를 보여주고 각 프로세스와 데이터 흐름의 관계를 가시화
  – 상세화: 0레벨 DFD를 기반으로 더 상세한 1레벨 DFD를 작성하여 프로세스를 세분화하고 데이터 흐름을 더욱 구체적으로 표현
  – 유효성 검사: 작성한 DFD를 검토, 논리적 오류나 모순점이 있는지 확인 

 

🚩단계 4: 문서화 및 의사소통

작성한 DFD를 문서화하여 요구사항 명세서나 설계 문서에 포함한다. 이에 개발팀 간 의사소통을 원활하게 하고 시스템 구조를 이해하는 데 도움을 준다. 요구사항이 변경되거나 갱신이 되면 요구사항 관리를 통해 변경된 요구사항에 따른 작업의 우선순위를 조정하고 추적 관리한다. 이 문서들은 개발 및 테스트 과정에서 참고 자료로 활용한다. 다시 말해 문서화와 의사소통의 중요성은 각기 다음과 같다.

  • 명확한 이해: 문서화로 프로젝트팀의 구성원, 고객, 스테이크 홀더 등 모두가 요구사항을 명확하게 이해 가능
  • 기능 및 범위의 정의: 문서화로 시스템의 기능과 범위가 정확하게 정의되며 프로젝트 방향성 보장
  • 변경 관리: 요구사항이 변경될 경우, 문서화로 변경 내역을 추적하고 관리 가능
  • 품질 향상: 문서화된 요구사항은 개발자들이 시스템을 설계하고 구현할 때 일관성 있고 정확한 정보를 참조할 수 있도록 지원

 

  • 이해 관계자 간의 의사소통: 프로젝트 구성원, 고객, 이해당사자 간 이해로 프로젝트 목표를 달성하기 위한 방향을 정하는 중요 기반
  • 오해 방지: 의사소통으로 모든 이해 관계자들이 동일한 의미로 요구사항을 이해할 수 있도록 지원하여 오해나 혼란이 줄어들면서 프로젝트 품질 향상
  • 피드백 수렴: 의사소통을 통해 고객이나 사용자의 피드백을 수렴하고 반영하여 요구사항의 정확성과 적절성 향상
  • 변경 관리: 프로젝트 진행 중 요구사항이 변경 시 이를 이해 관계자들과 공유하여 일관성을 유지하고 변경에 따른 영향을 평가 가능




소프트웨어 공학이란 (소프트웨어 공학)

“소프트웨어가 소수의 탁월한 능력을 갖춘 프로그래머에 의해 만들어지던 규모를 넘어서면서 소프트웨어 개발의 성패는 그 집단의 소프트웨어공학에 대한 숙달 정도에 크게 좌우된다.”

소프트웨어 공학의 첫 등장은 1968년 NATO가 지원한 한 콘퍼런스에서 시작되어 꽤 오랜 시간이 흘렀다. 이는 컴퓨터 소프트웨어 개발, 운영, 및 유지 보수에 관련된 체계적이고 표준화된 접근법에 대한 연구와 적용 기술로 이해된다. 이를 통해 고품질의 소프트웨어를 생산하고 시간과 비용을 최소화하며 고객과 사용자 요구사항을 충족하는 것이다.

그 결과물들은 공학적 원칙과 가이드라인으로 신뢰성, 확장성, 효율성, 보안성 및 사용성의 향상을 기대한다. 그래서 생명체와 같은 생명주기를 바탕으로 여러 기법, 도구 및 방법론이 고안되고 쓰이고 있다. 하지만 학문적 공학의 위치는 실제 현장에서 일하는 개발자들에게는 다소 생경하다. 이는 급변하는 IT 환경, 수요 대비 공급을 원활히 할 수 없는 교육적 생태계, 개발인력에 대한 대우 및 여러 편견 등으로 눈앞에 급한 불만 끄면 된다는 식의 대응에만 몰두한 결과이다.

현실은 현장에서 체득되는 지식도 있지만 학문적 고찰을 통한 지식과 지혜가 없이는 원하는 성과를 만들어낼 수 없다. 이는 수많은 무기를 지니고는 있으나 정작 아무런 전략, 전술도 세우지 않고 무작정 전장에 나서는 장수와 다를 바가 없다. 이제 개발자들은 모두 다시금 소프트웨어 공학을 찬찬히 살펴봐야 할 이유가 여기에 있다.

 

시작

무엇을 시작하든 제일 중요한 것은 “용어”를 제대로 알고 이해하는 것이다. 같은 용어라도 장소와 시간, 쓰임새 및 사람에 따라 모두 다를 수 있기 때문에 가장 먼저 다뤄야 할 용어를 정의하고 눈높이를 맞춰야 한다.

✔️ 프로그램
  : 프로그래밍 언어로 작성된 source code (정적)
✔️ 소프트웨어
  : 프로그램(source code)과 프로그램의 개발, 운용, 보수에 필요한 관련 정보 일체, 즉 산출물, 사용자 매뉴얼 등 모든 것을 포함한 것 (동적)
✔️ 시스템
  : 필요한 기능을 실현하기 위해 관련 요소들을 어떠한 법칙에 따라 조합한 집합체

시스템은 모든 것은 포괄하며 소프트웨어도 시스템 내에서 다른 요소들과 상호 동작하는 하나의 시스템으로 볼 수 있다. 이러한 시스템의 기능과 성능이 잘 발휘되려면 시스템을 구성하는 모든 요소, 서브 시스템이 잘 작동되어야 한다. 즉, 제대로 만들어져야 하는데 소프트웨어의 경우 눈에 보이지 않는 비가시성과 복잡성을 모두 가지고 있다.

물리적인 하드웨어는 눈부시게 발전하면서 구체적인 성과들을 보여주는데 소프트웨어는 그렇지 못하다. 그러다 보니 소프트웨어를 등한시하게 되었으나 하드웨어를 작동시키는 것이 소프트웨어임을, 그 수요가 하드웨어 못지않게 폭발하면서 수많은 수요를 따라가지 못하게 되었고 여기서 소프트웨어 위기라는 것이 발생한다.

 

소프트웨어 위기

이러한 위기는 소프트웨어가 가지는 비가시성과 복잡성을 포함한 또 다른 특징이 있는데 첫 번째. 소프트웨어는 제조가 아닌 개발이라는 것이다. 제조와 개발이 비슷해 보이지만 가장 큰 차이는 제조는 능력별 결과물의 차이가 거의 없지만 개발은 개인의 능력이 매우 중요시되고 그 능력에 따라 결과물의 차이가 크게 난다는 것이다. 둘째. 소프트웨어는 소모되는 것이 아니라 품질이 떨어진다는 것이다. 소프트웨어는 소모성 상품이 아니다. 다만 계속 사용됨으로써 지속적인 사용자의 요구사항을 반영해야 하는데 이것이 여러 사유로 원활하지 않다면 품질은 자연히 떨어지게 되는 것이다. 셋째. 소프트웨어 관리 기술이 전체가 아닌 일부만 사용된다. 즉 개발 프로젝트에서 활용하는 관리지식체계(PMBOK)가 있는데 이를 필요한 부분만 일부 적용함으로써 그 효과를 제대로 보지 못하는 것이다.

✔️ 소프트웨어 위기
  : 소프트웨어 생산성에 대한 심각한 인식 

소프트웨어 위기는 생산성 외에도 많은 문제점을 가지고 있었다. 소프트웨어 개발 프로젝트는 예산을 초과하기 일쑤이고 개발일정의 지연도 반복되었다. 중요한 소프트웨어 개발에 필요한 개발자는 각자 가지고 있는 역량의 편차로 그 결과물의 수준을 예측 할 수가 없었으며 이는 결국 품질문제로 비화되었다. 다른 공산품과 달리 불량품에 대한 관리나 품질보증에 대한 정량적 개념이 부족했고 고객은 인도된 결과물을 신뢰할 수 없었다. 이러한 상황에서 문제를 재인식하고 타계하고자 하는 노력으로 공학적 접근이 대두되었다.

✔️ 공학
  : 기술적 문제를 발견하고 기술적 해결책을 제시하는 학문으로 과학적이고 잘 조직된 지식을 현실적인 문제해결에 체계적으로 적용하는 것

공학의 특성은 자연과학하고 다르며 여러 제약사항이 있는데 우선 기간이 정해져 있고 예산도 정해져 있다는 것이다. 이러한 조건 하에서는 결국 최종적으로 기간을 얼마나 단축하고 보다 적은 비용으로 가능할 수 있는가에 대한 과학적 해법을 마련하는 것이다. 이 관점에서 소프트웨어를 개발하는 과정에서, 공학에서 쓰이고 있는 원리들을 적용하여 개발을 해보겠다는 것이 소프트웨어 공학이라고 볼 수 있다. 보다 효율적인 개발을 통한 생산성을 높이고 품질 좋은 소프트웨어를 제작하려는 것이 소프트웨어 공학의 취지이자 목적이다.

 

소프트웨어와 공학

✔️ 소프트웨어 공학
  : 소프트웨어 개발에 필요한 이론이나 기술, 도구들에 관하여 연구하는 학문

다시 말해 소프트웨어 공학은 “품질 좋은 소프트웨어를 최소의 비용으로 계획된 일정에 맞춰 제대로 개발하는 것”을 말한다. 이러한 품질과 생산성 두마리 토끼를 모두 잡아야 하는 소프트웨어 공학은 방법, 도구, 프로세스 및 페러다임을 가지고 있다. 이는 소프트웨어 개발을 위해 생명주기를 통한 단계별 방법들을 연구하고 효율성과 효과성을 획득하기 위한 적절한 도구의 사용, 사용자 요구사항에 맞게 개발하기 위한 절차와 단계들, 그리고 상황에 맞게 적용가능하고 유연한 철학이 그것이다.

✔️ 방법: 어떤 결과를 생성하기 위해서 적용하는 기법과 절차
✔️ 도구: 더 좋은 방법으로 작업하기 위한 기기 또는 자동화된 시스템
✔️ 프로세스: 도구와 기법을 사용하여 작업하는 순서
✔️ 패러다임: 개발 스타일

이러한 4가지 요소를 바탕으로 소프트웨어는 유기체와 같은 생명주기를 갖는데 이는 계획 단계, 분석 단계, 설계 단계, 구현, 테스트, 유지 보수하는 과정으로 소프트웨어 개발 과정에서의 생산성을 향상시키고 품질 좋은 소프트웨어를 생산하여 고객을 만족시키려고 하는 최종적인 목표에 방점을 찍는다. 생명주기 내 각 단계는 일련의 활동을 포함하며 전체 소프트웨어 프로젝트에 대한 계획과 관리를 수행하고 개발 과정의 체계적인 구조화와 일정 관리를 지원한다.

✔️ 소프트웨어 생명주기(Software Development Life Cycle)
  : 소프트웨어 제품 개발에서 시작하여 최종 사용자에게 배포되고, 유지 보수 및 폐기될 때까지의 전 과정으로 일반적인 작업단계는 다음과 같다.

  – 요구분석: 고객과 사용자의 요구와 기대를 조사하여 프로젝트 목표를 정의
  – 설계: 소프트웨어 기능, 구조, 데이터 흐름, 인터페이스 등을 결정
  – 구현(개발): 설계 문서를 토대로 소프트웨어 코드 작성
  – 테스트: 생길 수 있는 오류와 결함을 찾아내고 수정
  – 배포: 개발된 소프트웨어를 최종 사용자에게 전달, 설치하여 사용할 수 있도록 함
  – 유지보수: 소프트웨어가 효율적으로 동작하도록 지속적으로 업데이트하고 개선
  – 폐기: 소프트웨어 수명이 끝난 경우, 안전하게 제거하고 관련 데이터와 자원을 처리

 


※ SWEBOK(Software Engineering Body of Knowledge)
  : ISO/IEC 국제 표준화 기구와 IEEE(Institute of Electrical and Electronics Engineers)가 승인, 지원하고 전 세계 소프트웨어 전문가들이 협력하여 개발한 소프트웨어 공학 관련 전문 지식의 체계적 모음으로 소프트웨어 공학자들이 필요로 하는 기본 원칙, 개념, 기술 및 실천 방법을 포괄한다. 여기서 다루는 다양한 주제와 영역은 SDLC의 여러 단계에 지침을 제공하고 이는 소프트웨어 개발 및 관리의 범위와 효율성을 높이는 데 도움이 되며 소프트웨어 개발자에게 필요한 기술, 능력 및 전문적 역량을 개발하는 데 중요한 역할을 한다.

※ PMBOK(Project Management Body of Knowledge)
  : 프로젝트관리협회(PMI:Project Management Institute)에서 개발한, 프로젝트 관리에 관한 전문 지식의 체계적 모음으로 ‘프로젝트관리지식체계’라고 하며 PM과 팀원들이 프로젝트를 계획, 실행, 통제하고 성과를 평가하는 데 필요한 일련의 표준 및 가이드라인을 제공한다. 이를 통해 프로젝트를 실천하면 프로젝트의 성공 가능성을 높이고 리스크를 최소화하는 데 도움을 준다.