메뉴 바로가기 검색 및 카테고리 바로가기 본문 바로가기

한빛출판네트워크

소프트웨어 스펙의 모든 것

프로젝트를 성공으로 이끄는 소프트웨어 스펙(SRS) 작성법 (실무 템플릿 무료 제공)

한빛미디어

집필서

판매중

  • 저자 : 김익환 , 전규현
  • 출간 : 2021-01-05
  • 페이지 : 348 쪽
  • ISBN : 9791162243732
  • 물류코드 :10373
초급 초중급 중급 중고급 고급
4.8점 (25명)
좋아요 : 4

프로젝트가 실패하지 않는 답은 소프트웨어 스펙 작성에 있다 

 

소프트웨어 스펙(SRS)은 시작이고 기준이다. 스펙을 제대로 작성하는 것은 프로젝트의 성패를 가를 만큼 중요하다. 스펙을 잘 작성하기 위해서는 개발 문화, 관행, 습관, 프로세스, 원리, 원칙을 알고 접근해야 하며 실전을 통한 노하우 축적이 필요하다. 이 책은 저자들의 수많은 경험을 토대로 여러 유관 분야 이론을 망라하고 스펙 작성 요령을 제시한다. ‘스펙  작성’의 진짜 의미가 무엇인지 이 책을 통해 알아보길 바란다. 

 

 

출판사 리뷰

 

프로젝트의 불확실성을 줄이는 소프트웨어 스펙, 제대로 작성하고 있었을까?

 

프로젝트의 가장 많은 실패 원인은 스펙과 관련 있다. 소프트웨어 버그의 절반 이상이 부실하거나 잘못 작성된 스펙 때문에 발생한다. 프로젝트 성공률을 높이는 가장 좋은 방법은 스펙을 제대로 작성하는 것이다. 여기서 ‘제대로’는 ‘자세히’가 아니다. 어려움과 미지수까지 사실을 그대로 보고, 스펙을 작성하면서 검증해 불확실성을 줄여가는 것이다. 누구나 알고 싶어 하지만 쉽게 알 수 없는 소프트웨어 스펙 작성의 거의 모든 것을 정리했다. 훌륭한 소프트웨어를 만드는 데 힌트가 되기를 바란다. 

 

1부 소프트웨어 스펙이란?

소프트웨어 스펙 원리를 이해하고 이를 잘 작성하는 역량을 키우는 방법을 알아본다. 스펙, SRS(Software Requirements Specification)라는 용어는 글로벌 소프트웨어 업계에서 널리 통용되는 표준 용어이며 기능명세서, 시방서 등과는 의미가 다르다. 

 

2부 SRS 작성법

실제 SRS 템플릿을 제공하고 각 항목별 작성 내용을 설명한다. 

 

 

추천사 

 

저자는 소프트웨어를 만들 때 시작점이자 기준점이 되는 ‘스펙’을 예리하게 통찰한다. 책을 펼쳐 맨 처음 만나는 머리말에 일갈했듯이 “소프트웨어 프로젝트에서 가장 중요한 것은 스펙을 작성하는 일이다”라는 말에 이 한 권의 내용이 응축됐다.

규모가 크건 작건 이 책에서 제시하는 관점은 한결같이 유용하다. 스타트업에서 개발 요구사항이나 소프트웨어의 영향권 내에 있는 모든 이가 이 책에서 실질적인 도움을 받고 승승장구하기를 바란다.

- 신현묵, 뉴로핏주식회사 부사장

 

실전 경험이 있어야만 풀어낼 수 있는 이야기, 누구나 알고 싶어 하지만 쉽게 알 수 없는 이야기를 두 고수가 전한다. 프로젝트를 망치고 싶지 않은 PM, 아키텍트, 팀장이라면 꼭 알아야 하는 내용으로 가득하다. 실무 개발자 입장에서 당장은 필요하지 않다 생각하더라도 알아두면 도움이 된다. 정독하며 외운다는 생각보다는 가볍게 읽고 필요할 때 다시 펴보기 좋은 책이다.

- 손영수, 어니컴 최고제품책임자 상무

 

소프트웨어스펙의모든것_상세이미지_700px.jpg

저자

김익환

서울대학교 공과대학 졸업 후 미국 산호세 주립대학교에서 전산학 학사, 스탠퍼드 대학교에서 전산학 석사를 취득했다. GE, 썬 마이크로시스템즈, GTE Government Systems 등 세계적인 실리콘밸리 기업에서 17년간 소프트웨어 개발 실무 내공을 쌓았으며, 글로벌 기업에 인터넷 통합 메시지 솔루션을 제공하는 ‘스탠퍼드 소프트웨어(Stanford Software Corp, USA)’를 설립했다. 국내에서는 안철수연구소 부사장 및 CTO를 지내고, 카이스트 소프트웨어대학원 겸임교수를 역임했다. 현재는 다양한 기업을 대상으로 경영/개발 컨설팅을 진행하며 실리콘밸리의 선진 소프트웨어를 전파하고 있다. 『대한민국에는 소프트웨어가 없다』, 『소프트웨어 개발의 모든 것』, 『글로벌 소프트웨어를 꿈꾸다』, 『글로벌 소프트웨어를 말하다, 지혜』를 집필하고 『세상을 바꾼 32개의 통찰』을 번역했으며, 소프트웨어 공학 블로그 ikwisdom.com을 운영한다.
저자

전규현

연세대학교 공과대학 재학 중 개발한 타자연습 프로그램 '한글타자 1.0'이 계기가 되어 한글과컴퓨터에 입사했다. 이를 시작으로 26년간 한글과컴퓨터, 안철수연구소 등 여러 기업에서 수많은 소프트웨어를 개발했고 소프트웨어 엔지니어, 프로젝트 리더, 프로젝트 매니저, 수석 아키텍트, CTO, CEO 등 소프트웨어 개발 분야의 다양한 역할과 직무를 두루 경험하기도 했다. 그 과정에서 익힌 실리콘밸리 개발 문화를 국내 기업에 전파하고 글로벌 수준의 소프트웨어 역량을 갖추도록 선도하며 현재는 에이비시텍 소프트웨어 대표로서 소프트웨어 역량 향상을 위한 컨설팅 서비스를 온라인으로도 제공하고 있다. 『소프트웨어 개발의 모든 것』을 집필했고, 소프트웨어 공학 블로그 allofsoftware.net을 운영한다.

1부 소프트웨어 스펙이란?


1장 소프트웨어 스펙의 개요

1.1 소프트웨어 프로젝트 실패의 원인 

1.2 스펙에 대한 오해 

1.3 스펙의 역할

1.4 스펙을 제대로 작성하지 않으면

1.5 스펙과 프로젝트의 성공

 

2장 SRS

2.1 SRS란 무엇인가? 

2.2 어떻게 소프트웨어를 빠르게 개발할 것인가?

2.3 스펙 문서의 유형

2.4 요구사항과 스펙의 차이

2.5 스펙 문서에 대한 착각

2.6 스펙인 것과 스펙이 아닌 것

2.7 스펙과 프로젝트 일정의 관계

2.8 스펙과 설계의 구분

 

3장 스펙 작성의 현주소, 현실과 관행

3.1 현재의 관행과 문제점

3.2 스펙에 대한 잘못된 통념 

3.3 부실한 스펙 후 설계는 사상누각

3.4 시간만 있으면 누구나 스펙을 쓸 수 있는가?

3.5 소프트웨어 공학, 약인가? 독인가?

 

4장 사례 연구

4.1 A사의 해외 프로젝트_부실한 분석에 의한 계약

4.2 B사의 부품 교체_허술한 변경 관리

4.3 C사의 갑을 관계_고객의 의무 소홀

4.4 D사의 SI 수행_분석 역량 부족

4.5 E사의 소프트웨어 개발_있는 것은 소스코드뿐

4.6 F사의 공공 프로젝트_과도한 산출물

4.7 해외 사례_초기 분석 부실

 

5장 기업 문화

5.1 스펙과 기업 문화

5.2 잘 작성한 스펙의 혜택

5.3 좋은 관행 만들기

5.4 전사 아키텍처 전략을 선도하는 기술위원회

5.5 사수/부사수 시스템 탈피 방법

5.6 스펙을 제대로 작성하려면

 

6장 프로세스

6.1 소프트웨어 프로젝트의 개발 단계

6.2 스펙 작성 프로세스

6.3 SRS 관점으로 바라본 방법론 비교

6.4 스펙 작성에 시간을 얼마나 할애해야 하는가?

6.5 스펙은 얼마나 자세히 적어야 하는가?

6.6 스펙 리뷰

6.7 코드 리뷰보다는 설계 리뷰, 설계 리뷰보다는 스펙 리뷰

6.8 스펙과 베이스라인

6.9 스펙 변경 프로세스

6.10 종결된 프로젝트의 스펙, 업데이트할 것인가?

6.11 종결된 프로젝트의 스펙 일부 삭제

6.12 대형 프로젝트 분석의 협업

 

7장 Who?

7.1 스펙은 누가 쓰는가?

7.2 분석 아키텍트의 역할

7.3 분석 아키텍트의 자질

7.4 소프트웨어 개발자는 글을 잘 써야 한다

7.5 문서 작성 기술

7.6 시뮬레이션 능력

7.7 문제 해결 능력

7.8 프로젝트 이해관계자

 

8장 What?

8.1 why, what, how

8.2 목표와 범위 정의하기

8.3 요구사항에 우선순위 부여하기

8.4 외주 시 외주 업체에 전달할 문서는?

8.5 스펙 체크리스트의 효용성

 

9장 How?

9.1 스펙의 재료

9.2 스펙 가독성 높이기

9.3 문장 바르게 쓰기

9.4 스펙 작성 팁

9.5 스펙 재사용하기

9.6 소스코드로 스펙 작성하기

9.7 유닛 테스트로 스펙 작성하기

9.8 중복 최소화하기

9.9 품질 특성 명시하기

9.10 프로토타입 만들기

9.11 스펙을 적기 위해서는 why를 알아야 한다

9.12 훔쳐보기는 이제 그만

9.13 인터페이스 개선하기

9.14 인터페이스 정의하기

 

10장 도구

10.1 SRS 작성을 돕는 도구

10.2 UI 작성 방법

10.3 스펙 문서의 템플릿

 

2부 SRS 작성법 


1장 Introduction(개요)

1.1 Purpose(목표)

1.2 Product Scope(범위)

1.3 Document Conventions(문서 규칙)

1.4 Terms and Abbreviations(정의 및 약어)

1.5 Related Documents(관련 문서)

1.6 Intended Audience and Reading Suggestions(대상 및 읽는 방법)

1.7 Project Output(프로젝트 산출물)

 

2장 Overall Description(전체 설명)

2.1 Product Perspective(제품 조망)

2.2 Overall System Configuration(전체 시스템 구성)

2.3 Overall Operation(전체 동작방식)

2.4 Product Functions(제품 주요 기능)

2.5 User Classes and Characteristics(사용자 계층과 특징)

2.6 Assumptions and Dependencies(가정과 종속관계)

2.7 Apportioning of Requirements(단계별 요구사항)

2.8 Backward Compatibility(하위 호환성)

 

3장 Environment(환경)

3.1 Operating Environment(운영 환경)

3.2 Product Installation and Configuration(제품 설치 및 설정)

3.3 Distribution Environment(배포 환경)

3.4 Development Environment(개발 환경)

3.5 Test Environment(테스트 환경)

3.6 Configuration Management(형상 관리)

3.7 Bugtrack System(버그트래킹 시스템)

 

4장 External Interface Requirements(외부 인터페이스 요구사항)

4.1 System Interface(시스템 인터페이스)

4.2 User Interface(사용자 인터페이스)

4.3 Hardware Interface(하드웨어 인터페이스)

4.4 Software Interface(소프트웨어 인터페이스)

4.5 Communication Interface(통신 인터페이스)

 

5장 Performance Requirements(성능 요구사항)

5.1 Throughput(작업 처리량)

5.2 Concurrent Session(동시 세션)

5.3 Response Time(대응 시간)

5.4 Performance Dependency(성능 종속관계)

5.5 Other Performance Requirements(그 외 성능 요구사항)

 

6장 Non-functional Requirements(비기능 요구사항)

6.1 Safety(안전성 요구사항)

6.2 Security(보안 요구사항)

6.3 System Attributes(소프트웨어 시스템 특성)

6.4 Logical Database Requirements(데이터베이스 요구사항)

6.5 Business Rules(비즈니스 규칙)

6.6 Design and Implementation Constraints(설계와 구현 제한사항)

6.7 Memory Constraints(메모리 제한사항)

6.8 Operations(운영 요구사항)

6.9 Site Adaptation Requirements(사이트 적용 요구사항)

6.10 Internationalization Requirements(다국어 지원 요구사항)

6.11 Unicode Support(유니코드 지원)

6.12 64bit Support(64비트 지원)

6.13 Certification(제품 인증)


7장 Functional Requirements(기능 요구사항)


8장 Change Management Process(변경 관리 프로세스)


9장 Document Approvals(최종 승인자)

  • IMG_6637.jpg

     

     

    

    이직 후 세 번째 프로젝트를 진행하고 있다. 그도 어느새 끝 무렵.

    프로젝트를 할 때마다 피를 토하고 있어서 '일을 일답게 하는 법'에 대해 관심을 가지기 시작했다.

    내가 내 일을 아무리 정리하고 단순화하려고 아등바등해도 더 상위 영역에서 일이 일답게 흘러가지 않으면 매번 이렇게 피를 토할 수밖에 없다는 결론에 이르렀다.

     

     

    소프트웨어 스펙이 뭔지는 모르겠지만 책 표지 뒷면에 있는 소개말을 보고 읽어야겠다 싶어서 고르게 된 책.

    

     

    "프로젝트를 망치기 전에 알았다면 좋았을 것들"

    "무작정 키보드를 두드리는 개발자에서 벗어나 프로젝트 전체를 보는 진짜 실력을 키워보자."

     

     

    개발자를 하든 다른 일을 하든 뭘 하든, 큰 그림 속에서 꼼꼼하게 디테일을 챙겨가는 사람이 되고 싶다.

    아는 만큼 보인다고 했던가. 지금 당장 관리자가 될 수는 없겠지만 계속 안테나를 켜놓고 되도록 많은 걸 경험하고 또 느끼는 게 결국 내 자산이 될 것이라고 믿는다.

    그런데 그 '큰 그림'이라는 게 소프트웨어 개발 영역에서는 정말로 크다.

    수많은 이해관계자가 얽혀있고 다양한 영역에서의 인사이트가 필요하며 절대적이고 명확한 답이 정해져있지 않다.

    책 머리말에서도 이렇게 이야기한다.

    스펙을 잘 작성하기 위해서는 실전을 통한 노하우 축적이 필요한데 방법이 잘못되면 경험이 좋은 노하우로 이어지지 않으니 좋은 코치가 필요하고 피드백을 받아야 한다고. 그러나 우리나라 소프트웨어 업계에서는 그런 역량을 갖춘 인물을 찾아보기 힘든 것이 현실이라고. 소프트웨어 개발은 원리를 모르고 무작정 따라 해서는 성과를 낼 수 없으니 원리를 이해하는 데 도움이 되는 이야기를 하겠다고 한다.

     

     

    그런 책이다.

     

     

     

    책은 1부와 2부로 나눠져있다.

    1부는 '소프트웨어 스펙이란?'이라는 제목으로 굉장히 다양한 방면의 이야기를 한다.

    스펙은 뭐고, 현주소는 어떤지, 기업문화와 프로세스 측면에서도 살펴보고 who? what? how?의 흐름을 통해 자연스럽게 2부 'SRS 작성법'으로 넘어간다.

    2부는 SRS 템플릿 순서를 따라가며 작성법을 설명하는데, 무엇보다 실제적인 예제가 곁들여있어서 매우 좋았다. 이런 책은 아무리 이론 설명이 친절하고 자세하다 한들 좋은 예제 하나가 그 모든 것을 뛰어넘는다고 생각하기 때문에. 책이 두꺼워져도 상관없으니 템플릿이 조금 더 다양했으면 하는 아쉬움은 있다.

     

     

    이런 류의 책들은 외국 서적이 굉장히 많다. 좋은 책도 있지만 읽다 보면 내가 현재 경험하고 느끼는 현실과 너무 동떨어져있다는 생각을 하게 된다. 그래서 잘 걸러듣고 우리나라에 맞게 생각을 보정하는 과정이 꼭 필요한데 이 책은 국내 도서라 현실에 대해 적나라하게 이야기하고 있다는 점이 마음에 들었다. 내가 처한 현실, 그리고 아마도 많은 개발자들이 처해있을 현실을 짚어가며 그게 왜 합당하지 않은지를 이야기하는 부분에서는 위안까지 얻었다.

     

     

    중간중간 많은 생각을 하게 하는 책이라서 열심히 밑줄 긋고 메모하며 읽었다. 외워서 모든 걸 내 것으로 만들어야겠다, 하며 읽는 책이 아니라 밭에 거름 주는 심정으로 읽는 책이다. 언제나 중요한 건 내가 지금 몸담고 있는 곳에서 나만의 방법을 찾는 것이다. 언젠가 나만의 방법을 찾을 때에 이 책의 내용들이 좋은 거름이 되길. 뭐 거창한 이유가 아니더라도 술술 재밌게 읽기 좋은 책이다. 이런 국내 도서가 많이 나왔으면 한다.

    

     

  • 그림1.png

     

    저는 개발자가 아닙니다

    소프트웨어 프로그래머는 인공지능으로 대체될 확률이 매우 높은 직업이다. 하지만 소프트웨어 스펙을 작성하는 분석 아키텍트는 인공지능으로 대체될 확률이 매우 낮은 직업 중 하나다. 아무리 인공지능이 발전해도 스펙을 대신 작성해주는 세상이 올 가능성은 매우 희박하다. 그래서 스펙을 작성하는 일은 어렵지만 가치가 더욱 빛난다.
    - 머리말 中

    저는 데이터분석가입니다.

    데이터분석가가 원본데이터(raw data)를 가지고 직접 대시보드를 만들기도 하지만, 요즘은 구글애널리틱스(GA)나 앰플리튜드(Amplitude) 등 자동으로 만들어주는 툴들이 많아지고 있습니다. 그야말로 인공지능으로 대체될 수 있는 기술인 것이죠.

    하지만 아무리 인공지능이 발전해도 결국 최초로 지표를 '설계'하기 위해서는 데이터분석가가 필요합니다. 데이터분석가라면 공감하시겠지만, 그 하나의 지표를 발굴하는 것이 정말 어려운 일이면서 그만큼 가치가 빛나는 일입니다.

    자, 이렇게 생각하면 운영이나 마케팅 분야에서도 떠오르시는 것들이 있으리라 생각 됩니다. 인공지능이 대체 할 수 없는 일, 그중에서도 <설계>와 관련된 일은 어느 직군이든 하기 마련입니다. 만약 그런 일을 안하고 계신다면, 그런 분들에게도 왜 <설계>가 중요한지 이 책을 통해 알게 되실 겁니다.

    Tip. 결국 <설계>를 한다는 관점에서 일맥상통하는 부분이 있습니다. 저는 분석을 위한 설계를 한다고 가정하고, 저에게 익숙한 용어를 대입해가며 읽었습니다. 공감하고 끄덕끄덕 하는 포인트가 굉장히 많습니다.


    개발자와 협업을 더 잘 하고 싶다면

    위 말을 듣고 나면 '그럴 거면 데이터분석가 혹은 각 직군을 위한 책을 읽으면 되는 거 아니냐'는 생각이 들 수 있습니다.

    그럼에도 이 책을 여전히 권하는 이유는, 현업에서 <개발팀과 협업을 위한 설계>를 비일비재하게 하기 때문입니다. 다른 직군과 협업을 하면서 그런 경험을 해보셨을 겁니다. 아주 간단한 일인데 엄청 미안해 하면서 부탁한다거나, 반대로 신경 쓸 일이 많은 복잡한 일인데 사소한 부탁처럼 요청한다거나. 직군마다 전문성이 다르기 때문에 일어나는 현상이죠.

    사실 그런 상황에서 적절한 조율을 하기 위해 PM과 같은 매니저가 있습니다. 네, 그래서 이 책의 강력한 추천 대상에도 PM이 있고요. 하지만 매니저가 아니더라도 개발자와 직접 소통해본 경험이 있다면? 그런 분들께도 이 책을 추천합니다.

    이 책을 읽고 나서 앞으로 개발팀에 요구사항 혹은 기획서를 전달할 때 무엇을 얼마나 어떻게 전달하면 좋을지 조금 더 윤곽을 잡을 수 있습니다. 그렇게 되면 강약조절을 통해서 불필요한 커뮤니케이션을 줄이고, 상상하던 결과물에 좀 더 빠르고 정확하게 도달할 수 있겠죠.

    Tip.

    정독을 하지 않아도 됩니다. '소프트웨어 스펙'을 직접 작성할 아키텍트나 개발자가 아니라면요. 용어 하나하나에 집착하면 읽다가 지칩니다. '한 번도 들어본 적 없는 말' 보다 '어디서 들어본 말'의 차이가 아주 큰 만큼 모르는 개발용어는 들어본 정도로 만족합니다.
    요지는 "아, 우리 개발팀은 내가 쓴 요구사항 중에서 이걸 열심히 보겠구나" 입니다. 내가 중요하게 생각하는 것과 다른 직군이 중요하게 생각하는 것이 다르다는 것을 깨우치는 것만으로 일단 큰 수확 입니다.

  • 2021년 올해의 책리뷰 / 소프트웨어 스펙의 모든 것 / 한빛미디어

     

     

    소프트웨어를 개발하는데 가장 중요한 것이 스펙입니다. 이 스펙을 잘 작성하는 방법은 가르칠 수는 있는데 배울 수는 없습니다. 즉, 이론은 체계적으로 잘 짜여져 있지만, 그것을 현실에 적용하기란 어렵습니다. 스펙을 잘 작성하기 위해서는 실전을 통한 노하우의 축적이 필요하며, 개발 문화, 관행, 습관, 프로세스, 원리, 원칙을 알고 접근해야 합니다. 이러한 소프트웨어 스펙의 원리를 이해하고 이를 잘 작성하는 역량을 확보하는 방법을 이 책에서 다루고, 또한 실제 SRS 템플릿을 기준으로 작성할 내용을 설명하고 작성 예를 보여주고 있습니다.

     

    저자는 소프트웨어 프로젝트의 실패의 가장 주요 원인으로 스펙과 관계되어 있다고 합니다. 잘못된 스펙과 요구사항을 관리하는 부분에 있어서 문제가 발생하는데, 이를 해결하는 방법으로 원칙만 지킬 수 있는 최소한의 프로세스 환경에서 좋은 문화를 공유하는 것으로 보고 있고, 스펙의 역할에 대해서 알려주고 있습니다. 그러면서 스펙에 대한 오해에 대해서도 다루고 있습니다. 스펙에도 여러 종류가 있지만, 이 책에서는 SRS(Software Requirements Specification)이라는 문서를 다룹니다. 이 SRS를 통해서 소프트웨어를 어떻게 빠르게 개발할 것인가와 스펙과 프로젝트 일정의 관계를 논하고 있습니다.

     

    스펙의 모든 것을 세세하게 다루고 있습니다. 스펙을 적용하는데 있어서 현행에서의 문제점은 무엇인지 사례를 들어서 설명하고, 스펙을 위한 기업문화는 어떻게 되는 것이 올바른 것인지, 스펙을 적용하는 프로세스는 어떻게 정립해 나가야 하는지, 누가 스펙을 쓰고, 어떻게 이용하는 것인지, 스펙에 어떠한 내용을 어떻게 기입해야 하는지, 어떠한 도구를 이용하여 SRS를 작성해야 하는지 등등을 소개하고 있습니다.

     

    그리고 2부에서는 SRS 작성법을 세세하게 설명하고 있습니다. 시스템 구성, 동작 방식, 개발/테스트 환경, 외부 인터페이스 요구사항, 성능 요구사항, 비기능 요구사항, 기능 요구사항, 변경 관리 프로세스, 최종 승인자 등등의 정보를 어떻게 기입해야하는지에 대해서 설명하고 있고, 이는 현행에 소프트웨어 프로젝트를 진행하면서 많은 도움이 될 것으로 보입니다. 프로젝트에서 스펙에 문제점에 대한 해답을 제시하지는 못하지만, 그 해답을 찾아가는 과정을 알려주는 책이라고 보면 좋을 듯 합니다.

  •  

    해마다 몇권의 소프트웨어 방법론, 개발론, 인력 관리에 대한 책을 읽어 오고 있다.

     

    스타트업에서 일하면서 기술에 대한 습득 및 개발 방법론, 문서화, 인력에 대한 것을 고민해 왔는데 이번에는 "소프트웨어 스펙의 모든것" 을 읽게 되었다.

     

    먼저 "소프트웨어 스펙의 모든것"은 한국인 저자가 쓴 내용이어서 그런지 막연한 이상을 이야기하지는 않았고 우리나라 현실 프로젝트 현황과 문제점을 정확히 알고 쓰여져 있었다.

     

    문서에 대한 중요성과 그리고 어려움 그리고 현실에 대한 내용을 잘 표현하고 있고 해당 내용을 통해서 왜 스펙이 중요한지 그리고 작성해야 하는지 이유등을 알 수 있었다.

     

    우선 "소프트웨어 스펙의 모든것"을 읽어봐야 할사람은 소프트웨어를 수행하는 모든 사람이지만 그 중에서도 특히 프로젝트 리더, 그리고 발주처d의 업무담당자가 읽어보면 좋을것 같다고 생각한다.

     

    프로젝트 리더가 읽게 된다면 소프트웨어 스펙과 그리고 개발 방법에 대한 전반적인 어려움과 어떻게 해결해야 할지fm를 책을 통해서 체험할 수 있을것 같고 발주처 업무 담당자는 얼마나 무리한 요구및 그리고 소프트웨어가 어떻게 만들어지는지 이해하는 방법이 되지 않을까 생각한다.

     

    최근에 자택근무를 하면서 발주처에 대한 업무 미숙과 그리고 소프트웨어를 이해하지 못하고 진행하는것에 대해서 아쉬움이 있었는데 해당책을 통해서 전반적인 환경과 어떤것이 있는지 이해를 하면 좋을것 같다는 생각이 들었다.

     

    이책의 구성은

     

    1. 소프트웨어 스펙이란 ?

    - 10장의 주제로 구성

    1장. 소프트웨어 스펙의 개요

    2장. SRS

    3장. 스펙작성의 현주소, 현실과 관행

    4장. 사례 연구

    5장. 기업 문화

    6장. 프로세스

    7장. Who?

    8장. What?

    9장. How?

    10장. 도구

     

    2. SRS 작성법

    - 9장의 주제로 구성

    1장. Introduction (개요)

    2장. Overall Description (전체설명)

    3장. Environment (환경)

    4장. External Interface Requirements (외부 인터페이스 요구사항)

    5장. Performance Requirements (성능 요구사항)

    6장. Non-functional Requirements (비기능 요구사항)

    7장. Functional Requirements (기능 요구사항)

    8장. Change Management Process (변경관리 프로세스)

    9장. Document Approvals (최종승인자)

     

    되어 있었다.

     

    1장 소프트웨어 스펙이란 것에서 소프트웨어 개발의 전반적인 현주소와 그리고 SRS 중요성 , 전반적인 소프트웨어 환경에 대한 이해, 스펙에 대한 WHO?, WHAT?, HOW? ,도구등에 대한 설명 및 그림을 통해서 스펙에 대한것을 설명하고 있다. 해당 1장을 읽게되면 왜 스펙 SRS를 작성해야 하는지 충분히 알수 있고 해당문서를 통해 더 나은 소프트웨어를 만들 수 있다고 생각한다.

     

    2장 SRS 작성법은 1장의 스펙에 대한 구체화 및 SRS 작성에 대한 여러 샘플 및 작성 요령을 설명하고 있었다.

    프로젝트 관리자가 해당 내용을 통해 제대로만 학습하고 프로젝트에 적용할 수 만 있다면 멋진 스펙문서을 만들고 여러프로젝트에서 활용할 수 있다고 생각한다.

     

    다만 아위운것은 템플릿을 다운로드 받았는데 샘플이 아닌 실제 프로젝트에 대한 예제가 있는 내용이 추가되면 어댔을까 하는 아쉬움이 남았다.

    그래도 SRS 작성볍에 있는 예제나 샘플등을 프로젝트에 적용하고 스펙 문서 및 공유 문서를 만들면 멋지게 프로젝트를 완료할수 있다고 생각한다.

     

    마지막으로

    장점 : 우리나라 현실과 개발 방법론이 아닌 실제 적용할만한 문서작성법을 배울수 있음

    아쉬움 : 템플릿 문서가 여러개가 있었으면 좋았을텐데.

    하는 것을 학습하며 이 책을 읽게 되었다.

     

  • KakaoTalk_20210221_211741086.jpg

    2000년대부터 지금까지 낮은 취업률은 항상 문제가 되어왔습니다. 더군다나 현재는 코로나때문에 경제난이 닥쳐서 가뜩이나 낮은 취업률이 이제는 매우 소수적으로 되어버렸습니다. 그래서 청년들이나 실업자들에게 취업은 엄청난 부담감과 골치것리가 되었는데요. 제가 이 책을 선택한 이유는 이제 개발자로 취업을 하고자 하시는 분들이 이 책을 보시면 보다 더 성공적으로 바라시는 기업에 취업하실 수 있는 방법을 아실 수 있을거라 생각했기 때문입니다.

     

    이 책의 특성은 개발자로 취업을 원하시는 분들이라면 한번쯤은 해보셨을 프로젝트를 성공적으로 작성하는 방법을 제시하는 것입니다. 좋은 프로젝트일수록 개발자에게 엄청난 커리어를 안겨줄 수 있죠. 하지만 프로젝트를 자신이 생각한 그대로, 만족할 수 있게 완성한다는 것은 매우 어려운 일이라고 생각합니다. 저는 프로젝트를 진행하면서 프로그램을 만들때마다 항상 단점이 보이고 어떠한 기능을 더 추가하면 더 좋을것 같다는 느낌이 자주 들었습니다. 그래서 만족할만한 완성품을 내본 적이 별로 없었습니다. 이야기가 본의를 잠깐 지나갔네요. 아무튼 개발자로 취업을 희망하시는 분들이라면 이 책을 보시면 어떠한 준비를 해야되는지 아실 수 있으실거라 생각하여 이 책을 선택하게 되었습니다.

     

    이제는 프로그래밍을 학습하면은 고등학생, 빠르면 초등학생때부터 프로젝트를 진행하고 프로그램을 만들게 됩니다. 그래서 개발자를 희망하는 사람이라면 기본적으로 2~3개의 프로젝트를 진행한 경험이 있고 그것은 이제 당연시되었습니다. 또 단순히 많은 프로젝트를 한것이 플러스요인이 아닌 어떤 프로젝트를 진행하였고, 어떤 성취를 이루었으며 결과로 어떤 기능을 가진 프로그램을 만들었느냐에 따라 그것이 포트폴리오상에서 플러스 되는 요인이 되었습니다. 따라서 이제는 양보다는 질이 더 중요시해서 준비해야 하는 시대입니다.

     

    구성

    1부

    Chapter 1: 소프트웨어 스펙의 개요

    Chapter 2: SRS

    Chapter 3: 스펙 작성의 현주소, 현실과 관행

    Chapter 4: 사례 연구

    Chapter 5: 기업 문화

    Chapter 6: 프로세스

    Chapter 7: Who?

    Chapter 8: What?

    Chapter 9: How?

    Chapter 10: 도구

    2부

     

     

    Chapter 1: Introduction

    Chapter 2: Overall Description

    Chapter 3: Environment

    Chapter 4: External Interface Requirments

    Chapter 5: Performance Requirments

    Chapter 6: Non-functional Requirments

    Chapter 7: Functional Requirments

    Chapter 8: Change Management Process

    Chapter 9: Document Approvals

     

    파트별로 나누어 봤을때 책에서 나와있는 것처럼 1부에서 1~5장은 소프트웨어 스펙이 무엇이며, 그것에 대한 현 관행이나 문제점, 사례, 기업문화 등등을 설명하고 있고 6~10장은 소프트웨어 스펙을 만드는 방법을 단계별로 설명하고 있습니다.

    2부에서는 1~9장까지 모두 프로젝트를 통해 개발한 소프트웨어를 스펙처럼 설명하는 법에 대해 설명하고 있습니다.

     

    개인적인 생각으로 학습은 청년 취업자 같이 이제 막 개발자의 길로 들어서시는, 이러한 소프트웨어 스펙을 처음 작성하는 분들이라면 이 책을 2~3번 정독하시고 스펙을 작성하실때도 이 책을 보면서 참고하셨으면 좋을것 같습니다. 그리고 개발자로써 연차가 좀 되시고 스펙을 정돈하실줄 아시는 분들이라면 이 책을 정독하시면서 자신이 그동안 작성하면서 미처 발견하지 못했던 점이나 부족했던 점들은 보완하시는 것이 좋을것 같습니다. 물론 연차가 얼마나 되었든 모두 다 이 책을 자주 정독하시는 것을 추천드립니다.

     

    그리고 개인적으로 약간의 단점이 소프트웨어로 유명한 기업들의 사례가 더 많이 나왔으면 좋았을것 같다는 생각을 들었습니다. 사례가 더 많았다면 각자 자신이 희망하는 기업이 추구하는 이상향을 더 잘알고 준비할 수 있지 않을까라는 아쉬움이 있습니다.

  • 

    "프로젝트를 성공으로 이끄는 소프트웨어 스펙 작성법"이라는 내용에 알맞은 집약서하고 생각합니다.

    소프트웨어 공학의 필요성과 사용법에 대하여 압축하여 잘 설명해주고 있습니다. (어렵지 않아요~!)

    당장 스펙이 뭐지?! 라는 고민으로 구글링을 한다면 이책의 2부 부터 보면 됩니다. 약 100 페이지 안되는 정도로 적다면 적고 많다면 많은 내용으로 당장 필요한 정보는 획득 가능합니다.

    자세한 내용은 구글링. 간편이해는 앞장으로 돌아가서 하나씩 보기를 권장합니다.

     

    머릿말 다음에 용어 정리도 되어 있으니 이해를 위해서 읽고 외워서 넘어가는 것도 추천합니다.

     

    당장..이미 개발이 끝난 작은 추가 개발 건에라도 적용해보아야 겠다는 생각이 물씬 물씬.

    다음 작업 부터는 권장하는 방법을 따라 보기위해 일단 책내용을 정리해야겠네요.

     

    주니어를 넘어서기 위해서, 또는 주니어 막바지?라면 한번쯤은 읽고 이해 해보고 적용해 보기를 추천 드립니다.

    

  • [나의 한줄 추천사]

    부제목에 나왔듯이 프로젝트 성공으로 이끌기 위해서는 스펙 작성법 부터 보라

    [책을 구매한 이유]

    프로젝트 기획부터 수행까지 일연의 과정을 수행해야하는 상황에서 길잡이 같은 책이 필요했다. 최근 문서화 작업이 절실해서 이책이 더욱 눈에 들어왔다.

    [내가 찾고자 했던 질문과 대답들]

    1. 프로젝트 요구사항 문서화가 중요한가?

     - 현재 혼자서 일할 있는 방법 없다. 부서 협업 없이는 프로덕션 릴리즈도 못한다. 부서 협업할때의 기본은 문서화 인데 이중 가장 중요한 부분이 요구사항에 대한 문서화이다. 프로덕트가 이런 요건으로 필요하다는 것을 정의하기 때문에, 영업팀, 재경팀, 수행팀, 기획팀 해당하는 문서를 동시에 보면서 팀에서 수행하는 일정과 계획을 세우기 때문에 문서화는 요구사항에 대한 문서화는 절대 절대 중요하다.

    2.문서화는 어떻게 관리되어야 하는가?

     - 애자일 방식과 폭포수 방식이 있다. 지속적으로 리비전이 발생하기 때문에 폭포수 처럼 한번에 설계가 끝낼수가 없다. 무수한 리비전에 의해서 내용이 즉시 공유되어야 하고 잘못 공유 되었을때의 손실은 어마어마하다. 문서에 대한 버전관리는 필수이다.

    3.SRS(Software Requirements Specification) 어떤 내용이 담겨있는가?

     - https://www.abctech.software/download-templates/

     

     

    4.분석 아키텍트는 어떤 능력이 필요한가?

     - 요구사항을 바탕으로 분석을 해야하는데, 이때 분석 아키텍트의 역할이 중요하다. 요구사항을 최대한 명료하게 만들기 위해서 인터뷰를 해보는 것이다. 그에 필요한 덕목으로는 아래와 같다.

    인터뷰 기술, 인내심, 정보유도 기술, 질문 기술, 협상과 중재, 분석 기술, 청취 기술, 관찰 기술, 문서 작성 기술, 정보 조직화 기술, 모델링 기술, 대인 기술, 창조성

    5. 결국 모든 것은 프로젝트 성공을 위한 하나의 인자라고 보여지는데?

     

     - 프로젝트 실패요인이 어마어마 많듯이 성공 요인 또한 많다. 하지만 중에서 중요한 성공 요인이

  • 이 책을 통해서, 프로젝트 경험이 부족한 초보 개발자부터 이미 경력이 많이 쌓인 개발자까지 추상적으로만 갖고 있던 생각을 정리할 수 있을 것이다.

    컴퓨터 공학과에서 팀 프로젝트를 진행해본 경험과 AI기반의 스타트업에서 인턴으로 근무하고 있는 경험을 바탕으로 이 책을 읽으며 공감가는 부분과 미쳐 생각치 못한 부분이 많았다. 특히 책의 앞단에 소프트웨어의 스펙에 대한 오해와 스펙과 설계의 차이점 등에 대한 설명을 읽으며, 추상적으로만 갖고 있던 개념을 조금이나마 정리할 수 있게 된 계기가 되었다.(더 확실하게 정리하기 위해서는 책을 다시 읽고 2장의 SRS작성법을 따라하며 새 프로젝트를 진행해 봐야할 것 같다.)

    소프트웨어 스펙에 대한 기본적인 개념과 스펙 작성의 중요성, 잘못된 스펙 작성으로 인한 문제점과 사례 등의 순서로 내용이 진행되며 읽는 것에 대한 큰 부담감은 들지 않는다. 다만 많은 내용을 다루다 보니 조금은 지루하게 느껴질 수도 있다. 하지만 그만큼 배우는 것이 많은 게 장점인 책이다.

    앞서 말했듯, 초보 개발자부터 경력자가 봐도 좋은 책이지만, 특히 곧 개발자로서 취업준비를 하는 나로서는 아주 도움이 많이 되는 책이다. 물론 실무와 어느 정도 차이가 있겠지마는, 개발자로서 알아둬야 하는 내용을 인수인계받은 느낌을 받았다. 그동안 진행한 프로젝트에서 작성한 소프트웨어 스펙에서 누락된 내용이나 프로젝트 진행과정에서 아쉬웠던 부분들을 회상하며, 앞으로 프로젝트 진행을 할 때마다 들여다 볼 책인 것 같다.

  • 소프트웨어 스펙의 모든 것 - 김익환, 전규현 저 

     

    ## 책의 구성 및 평가 

    소프트웨어 개발에 있어, 스펙 명세의 중요성과 그 방법에 대해 서술 해 놓은 책입니다.

    1부에서는 소프트웨어 스펙이 어떠한 것인지, 스펙을 작성하지 않았을 때의 문제점 등 스펙이 왜 필요하고, 스펙이 어떤 것인지를 서술 하고 있으며, 2부에서는 스펙의 구체적인 작성 법에 대해 서술 하고 있습니다. 

    책에서 많은 내용을 다루고 있고, 처음 들을법한 이야기도 많으나 사례 중심으로 잘 적혀 있어 이해하는데 큰 어려움이 없습니다. 또, 실질적인 스펙 작성법에 있어서도 사례 중심으로 잘 설명해주어 추상적인 내용을 구체화 하여 받아들이는데 큰 어려움은 없었습니다. 

     하지만, SRS 스펙 문서를 작성하지 않았을 시에 대한 단점, SRS를 작성하면 좋은 점이 책의 초반부에 장황하게 나열되어 있어 처음에 글을 읽는데 어려움이 있을 수 있습니다. 문서를 제대로 작성하지 않았을 시의 단점을 너무 많이 제시 해 주는 반면에, 그에 대한 해답은 책의 뒷편에 있는 편이라 그래서 어떻게 해야 하는데 ? 라는 의문이 계속해서 떠올라 답답하게 느껴지기도 했습니다. 

     이 책은, 현재 주니어 개발자인 제가 읽기에는 너무 이른 감이 없지않아 있다고 생각은 들었지만, 다양한 사례와, 넓은 시야로 회사 프로젝트를 바라보는 시야를 가질 수 있는 좋은 경험이었습니다. 

     

    - 위 서평은 한빛미디어 '나는 리뷰어다` 서평단 자격으로 책을 무료로 제공받아 작성된 서평임을 밝힙니다.

  • 해당 도서는 기획자 및 개발자(특히나 시니어 및 리더) 분들에게 강력하게 추천을 드립니다. 전 지금까지 리뷰했던 책들이 저 개인에게는 좋았지만 타인에게 추천해야겠다는 생각은 크게 생기지 않았었는데 이번 책은 꽤나 추천에 대한 욕구가 솟아났던 책이었습니다. 그래서 책을 읽는 중간에 이미 제가 알고 있는 기획자 및 PM분 2분에게 해당 도서를 추천해버렸습니다.

     

    이 책은 SRS(Software Requirements Specification), 즉 스펙 작성에 대한 내용입니다. 책에 대한 내용은 목차 및 책을 훑어보시면 충분히 아실 수 있기에, 책을 읽으면서 느꼈던 감정 및 생각들을 공유하려고 합니다.

     

    참고로, 저의 직업 및 경력 그리고 일해온 조직 등의 배경으로 인해서 무릎을 치게되고 "아!"를 외쳐가면서 읽게되었습니다. 

    ✔️직업 : 개발자

    ✔️경력 : 6년

    ✔️환경 : IT 스타트업 경험이 전부

                  (첫 회사(약 6명) -> 두번째 회사(약 20명) -> 세번째 회사(약 120명))

     

    책의 내용에 왜 공감이 가는 이유를 생각해보니, 작은 규모의 회사 혹은 IT관련 스타트업에서 일한 경험이 가장 크다고 생각합니다. 모든 IT 스타트업이 그런건 아니지만 주로 소규모의 혹은 수익을 내지 못하는 회사라면 주로 공감이 갈것 같습니다.

     

    회사는 이익을 창출하는 곳인데 이익을 창출하기 위해서는 여러가지 서비스를 만들어내거나 혹은 하나의 서비스에서 다양한 기능을 만들거나 수많은 전략들을 시도하게 됩니다. 그리고 자연스럽게 이거저것을 많이 시도하면서 마감기한은 짧기에 주어진 시간이 늘 부족하게 되고 어쩔 수 없이 야근을 하게됩니다. 그러다보니 자연스럽게 문서를 작성한다거나 소프트웨어 혹은 기능을 만들기 위한 사전 작업에 소홀해지고 요구사항에 부합한 결과물을 만들어내지 못하게 됩니다. 더불어서 버그도 많이 양산하게 됩니다. 더불어서 제대로 스펙을 상정하고 아키텍트를 만들어가는 경험이 부족하게 됩니다. 일도 많이 하고 경력은 많아지는데 실력의 질은 비례하지 않게 되죠...

     

    책을 읽으면서 지금까지 프로젝트를 진행하면서 부족했거나 아쉬웠던 부분들이 생각났고 이런 부분들이 제대로 수정이 된다면 더 즐겁게 일할 수 있지 않을까란 생각도 자연스럽게 하게 되었습니다.

     

    책에는 소프트웨어 스펙이란 무엇이며 왜 필요한지에 대한 얘기가 자세히 설명되어 있으며 더불어서 SRS는 어떻게 작성해야하는지에 대한 도움을 받을수 있습니다. 개인적인 견해지만, 프로세스가 없거나 부족한 그리고 만들어가는 회사에서 일하고 있는 경력자인 개발자 및 PM 이라면 도움이 많이 될것이라고 생각합니다.

     

    아 그리고 중요하다고 생각한 부분입니다.

    해당 책은 혼자 읽으면 일하는 환경을 나아지게 만들기 어렵습니다. 최소한 팀 전체가 공감하고 실행할 수 있어야하며, 더불어서 회사 전체적으로 공감을 형성해야지 의미가 있다고 생각합니다. 아무리 프로젝트를 진행하는 팀이 괜찮은 방법을 적용시키려고해도 C레벨에 준하는 임원들이 공감을 해주지 않고 '그건 우리에게 맞지 않아' 같은 형태의 태도를 유지하고 명령(?)한다면 지킬 수 없기 때문입니다. 그럼에도 시작은 중요한 터닝포인트를 만들어줄 수 있기에 시작은 하는게 좋다고 생각합니다 ㅎㅎ

     

     

  • 소프트웨어 스펙의 모든 것

    프로젝트를 하면서 느낀 것은 사람들은 시스템으로 원하는 것이 어떤 것을 원하는지 잘 모른다

    요구사항은 프로젝트를 하면서 계속 변경된다.

    원하는 데로 만들고 나면 그것을 보면서 자신의 생각하는 것이 아니라고 한다.

    그러면 다시 재작업을 하면서 시간은 점점 소요되곤 한다.

     

    이 책을 보면서 스펙이란 것의 중요성을 다시 한번 생각하게 되었다.

    공감하는 내용이 잘된 샘플을 가지고 적용하고 싶지만,

    '남들이 만들어 놓은 샘플을 보는 것보다 스스로 많이 생각하면서 직접 맨땅에 부딪혀보는 것이 더 현명하다'라는 문구였다.

    프로젝트는 스펙에 대한 많이 고민하면서 나에게 많은 지침서가 될 수 있을 듯하다.

    누구나 중요하다고 생각하지만 아무도 잘 모르는 소프트웨어 스펙에 대해서 많이 고민하게 해준 책이다.

  • 한 줄 요약 : 초보 개발자부터 프로그램 관리자까지 프로그램에 대한 시야를 넓히는 데 도움을 받을 수 있는 책

     


     

    소프트웨어를 개발할 때 개발 결과물이 될 소프트웨어로(What) 문제점을 개선하기 위해(Why) 어떻게 만들 것인가(How)를 결정하고, 담당자, 실무자들의 협의를 거쳐 일정(When)을 결정하게 된다. 실제로 일을 할 때는 '최소한의 설계만 하고 일단 개발을 시작한다'와 같은 이야기를 많이 듣는다. 그 이유를 생각해보면 프로그램 개발을 요청한 사람의 요구사항은 변하는 게 당연하고, 변경된 요구사항이 전달될 때마다 스펙을 다시 정의하는 게 번거로운 일로 여겨지기 때문인 것 같다. 하지만 경험이 많은 경력 개발자(프로젝트 담당자)는 이런 점까지 고려해서 개발을 진행한다. 이들은 스펙을 따로 정의하지는 않지만 다양한 경험을 통해 돌발상황까지 머릿속에서 계산하면서 진행한다.

     

     

    나는 프로젝트 경험이 많지 않을수록 스펙 분석에 더 큰 노력을 해야 한다고 생각한다. 스펙을 분석하면서 프로젝트에 대한 이해도도 높이고, 돌발상황을 미리 생각해볼 수 있기 때문이다. 처음부터 이런 생각을 했던 것은 아니다. 처음엔 프로그램의 일부분만 보고 소스 코드부터 작성했다. 하지만 얼마 지나지 않아 수정 요청을 하거나, 생각하지 않았던 부분도 '당연히 생각했어야 했지 않느냐?'라는 이야기를 들을 때마다 답답함을 느꼈다.

     

     

    근본적인 이유는 내가 무엇을 프로그램으로 만들려고 하는지, 왜 만들어야 하는지에 대한 이해가 업무 요청자와 달랐기 때문이다. 작업을 요청한 사람은 숲을 보고 있는데 난 나무 한 그루만 보고 달려든 것이다.


     


     

     

    KakaoTalk_20210221_010917381_03.jpg

     


    이번에 읽은 <소프트웨어 스펙의 모든 것>은 이런 답답함을 줄여나가는 데에 큰 도움이 되었다. 저자는 시스템 개발 전 설계와 스펙을 SRS(Software Requirements Specification)라는 용어로 스펙을 왜, 어떻게 정리해야 하는지를  실제 사례를 들어 풀어내고 있다. 책은 크게 소프트웨어 스펙이 무엇인지 설명하는 부분과 SRS 작성법을 설명하는 두 부분으로 나뉘어 있다.


     

    소프트웨어 스펙인지 무엇인지 설명하는 부분에서는 에세이를 읽는 느낌을 받았다. 저자가 스펙의 필요성과 스펙 정의를 내릴 때 생각해봐야 할 것들에 관해 이야기해준다. 스펙은 상황에 따라 더 적절한 방법이 있을 뿐이다. 그렇기 때문에 경험이 부족한 나에겐 폭넓은 시야를 간접 경험할 수 있어서 도움이 되었다. 스펙을 설계할 때 생각해봐야 하는 것들을 독자에게 질문하고 답변하거나, 실제 스펙 설계를 할 때의 사례, 좋은 방법들을 알려주고 있기 때문이다. 내가 혼자 고민할 때는 생각하지 못했던 부분이 많아서 생각하며 읽어야 했다.


     

    KakaoTalk_20210221_010917381_02.jpg

     

     

     

    SRS 작성법을 설명하는 부분에서는 수많은 SRS 문서의 종류와 템플릿 예시를 설명해주고 있다. 스펙을 문서로 정리하는 것은 프로젝트의 규모, 당사자의 상황에 따라 형식이 다를 수밖에 없다. 나는 구글 문서를 이용해서 내가 보기 편한 대로 작성하곤 했다. 책에 포함된 템플릿 예시를 보면서 나의 부족한 부분들을 알게 되어서 큰 도움이 되었다. 


     

    KakaoTalk_20210221_010917381_01.jpg

     


    책을 읽으며 가장 기억에 남았던 한 구절은 머리말이었다.


    "소프트웨어 개발에 있어서 가장 어려운 일은 개발 자체가 아니라 무엇을 개발할지 결정하는 일이다"

     

    나는 경험이 부족한 개발자라서 프로그램을 개발할 때 다른 사람들과 커뮤니케이션하는 것이 가장 어렵게 느껴진다. 이 책은 나처럼 경험이 부족한 초보 개발자부터 프로그램 관리자까지 프로그램에 대한 시야를 넓히는 데 도움을 받을 수 있는 책이라고 생각한다.

     

    원문 블로그 : https://erinyees.tistory.com/36

     

  • 리뷰어's 잡담

    저는 소프트웨어 공학이라는 과목을 제 복수 전공들 과목들 중에 가장 자신있고 결과도 좋고, 재미있었던 과목이었습니다. 좋은 성적으로 해당 과목을 담당하시는 교수님으로부터 연구소 프로젝트 참여를 제안받아서 반년간 함께하게 되고, 제가 많이 성장하는 시간도 가질 수 있게 해준 기억이 있습니다. 소프트웨어 공학은 소프트웨어 프로젝트와 관련된 스펙, SRS, 설계, 테스팅, 프로세스 등등에 관한 내용을 다루는 학문으로, 현업 직무를 해보니 많은 관련이 있는 좋은 과목이었다고 생각합니다. 이번에 제가 리뷰어로서 작성해 볼 책이 이와 관련이 깊은 내용의 '소프트웨어 스펙의 모든 것'입니다. 저는 연구소에서 프로젝트를 진행하면서 SRS를 보고, 작성해보기도 했습니다. 명확한 SRS는 개발자의 혼돈을 줄이고 더 자세한 설계를 진행할 수 있습니다. 그런 점에서 이 책을 한번 읽어보면 좋을 것 같습니다.

    누가 읽으면 좋을까?

    여기서는 소프트웨어 스펙이라고 하지만 학사 출신으로서 가장 관련된 전공과목이라고 한다면 소프트웨어 공학 과목입니다. 컴퓨터 분야에 앞으로 종사 또는 이미 계신 분들도 읽어보기 좋은 간단한 책이며, 제 생각에 설명과 그림이 아주 심플하고 사례가 많아서 관련된 모든 분들이 잠깐잠깐 가볍게 읽으면 좋을 것 같습니다.

    책의 구성

    책의 구성은 크게 보면 간단하며 이론과 실전으로 구분을 해도 될 만한 내용이라고 생각합니다.

    1. 소프트웨어 스펙이란?

      전체적인 개요부터 SRS, 관행과 사례 등등의 내용이 있고, 점점 더 디테일한 부분을 간단한 그림과 예제로 쉽게 설명을 해줍니다.

    2. SRS 작성법

      실제의 예제들을 기준으로 간결하고 깔끔하게 설명해줍니다. 실수할 수 있는 부분에 대해서도 많은 설명이 나와있어서 그 부분이 좋았습니다.

    SRS와 설계

    제가 설계에 대한 개념이 없을 때 저는 소프트웨어 공학 및 설계 과목을 들었습니다. 유저의 관점, 개발자의 관점에서 다양한 설계를 해보면서 기본적인 방법을 익혔고, 연구소의 큰 프로젝트를 진행하면서 더 구체적인 SRS 작성부터 설계 및 구현까지 진행해보았습니다. SRS를 잘 작성만 해놓아도, 많은 충돌을 해결할 수 있습니다. SRS와 이를 바탕으로 진행 한 설계가 프로젝트 구현을 쉽게 만들어주고, 실수를 줄여줍니다. 어찌보면 프로젝트에서 가장 중요한 부분이고, 나중에 유지보수도 쉽고 오류가 적게 만들어줄 수 있습니다. 저도 이와 관련된 내용으로 포스팅이 존재합니다.

    다양한 예제를 통해 실전 프로젝트에 SRS을 작성해보자!

    2장의 SRS 작성법에는 구체적인 실제 SRS 템플릿으로 내용 설명 및 팁, 예제 등을 제공해줍니다. 이를 보면서 자신이 해보고자 하는 실제 프로젝트의 시작단계에서 간단한 SRS를 작성해보면 좋을 것 같습니다. 이를 바탕으로 설계도 해보고, 실제 구현에서 얼마나 많은 도움이 되며, 소프트웨어를 처음 보는 사람도 이해를 잘할 수 있는지에 대한 것도 한번 살펴보면 좋을 것 같습니다.



    출처: https://davinci-ai.tistory.com/58 [DAVINCI - AI]

  •  

    스펙이 사람의 역량으로 명명되고 있는 시대, 그래서 더 다양하게 사양되는 단어이기도 합니다.

    그리고 프로젝트를 성공으로 이끄는 소프트웨어 스펙 작성법으로 소프트웨어 스펙의 모든 것이 출간되었습니다.

     

    개인적으로는 책 뒷면에 SRS 프로젝트를 망치기 전에 알았다면 좋았을 것들이 소제목이었거나, 앞 페이지에 수식어였다면, 좀 더 명확하게 다가오지 않았을까 생각도 해 봅니다. 하지만 결국은 프로젝트 성공인 것은 마찬가지 입니다.

     

    소프트웨어개발사라는 그리고 개발자라면 항시 고민하게 되는 소프트웨어공학적인 접근과 실제의 괴리감입니다.

    프로젝트가 우선이기에 스펙없이 개발을 하다가 돌이키거나, 유지보수에서 전체 소프트웨어를 뜯어고치는 경우는 책에서만이 아니라는 것이다. 그런면에서 이 책은 실제사례를 A사, B사 이렇게 표현하면서 이야기 하고 있습니다. 진단을 위한 실제 사례들을 다루어서 좀 더 현장감이 있다는 겁니다. 

     

    실제로 많은 책들이 실제 다양한 사례들을 현장감있게 정리하는 것조차도 어려운 작업이고, 무엇보다 그래서 어떻게 해야 하는지를 독자에게 맡기는 경우가 많다는 것이다.  문제를 공감하지만 어떻게 약하다는 것이다. 하지만 스펙에 없을 때 등한시 했을 때 사례들과 문제점을 정리하고 스펙을 통해 가져올 수 있는 이점을 정리했고, 더 나아가 스펙을 작성하는 방법은 2부에서 상세히 다루고 있다는 것입니다.

    어쩌면 전사적인 활동으로 가능한 일 일수도 있고, 단순히 일회성으로는 유지가 되지 않는 것도 사실입니다. 하지만, 필요에 의하여 하게된다면 보다 체계적으로 진행해야 하는 것이다. 그런면에서 가이드가 되어 줄 책이라고 봅니다. 

     

    소프트웨어 스펙의 모든것

    2021-02-20-09-42-38-848.jpg

     

    SRS 프로젝트를 망치기 전에 알앗다면 좋았을 것들, 부정적인 문장이지만 그래도 공감도할 수 있는 문장이다.

     

    20210220_094320.jpg

     

    한빛미디어의 미리보기를 통해서 책의 내용을 참조할 수 있어서, 책의 어떤 내용인지 맛을 볼수 있습니다.

    https://preview2.hanbit.co.kr/books/gkws/#p=1

    목차.PNG

     

    SRS

    2021-02-20-10-07-24-334.jpg

    SRS

    2021-02-20-10-07-34-126.jpg

     

    SRS, SRS하는데 SRS가 몬가요?

    20210220_094249.jpg

    Software Requrements Specification 소프트웨어 스펙, spec, 소프트웨어 요구사항을 분석하고 이를 정리해 작성하는 스펙 문서이다.

    20210220_100757.jpg

     

    그럼 요구사항아인가요. 스펙하고 요구사항은 무엇이 다른가요? 책을 읽어보니 개인적으로 스펙 > 요구사항라고 생각이 듭니다. 

    2021-02-20-10-08-32-402.jpg

    스펙의 구성, 3W

    2021-02-20-10-12-29-386.jpg

     

    20210220_101247.jpg

     

    비즈니스 요구사항도 함께 작성이 된다는 것이다.

    20210220_101348.jpg

     

    프로젝트 단계별로

    20210220_100937.jpg

     

    20210220_100944.jpg

     

    그렇게 모든 것을 이야기 합니다.

    20210220_094257.jpg

    프로젝트 성공을 위한 발걸음입니다.

    20210220_094304.jpg

    책의 구성은 2부로 구성되어 있습니다. 1부 소프트웨어 스펙이란? 2부 SRS 작성볍

    20210220_094323.jpg

     

    스펙 작성법 중

    20210220_101417.jpg

     

    20210220_101618.jpg

    저자의 경력을 보면 실리콘밸리에서 시작되어, 국내 회사까지 두루 두루 경력이 스펙을 정리합니다. 그래서 단순히 이론에서 끝나지 않는 것 같습니다.

    20210220_101936.jpg

     

    전체적으로 책도 잘 읽혀집니다. 저자가 개발자의 글쓰기에 대하여서도 언급했는데, 명확하게 내용이 들어와서 구성과 내용도 대단히 만목합니다.

  • 책은 크게 1부와 2부로 구성되며 1부에서는 소프트웨어 스펙의 전반적 개념, 2부에서는 소프트웨어 스펙 작성법 중 하나인 'SRS'을 설명한다

    도서 초입에 프로젝트 성공/실패와 소프트웨어 스펙의 연관성을 설명하여 중요성을 강조하지만, 현업에서 오가는 말들을 통해 소프트웨어 스펙 정의의 현실을 보여준다 추가로 실제 프로젝트 사례를 나열하여 안타까운 현실과 스펙 정의의 중요성을 다시 한번 강조한다

    중반부에는 소프트웨어 스펙 작성 외 프로젝트 성공을 위한 조건 및 자세를 설명한다 회사는 공유 문화가 만연하고, 각 팀들은 역할 분담을 정확히 하여 병렬적으로 일을 수행하면 프로젝트는 성공적으로 끝낼 수 있다고 한다 여기서 개인은 공유 문화를 위해 수평적으로 협업하고 개발, 테스트, 인증 팀들은 짧은 주기로 공유하고 협업하여 효율적인 시스템을 유지해야한다고 한다

    후반부에는 위에 서술했던 'SRS' 작성을 구체적인 예시를 들어 설명하고 문서 작성 능력의 성장을 위해 꾸준히 작성할 것을 도모하며 마무리한다


    이 책은 개발 프로젝트의 성공을 위해 소프트웨어 스펙의 중요성을 강조한다 


    소프트웨어 스펙이 개발 기간, 개발 범위, 진행 사항, 팀원 혹은 팀 간 역할 분담, 고도화 계획 등 많은 것을 망라함을 말하는데 공감과 놀라움을 반복하며 읽었다 특히 소프트웨어가 미치는 부서의 영향 범위에 놀랐고, 여러 부서가 공동체로 움직였을 때 상상되는 파급력이 거대한 공룡처럼 느껴졌다 책의 일부에서 스펙과 스펙이 아닌 것을 정리해 준 부분을 읽을 땐 현업에서 나의 경험을 떠올리며 얼마나 형편 없게 작성했는지 부끄러움을 느꼈다

    감상평에 일일이 적을 수 없을 만큼 중요한 내용이 많이 담긴 책인건 확실하다 그렇지만 몇 가지 아쉬운 점도 있다 

    소프트웨어 스펙의 미치는 영향력을 설명하기 위해 A부터 Z까지 담으려고 한 의도는 알겠으나 범위가 너무 광대하여 집중하기 어려웠다 포괄적인 범위는 '이 것까지 고려해야하나..?' 싶은 의구심이 들었고 개발자라면 주니어에서 시니어로 넘어가는 개발자에게 적합하다고 느껴졌다 또한 마지막에 'SRS' 작성을 위해 구체적 예시도 설명해주며 이해하기 쉽게 쓰였지만 책에서 SRS 작성법 분량이 적지 않아 'SRS'를 작성하지 않는 사람이 읽기에는 아쉬움이 느껴질 것 같았다

    책 제목을 내 마음대로 응용하여 감상평을 마무리 한다

     

    소트트웨어 스펙의 모든 것(부제: 성공적인 개발 프로젝트를 위해 필요한 것, 그리고 SRS)

     

  • 김익환 님의 책들의 특징은 편안한 문체로 담담하게 서술하지만, 개발자로서 평소에 답답해하던 부분을 예리하게 집어 준다는 데 있는 것 같습니다. 이 책도 그러했고, 재미있게 읽었습니다.

    폭포수 모델과 달리 우리는 애자일이라서 잘 적을 필요가 없다.

    스펙 작성은 폭포수 모델에서나 하는 것이라는 생각은 오해다. 그런데 안타깝게도 스펙 작성이 어렵다는 귀에 익은 소문을 듣고 애자일을 선택하는 회사도 있다. 이 또한 애자일을 적용하면 어렵게 스펙을 작성하지 않아도 된다는 잘못된 생각에서 비롯된 것이다. 실무에서 폭포수 모델을 사용하는 소프트웨어 회사는 거의 없다. 방법론과 상관없이 소프트웨어 스펙은 중요하다. 애자일이라 하더라도 스펙 내용은 바뀌지 않는다. 적는 방법이 달라질 뿐이다. 폭포수 모델에서 소프트웨어 스펙을 잘 작성할 수 있다면 애자일을 적용한 프로젝트에서도 효율적으로 스펙을 작성할 수 있다. 애자일을 적용한 프로젝트에서도 스펙은 잘 작성해야 한다.

    1.2 스펙에 대한 오해 ( 본문 31페이지 )

    이 책의 전체 내용을 모두 담은 문장이 아닌가 싶어 가져와 봤습니다.

     

    제가 본 이 책의 내용은 크게 두가지 입니다.

    첫째, 이 책은 소프트웨어 개발 중 "스펙 작성"에 대한 이야기를 하고 있습니다. 전작들에서도 스펙작성에 대해서 꽤 강조하시는 편이었는데요. 이번 책은 아예 스펙 자체에 대해서 소상하게 설명하고 있습니다. 아마 이렇게 스펙을 소상하게 그리고 쉽게 서술한 책은 없지 않을까 싶습니다. 저자들에게 정말 감사의 말씀을 전하고 싶을 정도입니다.

    둘째, 몇가지 오해에 대해서 언급하는 부분들이 있습니다.애자일은 스펙을 작성하지 않는다던가, 실무에서 우리가 어떤 개발방법을 쓰고 있다는 착각에 대한 이야기 입니다.

     

    저자들은 전작들에서도 스펙의 중요성을 이야기 하곤했습니다.  "소프트웨어 개발의 모든것"에서 "소프트웨어 프로젝트 팀의 역량 평가표"를 제시하는데요. 20개 항목중 4가지가 스펙에 대한 겁니다.

    10. 프로젝트의 스펙 문서를 가지고 있다

    11. 스펙문서를 모든 관련자가 충분히 리뷰한다.

    12. 스펙이 바뀜에 따라 스펙문서가 업데이트되고 있다.

    13. 스펙 변경이 통제 관리되고 있다

    " 소프웨어 개발의 모든 것 "

    그만큼 스펙이 소프트웨어 프로젝트 팀의 역량에 중요한 요소인 셈이죠.

    물론, "글로벌 소프트웨어를 꿈꾸다"에서도 여러군데 스펙문서를 강조하는 이야기가 나옵니다.

    그러나 진실은 이렇다. 모든 소프트웨어 회사는 스펙을 작성해야 하고, 변화무쌍한 고객과 스펙을 조율하며 살아야 하고, 또 빡빡한 일정은 당연한 것이고, 그 일정에 맞추어 어려운 프로젝트를 수행해야 한다. 그러기 위해서는 회사에 잘 정비된 조직, 적절한 프로세스 유연한 문서작성법, 개발을 도와주는 기반시스템, 이런 것들을 수용하는 문화 등이 정리되어야 한다. 많은 부분이 경영진의 책임임은 말할 것도 없다.

    글로벌 소프트웨어를 꿈꾸다 - 22 소프트웨어 회사의 종류

     

    그래서 아마 이 책도 나온것 아닌가 싶군요. 저자들은 책을 두 부분으로 나누어서 서술했는데요. 1부에서는 스펙에 대해서 독자들이 이해할 수 있도록 다양한 방식으로 설명했고요. 2부에서는 스펙을 작성하는 방법을 서술했습니다.

    소프트웨어 개발에 대해 "체계"라는 것을 만들고 싶은 관리자들이 있다면, 이 책이 상당히 큰 도움이 될 겁니다. 특히 저자들은 컨설팅도 하시는 것으로 알고 있는데요. 컨설팅 의뢰를 하시는 것도 좋은 방법이 아닐까 싶습니다.

  • 리뷰를 시작하기 앞서

     

    운좋게 한빛미디어 도서 서평단에 선정이 되서 책을 리뷰할 수 있는 좋은 기회가 찾아왔다.

     

    나는 주니어 개발자임을 앞서 알리고, 책을 읽은 시점이 주니어 개발자의 시점이라고 봐주셨으면 좋겠다.

     

    책의 목차

     

    이 책은 크게 두 부분으로 나뉜다. 1부에서는 소프트웨어 스펙이란? 이라는 주제를 다루고, 2부에서는 스펙이라고도 하는 SRS 작성법에 대해 다룬다.

     

    책 소개

     

    나는 책을 읽기 전 스펙 작성이 그렇게 중요한가? 라는 생각을 항상 갖고 있었다. 학교 프로젝트를 할 때 나는 항상 스펙을 간단히 적거나 혹은 아예 적지 않고 바로 개발에 들어가곤 했었다. 하지만 이 책을 읽고나서 그러한 생각들이 아예 싹 사라졌다. 이 책은 나의 그러한 생각을 바꿀 수 있게 스펙을 써야하는 이유와 스펙을 안쓰거나 대충 작성할 경우에 일어날 수 있는 일들을 사례를 하나하나 들어가며 친절하게 설명해준다.

    또한, 스펙에 대해 Who, What, How 세가지 키워드로 분리하여 스펙은 어떻게 써야 제대로 잘 쓸 수 있는지를 알려주는 지침서가 되주기도 한다.

     

    마지막 2부에서는 실제로 SRS 즉, 스펙 문서 작성법을 어떻게 작성하는지 목차부터 시작해 자세한 예시를 들어서 설명해 주는 책이기도 하다.

     

    나는 이 책을 읽고나서 스펙을 왜써야 하는지, 스펙을 어떻게 써야하는지, 스펙을 쓰는 이유가 무엇인지에 알게되었고 앞으로 스펙문서를 쓰면서 항상 참고를 해볼만한 좋은 지침서가 하나 나온 것 같다.

     

    이 책을 살지말지 고민하거나, 나처럼 위와 같은 고민들을 갖고 있다면 이 책에서 정답을 찾을 수 있을 것 같다.

     

    주니어 개발자라면 대략적인 스펙 문서의 흐름을 터득하기에 좋을 것 같고, 시니어 개발자라면 스펙 문서의 교과서 같은 책이 아닐까 싶다.

     

    이 책의 머리말 중 가장 멋있던 말을 하나 남기며 소개를 끝낼까 한다.

     

    "소프트웨어 개발에 있어서 가장 어려운 일은 개발 자체가 아니라 무엇을 개발할지 결정하는 일이다"

    -프레드릭 브룩스-

     

    마치며

     

    책을 읽으며 소프트웨어 개발이 단순히 개발 능력이 중요한 것이 아니라 설계하는 것이 얼마나 중요한지 깨닫게 되었다.

     

    앞으로 이 책을 참고하며 개발을 할 때 스펙을 작성하는 법을 천천히 터득해가는 것도 좋은 경험이 될 것 같다.

     

    만약, 스펙에 관해 어떻게 써야할지를 몰라 인터넷을 돌아다니다가 이 글을 보게 된다면 과감하게 소프트웨어 스펙의 모든 것을 추천하고 싶다.

     

     

  • 개발자로서 스펙을 많이 작성했지만 아직도 매번 어려운 게 스펙 작성이다. 여러 가지 사항을 고려해야 하고 여러 사람들과 협의를 해야 하고 작성 이후에도 배포하고 운영하는 과정에서 나오는 여러 가지 문제 등 정말 제품의 시작과 끝을 함께하는 녀석이 아닐까 싶다.

    항상 해오는 것들이지만 다시한번 곰곰이 생각하게 되는 책의 내용에서 제법 많은 부분을 생각하게 되었다. 내가 기존에 정답이라 생각했던 게 그렇게 정답은 아니라는 거, 간과하고 지나쳤던 부분들이 실제로는 많이 중요하단 거. 그런 것들을 중간중간 보다 보니 책 읽는 재미가 있다.

    특히나 스펙에 포함되어야 되는 부분들에서 인터페이스, 하위 호환성 부분들은 놓치고 지나치기 쉬운 부분들이라 밑줄 그어놔야 겠다. 

    개발자로서 많은 시간을 보냈던 나로서는 부실한 분석의 스펙이 얼마나 차후에 큰 어려움을 다가오는지 뼈저리게 알기때문에 책의 한 줄 한 줄이 참 크게 와 닿았던 것 같다. 팀의 매니저로 선임연구원 정도에게 추천하고 싶은 책이다.

     

    다운로드.jpg

     

     

  •  

     

    <이 책은 한빛 미디어에 의해 제공받았습니다.>


    저는 이 책을 보자마자 '소프트웨어 스펙'이 도대체 무엇인가? 라는 질문에 사로잡혔습니다. 흔히 '스펙'은 specification의 약가로 서류 상의 기록이라는 의미로 사용됩니다. 그래서 제가 접해봤던 스펙은 취업하기 위해 쌓는 스펙과 컴퓨터의 사양을 의미하는 스펙 정도 밖에 없었던 것 같습니다. 그래서 이 책에서 스펙이라고 칭하는 SRS(Software Requirements Specification)는 저에게 굉장히 낯선 개념이었던 것 같습니다. 스펙은 프로젝트의 모든 요구사항을 취합해 모든 프로젝트 이해관계자를 연결하는 프로젝트의 중심이 되는 문서입니다. 따라서 프로젝트를 진행하는데 가장 중요하고 필수적인 문서도 스펙이라고 할 수 있겠습니다. 


    1부에서는 제 질문에 대한 답변을 해주는 듯이 '소프트웨어 스펙이란?'이라는 주제로 소프트웨어 스펙과 관련된 전반적인 내용을 독자들에게 설명해주고 있습니다. 흥미로웠던 것은 어떤 점이 소프트웨어 스펙을 기록하는데에 있어서 실패로 이끄는지에 대해서 이유를 짚어주고 있기도 합니다. 많은 예시들을 제시하고 있어서 이해를 하기 더욱 쉬웠던 것 같습니다. 특별히 기억에 남았던 사례는 분석 및 설계를 제대로 끝내지 않은 상태에서 개발을 하며 결국 빌딩을 지어놓은 채로 설계도를 그리는 것과 다름이 없다는 프로젝트 만 일정에 쫓겨 개발하는 회사의 사례입니다. 스펙은 프로젝트 진행을 위해서 초기에 필요하기도 하지만 프로젝트가 올바른 방향으로 끝까지 이어지려면 마지막까지 많은 수정과 보완을 거쳐가며 프로젝트 내용을 뒷받쳐 줄 스펙 문서가 필요합니다. 그러나 프로젝트 마감 기한에 맞춰서 간신히 개발을 진행하면서 문서를 요구하니까 개발 혹은 기획에 대해서 아무 것도 모르는 문서 전담팀이 개발된 내용을 바탕으로 오히려 역으로 문서를 작성하기도 한다는 예시였습니다. 말도 안되는 일이라고 생각할 수 있지만 아직까지도 스펙의 중요성을 깨닫지 못한 회사들에서 많이 발생하고 있는 일입니다.


    이 책의 중반에는 기업의 문화, 스펙을 작성하고 변경하는 프로세스, 그리고 누가(Who) 스펙을 작성하고, 무엇을(What) 스펙에 기록해야하며, 어떻게(How) 스펙의 재료를 얻어 가독성을 높일 수 있는지 서술하고 있습니다. 제가 가장 인상 깊었던 부분은 How 부분에서 '훔쳐보기는 이제 그만'이라는 소주제의 단락이었습니다. 프로그래밍 언어를 조금이라도 다뤄보신 분이라면 설계 없이 개발을 한다가 어떤 기능이 필요해지면 그 기능과 유사한 기능을 갖고 있는 소스 코드를 열심히 찾아볼 것입니다. 비슷한 것을 찾게 되면 복사 붙여넣기를 하기 십상입니다. 소프트웨어가 이런 식으로 개발을 지속해도 결국에는 돌아갈 수 있을지 모르지만 시스템의 결합도가 증가하여 복잡해지는 등의 어려움을 겪게 됩니다. 저는 이렇게 필요한 기능을 가져다가 그대로 사용하는 것을 훔쳐보기로 지칭한다고 생각했습니다. 이러한 훔쳐보기는 유지 보수가 어려워지거나 협업이 어려워질 수 있다는 큰 단점을 가지고 있습니다. 설계도에 없는 훔쳐보기는 순환 참조를 한다는 것인데 순환 참조는 코드 하나의 변화가 전체 소프트웨어에 영향을 준다는 점에서 굉장히 위험할 수 있습니다. 화자는 이러한 문제를 해결할 수 있는 방법까지 제시해주어서 흥미로웠습니다. 해결 방법은 바로 공통 모듈을 정의하는 것이었습니다. 공통 모듈은 초기 분석, 설계부터 시작해서 단순하고 시스템 이해에 도움이 될 수 있도록 한다는 큰 장점이 있기 때문에 앞서 언급했던 문제들을 해결할 수 있는 해결책이 될 수 있다는 것입니다. 


    이 책의 후반에는 2부의 시작과 함께 SRS를 작성하는 방법에 대해서 서술하고 있습니다. 이 또한 예시를 통해 어떻게 작성하면 좋은지 제시하고 있다는 점에서 정보로 가득차있는 책이라는 사실을 다시 한 번 깨달았고 관심 분야인 게임 앱을 만들 때를 예시로 들어 전체 설명을 한 부분이 가장 재미있게 읽었던 것 같습니다.


    만약 개발의 전반적인 부분을 관리하고 계획을 세워야 하는 일을 하고 계신 분들에게 이 책을 꼭 추천해드리고 싶습니다. 앞 부분부터 끝까지 하나도 뺄 내용 없이 스펙 작성이 얼마나 중요하고 프로젝트 하나하나의 큰 자산이 될 수 있는지를 몸소 느끼실 수 있을 것이라고 생각합니다. 처음 보면 어려울 수 있는 내용이라고 생각하고 저 또한 읽으면서 굉장히 어려웠습니다. 그러나 처음 소프트웨어 스펙에 대해서 접하게 되신 분들도 스펙의 의미부터 중요성, 용도와 작성법 등 많은 것을 배워 풍부해짐을 느끼실 수 있으리라 생각해 꼭 읽기를 추천드리고 싶습니다. 

  •  

    이 책은 한빛미디어에서 협찬 받았습니다.

    1.책을 읽기 전에

    전 소프트웨어 자문 및 개발을 하는 소프트웨어 사업자입니다.

    그래서 책 제목이 아주 마음에 들었습니다. 소 제목을 소개하자면

    "프로젝트를 성공으로 이끄는 소프트웨어 스펙 작성법"입니다.

     

    저 같은 소프트웨어 사업자는 꼭 읽어야 하는 필독서처럼 보였고 설레임으로 다가왔습니다.

    내 돈 주고 산 책은 아니고 한빛미디어 리뷰어로 참여해서 받은 책입니다.

    여러 종류의 책 중에서 다른 책은 관심 밖이었고 이 책을 제일 먼저 선택했습니다.

    왜냐하면 수 년간 이 업을 해오면서 고충사항이기도 한 스펙 작성"에 대한 내용이기 때문입니다.

    제가 하는 일에 직접적으로 도움이 되겠구나 생각했습니다.

     

     

    2.책을 읽고 난 후

      책을 읽기 전에도 예상했지만 다양한 프로젝트의 실패 사례를 소개하고 있습니다.

    저도 실무에서 직접 겪었던 일이기에 공감되는 부분이 많았습니다.

    프로젝트는 사람이 하기에 결국은 그 프로젝트를 이끄는 매니저(PM,PL이라고 많이 부름)의 역량에 따라 성공과 실패로 나뉘기도 합니다.

    저는 ERP 프로젝트를 여러차례 수행한 프로젝트 매니저이기도 합니다. 

    이 책에서 다루는 SRS 템플릿과도 사뭇 다른 문서이지만 스펙을 작성했었습니다.

    단지 덜 체계적이고 그 핵심 포인트가 빗나갔던 것 같기는 합니다.

     

     

    전산정보처리 업종에서 년수만 따지면 28년이라는 시간이 흘렀습니다.

    꽤 긴 시간동안 성공적인 프로젝트를 수행하기 위한 다양한 방법론을 공부했습니다.

    저자 두 분 역시 개발을 한 경험자분이기에 책의 내용 또한 충실하다고 생각하고 신뢰합니다.

     

     

      1부에서는 SRS에 대해서 이야기 하는데 전체 페이지중 25쪽부터 250쪽까지입니다. 

    상당히 길게 이야기 합니다.1부는 다소 지루한 면도 있었습니다.

    작성하는 방법은 언제 나오나하고 상당히 조바심도 생겼습니다.

    드디어 2부는 SRS 작성법입니다. 251쪽부터 347쪽인데 1부에 비해 상대적으로 내용이 많지 않습니다. 

    전부 읽고 나니까 굳이 첫 페이지부터 읽을 필요나 있었나 하고 후회가 됩니다.

    예비 독자분들은 2부인 SRS 작성법부터 먼저 읽어도 좋을 것 같습니다.

    그리고 1부로 넘어와도 내용 연결에는 큰 불편함이 없을 것 같습니다.

     

     

      책을 전부 읽고 난 후 느낀 점을 한 마디로 표현하자면 이렇습니다.

    SRS라는 용어는 처음 접했고 그 중요성을 새삼 다시 깨닫게 되었다는 것입니다.

    그리고 고민거리도 생겼습니다.스펙을 언제 작성해야 하냐는 것입니다.(외주 프로젝트의 경우를 말합니다.)

    물론 이 책에서는 스펙에 대해서 긴 지면을 통해 많은 이야기를 하고 있고 작성법 또한 상세하게 적혀 있습니다.

     

      매번 고객들과 상담할 때 했던 이야기가 떠오릅니다.

    고객들은 간단한 정보만 주고 견적서를 요구합니다.

    저는 그때마다 항상 똑같은 이야기를 합니다. 대략적인 견적을 드릴 수는 있지만 추후 변경될 수 있습니다.

    대략적인 견적이든 확정 견적이든 한번 견적서를 제출하면 금액이 내려 갈 수는 있지만 올리기는 어렵다고 생각합니다.

    그렇다고 처음부터 변동될 것을 대비하여 높은 견적을 내기도 어렵습니다. 업체 선정 검토 대상에서 제외될 수 있기 때문입니다.

     

      이와같은 고민때문에 저는 상세한 요구사항을 요구하지만 이에 호응하여 대응하는 고객은 그리 많지 않습니다.

    입장을 바꿔 놓고 생각해 보면 그 이유를 알 수 있습니다.

    최소한의 정보만을 제공하고 대략적인 견적을 복수의 업체에게 받아서 1차 검토대상 업체를 선정할 수도 있겠다는 생각이 듭니다.

     

      소프트웨어 프로젝트 실패의 원인은 많지만 제가 생각하는 원인 하나는 견적 관리입니다.

    프로젝트의 시작은 견적인데 첫 단추부터 제대로 처리하지 못하는 것입니다. 

    두번째 실패의 원인이 부실한 스펙의 작성이라고 생각합니다.


    3.스펙 작성의 중요성과 현실

      책을 읽다 보면 스펙 작성은 꼭 필요하다고 공감합니다.빠르게 그리고 품질은 좋게 만들어야 겠지요?(다 알고 있는 사실입니다)

    하지만 문제가 하나 있습니다. 바로 스펙을 작성하는 시점입니다.(외주 프로젝트의 경우)

    더 구체적으로 이야기하자면 계약 전에 하느냐 아니면 계약 후에 하느냐의 문제입니다.

    전 이 이야기를 꼭 하고 싶습니다.

    구매 발주자가 아닌 소프트웨어 사업자 입장에서는 계약 이전 단계에서 스펙을 작성하는 게 맞다고 생각합니다.

    이런 이야기를 하는 이유는 종종 견적단계에서는 대략적인 내용만 파악하고 계약 후에 상세한 스펙 작성을 하는 경우가 있어서입니다.

    (계약 전에 작성해야 상호 피해가 줄어 든다는 표현이 더 맞을 수도 있겠다는 생각이 듭니다.)

    쉽게 말해 프로젝트의 성패가 갈릴 수도 있을거라 생각합니다.

     

      책에서는 요구분석 단계에서 SRS 작성을 한다고 말하고 있습니다.

    물론 자사 제품을 만들 경우에는 큰 문제가 없겠지만 프로젝트를 외주업체에 맡기는 경우는 다르다고 생각합니다.

    아웃소싱의 경우에는 이 단계에서 작성하면 안된다고 생각합니다. 

     

      프로젝트의 크기도 제대로 파악하지 못하고(스펙도 모른체) 계약을 할 수 있냐는 것입니다. 

    이미 계약금은 입금되었을테고 알수 없는 리스크를 안고 프로젝트가 시작된 것이라 생각합니다.(프로젝트 중단 또는 실패로 끝날 수 있을 것입니다.)

    그렇다면 요구분석을 다 끝내고 계약을 하면 되지 않느냐고 되물어 볼 것 같습니다.

    이 문제는 한번 심도있게 생각해 봐야 할 것 같습니다. 

     

      긴 시간동안 고객(발주자)과 대면하면서 무상으로 분석을 해 줄수 있느냐,

    아니면 분석비용을 받고 요구분석을 하느냐의 선택이 필요합니다.

    그리고 발주자 입장에서 프로젝트를 수행업체 선정여부도 결정하지 않은 상태에서

    기업의 상세한 정보를 제공할 수 있느냐의 문제도 생길 수 있습니다.(보안상의 문제가 발생하는 것입니다.)

     

    4.마무리

      그렇다면 프로젝트 성공을 위해 어떻게 해야 할까요? 어려운 문제입니다.

     

    전 계약하지 않고도 간단한 핵심 데모를 만들어 시연해 주기도 했습니다.

    그리고 요구 분석은 1도 하지 않고 계약서에 도장부터 먼저 찍고 프로젝트를 진행한 적도 있습니다.

    그렇다고 해서 제가 기술적으로 뛰어나지도 않고 영업적인 테크닉도 전혀 없습니다.

    어려운 환경속에서 어떻게 살아남을 지를 고민하고 스펙 작성의 노하우를 터득하기 위해

    노력하고자 합니다.

     

    이 책은 저 같은 소프트웨어 사업자분들께서 한번쯤 읽어 보셔도 좋을 것 같습니다.

     

    긴 글 읽어 주셔서 감사드립니다. 대한민국에서 소프트웨어 개발을 해 본 솔직한 후기였습니다.

     

    2021.02.16

  • 개인적으로 프로젝트에 돌입할 때마다 스펙이라는 문서를 읽고 쓸 기회를 접하며, 덕질하는 시간에는 오픈 소스 문서 번역등에 기여해 본 경험이 있기에 언제고 기회가 되면 소프트웨어 스펙 작성법에 대해 진지하게 배우고 고민해봐야 겠다는 생각을 했는데 마침 적합한 책이 등장하여 리뷰를 남긴다.

    본 책의 메인 주제인 SRS란 소프트웨어 요구 명세를 의미하며 스펙이라고도 부른다. 구체적인 실체를 알고 싶다면 아래 링크를 클릭하여 저자가 소개하는 템플릿을 다운로드 하여 확인하기 바란다.

    SRS Template 다운로드SRS1
    SRS2

    이 책은 SRS를 작성하는 방법을 다루는 책으로 Who, What, How 등 다각도에서 고민해보며 기업 문화까지 스펙에 녹이고자 노력하는 진솔함이 돋보이는 책이다.

    저자는 2000년 초반에 출간된 “대한민국에는 소프트웨어가 없다.” 책의 저자이기도 하다. 당시 대한민국의 찍어내기식 사농공상 문화에 회의를 느꼈기에 책을 읽으며 많은 생각을 하였다.

    S/W 중심의 대한민국의 경쟁력 향상을 위해 개발자, 정부, 기업 등에 강한 일침을 가한 내용이 인상적이었는데 20년 가까이 지나 당시의 조언에 실리콘밸리식 문화와 커리어가 가미된 본 도서를 읽게 되니 감회가 새로웠다.

    컴퓨터 공학을 전공한 사람이라면 대부분 소프트웨어 공학 만큼 재미없는 전공 과목을 찾기도 어려울 것이다. 코딩을 통해 눈으로 결과를 보는 과정도 없고 실무 경험도 전무한 대학생이 사상 누각 형태로 장님이 코끼리 다리 만지듯 저 위에 떠 있는 실체없는 공학을 이해하고자 노력하는 것은 정말 답답한 노릇이 아닐 수 없다.

    문제는 이 현상이 기업에 입사하여 시니어가 되어도 지속된다는 점에 있다. 하나의 프로젝트를 모두 총괄하는 사람이 되어보기 전까지는 이런 총체적인 눈을 필요로 하지 않기 때문이다. 게다가 경험 미숙으로 스펙에 대한 내용이 구체적으로 와 닿을리도 만무하다.

    그런 측면에서 본 도서는 스펙을 작성하는 일이 따분함을 넘어서 왜 어려운지, SRS의 실체는 무엇인지 설명하기 위해 많은 지면을 할애한다.

    스펙에 대한 회사 구성원의 오해는 어떤 것들이 있는지, 스펙과 유사한 설계 및 요구사항과의 차이점은 무엇인지, 현재 스펙과 관련된 악습과 관행은 무엇인지, 기업 문화가 스펙에 왜 반영되어야 하는지, 스펙을 제대로 작성하지 못해 발생하는 실제 사례들은 어떤 것이 있는지 살펴본다. 2부에서는 실제 사례를 중심으로 SRS를 작성하는 예시도 소개된다.

    스펙이 작성하기 어렵다는 것은 저자도 충분히 공감하고 인정하기에 이를 작성하는 딱딱한 매뉴얼에서 벗어나 예시, 차이, 관점의 변화, 기업 문화, 영향 사례를 다각도로 짚어보며 스펙을 최대한 알기 쉽게 설명하고자 노력한 점이 책의 백미이다.

    이 책에는 SRS의 작성법 외에 또 다른 가치가 숨어있다. PM, 아키텍트 이상의 관리자에게 필수적인 프로젝트가 실패하는 이유, SRS를 통해 소프트웨어를 최단 시간 내 개발하는 법, 기업 문화와 사람 관리에 대한 방법에도 포커싱을 맞추고 있다.

    사실 이 모든 내용들이 올바른 방향으로 선행되어야 의미있는 SRS를 작성할 수 있음을 강조하고 있다. 그저 작성 요령만 갖출것이 아니라 개발문화, 관행, 습관, 프로세스, 원리, 원칙들이 모두 녹아있어야 좋은 SRS를 작성할 수 있다는 의미이다.

    SRS의 중요성을 인식하기 위해 책에서 제시하는 여러 예시 중 특히 인상 깊었던 것 2개를 꼽아보려 한다. 하나는 모든 프로젝트 이해관계자를 연결하는 중심이라는 점이다. 이 덕분에 제품이 완성되지 않아도 영업팀은 사전 판매에 돌입할 수 있으며, 인증도 사전에 취득할 수 있게 된다.이해관계자

    다음은 1:10:100 규칙에 대한 설명이다. 스펙이 변경될 경우 요구분석 단계에서의 비용이 1이라는 가정하에 유지보수 단계로 넘어갈수록 200배에 가까운 비용이 낭비된다. 시간이 흐를수록 얼마나 큰 비용이 발생하는지 구성원 전부 명확히 인식할 필요가 있으며, 그렇기에 스펙이 정확히 작성되어야 하는 것이 얼마나 중요한지를 보여주는 사례이다.규칙

    가장 인상깊었던 파트는 6장(프로세스)과 9장(How) 파트이다. SRS를 작성하는 매우 구체적인 방안과 예시가 소개되고 있으며 코드 리뷰처럼 스펙을 리뷰하는 방법이나 협업의 방향을 다루고 있어 조직의 발전을 위한 방향을 엿볼 수 있다.

    더불어 소스코드 및 유닛 테스트를 통한 스펙을 작성하는 실전법이나 인터페이스 개선 및 정의 부분은 수십년 간 경험을 축적한 저자의 내공을 느낄 수 있는 파트였다.

    10장 도구 편에는 SRS를 작성하는데 도움이 되는 툴들이 소개되는데 미처 몰랐던 유용한 Tip들이 다양하게 소개되어 있어 실전에 유용하게 사용할 수 있다.

    2부에서는 SRS 작성을 위한 구체적인 예시가 등장한다. 1부에서 익힌 감에 현 직장의 문화를 더해 실전처럼 적용해 볼 수 있는 구성이 마음에 들었다. 다만 한가지 아쉬운 점은 하나의 특정 개발 사례를 중심으로 일관성있게 소개되었다면 더욱 템플릿을 이해하기 쉽지 않았을까 싶다.

    소프트웨어 공학에 대한 책 중 이론을 설명하거나 번역서는 그래도 자주 접할 수 있다. 하지만 국내 저자가 국내 정서를 반영하여 작성했다는 점, 지극히 실전적이고 구체적인 예시를 든다는 점, 수십년 간의 전문적인 커리어가 반영되었다는 점에서 이 책은 관련 서적 중 매우 귀중한 희소성을 띈다 할 수 있다.

    PM, 아키텍트 이상의 관리자에게는 SRS 작성법은 물론 프로젝트의 성공과 올바른 기업 문화의 정착을 위해 필독서일 것이다.

    그 외 구성원에게 있어서도 이론으로만 존재했던 소프트웨어 공학의 실체를 느끼고, 개발 및 조직 문화를 이해하며, 프로젝트의 일원으로서 커뮤니케이션 능력을 향상 시키는데 도움이 되므로 어느 정도의 경험이 쌓인 개발자라면 반드시 일독할 것을 권하고 싶다.


  •  


    소프트웨어 스펙의 모든 것

     

     


    프로젝트를 성공으로 이끄는 소프트웨어 스펙 작성법

     

     


    저자 김익환, 전규현의 실전 경험을 녹여낸 『소프트웨어 스펙의 모든 것』을 보여주고 있다.

     

     


    읽기 쉽도록 기획된 구성은 소프트웨어 탄생 한편의 시나리오를 읽는 듯 하다.

     

     


    적절한 용어의 선택과 그림으로 이해하기 쉽게 편집된 것 또한 독자들을 위한 배려라 하겠다.

     

     


    소프트웨어 개발에 관여한 경영자, 기획자, 프로젝트 PM, 개발자, 코디네이터, 사용자 등 경험자라면 누구나 공감 100% 자신들이 경험한 이야기들이다.

     

     


     


    소프트웨어 개발에 왕도는 없다.

     

     


    프로젝트의 성공을 위해 소프트웨어 개발 목적과 스펙이

     

     


    왜? 명확해야 하는지를 다시 한번 일깨워준다.

     

      


    특히, 저자가 강조한 글로벌 진출을 위해 노력하는 소프트웨어 개발기업들은

     

     


    국제적으로 표준화된 스펙 작성에 관심을 갖고

     

     


    글로벌 협업의 필수인 ‘소프트웨어 스펙’ 작성

     

     


    인력양성 노력이 필요하다.

     

     


     


    그 동안의 경험을 체계적이고 누구나 쉽게 이해할 수 있도록 서술한

     

     


    한편의 시나리오를 함께 공유하여, 소프트웨어 개발기간 준수, 품질향상 등 경쟁력을 갖추자.

     

     


     


    이 책은 소프트웨어 개발에 참여하는 경영자, 프로젝트 PM, 개발자, 코디네이터, 사용자들의 필독서로 가까이 두고 읽고 활용할 것을 추천한다.

     

     


     

     


     

     


    #소프트웨어스펙의모든것 #프로젝트를 #성공으로 #이끄는 #소프트웨어 #스펙 #작성법 #김익환 #전규현 #한빛미디어 #개발자 #프로젝트PM

     

  • 이 책의 머리말에 보면 프레드릭 브룩스는,

    소프트웨어 개발에 있어서 가장 어려운 일은
    개발 자체가 아니라
    무엇을 개발할지 결정하는 일이다.

    라고 했습니다. 프레더릭 필립스 브룩스는 IBM에서 일한 소프트웨어 엔지니어이자, 컴퓨터 과학자입니다.

    실무에서 무엇을 개발할지 몰라, 일정이 지연이 되고 결국 실패로 끝나거나 아니면 다시 새로 개발을 하는 일이 비일비재합니다.

    그래서 이 책은 소프트웨어 개발에 있어서 뼈대가 되는 SRS(Software Requirement Specification) 을 다룹니다.

    1부에서는 SRS가 무엇인지 설명을 하면서 왜 소프트웨어 개발이 실패를 하는지, 왜 이런 Spec. 작성이 중요한지 그러기 위해서는 조직의 문화가 어떻게 바뀌어야 하는지 설명을 하고 있습니다.

    그러고 나서 2부에서는 SRS를 작성하는 방법을 설명하고 있으며 홈페이지에서는 템플릿을 제공합니다.

    옛날부터 소프트웨어 개발의 문제점을 해결하고 성공으로 이끌기 위한 여러 가지 방법론 들은 많이 나왔습니다.
    그러나, 단지 형식으로 끝나거나 우리나라 문화에 맞지 않는 방법론을 억지로 적용하다가 실패하는 경우가 많습니다. 그리고 문서작업은 낭비라는 선입관(?)을 갖는 개발자도 많습니다.

    하지만, 소프트웨어 개발을 성공으로 이끌기 위해서는

    "무엇을 어떻게 만들어야 하는가?"

    에 대해 대답을 할 수 있어야 합니다.
    또한 이해관계자들이 서로 같은 방향을 바라보기 위해서는 SRS와 같은 최소한의 문서는 필요합니다.

    이 책에서는 "일을 잘하기 위해서", "좋은 소프트웨어를 만들기 위해서"라는 형식에 얽매이지 않는 문서 작업은 필요하다고 말하고 있습니다. 그래서, 실제로 작성을 해보는 것이 중요하다고 말하고 있습니다.

    사실, 우리가 외국의 여러 가지 프로세스를 국내에 적용하면서 소프트웨어 개발 실패나 프로젝트 실패의 원인으로 우리나라 조직문화의 문제점을 말합니다. 관료주의라서 안되고, '빨리빨리'진행해서 결과를 중요시하는 문화 탓을 합니다.

    저는 생각이 좀 다릅니다. 이런 문호는 어쩔 수 없는 우리의 조직문화입니다.
    하루아침에 바꿀 수도 없고 바뀌지도 않습니다. 그래서 이런 조직문화에서도 소프트웨어 개발을 성공하고 프로젝트를 성공하기 위한 프로세스가 필요하다고 생각합니다.

    SRS 작성은 그 출발점이라 생각합니다.

    이 책의 저자 중의 한 분은 과거 "글로벌 소프트웨어를 꿈꾸다."라는 책을 쓰셨습니다. 그때도 그 책을 읽고 많은 생각을 했는데, 이번 "소프트웨어 스펙의 모든 것"이라는 책도 저로 하여금 많은 생각을 하게 합니다.


    "이 글은 한빛미디어 '나는 리뷰어다.' 서평단 자격으로 작성된 글입니다."

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

  •  대학원 시절 부터 글을 많이 적었었다. 제안서, 중간 보고서, 최종 보고서 등... IT 업계로 전직을 하고는 이상한 자료들을 만들었었던 기억이 있다. 그 당시에는 회사에서 시키기에 만들었지만, 지금 생각하니 SRS 등의 문서였던 것 같다. 어쨌든 그런 자료들을 만드는 게 너무 싫었다. 작성한 문서들은 작성한 이후 다시는 꺼내보지도 않았기에... 그냥 문서가 필요해서 만드는 문서, 그 이상도 이하도 아니었다. 그랬기에 반감이 더욱 컸던 것 같다. '문서 작성 = 시간을 축내는 일' 이었기 때문이다. 해당 도서에서는 스펙을 작성하는 이유는 개발 공수를 줄이기 위해 작성을 하는 것이라고 주장한다. 그럼 어떻게 해야 공수를 줄이는 글을 쓸 수 있을까? 여기서는 글을 쓰는 방법만이 아닌 기술을 공유하는 문화, 조직의 구성에 대해서도 상세히 기술하였다. 읽기 전에는 소프트웨어라는 단어 때문에 전문용어로 도배되어 있는 책일 것이라 생각이 되었지만, 개발을 잘 모르는 사람들도 읽을 수 있게 작성이 되었다. 물론, 이 책을 보는 것만으로는 좋은 글을 쓰기는 힘들다. 작은 프로젝트라도 직접 작성하는 버릇을 들여야 좋은 글을 쓸 수 있을것이라 생각한다.

  • 보통 개발자라고 하면 코드를 개발하고 프로그램을 잘 짜는게 중요하다 생각하지만, 이에 못지 않게 중요한 부분이 문서화라고 생각을 한다. 아무리 개발을 잘하고 완성도 높은 프로그램을 만들어도 이 프로그램의 스펙이 어떻고, 어떤 구조를 이루고 있는지를 설명을 못한다면 결국 그 프로그램의 가치를 제대로 이끌어내지 못하기 때문이다. 학교 전공으로 종종 프로젝트나 공모전등을 나갈때에도 이런 스킬이 꽤나 중요하다는 게 많이 실감나는 순간이 많았다. 하지만 보통의 전공에서는 개발을 중점적으로 진행하지, 이런 스펙 작성법에는 자세히 얘기하는 것이 드물기에 이런 부분에 약하지 않을까 싶은 생각이 든다.

     

     

    이번에 읽은 책은 이런 스펙 작성법을 잘 요약한 책이라고 생각한다. 이 책에서는 다양한 스펙문서 작성법중 SRS를 기반하여 작성을 하고 있다. SRS가 스펙 작성의 원리를 이해하기 쉬워서 도입했다고 하는데, 그래서 그런지 1부에는 스펙 작성의 원리를 2부에서는 이에 대한 실습으로 SRS작성법에 대해 소개하고 있었다.

    초반부에서는 스펙 작성 현주소와 여러 사례를 통해 스펙작성의 필요성을 언급하였고, 중반부에는 스펙 작성이 그렇게 어렵지 않은 것을 얘기하면서 구체적으로 어떻게 적어야 하는지를 육하원칙에 근거하여 설명을 하고 있었다. 특히 육하원칙(5W1H)에 따라 소개하는 부분에서 소제목으로 단순명료한 문장으로 보여주고 있는게 직관적으로 이해하기 쉽게 설명해주고 있어 무척 마음에 들었다. 

     

    2부인 SRS작성법은 하나의 템플릿을 보는듯 하였다. 1장에서 9장까지 소개된 내용은 어떠한 작성법이기 보단 이런 식의 내용이 들어간다고 소개를 하는데, 이런 소개내용이 일종의 완성된 보고서 양식같단 느낌이 들었다. 이 아홉장의 양식을 그대로 유지한채 자기가 개발한 프로젝트 내용만 여기에 맞춰 잘 정리하면 말 그대로 하나의 스펙이 완성되는 그런 잘 만들어진 모형틀이란 게 많이 느껴졌다.

     

    사실 소프트웨어 스펙 작성법이라고 해서 엄청 난이도가 높거나 어려운 내용을 요구할줄 알았는데, 생각보다 크게 어려운 부분없이 요점만 딱 잘짚어서 설명한 책이란 생각이 든다. 물론 모든 부분을 다 이해한건 아니고, 약간의 기술적인 배경지식을 요하는 건 있지만, 그래도 이런 식의 보고서 스킬을 정리한 책도 적을 뿐더러 이 책에서 소개하는 정리방법론도 꽤나 잘 설명하고 있어 마음에 드는 부분이 무척 많았다. 보고서 작성, 스펙 작성에 대해 고민인 사람들에게는 한번쯤 고민하고 구매해 볼만한 책이란 생각이 든다.

결제하기
• 문화비 소득공제 가능

배송료 안내

  • 책, 아이템 등 상품을 1만원 이상 구매시 무료배송
  • 브론즈, 실버, 골드회원이 주문하신 경우 무료배송

무료배송 상품을 포함하여 주문하신 경우에는 구매금액에 관계없이 무료로 배송해 드립니다.

닫기

도서판매처

리뷰쓰기

닫기
* 도서명 :
소프트웨어 스펙의 모든 것
* 제목 :
* 별점평가
* 내용 :

* 리뷰 작성시 유의사항

글이나 이미지/사진 저작권 등 다른 사람의 권리를 침해하거나 명예를 훼손하는 게시물은 이용약관 및 관련법률에 의해 제재를 받을 수 있습니다.

1. 특히 뉴스/언론사 기사를 전문 또는 부분적으로 '허락없이' 갖고 와서는 안됩니다 (출처를 밝히는 경우에도 안됨).
2. 저작권자의 허락을 받지 않은 콘텐츠의 무단 사용은 저작권자의 권리를 침해하는 행위로, 이에 대한 법적 책임을 지게 될 수 있습니다.

오탈자 등록

닫기
* 도서명 :
소프트웨어 스펙의 모든 것
* 구분 :
* 상품 버전
종이책 PDF ePub
* 페이지 :
* 위치정보 :
* 내용 :

도서 인증

닫기
도서명*
소프트웨어 스펙의 모든 것
구입처*
구입일*
부가기호*
부가기호 안내

* 인터넷 서점에서 구입한 도서를 인증하면 마일리지 500점을 드립니다.

* 한빛 웹사이트에서 구입한 도서는 자동 인증됩니다.

* 도서인증은 일 3권, 월 10권, 년 50권으로 제한되며 절판도서, eBook 등 일부 도서는 인증이 제한됩니다.

* 구입하지 않고, 허위로 도서 인증을 한 것으로 판단되면 웹사이트 이용이 제한될 수 있습니다.

닫기

해당 상품을 장바구니에 담았습니다.이미 장바구니에 추가된 상품입니다.
장바구니로 이동하시겠습니까?

자료실