SI 의미와 프로세스

SI는 System Integration(시스템통합) 약자로, 그 자체로 부정적인 의미가 아니며 과거 하드웨어에 소프트웨어가 포함되어 납품되어 타사의 시스템에 통합되는 형태를 지칭한것으로 보이며

시간이 지남에따라 이러한 형태도 하드웨어보다 소프트웨어의 비중이 커지게 되었지만 소프트웨어 개발 아웃소싱 을 지칭하는 단어로 한국에만 존재 하는 IT용어가 되었습니다.

오늘날의 소프트웨어의 요구사항은 점점복잡해지고,요구사항이 변경되는 불확실성이 점점 늘어나고 있으나

SI를 다루는 개발방식은 과거 하드웨어가 포함된 기초적인 소프트웨어를 다루는 방식인 제조납품 사용된 프로세스와크게 개선되지 않았으며 ( 제조기준 납품/품질관리/원가기준 투입단가등....)

오히려 소프트웨어 납품이, 제조납품 절차보다 더 열악한 하도급형태인 경우도 많습니다.

외주개발,아웃소싱,갑을병정,남의 시스템 레거시시스템 유지보수등 일반적으로 SI(+SM)는 국내에서 안좋은 의미(속성)로 해석되는 케이스가 일반적입니다.

 

SI프로젝의 부정적 요소 VS 긍적적 요소

기업문화및 계약에따라 긍정적 요소도 있을수 있지만, 대부분 부정적 요소가 훨씬 많으며 SI가 나쁘다란 관점이 아닌 SI는 도대체 뭐하는 녀석인가?

하는 관점에서 이 아티컬을 정리해보았습니다. 

SI 라이프 사이클

---

 

RFI라고 하면, 인적 네트워크 등을 통해 외주 업체를 미리 만나 회사 소개나 제품/서비스 소개를 받는 것에 해당되겠지만
이는 비공식적인 절차이므로 유무형의 압력에 노출되기 쉽다. 따라서 미리 업체들에게 RFI를 보내,
진행하고자 하는 업무(프로젝트)에 대한 정보를 수집할 필요가 있다.
따라서 RFI에는 많은 요구사항을 담지 않는다. RFI에서는 추진하고자 하는 업무(프로젝트)에 대한 간단한 개요/목적/예상 기간 정도를 표시하고,
이에 맞추어 외주 업체에 대한 정보, 제품/서비스에 대한 정보, 간단한 시장 동향, 주요 경쟁사 정보를 요청할 수 있다.
그리고 RFI에 대한 회신으로 20페이지 이내의 워드 문서로 받는 것이 좋다.

 

RFP로 넘어간다. RFI를 통해 수집된 정보를 바탕으로 실제 해당 프로젝트를 추진할 수 있도록 구체적인 정보들을 요청해야 한다.
RFP 단계에 참여하는 외주 업체는 모두 해당 업무나 프로젝트를 수행할 가능성이 있는 업체이므로, 최대한 자세하고 구체적이고 정확하게
RFP를 작성하여 요청해야 한다.RFP가 구체적일수록, 제안서의 품질인 높아지고 예산에 대한 이견도 줄어들 수 있기 때문이다.
또한 프로젝트를 진행하는 동안의 의견 충돌이나 갈등을 미연에 막을 수 있다.
RFP에는 해당 업무(프로젝트)에 대한 자세한 정보, 추진 일정, 예산, 그리고 제안서의 목차, 제안 평가 기준 등을 구체적으로 명시해야 한다.
RFP 작성부터 해당 외주 업무(프로젝트)의 성공 여부가 달려있다고 해도 과언이 아니다. RFI를 하는 이유도 실은 RFP를 제대로 작성하기 위해서이다.

 

SI에서 잘 정돈된 개발 라이프 사이클및 프로세스를 가지고 있으며 이 절차를 이해하고 수행하는것은

좋은  경험이 될수 있습니다. 그리고 비즈니스 규모가 어느정도있고 가치가 있다고 한다면

큰 프로젝트를 완주한것은 대단히 좋은 경험이 될수 있습니다.

개빌프로세스로 는 폭포수모델을 주로 따르지만, 항상 그런것은 아닙니다.

폭포수모델 역시 나쁘다가 아니라, 과거 소프트웨어가 성공한 방식이기떄문에

이것에 대한 경험자체가 나쁜것은 아닙니다.

 

오늘날의 소프트웨어의 요구사항은 점점복잡해지고 요구사항이 변경되는 불확실성이 점점 늘어나고 있으나 폭포수 모델만이 한계가 있는 것은 분명합니다.

폭포수모델이 나쁘다 좋다가아닌, 애자일부타 시작하는 팀도 이것을 먼저 이해하는것에서 출발한다고 보여집니다. 

 

SI를 이해하기위한 폭포수모델의 이해

• 폭포수 모델과 한계점
• 폭포수모델의 한계와 애자일인식을 통한 우리만의 방식찾기