-All of Software-

Search results for 'SRS'

2009/11/13 -- SRS에 대한 인식의 변화 (6)
2009/10/19 -- SW개발과 Teamwork, 그리고 Review (2)
2009/03/30 -- 외주를 주면 된다고요? (6)
2009/01/20 -- 샘플만 보여주세요.
2008/11/19 -- SRS(Software Requirements Specification)의 중요성

SRS에 대한 인식의 변화

2009/11/13 23:46

6 Comments

All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다.

RSS Feed

그 동안 본 블로그를 통해서 소프트웨어 개발에서 SRS(Software Requirements Specification)가 얼마나 중요한 역할을 하는지에 대해서 수 차례 역설한 적이 있습니다.

지금까지는 SRS라는 용어조차 한번도 들어본 적이 없는 소프트웨어 개발자나 관련자들이 많았었습니다. 하지만 이제는 조금씩 SRS라는 용어에 대해서 알기 시작하는 것 같습니다. 또 소프트웨어 개발에서 있어서 요구분석이 왜 중요한지에 대해서 조금씩 인식해가는 것 같습니다.

그 예로 최근에는 정부에서도 소프트웨어 기업들의 경쟁력 강화, 특히 해외 시장 진출 시 경쟁력 확보를 위해서SRS 작성을 중요한 요소로 보고 정부 지원 과제에 포함을 하고 있습니다.

이러한 과제에 평가위원으로 참석을 해보니 아직은 많은 소프트웨어 회사들이 분석능력을 제대로 갖추고 있고, SRS를 잘 쓸 수 있는 역량을 갖췄다고 보기는 어렵습니다. 하지만 제대로 된 소프트웨어를 짧은 시간에 개발하기 위해서는 분석을 제대로 하여 SRS를 작성하고 SDP를 만들어야 한다는 것을 인지한 것만으로도 큰 변화라고 볼 수 있습니다. 필요성을 인식하는 것이야 말로 변화가 가능하게 하는 원동력입니다.

다만, 문제는 분석을 잘해야 한다는 것, 즉 SRS를 잘 써야 한다는 것을 인식하고도 SRS를 잘 적는 방법을 배울 곳이 없다는 것입니다. Software 선진국에서는 수십년 간 개발자들이 SRS를 써 왔기 때문에 서로 Template는 조금씩 달라도 개발자로서 일을 하는 동안에 계속 접해 왔고, 써왔기 때문에 따로 배우고 말 것도 없이 SRS를 쓸 줄 알게 되었습니다. 물론 모든 개발자가 SRS를 다 제대로 쓸 줄 아는 것도 아니고 그럴 필요도 없지만, 소프트웨어 프로젝트를 시작할 때 누군가가 SRS를 작성하고 관련자들과 리뷰를 하는데 전혀 문제가 없습니다.

하지만 이제 시작인 우리나라는 배울 곳도 없고, 스스로 연구하고 공부해서 작성하기에는 요구분석이라는 분야 자체가 너무 어렵습니다. 그 동안 여러 회사에서 스스로 작성했다고 하는 SRS를 분석해보면 합격점을 줄 수 있는 것은 거의 전무했다고 해도 과언이 아닙니다. 그렇다고 미국 회사에 가서 몇 년 배우고 오기도 어려운 실정입니다. 또, 국내에서는 학교나 학원에서 배울 수 있는 환경도 되지 않습니다. 그렇게 배운다고 해도 몇몇 기법만 배우고 핵심은 파악하지도 못하게 됩니다. 그 이유가 대부분의 교수나 강사가 소프트웨어 프로젝트에서 실제로 SRS를 써본적이 거의 없이 이론적으로 배운 정도이기 때문입니다. 실제 프로젝트에서 SRS를 제대로 써본 경험을 많이 가지고 있는 경험자와 같이 SRS를 써보면서 꾸준히 배워 나가는 것이 가장 적절한 방법입니다.

물론 몇몇 개발 방법론에서는 SRS를 작성하지 않습니다. 하지만 이러한 방법론에서도 스펙이 필요 없다고 하는 것은 아닙니다. 다만 스펙을 바라보는 관점과 적는 방법이 다를 뿐입니다. 따라서 스펙의 개념을 정확하게 알고 SRS를 잘 작성할 줄 아는 개발자들이라면 스펙의 형태가 테스트케이스가 되든 어떤 다른 형태가 되든 문제는 없습니다. 즉, 소프트웨어 분석역량이 문제입니다.

분석역량의 부족은 부실한 스펙문서를 만들게 되고 이는 설계, 구현 기간에 많은 혼란과 재작업을 초래하고 출시 후에도 유지보수 비용을 크게 증가시킵니다. 그 동안 우물 안 개구리처럼 내수시장에서 소수의 개발자를 데리고 고객이 원하는 대로 뚝딱 만들어서 장사를 했는데, 소프트웨어 볼륨이 커지고 해외 시장에 진출을 하려니까 딱 벽에 부딪히는 겁니다. 이 과정에서 무리하게 해외 진출을 추진하다가 유명을 달리한 회사들이 상당히 많습니다. 그렇다고 세계 시장의 1%밖에 안되는 국내 SW시장에서만 놀기에는 국내 시장은 너무나 작습니다. 왠만큼 성장한 회사라면 해외 시장 진출의 유혹을 떨처버리기 어렵습니다.

물론 SRS, 스펙, 분석능력이 이 모든 것을 해결해주지는 않습니다. 하지만, 가장 중요하고 핵심적인 요소라 확신합니다. 이는 저만의 주장이 아니고 제가 존경하는 수많은 실전 소프트웨어 전문가들의 주장이기도 합니다. 그러한 맥락으로 앞으로 SRS, 스펙, 분석역량 향상에 대한 글을 종종 올려보려고 합니다. 블로그를 통한 지식전달이 얼마나 효과가 있겠는지 의문은 들지만, 필요성에 대한 인식만 생기더라도 글을 올린 보람을 있을 것으로 생각됩니다.

이와 관련된 궁금증, 의견, 경험, 고민거리, 정보, 아이디어 등 어떤 것이라도 같이 교환하고 싶습니다. 댓글이나 방명록, 메일로 얼마든지 보내주세요. 제가 해결해드릴 수 있는 것은 해결해드리죠.

그리고 교육을 받고 싶으신 개발자나 회사라면 연락 주시기 바랍니다. 제가 여건이 되는 한도내에서는 많은 소프트웨어 개발자들에게 전달하고 싶습니다.

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.

'프로젝트 > 요구사항분석' 카테고리의 다른 글

SRS에 대한 인식의 변화 (6)	2009/11/13
이건 기능이 아닌데 (4)	2009/08/03
고객이 요구사항을 너무 자주 바꿔요. (4)	2009/07/30
Track me, if you can (0)	2009/05/04
개발자들이 바글바글한 외딴섬에 떨어진다면 (20)	2009/04/22
요구사항 분석의 출발점 (6)	2009/02/12

Ray.전규현 프로젝트/요구사항분석 SRS, 분석, 스펙, 요구분석, 정부과제

Leave a Commnet Leave a Trackback

Trackback Address: http://allofsoftware.net/trackback/157

Peter

2009/11/14 06:59

Reply | Edit

최근 프로젝트 진행하면서, 요건정의서 / 주요화면 정의서만 가지고 프로젝트를 수행했었습니다. 유사 경험이 있으니 잘 되겠지라구 약간은 자만하면서요..

하지만 관련 분야 업무를 처음 해보는 사람들과의 협업/구현하면서 문제가 하나둘씩 생겨나기 시작하고, 주기능 보다는 당연히 될거라고 생각했던 부기능에서의 생각의 차가 너무 컸고, 결국 Rework을 하게 되더군요.
확실히 일은 정석대로 해야한다고 SRS 로 시작했으면 좋았겠다는 후회가 나중에 들더라구요...

좀 부끄러운 경험담이지만.. SRS 중요성/초기 설계의 중요성을 깨닿게 했던 중요한 교훈이었던 것 같습니다.
전규현 수석님.. 블로그글 잘 공감하고 있습니다. 감사합니다.
Ray.전규현

2009/11/15 01:09

Reply | Edit

Peter님 안녕하세요.
실제로 제가 다른 개발자들이 작성한 여러 SRS를 검토해보면 비기능요구사항이 주로 부실하게 작성되어 있더군요. 하지만 비기능요구사항이 SRS에서 더 중요하다는 것을 잘 인식하지 못합니다. 기능이 하나 잘못적힌 것은 일반적으로 해당 모듈만 수정하면 되지만, 비기능요구사항 하나 누락되거나 잘못 적힌 것은 시스템 전체를 다 뜯어 고쳐야할 정도로 큰 사건일 수 있습니다. 앞으로 블로그에서 이와 관련된 다양한 내용들을 다룰 계획입니다.
구차니

2009/11/14 13:26

Reply | Edit

개발자들도 이러한 개발의 효율을 위한 절차를 받아 들여야 하지만
그에 못지 않게 개발을 위탁하는 사람도 개발에 대한 이해가 널리 퍼졌으면 좋겠다는 생각이 듭니다.

이러한 프로세스 없이, 중간에 계속 수정을 요구하고 이에 따른 추가기간을 정산하지 않으면
개발자 역시 무상으로 계속 지치게 되니 말이죠. 물론 인간이라 처음부터 완벽하게 SRS를 만들어내서
한번에 만들수는 없기에 어느정도 변경사항이 생기겠지만, 디자인이 마음에 안들어요 이렇게 바꾸어 주세요
라고 하는건 개발 위탁하는 사람역시 이러한 개발의 과정중 하나로 넣어 교육을 시켜야 하지 않을까?
라는 생각마저 들게 합니다.
Ray.전규현

2009/11/15 01:06

Reply | Edit

구차니님 안녕하세요.
말씀 하신 것처럼 처음부터 스펙을 완벽하게 다 정하고 프로젝트 끝날 때 까지 절대 바꾸지 않을 수는 없습니다. 그래서 어차피 바뀌니 대충 시작하는 것은 더 문제가 크죠.
개발자나 고객이나 모두 스펙에 대한 이식의 변화가 필요하겠죠. 또한 교육, 훈련과 경험 모두가 필요하고 1,2년에 해결될 문제는 아니라고 봅니다.
김경록

2009/11/17 11:00

Reply | Edit

좋은 글 잘 읽고 갑니다.
^^
Ray.전규현

2009/11/17 11:56

Reply | Edit

김경록님 오랫만입니다.
댓글 남겨주셔서 감사합니다. 항상 건강하세요.

SW개발과 Teamwork, 그리고 Review

2009/10/19 11:29

2 Comments

All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다.

RSS Feed

거의 모든 SW개발은 팀으로 진행됩니다. 종종 혼자서 기획하고 개발, 테스트, 영업까지 모두 다하는 경우도 있기는 하지만, 이는 워낙 작은 규모의 회사에서 있는 일이고, 대부분은 팀을 이뤄서 일을 해야 효과적으로 SW를 개발해 낼 수 있습니다.

그 팀의 규모는 2명에서부터 수천 명에 이르기까지 다양합니다.

하지만, 주변에서 대규모 프로젝트 팀을 보기란 그렇게 쉽지 않습니다. 5~6명 안팎의 소규모 팀은 아주 흔하게 볼 수 있고, Teamwork도 꽤 좋은 편입니다. 하지만, 규모가 몇 십 명만 넘어가도 효과적으로 관리를 해내지 못하는 경우가 흔합니다. 그래서 팀이 규모가 커지면 프로젝트가 오히려 늦어진다는 얘기도 있습니다.

이런 경우라면 소규모의 팀은 제대로 된 Teamwork를 갖춘 것이 아니라 워낙 작아서 서로 인간적으로 잘 통하고 서로 커뮤니케이션을 왕성하게 하면서 프로젝트를 진행하기 때문에 문제가 없는 것이고 수십 명 규모의 팀은 똑같은 방법으로 커뮤니케이션이 잘 되지 않기 때문에 문제가 많을 가능성이 더 높습니다.

팀을 이뤄서 소프트웨어를 개발할 때 가장 중요한 것은 Review입니다.

Review에 익숙하지 않은 개발자들이 모여서 개발을 하는 것은 서로 따로 개발하는 개발자들을 한데 모아 놓은 것과 별반 다르지 않습니다. 이런 팀은 개발을 하면서 서로 다른 목표를 가지고 개발을 하기도 하고, 아키텍처

에 대한 오해를 하고 통합 시 인터페이스가 안 맞고, 일정이 서로 어긋나곤 합니다.

물론 각 개발자들이 서로 개발하는 모든 내용을 다 Review하고 공유할 수는 없습니다. 프로젝트의 규모에 따라서 또, 서로의 역할에 따라서 Review하는 범위와 대상이 달라집니다. 그럼 소프트웨어 개발팀에서 리뷰를 해야

하는 것들은 어떤 것이 있는지 알아보겠습니다.

1. SRS(스펙) 작성 및 리뷰 (중요도 : 매우 높음)

제가 여러 차례 강조했지만 SRS는 SW개발에 있어서 가장 중요하며 프로젝트 기간을 단축하고 비용을 절약하는데 가장 핵심입니다. SRS작성시는 개발팀 뿐만 아니라 프로젝트의 모든 관련자와 수 차례 리뷰를 합니다. 모든 관련자가 SRS의 모든 항목을 다 리뷰하는 것이 아니고 본인들이 책임지는 부분만 리뷰를 하면 됩니다. 예들 들어 Marketer인 경우는 프로젝트 목표와 비전, 주요 기능 등과 같이 마케팅에 필요한 부분만 리뷰를 하면 됩니다. 이렇게 SRS를 철저히 리뷰를 해야 모든 관련자가 프로젝트에 대하여 동일한 생각을 가지게 되고 프로젝트가 끝

날 때까지 스펙 변경을 최소한으로 유지하게 됩니다. 또한 이런 SRS리뷰가 일상적으로 반복적으로 일어나야 자연스러운 관행으로 자리잡고, 개발자들의 분석 능력을 향상하는데도 도움이 됩니다. 참고로 SRS(스펙, 요구분서)는 SW개발에서 약 40%의 비중을 차지한다고 합니다.

2. SW아키텍처 리뷰 (중요도 : 높음)

웬만한 규모의 SW의 아키텍처는 한 명의 머리 속에 나올 수가 없습니다. 아키텍처는 정답이 있는 것이 아니라서 생각을 많이 할 수록 좋아 질 수 있습니다. 개발자들은 설계 단계에서 이런 아키텍처 리뷰를 여러 차례 반복하게 됩니다. 그러면서 아키텍처를 점점 구체화 해나가고 개량해나갑니다. 규모가 큰 SW인 경우에는 상,하위 아키텍

처를 구분해서 설계를 하기도 하고 각 컴포넌트간에는 인터페이스만 정하게 되고 그 내부는 또 각 개발자들이 설계를 하고 리뷰를 하게 됩니다. 이 때 UML을 사용하건, Flow chart를 사용하건, DFD를 쓰던 큰 상관은 없으며 각자 익숙한 툴로 현재의 아키텍처를 가장 잘 표현할 수 있는 것으로 작성하면 됩니다. 이러한 과정 또한 선배 개발자들이 후배 개발자들에게 지식과 경험을 전달할 수 있는 좋은 기회가 됩니다.

3. 소스코드 리뷰 (중요도 : 중간)

소스코드 리뷰가 중요하기는 하지만 SRS와 아키텍처리뷰보다 중요하지는 않습니다. SRS와 아키텍처가 잘못되면 엄청나게 많은 재 작업을 해야 하지만, 소스코드가 잘못된 것은 버그로 발견되고 또, 상대적으로 쉽게 고칠 수 있습니다. 그렇긴 하지만 소스코드 리뷰는 좋은 관행이며 꾸준히 노력해서 정착해야 합니다. 소스코드 리뷰 방법은 매우 다양하지만, 저는 가장 간단한 방법은 Peer desk check을 권합니다. 소스코드 관리시스템에 Commit하기 전에 동료와 같이 리뷰를 하는 겁니다. 간단히 Diff툴을 실행해서 바뀐 소스코드를 볼 수도 있습니다. 그리고 소스코드를 등록할 때 누가 리뷰를 했는지도 꼭 기록하게 하는 정책도 소스코드리뷰를 확산하는 좋은 방법 중 하나입니다.

소프트웨어 개발에 있어서 Teamwork은 서로 사이가 좋은 팀을 말하는 것은 아닙니다. Teamwork에 있어서 서로 간의 신뢰는 중요한 요소이지만 필요충분조건은 아닙니다. 각자 전문가로서의 자신의 일들을 제대로 수행하면서 리뷰 등의 커뮤니케이션이 적절히 원활하여 동일한 목표와 비전을 가지고 SW를 개발해야 합니다.

우리는 흔히 혼자서는 일을 정말 잘하는데 뭉쳐 놓으면 삐걱대는 개발자들을 많이 보아 왔습니다. 이는 그 개발자만의 탓도 아닙니다. 서로들 Teamwork이 부족한 것이지요. 즉, 팀을 이뤄서 일하는 방법에 서툰 것입니다. 가장 좋은 방법은 제대로 되어 있는 회사에서 몇 년 일해보는 것입니다. 그런 환경이 안 된다면 SRS(스펙)리뷰부터 조금씩 활성화 해나가는 것이 좋습니다. 제대로 된 SRS(스펙)을 써보지 않는 개발자들에게는 SRS(스펙)을 쓰는 것도 큰 도전이지만, 어차피 SW를 제대로 개발하기 위해서는 피해 갈 수 있는 것이 아니기 때문에 시도를 해봐야 합니다.

좋은 Teamwork를 갖추지 못한 개발팀에서는 아무리 뛰어난 개발자라고 하더라도 제대로 실력을 발휘할 수 없습니다.

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.

image by tim ellis

'개발문화' 카테고리의 다른 글

Google을 이끄는 힘 (7)	2009/10/30
SW개발과 Teamwork, 그리고 Review (2)	2009/10/19
우리는 다르다. (6)	2009/10/09
Peer review의 혜택 (2)	2009/05/13
개발자 여러분~ 문서 만들기 싫죠? (12)	2009/05/06
이 정도도 안되면서 Peer Review를 한다고요? (6)	2009/04/06

Ray.전규현 개발문화 review, SRS, Teamwork

Leave a Commnet Leave a Trackback

Trackback Address: http://allofsoftware.net/trackback/150

김경록

2009/10/19 14:13

Reply | Edit

좋은 글 잘 읽었습니다. Agile에서 pair programming이 생각나네요..
저희 회사에서도 Source Review가 점점 중요해져서 전문 Reviewer까지 새로 뽑고 했는데 잘 되면 좋겠네요ㅎㅎ
Ray.전규현

2009/10/21 11:08

Reply | Edit

김경록님 안녕하세요.
전문 Reviewer가 있습니까? 음~~ 회사 규모가 엄청나게 크나보죠? 제가 전에도 지적했지만, 차근차근 접근하여 개발자들 몸에 자연스럽게 베어들게 해야 하는 일들을 너무 형식적으로 접근해서 프로세스에 얽메이게 되면 벽에 부딪혀서 실패할 수도 있습니다.
전문Reviewer는 Review전문가이고 채용이 된 이상 가시적인 성과를 내어야 하기 때문에 무리한 시도를 할 수도 있고 관료화 될 수도 있습니다. 또한 소스코드리뷰보다 스펙/설계 리뷰가 더 중요한데, 이런 것이 시도 또는 정착되지 않은 상태에서 소스코드리뷰만 너무 강조하면 개발에 도움이 되기보다는 번거롭기만 하다는 인식이 생길 수도 있습니다. 따라서 좋은 시도가 성공하려면 현재 역량과 상황에 맞게 조심스럽게 차근차근 접근하는 것이 필요합니다.
기우일수도 있으나 잘못 접근하면 아니한만 못한 경우가 워낙 많아서 조심스럽게 말씀드립니다.

외주를 주면 된다고요?

2009/03/30 22:07

6 Comments

All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다.

RSS Feed

"우리가 못하면 외주를 주면 된다."

이렇게 생각하십니까? 아니면 인력이 모자라거나 시간이 부족하여 외주를 주십니까?

대부분의 개발자라면 외주에 대한 쓰라린 기억이 있을 겁니다.

한 포탈업체가 인도에 포탈 시스템 외주를 줬다가 통째로 버리고 국내 업체에 다시 외주를 줘서 개발한 적이 있습니다. 그리고도 국내 업체에 질질 끌려 다녔었지요.

인도에 외주를 줄 때는 스펙을 제대로 전달 하지 못했고, 개발 기간에도 전혀 관리와 리뷰를 하지 않고 최종 결과물만 받아 본 사례입니다. 이런 케이스 많죠?

그리고 국내 업체에 외주를 줄 때도 자체적으로 기술을 보유하지 못하고 외주에 의존하다 보니 지속적으로 문제가 됩니다.

결국 스스로 만들 능력이 없는데, 외주를 주는 것은 성공할 확률도 낮고, 경험있는 외주 업체를 만나면 개발은 제대로 되더라도 질질 끌려다니기 일쑤입니다. 또한 외주를 주기 위해서는 분석능력과 관리 능력이 필수 입니다. 특히 해외 업체에 외주를 줄 때는 대단히 정교한 스펙문서(SRS 등)가 필요합니다. 따라서 대다수의 업체는 외주를 줄 능력이 없다고 볼 수 있습니다. 그래서 외주가 아니고 사람만 빌려오는 거죠. 옆에 앉혀놓고 같이 의논해가면서 개발하는 방법이 유일한 방법입니다. 소프트웨어 개발 생산성이 아직도 매우 낮은 수준에 머물러 있는 원인이기도 합니다.

"스스로 잘 할 수 없다면 외주는 더 어렵다."

이미지출처 : Microsoft Office Online

'소프트웨어이야기' 카테고리의 다른 글

나는 혼자가 아니다. (5)	2009/05/15
이거 팔면 돈 되겠는데! (20)	2009/04/17
외주를 주면 된다고요? (6)	2009/03/30
소스코드가 그렇게 중요한가요? (18)	2009/03/23
소프트웨어 개발자의 권리 (8)	2009/03/15
짝퉁 고수 (8)	2009/03/04

Ray.전규현 소프트웨어이야기 SRS, 스펙, 외주

Leave a Commnet 2 Trackbacks

Trackback Address: http://allofsoftware.net/trackback/103

2009/04/01 11:39

Delete

십년차의 생각 Tracked from sugiii's me2DAY
2009/04/05 15:07

Delete

멤피스의 생각 Tracked from cychong's me2DAY

영회

2009/03/31 00:02

Reply | Edit

날로 글이 간결하면서 핵심을 전하는군요. 대단하십니다.
외주의 기본 요건을 다룬 이 글은 현장에서 질리도록 보는 우울한 장면을 담아내서 씁쓸하기도 하고, 계도하려는 노력에 반갑기도 합니다.

그나저나 조 아래.. RSS 구독 아니콘을 보니 구독자 하위 호환성(?)을 유지하시는 모습이 인상적입니다.
Ray.전규현

2009/03/31 13:20

Reply | Edit

영회님 안녕하세요. 과찬의 말씀입니다. 수많은개발자와 경영자들이 착각속에 살고 있는 듯합니다. 저는 그뒤로 또 새로운 바이러스의 감기에 걸려서 캑캑대고 있습니다. 바이러스가 없는 세상에서 살고 싶어요. 나중에 하와이로 이민가고 싶습니다.
황상철

2009/04/08 01:04

Reply | Edit

요구사항에 대한 잦은 피드백이 필요한것은 인도나 한국이나 동일하다고 생각합니다. 제 경험으로 정교한 스펙을 주는것보다 성근 스펙에 잦은 피드백이 더 효과 있었던거 같습니다. 다만 커뮤니케이션을 위한 가혹한 피드백은 각오해야...^^
Ray.전규현

2009/04/08 11:19

Reply | Edit

황상철님 안녕하세요.
요구사항은 계속 변하기 마련이지요. 한번에 제대로된 스펙을 만들어서 소프트웨어를 개발하는 것은 불가능합니다. 당연히 지속적인 피드백과 변경관리는 필수입니다.
정의의소

2009/04/09 00:50

Reply | Edit

Outsourcing과 Offshoring의 차이점에 대해서 잘 못 이해하시는 분들도 있으신 것 같습니다. 특히 테스트부분에 Outsourcing이 아닌 Offshoring을 진행한 일을 개선하러 해외 출장을 나왔는데...
와서 보니 넘 우울하네요. Test에 대한 Offshoring은 저희 회사에서는 100% 실패할 것이라 생각하고 아니라고 말씀을 드렸는데... 흑...
어찌해서 진행은 되었고 시간이 꽤 지난 지금 어떻게든 개선?을 하라고 하시네요.
이 부분은 제가 나중에 다시 한 번 정리해서 블로그에 올려보겠습니다. ^^;

테스트에 대한 생각이 많이 바뀌었더라도 아직 테스트에 대해서 너무 쉽게 보시는 분들이 넘 많습니다. 안타깝습니다. Offshoring이라니... ㅡㅡ;

*회사 상황을 자세히 못 적으니 말이 좀 이상하고 이해하기 힘들 것 같네요... 그래도 속상해서... 장기 해외출장은 참 힘드네요... ㅎㅎ
Ray.전규현

2009/04/09 10:14

Reply | Edit

정의의소님 안녕하세요.
테스트부분은 개발의 한부분으로 개발 초기부터 참여를 해야하는데, 테스트를 너무 기계적으로 생각하는 분들이 많이 있습니다. 그냥 자신들의 경험에 비춰서 생각하는 것이지요. Offshoring할 수 있는 분야는 따로 있지요. 무슨 뜻인지 충분히 알고 있습니다. 이와 유사한 사례들도 알고 있고요. 자칫 준비도 안되었고 내부적으로도 제대로 못하는데, 비용절감을 위해서 Outsourcing이나 offshoring을 시도하는 회사들을 보면 100이면 100실패할 것이기 때문에 안타깝고 말리고 싶습니다.

샘플만 보여주세요.

2009/01/20 18:20

'프로젝트 > 요구사항분석' 카테고리의 다른 글

개발자들이 바글바글한 외딴섬에 떨어진다면 (20)	2009/04/22
요구사항 분석의 출발점 (6)	2009/02/12
UI Mock-up (2)	2009/01/21
샘플만 보여주세요. (0)	2009/01/20
그냥 쓸 수 있겠네요. (2)	2009/01/19
SRS(Software Requirements Specification)의 중요성 (0)	2008/11/19

Ray.전규현 프로젝트/요구사항분석 SRS

Leave a Commnet Leave a Trackback

Trackback Address: http://allofsoftware.net/trackback/55

SRS(Software Requirements Specification)의 중요성

2008/11/19 10:32

'프로젝트 > 요구사항분석' 카테고리의 다른 글

개발자들이 바글바글한 외딴섬에 떨어진다면 (20)	2009/04/22
요구사항 분석의 출발점 (6)	2009/02/12
UI Mock-up (2)	2009/01/21
샘플만 보여주세요. (0)	2009/01/20
그냥 쓸 수 있겠네요. (2)	2009/01/19
SRS(Software Requirements Specification)의 중요성 (0)	2008/11/19

Ray.전규현 프로젝트/요구사항분석 Requirement, spec, SRS, 스펙, 요구사항

Leave a Commnet 5 Trackbacks

Trackback Address: http://allofsoftware.net/trackback/21

2008/11/19 14:59

Delete

SRS(Software Requirements Specification)를 작성할 때 유의할 점 Tracked from Younghoe.Info
2008/11/19 20:03

Delete

소프트웨어 개발 방법론 Tracked from 녹차 프린스
2008/11/19 22:40

Delete

요구파악과 사양정의 Tracked from Insight..
2008/11/24 11:30

Delete

SRS는 유용한가.. Tracked from 상실의시대
2008/12/09 11:44

Delete

11 Tracked from 『dK』‘s 나의 지식을 오픈하는 것은 나를 더욱 강하게 만드는 길이다. (아무개..)