본문 바로가기

분류 전체보기

SRS(Software Requirements Specification)의 중요성 본 블로그에서 소프트웨어 개발, 소프트웨어 공학에 대한 여러 주제에 대해서 다루겠지만, 특히 나는 요구사항 특히 SRS에 대해서 많이 다루려고 합니다. "소프트웨어개발의모든것"이라는 책에서도 요구사항에 대해서 가장 중요하게 다루고 있지만 지면의 한계와 다양한 독자층의 눈높이를 맞추기 위해서 욕심보다는 많이 설명하지 못하는 측면이 있습니다. 그래서 소프트웨어 개발단계에서 가장 중요한 "요구사항"에 대해서 천천히 여러분들과 의견을 주고 받으면서 심도있게 다뤄볼까 합니다. 제가 세상의 모든 경우의 요구사항 분석 기술 및 경험이 있는 것이 아니니 여러분들과 토론을 하면서 또 많이 배울 것을 기대하고 있습니다. 먼저 제가 책에서 요구사항에 대해서 설명한 내용을 앞부분을 약간 소개할까 합니다. 요구사항 분석 소프트.. 더보기
Release Branch, Function Branch and Customer Branch 서영아빠님의 "브랜치를 이용하여 운영환경에 선별적으로 배포하기"란 글을 보고 소프트웨어 프로젝트에서 브랜치란 어떤 의미를 가지는지 "소프트웨어 개발의 모든것"이라는 책에서 이에 대하여 소개한 내용이 있는데 이를 인용하여 설명을 하려고 합니다. 여기서 소개하는 브랜치에 대한 얘기의 핵심은 브랜치의 위험성에 대한 "경고"입니다. 브랜치는 위험하지만 소프트웨어 개발에서는 흔히 꼭 필요하게 되어서 철저히 통제가 되어야 한다는 것입니다. 브랜치(Branch) 브랜치란 필요에 의해서 소스코드를 분기하는 것이다. 브랜치를 얼마나 잘 통제하는가가 훌륭한 소프트웨어 회사와 평범한 소프트웨어 회사를 구별하는 핵심 요소 중 하나이다. 브랜치를 해야 하는 경우를 예로 들면 다음과 같다. 제품을 출시 후 유지보수를 하면서 동시.. 더보기
빌드와 컴파일의 차이 kenu님의 블로그에 빌드와 컴파일에 대한 차이를 묻는 글이 올라와서 간단히 설명해보려고 합니다. http://okjsp.tistory.com/1165643615 컴파일 : 소스코드 파일 등의 원시파일을 실행파일, 라이브러리 등의 Object 파일로 바꾸는 작업 빌드 : 소스코드 파일들을 컴퓨터에서 실행할 수 있는 소프트웨어로 변환하는 일련의 과정 컴파일은 빌드의 부분 집합입니다. 빌드 과정은 제품마다 서로 다르지만 간단한 예를 하나 들어보면 다음과 같습니다. 보통 아래 과정은 Build Script에 의해서 한번에 자동으로 실행됩니다. 실제 예는 아래 나열한 것보다 수십배는 더 복잡합니다. ^^ 소스코드관리시스템에 태그(베이스라인) 작성 작성된 태그(베이스라인) 체크아웃을 통해 빌드 전용시스템으로 소소.. 더보기
내부 세미나 영회님의 공감이 가는 글(http://younghoe.info/994#footnote_link_994_1)을 보고 의견을 남겨보려고 합니다. 소프트웨어를 개발하는 회사라면 당연히 갖추고 있어야 할 개발 문화는 여러가지가 있지요. Peer Review, Sharing, 규칙 준수 ... 이 중에서 좋은 문화 중의 하나가 일상화된 내부세미나입니다. 유수의 소프트웨어 회사들을 보면 회사에 늘상 세미나 공지가 있습니다. 누구나 세미나를 진행할 수 있고, 대부분 직원들이 관심을 가질 만한 주제들이고, 누구나 부담없이 참여를 합니다. 오다가다 들려서 보기도 하고, 관심이 많으면 준비를 해와서 발표자와 토론도 하기도 하기도 합니다. 누가 시켜서 의무적으로 하는 세미나는 아니지요. 그러한 과정에서 발표자에게도 지식을 .. 더보기
Expect Unexpected 제가 구독하는 블로그에 좋은 글이 있어서 번역해서 소개를 합니다. 예상치 않은 것을 예상하라. 프로젝트관리의 오래된 규칙: 항상 예상치 못한 일이 일어난다. 프로젝트관리자라면 예상치 못한 것을 예상하고 가능한 많은 준비를 해야 한다. 실제로, 잘 준비된 프로젝트 관리자는 예상치못한 일이 일어 났을 때에 대비하여 단지 B플랜(백업플랜)을 가지고만 있는 것이 아니라 B플랜을 실행할 능력을 가지고 있다. 리스크관리는 예측할 수 있는 이슈를 다루는 것이고 바라건데 모든 프로젝트관리자의 기본이다. 하지만 몇가지는 절대로 예상할 수 없다. 이것이 좋은 프로젝트관리자와 위대한 프로젝트관리자를 구분하는 것이다. 예상치 못한 일을 예상하는 능력과 이를 처리할 수 있는 능력이다. 그리고 당신은 예상할 수 없는 상황을 어떻.. 더보기
신입 개발자가 들어오면?  신입 개발자가 들어오면 어떻게 하시나요? 회사에서 소프트웨어를 개발하기 위해서는 많은 것을 알아야 함에도 불구하고 딱히 가르칠게 별로 없는 경우를 많이 보았습니다. 체계적인 교육 방법로 마땅치 않고요. 어떻게 신인 개발자를 가르치고 있는지 제가 아는대로 한번 나열을 해보죠. 멘토(사수)를 지정해서 맨투맨으로 이거 저거 생각나는 대로 알려준다. 회사에 문서는 정말로 많다. 책꽂이로 한 벽 가득이다. 그 중에서 뭘 보라고해야 할지 잘 모르겠다. 제품에 관한 변변한 문서가 하나도 없다. 있다 하더라도 부실하거나 옛날 버전이다. 그래서 말로 아는대로 설명해준다. 개발하는 제품의 메뉴얼을 보여주고 제품의 기능을 익히게 한다. 일단 일을 시키고 본다. 물어보는 것이 있으면 그때 그때 알려준다. 소스코드를 보게 .. 더보기
빌드가 먼저일까? 베이스라인 설정이 먼저일까? 빌드와 베이스라인 순서에 대해서 이슈가 있다는 글을 보고 아래 글을 작성합니다. 몇몇 빌드관련 솔루션들이 빌드를 해서 성공을 하면 베이스라인(Tag, Label)을 설정하는 것이 있더군요. 이는 원칙에 어긋나는 겁니다. 원칙은 베이스라인을 설정한 후에 해당 베이스라인을 가지고 빌드를 하는 것입니다. 작은 소프트웨어는 사실 이러한 것이 거의 문제가 되지 않습니다. 하지만 대규모 프로젝트는 빌드에 24시간이 넘게 걸리는 것도 있습니다. Windows NT 개발팀은 Daily Build가 48시간이 걸려서 몇대의 장비가 교대로 Daily Build를 수행했다고 할 정도 입니다. 이 경우 빌드가 끝나고 나서 베이스라인을 설정하려고 하면 이미 소스코드는 엄청나게 바뀌어 있게 됩니다. 베이스라인 설정, 태깅 한 후.. 더보기
Subversion(SVN)과 CVS의 비교 Subversion(SVN)과 CVS에 대한 비교라기 보다는 SVN이 CVS와 비교하여 상대적으로 어떤 점이 더 좋은지에 대한 설명입니다. SVN은 CVS를 개발하던 핵심 개발자들이 그동안 CVS가 가지고 있던 문제를 해결하고자 완전히 새로운 아키텍쳐로 새로 만든 제품입니다. 따라서 기존에 CVS를 사용하고 있던 개발자들은 SVN으로 넘어오는 것을 적극 검토해보시기 바랍니다. Subversion(SVN)의 장점 CVS에 비해 엄청나게 빠른 업데이트/브랜칭/태깅 시간. -> 최고로 강력한 장점입니다. 기존에 대형 프로젝트 같은 경우는 CVS를 이용하면 태깅에 수십분이 걸리기도 했습니다. 하지만 SVN은 아무리 규모가 커도 몇초면 끝납니다. 커밋 단위가 파일이 아니라 체인지셋이라는 점입니다. CVS에서라면 .. 더보기
소프트웨어 프로젝트는 누가 진행하는가? http://skcho.com/58 난 자율따위는 믿지 않는다. 긁적 2008/11/12 13:17 안녕하세요. 조성경님. Ray라고 합니다. 블로그에 쓰신 글을 보고 동감을 하면서 제 의견을 몇자 덧붙여 봅니다. 소프트웨어 프로젝트를 진행하기 위해서는 여러 전문가가 필요하죠. 프로젝트관리자도 전문가여야 하고, 개발자들도 소프트웨어 전문가여야 하고, 분석/설계/테스트/빌드/UI/Techpub 등 많은 전문가가 있어야 하죠. 물론 프로젝트 규모에 따라서 혼자서 이 모든 일을 다하는 경우도 있고, 수백명이 각각의 업무를 나눠서 하는 경우도 있습니다. 확실한 것은 혼자서 뚝딱뚝딱 만드는 것과는 다르다는 것이죠. 그런데, 우리는 전문적이지 못한 사람들이 모여서 프로젝트를 진행하는 경우를 허다하게 봅니다. 그런 .. 더보기
Broken tree 소프트웨어의 빌드가 안 되는 상황을 Broken Tree라고 합니다. 소프트웨어를 개발하는 회사라면 Broken Tree의 발생을 엄격하게 규제해야 합니다. 소스코드관리시스템 안의 소스코드는 항상 빌드가 가능한 상태로 존재해야 합니다. 그리고 언제든지 꺼내서 빌드를 하면 빌드가 되어야 합니다. 개발자들은 버그를 고치거나 새로운 기능을 추가할 때 소스코드관리시스템에서 최신 소스코드를 가져와서 소스코드를 고치고 개발자 테스트를 마친 후 소스코드를 체크인 하는 것만으로 임무가 끝나지 않습니다. 내가 소스코드를 수정하는 사이에 누군가가 다른 소스코드를 수정했을 수도 있으니 꼭 다시 한번 최신 소스코드가 빌드가 되는지 확인을 해야 합니다. 믈론 한두명이 개발한다면 이런 일은 거의 없겠지만, 꽤 큰 규모의 회사나 .. 더보기

티스토리툴바