개발자에서 한회사의 프로젝트 관리자로 채용이 되었는데요.
처음엔 내부 요구사항 파악해서 개발사 의뢰 후 개발 착수 하려고 했는데 생각보다 대처 및 부족한 부분이 많을 것 같아 알아보다가 PI(Process Innovation) 컨설팅이 있다는 것을 알았습니다.
IT도 저 혼자입니다.
1.요구사항 수집 및 분석 > PI > SI > SM 이 맞는지? 아니면
2.요구사항 수집 및 분석 > SI > SM 이 맞는지? 아니면
개발자로 오래 일했지만 해당 관련하여는 고민이 되어 자문을 구하고자 글 남겨봅니다.
감사합니다.
9개의 답변이 있습니다.
우리가 이론으로 배울 땐 이상적인 방법으로 요구사항 수집 및 분석 -> PI -> SI -> SM 을 말하지만,
실제 현업에서 프로젝트를 하다보면...
PI 없이 현업의 의견을 반영하여 현 상태 그대로 전산화 하려는 경향이 강합니다. PI -> SI 단계로 진행하면 업무 개선, 요구사항을 명확하게 정의하고 사용자 만족도도 높을 수 있는데 프로젝트 기간 등의 여러가지 이유로 쉽지 않는 과정입니다.
( PI 없이 바로 SI로 가면 기능 등 요구사항 반영이 제대로 되지 않아 사용자 만족도도 떨어지고 결국은 개발자나 사용자 모두 힘들어 지는데도 말이죠. ^^ )
그래서 정확한 요구사항 정리도 어렵고 해서 현실적으로 2번으로 많이 진행합니다.
알아보면 요즘은 대기업에서만 대규모 프로젝트에 PI 컨설팅을 하는게 아니고, 경량화된 PI도 있으니 하려고만 한다면 가능할 것 같습니다.
다만, 최소한 PI 없이 진행한다면, 적어도 TO-BE, R&R 정의, DFD 정도는 내부적으로 정리하는것을 추천합니다.
댓글 남기기
답변을 작성 하시려면 로그인이 필요합니다.
로그인 회원가입1번이 기본적인 프로세스입니다. 혼자서는 불가능하죠
댓글 남기기
답변을 작성 하시려면 로그인이 필요합니다.
로그인 회원가입요구사항 수집 및 분석 > SI > SM 순서가 맞다고 생각 되고요.
PI는 이전 단계인 초기단계에 진행되어야 하는 것이라고 봅니다.
댓글 남기기
답변을 작성 하시려면 로그인이 필요합니다.
로그인 회원가입당연히 PI 컨설팅을 별도로 받고 시작하면 좋겠죠... 하지만 대부분의 사업에서
해당 컨설팅에 대한 비용을 책정을 하지 않는 경우가 많습니다.
그런 경우에는 요구사항 분석 단계나 SI 에서 해당 롤을 수행해야 하는 수 밖에 없습니다.
댓글 남기기
답변을 작성 하시려면 로그인이 필요합니다.
로그인 회원가입SDLC는 보통 다음과 같은 단계로 구성됩니다:
1.요구사항 수집 및 분석: 요구사항을 정의하고 문서화.
2.프로젝트 계획 (또는 PI): 프로젝트 범위, 일정, 자원 등을 계획.
3.설계 (Design): 시스템 아키텍처와 세부 설계를 수행.
4.개발 (Implementation): 실제 코딩 및 단위 테스트.
5.테스트 (Testing): 단위 테스트, 통합 테스트, 시스템 테스트 등.
6.시스템 통합 (SI): 개별 모듈을 통합하여 전체 시스템을 구성.
7.배포 (Deployment): 시스템을 운영 환경에 배포.
8.유지보수 (SM): 배포 후 오류 수정 및 개선.
요구사항 수집 및 분석 > PI > SI > SM은 SDLC의 일반적인 흐름을 따를 때 맞는 순서입니다.
요구사항 수집 및 분석 > SI > SM은 설계, 개발, 테스트 단계가 생략된 형태로, 일반적인 SDLC에서는 맞지 않습니다.
댓글 남기기
답변을 작성 하시려면 로그인이 필요합니다.
로그인 회원가입보통은 PI>SI>SM이 맞겠죠
댓글 남기기
답변을 작성 하시려면 로그인이 필요합니다.
로그인 회원가입PI(Process Innovation) 정의는 업활동의 전반적인 과정에 있어 불필요한 요소를 제거하고, 일하는 방식을 개선하여 더 나은 경영환경을 조성하는 것을 의미 합니다.
PI의 목적은, 이러한 프로세스들을 업무 단위로 하나하나 뜯어보며 현 상태를 진단하고, 전략목표와 고객사의 니즈를 기반으로 가시적인 성과를 달성하는 것에 있다.
PI 단계에서 As-Is 분석, To-Be 설계, 이행계획 수립이 포함되므로 PI → SI → SM 진행으로 보시면 됩니다.
댓글 남기기
답변을 작성 하시려면 로그인이 필요합니다.
로그인 회원가입용어나 프로젝트 방법론은 큰 의미 없습니다.
큰 기업에서 프로젝트 관리 감사할 때 절차를 지켰는지 등에 많이 필요합니다.
신규 프로젝트 개발을 하는 방법도 순서도 회사마다 약간씩 다르구요.
말씀하진 PI, SI, SM으로 본다면 일반적인 순서는 PI > SI > SM 순입니다.
제일 먼저 PI단계에서 현재 프로세스 문제점, 향후 방향, TO-BE 프로세스 설계하게 되고,
다음으로 SI단계에서 요구사항 분석, 아키텍처 설계, 개발, 테스트, Go-live를 진행합니다.
마지막으로 SM단계에서 구축 한 시스템를 운영, 유지보수하게 됩니다.
신규 프로젝트 시스템의 규모가 어떻게 되시는지? 자체 개발을 하는지? 아니면 외주를 주는지?
모르겠지만 IT에 혼자 계시다면 외부 SI업체의 가이드를 받으시는게 좀 더 효율적이지 않을까 생각되네요.
혼자서 북치고 장구치고 하시길 업무 부담이 많을 것 같아요.
외부 업체가 프로젝트 많이 하기에 관련 방법론 잘 정리되어 있을겁니다.
댓글 남기기
답변을 작성 하시려면 로그인이 필요합니다.
로그인 회원가입절차와 형식에 너무 얽매이지 않아야 하지 않을까 싶어 보이네요.
신규 사업이라면...
무엇이 요구되는지 일반 사용자들도 잘 모르는 상황이 아닐까 싶어 보이고요.
요구 사항 수집과 요구 사항 분석은 있어야하겠지만...
무엇이 필요한지도 모르는 일반 사용자들에게 요구 사항을 수집해도 신규 사업에 큰 도움이 되지는 않을 걸로 보여지네요.
요구사항 수집은 참고하기 위한 목적으로 수집해서 분석해 두는 것이 필요할 것 같고...
직접 개발할 것이라면, 큰 그림을 그려두고 조금 조금씩 개발하면서 실무자와 협조를 하면서 개선 사항과 추가적인 기능등을 협의하면서 개발을 진행해가야 할 것 같은데... 충분한 경험을 가지고 있는 개발자들이 있어야 하지 않을까 싶어 보이고요.
외주 업체의 도움을 받아 진행할 예정이라면 몇개 후보 업체에 제안 요청서를 보내서 제안서을 받아서 진행해야 할 거라 생각되네요.
업무 처리 프로세스는 제안하는 업체의 프로세스를 기반으로 실무 부서들과 협의해서 그대로하는 것이 좋을지 아니면 보완 수정해서 하는 것이 좋을지를 논의해 보아야 할 것 같고... 업체에서 제안한 프로세스를 변경해야 할 경우라면 업체와의 협의를 통해서 변경했을 경우에 어떤 영향이 있는지, 발생할 문제점은 어떤것이 있는 지 등을 논의해서 판단 결정해야 할 것 같고요.
기존 시스템을 업그레이드할 경우라면 실무 사용자들의 의견들을 중심으로 추진하는 것이 좋겠지만, 신규 시스템이라면 경험이 충분히 축적되어 있는 업체의 제안을 중심으로 사용자들의 의견을 반영하는 것으로 추진하는 것이 좋지 않을까 싶어 보이네요.
댓글 남기기
답변을 작성 하시려면 로그인이 필요합니다.
로그인 회원가입