본문 바로가기

SRS

내가 소스코드를 몰래 고치는 이유 여러 소프트웨어 회사를 분석해보면 소스코드를 공유하는 정도에서 정말 많은 차이가 난다. 여기서 소프트웨어 회사란 소프트웨어를 개발하고 있는 회사로서 흔히 얘기하는 팩키지 소프트웨어 회사가 아니다. SI회사, 가전회사, 산업로봇회사, 반도체장비회사, 인터넷회사, 게임회사, 금융회사 등의 다양한 회사를 모두 말한다. 이들 회사 중에서는 개발자가 소스코드를 몰래 고치고 공유도 하지 않는 회사들이 의외로 많다. 개발자가 소스코드를 몰래 고치는 이유에는 이건 것들이 있다. 내 소스코드는 나만 알아야 회사에서 나의 파워가 유지된다. 일부 일리가 있는 이론이다. 내가 없으면 내가 작성한 소스코드를 이해하지도 고치지도 못하면 나는 절대로 짤릴 수가 없다. 문제가 있을 때마다 나에게 달려와서 이것 좀 고쳐달라고 하면 내.. 더보기
마이크로소프트, 구글의 소스코드 트리의 비밀? 오늘 출근을 해서 메일을 확인하니 독자로부터 메일이 한통 와있더군요. 책에 대한 리뷰의 글이어서 감사히 읽었습니다. 질문도 하나 있어서 답변 겸 블로그에 글을 남깁니다. 독자 블로그 글 : 소프트웨어 개발의 모든 것 -전규현 질문은 다음과 같습니다. 나는 마이크로소프트 같은 커다랗고 프로세스가 잘 정립된 회사의 형상 관리툴의 소스트리를 보고 싶다. 그들이 모듈을 어떤 식으로 분리하고 어떤 구조로 트리를 구성하는지, 중복되는 코드들을 어떤 식으로 제거하고 또 공유하는지, 체크인 되는 코드의 코멘팅은 어떤 규칙으로 하는지 등이 너무 너무 궁금하다. 1시간 만이라도 들어가서 차근차근 살펴볼 수 있다면 내 실력은 훨씬 나아질 것이다. 사실 책에서는 이러한 내용은 구체적으로 설명되어 있지는 않지만 전체 맥락을 이.. 더보기
SRS에 대한 인식의 변화 그 동안 본 블로그를 통해서 소프트웨어 개발에서 SRS(Software Requirements Specification)가 얼마나 중요한 역할을 하는지에 대해서 수 차례 역설한 적이 있습니다. 2009/08/03 - [프로젝트/요구사항분석] - 이건 기능이 아닌데 2009/07/30 - [프로젝트/요구사항분석] - 고객이 요구사항을 너무 자주 바꿔요. 2009/05/04 - [프로젝트/요구사항분석] - Track me, if you can 2009/04/22 - [프로젝트/요구사항분석] - 개발자들이 바글바글한 외딴섬에 떨어진다면 2009/02/12 - [프로젝트/요구사항분석] - 요구사항 분석의 출발점 2009/02/04 - [개발프로세스] - 소프트웨어 개발 단계에서 가장 중요하다고 생각하는 것은? .. 더보기
SW개발과 Teamwork, 그리고 Review 거의 모든 SW개발은 팀으로 진행됩니다. 종종 혼자서 기획하고 개발, 테스트, 영업까지 모두 다하는 경우도 있기는 하지만, 이는 워낙 작은 규모의 회사에서 있는 일이고, 대부분은 팀을 이뤄서 일을 해야 효과적으로 SW를 개발해 낼 수 있습니다. 그 팀의 규모는 2명에서부터 수천 명에 이르기까지 다양합니다. 하지만, 주변에서 대규모 프로젝트 팀을 보기란 그렇게 쉽지 않습니다. 5~6명 안팎의 소규모 팀은 아주 흔하게 볼 수 있고, Teamwork도 꽤 좋은 편입니다. 하지만, 규모가 몇 십 명만 넘어가도 효과적으로 관리를 해내지 못하는 경우가 흔합니다. 그래서 팀이 규모가 커지면 프로젝트가 오히려 늦어진다는 얘기도 있습니다. 이런 경우라면 소규모의 팀은 제대로 된 Teamwork를 갖춘 것이 아니라 워낙 .. 더보기
외주를 주면 된다고요? "우리가 못하면 외주를 주면 된다." 이렇게 생각하십니까? 아니면 인력이 모자라거나 시간이 부족하여 외주를 주십니까? 대부분의 개발자라면 외주에 대한 쓰라린 기억이 있을 겁니다. 한 포탈업체가 인도에 포탈 시스템 외주를 줬다가 통째로 버리고 국내 업체에 다시 외주를 줘서 개발한 적이 있습니다. 그리고도 국내 업체에 질질 끌려 다녔었지요. 인도에 외주를 줄 때는 스펙을 제대로 전달 하지 못했고, 개발 기간에도 전혀 관리와 리뷰를 하지 않고 최종 결과물만 받아 본 사례입니다. 이런 케이스 많죠? 그리고 국내 업체에 외주를 줄 때도 자체적으로 기술을 보유하지 못하고 외주에 의존하다 보니 지속적으로 문제가 됩니다. 결국 스스로 만들 능력이 없는데, 외주를 주는 것은 성공할 확률도 낮고, 경험있는 외주 업체를 만.. 더보기
샘플만 보여주세요. 소프트웨어 개발에서 가장 어려운 것이 "요구사항분석"이라고 여러 차례 언급한 바가 있습니다. 요구사항을 분석하여 "스펙"으로 만들어서 적어 놓은 문서를 "SRS"라고 합니다. 그런데 SRS는 샘플이나 Template을 보고 잘 적는 것은 거의 불가능합니다. 개발자들은 원래 샘플 소스코드를 보고 많은 것들을 배워왔기 때문에 스펙도 샘플을 보면 잘 적을 수 있을 것 같은 착각을 하는 경우가 흔합니다. 샘플 소스코드가 도움이 되는 이유는 개발자들인 소스코드에 대해서는 이미 상당한 지식과 경험이 있기 때문입니다. 샘플만 보고 잘하려고 하는 것은 피아노를 잘 치고 싶다고 유명 피아니스트가 친 것을 몇 번 보고 피아노를 잘 치려 하는 것과 비슷합니다. 심지어는 지금 듣고 있는 피아노 연주가 잘 하는 것인지 못하는 .. 더보기
SRS(Software Requirements Specification)의 중요성 본 블로그에서 소프트웨어 개발, 소프트웨어 공학에 대한 여러 주제에 대해서 다루겠지만, 특히 나는 요구사항 특히 SRS에 대해서 많이 다루려고 합니다. "소프트웨어개발의모든것"이라는 책에서도 요구사항에 대해서 가장 중요하게 다루고 있지만 지면의 한계와 다양한 독자층의 눈높이를 맞추기 위해서 욕심보다는 많이 설명하지 못하는 측면이 있습니다. 그래서 소프트웨어 개발단계에서 가장 중요한 "요구사항"에 대해서 천천히 여러분들과 의견을 주고 받으면서 심도있게 다뤄볼까 합니다. 제가 세상의 모든 경우의 요구사항 분석 기술 및 경험이 있는 것이 아니니 여러분들과 토론을 하면서 또 많이 배울 것을 기대하고 있습니다. 먼저 제가 책에서 요구사항에 대해서 설명한 내용을 앞부분을 약간 소개할까 합니다. 요구사항 분석 소프트.. 더보기

티스토리툴바