본문 바로가기

프로젝트/요구사항분석

SRS를 개발 후에 연습하는 차원으로 적어보면 도움이 되지 않을까? 소프트웨어를 개발하는데 있어서 가장 어렵고도 중요한 것은 SRS(Software Requirements Specification) 즉, 스펙을 잘 작성하는 것이다. 그럼 SRS 작성법을 배우고 싶은데 어떻게 해야 할까?남이 작성한 SRS를 보면 도움이 될까? 가상으로 한번 써보면 도움이 될까? 케이스별로 얼마나 도움이 될지 알아보자. 1% 스펙을 작성하는 방법을 배우기 위해서 남이 작성한 SRS를 보는 것은 얼마나 도움이 될까?1%정도 밖에 도움이 안된다.남이 치는 피아노, 골프를 보고 얼마나 도움이 될지 생각해보면 된다. 작성한 SRS의 내용이 그러게 도출되는 과정을 겪지 않고 결과만 보는 것은 1%밖에 보이지 않는다. 10% 그럼 실제 프로젝트에 적용하기는 어려우니 가상의 프로젝트를 생각해서 작성하면.. 더보기
넣는 것 보다 빼는 것이 더 어렵다. 초창기에 좋은 소프트웨어로 성공하는 업체들이 지속적으로 성장하지 못하고 고전을 면치 못하는 이유는 여러가지가 있다. 그중 하나가 제품이 점점 과도하게 비대해지는 것을 꼽을 수 있다. 성공하는 회사들의 초기 제품은 간략하고 핵심적인 기능으로 사용자들의 요구를 만족시켰다. 하지만 시간이 흐를 수록 경쟁상대가 많아지고 선두를 유지하거나 따라잡기 위해서 제품은 기능은 경쟁 제품들의 모든 기능을 다 포함하기 시작하곤 한다. 고객이 많아질수록 고객들의 요구사항도 다양해지고 하나의 고객도 놓치기 싫어서 가능하면 모든 요구사항을 신제품에 다 우겨 넣으려곤 하다. 이렇게 온갖 기능이 다 포함된 제품을 우리는 "Kitchen Sink"라고 한다. 설거지통에 닦아야 할 그릇들이 잔뜩 쌓여 있는 모습을 상상해보라. 기본적으로.. 더보기
[공지] 요구사항 분석 세미나를 실시합니다. - 마감되었습니다. 소프트웨어를 개발하는데 있어서 가장 어려운 것을 하나 꼽으라면 "요구사항분석"입니다.소프트웨어를 개발하는데 있어서 가장 중요한 것을 하나 꼽으라도 "요구사항분석"을 선택합니다 하지만 우리나라에서 "요구사항분석" 역량을 제대로 갖춘 개발자를 만나보는 것은 매우 어렵습니다. "요구사항분석"은 교과서를 통해서 배울 수 없고 실전을 통해서 익혀야 하는데 우리나라는 자수성가한 개발자들로부터 시작되고 이어져 왔기 때문에 이를 가르쳐 줄 수가 없었습니다. 대기업에서는 대규모 방법론이나 비싼 툴을 사용하여 "요구사항분석"을 해보려고 하는데 아무리 비싼 골프채가 있어도 골프를 잘치는 것은 딴 얘기이듯이 툴이 이것을 해결해주지는 않습니다. 결국은 요구사항분석의 핵심을 꺠닫고 꾸준히 현실 프로젝트에서 경험을 쌓아가는 것이 .. 더보기
소프트웨어 개발시 일을 작게 쪼개야 하는 이유 대부분의 소프트웨어는 수명에서 수백명, 많게는 수천명이 같이 개발한다. 그래서 효과적으로 일을 나눠서 개발할 수 있어야 한다. 심지어는 혼자서 개발을 할 때도 일을 쪼개야 한다. 왜 일은 쪼개야 하고 어떻게 쪼개야 하는것일까? 대부분의 다른 산업 분야는 일을 잘 쪼깬다. 시계하나를 개발해도 각 부품을 따로 개발해서 조립한다. 따로 개발하기 전에 이미 어떻게 연결이 되는지 인터페이스를 완벽하게 정의하고 개발한다. 그렇지 않으며 나중에 조립이 안되서 처음부터 다시 개발해야 할 수도 있다. 소프트웨어 프로젝트에서 일을 서로 어떻게 나눠서 개발을 하고 있는지 생각해보자. 흔히 사용하는 방법이 화면 단위로 일을 나누는 것이다. 이 방법은 일을 나누기는 쉬워보이지만 문제가 많다. 나눠서 한 일이 서로 통합이 잘 안.. 더보기
요구사항이 계속 바뀌기 때문에 스펙을 적을 수 없다. 소프트웨어 개발 프로젝트에서 스펙을 제대로 적지 않는 회사들에게 그 이유를 들어보면 여러가지가 있다. 1. 프로젝트 기간이 너무 짧아서 스펙을 적을 시간이 없다.2. 프로젝트가 너무 복잡해서 적어야 할 것이 너무 많아서 적을 수 없다.3. 요구사항을 계속 바꿔서 스펙을 적을 수가 없다. 위의 어떠한 이유도 적절한 이유가 되지는 않는다. 오직 한가지 이유가 될 수 있다면 다음과 같은 것이 있을 수 있다."우리는 분석역량이 떨어져서 스펙을 적을려고 해도 제대로 적을 수 없다. 그래서 그냥 개발한다." 위 1,2,3번의 이유 때문에라도 스펙을 적어야 하는 것이다.이중에서 3번 "요구사항이 계속 바뀌기 때문에 스펙을 적을 수 없다"에 대해서 얘기를 해보고자 한다. 99%의 소프트웨어 프로젝트는 분석 기간은 당연.. 더보기
개발자의 취향 소프트웨어 프로젝트를 진행할 때 합리적인 결정보다는 개발자의 취향대로 진행되는 경우가 많다. 이 경우 Architecture상의 심각한 문제점을 내포하게 된다. 제대로된 분석과 설계를 통해서 Architecture가 결정되어야 하는데 개발자 취향에 맞는 개발언어를 선택하고 검증이 안된 기술을 선택하면 그 Risk는 고스란히 프로젝트가 떠안아야 한다. Architecture를 결정할 때 고려해야 하는 요소는 개발자의 취향이 아니다. 회사의 미래 비즈니스 전략을 고려해야 하고, 현재 개발자들의 구성과 역량, 제품의 성격과 로드맵이 중요한 고려사항이다. 이러한 전략없이 특정기술을 맹신하거나 거부하기도 하고 무조건 새로운 기술을 채용하기도 한다.그러다보면 각 제품마다 중구난방으로 여러 기술이 쓰이고, 유지보수에.. 더보기
스펙을 제대로 작성하는 것은 구식이다? '소프트웨어 개발 방법이 얼마나 발전했는데 아직도 스펙을 제대로 작성하고 개발을 하는가?' 라고 하면서 스펙 작성에 반대하는 주장을 하는 사람들이 있다. 스펙, 설계를 작성하고 구현을 하고 테스트를 하는 방식으로 개발하는 것을 판에 박힌 절차라고 생각하고 부정하기도 한다. 그런 주장을 하는 사람들은 이 방법은 Waterfall 방식으로 구닥다리이며 요즘은 Agile 등의 최신 방법으로 개발을 하기 때문에 과거처럼 스펙을 작성하지 않는다고 한다. 이렇게 주장하는 사람들에게 반문해보고 싶은 것이 있다. "스펙을 한번이라도 제대로 작성해 본적이 있는가?" 이런 생각을 하는 것 자체가 스펙을 제대로 이해하고 있지 못하다는 반증이다. 왜냐하면 스펙이 무엇인지 제대로 이해하고 있다면 이런 말이 나올 수가 없다. 지.. 더보기
프로토타입을 재활용하면 될까? 안될까? 며칠 전 프로토타입에 관해 올린 글에 대해서 프로토타입 재사용에 대해서 여러 의견이 있어서 이 내용에 대해서 조금더 설명해보려고 한다. 2011/11/03 - [프로젝트/요구사항분석] - 프로토타입이란? 소프트웨어공학의 목적은 가장 적은 비용으로 가장 빠른 시간에 Software를 만들어내는 것이다. 여기에 부합되면 옳은 방법인 것이다. 하지만 우물 안에서 자신의 방법이 가장 좋은 방법이라고 우기는 것은 미숙함일 뿐이다. 여러가지 의견이 있었지만 모두 옳고 그름으로 구분 지을 수는 없다. 여러 답변들을 맞다 틀리다 얘기를 할 수 없으므로 좀더 원칙에 치중해서 얘기를 해보겠다. 필자의 의견은 프로토타입은 만들어 보고 버리는 것이라고 했다. 또한 버리는 코드라고 생각하고 만들어야 하는 것이다. 프로토타입을 .. 더보기
프로토타입이란? 프로토타입 (경제/경영) 양산(量産)에 앞서 제작해보는 원형(原型)을 '프로토타입'이라 하는데, 프로토타이핑이란 개발자들과 사용자들의 의사소통상의 효과를 증진시키기 위하여 취하는 시스템개발상의 기법이다. 일반적인 분석방법을 취할 경우 양자간에 서로 다른 이해를 가져올 수 있으므로 프로토타입이라는 의사소통도구를 만들자는 것이다. 프로토타이핑은 그 목적에 따라 여러가지 형태가 있다. by 다음 백과사전 (http://100.daum.net) 소프트웨어 개발을 할 때 프로토타입은 여러 용도로 사용된다. 특히 고객과 스펙을 의논할 때 고객의 이해를 돕기 위해서 UI프로토타입을 만든다. 이외에도 기술적인 검증을 위해서 프로토타입을 만들어 보는 경우도 있다. 스펙을 작성하다보면 이것이 가능할지 불가능할지 잘 모른 .. 더보기
스펙에 있어서는 안될 표현들 필자는 여러 개발자들이 작성해 놓은 스펙문서를 볼 기회가 많다. 대부분 99.9% 스펙이라고 하기에는 내용적으로 부족하고 리뷰도 부족한 문서들이지만 우선 각 문장을 하나씩 보다라도 고쳐할 부분이 매우 많다. 스펙(SRS)은 작성을 하고나면 이를 토대로 비즈니스도 하고 설계/구현도 하고 테스트팀은 테스트를 준비한다. 따라서 각 내용은 매우 정확하게 적어야 하며 두루뭉실하게 적으면 안된다. 하지만 정확한 표현을 하는 습관을 가지고 있지 않은 거의 대부분의 개발자들은 무심코 대충 작성을 하게 된다. 이는 수많은 오해를 유발해서 재작업과 품질 저하를 초래한다. 사실 원칙은 간단하다. 오해를 불러일으키지 않게 정확하게 작성해야 하고 범위를 구체적으로 명시해야 한다. 또한 정량적인 테스트가 가능하도록 설명해야 한다.. 더보기