Blogs

소프트웨어는 하루짜리부터 몇 년짜리 대형 프로젝트도 있다. 이런 모든 프로젝트에 동일한 스펙 문서를 적용하면 비효율적이다. 스펙 문서의 형태는 매우 다양하며 상황에 맞는 문서를 적절히 사용하는 것이 좋다. 이슈관리시스템의 한 줄 또는 몇 줄의 설명 스펙이라고 하면 수십에서 수백페이지의 문서를 먼저 떠올리지만 상황에 따라서는 Jira나 Redmine과 같은 이슈관리시스템의 이슈 하나, 또는

소프트웨어는 빠르게 개발하는 것이 매우 중요하다. 소프트웨어는 빠르게 개발하는 것이 매우 중요하다. 소프트웨어 개발 기간이 오래 걸린다면 적절한 시장 진입 시기를 놓칠 수 있다. 소프트웨어 시장 변화는 매우 빨라서 너무 오래 개발을 하면 그동안 시장의 상황이 바뀐다. 경쟁자들은 새로운 제품을 출시하여 우리 회사에서 지금 개발하고 있는 제품이 뒤쳐지곤 한다. 또한

“소프트웨어회사에서 재택근무를 할 수가 있는가?” 라는 필요조건에는 다양한 문제가 있다. 먼저 간단히 소개 정도만 할 주제는 보안이다. 보안이라고 하면 한 회사에서 습득한 지식, 설계문서, 소스코드 등 지적재산을 다른 회사에서 사용할 수 있는가에 대한 도덕적 혹은 법적인 주제이다. 구글의 전 개발자였던 Levandowski 가 구글의 비밀을 우버에 가져가 자율자동차에 기여를 한 것에 대한 구글의 소송에서 일주전인 3월4일에 최종판결이 났는데 Levandowski는 구글에게 2000억원, 우버는

소프트웨어 요구사항을 분석해서 작성하는 스펙 문서의 형태와 종류는 셀 수 없을 만큼 다양하다. 개발방법론에 따라서 제시하는 문서도 다르고 그 개수도 천차만별이다. 이 시리즈의 글에서 소개하고 주로 다룰 문서는 SRS다. SRS는 Software Requirements Specification(s)의 약자다. Specification 혹은 Spec(스펙)이라고도 한다. SRS는 IEEE830에서 문서를 작성하는 가이드가 정의되어 있고, DoD(미국 국방부) 표준 문서이다. SRS는

스펙을 부실하게 작성하고 진행하는 프로젝트는 수없이 많다. 하지만 그 중에서 성공을 하는 프로젝트도 있다. 그래서 스펙을 제대로 작성했다고 착각을 하기도 하고 반대로 스펙을 제대로 작성해야 하다는 것을 믿지 않기도 한다. 이럴 때는 프로젝트가 10배로 커지고 개발자가 10배 투입되면 어떤 일이 벌어질지 상상을 해보면 된다. 많은 프로젝트들이 첫번째 버전을 성공했다가 이를