프로젝트리서치(주) 법인 기념 세미나였던 “대한민국 개발자들이여.. 깨어나라! 올바른 SW 개발 방법과 개발 도구로 제대로 일하는 문화를 만들어보자!” 는 주제로 SRS 요구사항스펙정의서 작성기법(전규현 상무)과 SW공학 도구 체인(유승우 부사장)에 대해서 2일 세미나를 잘 치뤘습니다. 그날의 약속드린 자료와 +@에 자료를 더 챙겨서 본 후기 3.배포자료 다운로드를 통해 전달해 드립니다.
1. 실리콘밸리SW 회사들의 요구분석핵심 기법
2. SW개발 자동화 도구 아키텍처 분석 및 개선
3. 배포자료 다운로드
1. 실리콘밸리SW 회사들의 요구분석핵심 기법
“SW개발의 모든 것”의 저자이자 http://allofsoftware.net 로 유명하신 전규현 상무님께서 SRS Software Requirement Specifications, 소프트웨어 요구사항 스펙 문서 작성 기법에 대해서 첫 강연을 열어주셨습니다.
![SW공학 요구분석 SRS 및 툴체인 특집 SW공학 요구분석 SRS 및 툴체인 특집]()
![SW공학 요구분석 SRS 및 툴체인 특집 SW공학 요구분석 SRS 및 툴체인 특집]()
전규현 상무님 강의 자료는 참석 대상자 분들 포함해서 저작권 비공개 항목이라 분위기 캐치하기 위한 사진 정도로 만족하셔야할 듯 합니다. SRS의 유래에 대해서 ISO 12207, SWEBOK, IEEE830, DoD 문서와 비교를 해주셨습니다.
![SW공학 요구분석 SRS 및 툴체인 특집 SW공학 요구분석 SRS 및 툴체인 특집]()
SRS를 적는 이유에 대해서는 성숙한 개발자, 성숙한 기업, 주묵구구식, 주먹구구식.문서 기준을 비교하여 말씀하셨습니다. 주먹구구식 방식이나 초기에 분석/설계를 미흡하게한데다가 문서도 갱신없이 코딩만하면 결과적으로 계획보다 2-3배 정도 개발 시간이 더 걸리는데 반해 성숙한 개인이나 성숙한 기업은 분석:설계:코딩의 비유을 3:3:3 정도의 비율로 분석과 설계를 탄탄하게 한 후에 코딩/개발을 해야 일정 계획을 준수할 수 있다고 말씀해 주셨습니다.
![SW공학 요구분석 SRS 및 툴체인 특집 SW공학 요구분석 SRS 및 툴체인 특집]()
1:10:100의 원칙으로 소프트웨어 버그의 56%이상이 결국 “요구사항”에서 발생하며 이는 잘못된 요구사항과, 잘못 전달된 요구사항 아울러 누락된 요구사항에서 비롯된다고 말씀하였습니다.
![SW공학 요구분석 SRS 및 툴체인 특집 SW공학 요구분석 SRS 및 툴체인 특집]()
전규현 상무님은 국내 내노라하는 대기업, 중견기업, 벤처기업에서 SRS 및 SW공학 컨설팅을 진행하셨는데요, 한결같이 그들 회사 나름대로의 요구사항 정의를 제대로 못하는 이유를 나열해주셨습니다.
- 적는 것이 좋은 줄 몰라서 안 적는게 아니다.
- 만들어 보기 전에는 천재도 기능 내용을 다 알 수 없다.
- 나도 작성할 줄 아는 데 적을 시간이 없다.
- 나도 작성해 보았는데 우리 경우는 달라서 적기가 어렵다.
- 기획에서 주는 문서가 충실치 않아서 스펙을 적을 수가 없다.
- 폭포수 모델과 달리 우리는 Agile이라서 잘 적을 필요 없다.
- 잘 적은 샘플을 보여주세요
- 실리콘밸리에서는 한번 적으면 스펙이 변경되지 않는 다는 겁니까?
하지만 이런 것들은 모두 궁색한 변명들이고, SW개발의 뼈대가 되는 SRS가 가장 최우선 순위라고 말씀해주셨습니다. CBD, Waterfall, Agile과 상관없고 UML, 심지어 파워포인트 같은 설계보다 가장 우선시 하는 것이어야 한다고 말씀하시며 외국 SW 기업들은 이러한 UML, 설계서는 없어도 SRS만 잘 정의되어 있으면 이것을 기반으로 개발에 착수할 수 있다고 말씀하셨습니다.
![SW공학 요구분석 SRS 및 툴체인 특집 SW공학 요구분석 SRS 및 툴체인 특집]()
SRS 작성 중의 몇가지 원칙 중 MECE(미시, Mutually Exclusive and Collectively Exhaustive, 상호배제와 전체포괄)는 항목들이 상호 배타적이면서 모였을 때는 완전히 전체를 이루는 것을 의미, 즉 ‘겹치지 않으면서 빠짐없이 나눈 것’이 중요하다고 설명하십니다.
![SW공학 요구분석 SRS 및 툴체인 특집 SW공학 요구분석 SRS 및 툴체인 특집]()
SRS의 구조는 비즈니스전략, 제품조망, 전체시스템구성, 제품주요기능, 가정과 종속관계, 단계별 요구사항, 환경, 인터페이스 요구사항, 비기능 요구사항, 기능 요구사항으로 나뉘며 이 부분은 (1) 기계적으로 적는 부분 (2) 협업이 필요한 부분 (3) 창의성이 필요한 부분으로 분류될 수 있다고 설명하십니다.
![SW공학 요구분석 SRS 및 툴체인 특집 SW공학 요구분석 SRS 및 툴체인 특집]()
또한 SRS를 작성하기 전에 필수적으로 해야하는 일이 기준이 되는 (1) SRS의 파일명 정하기, (2) 형상관리에 포함시킬 폴더 정하기, (3) 이슈관리 시스템과 연동 규칙 정하기 (4) 문서 갱신에 대한 룰 정하기.. 이런 것들이 되어야 SRS를 첫 기획하고 계속 회의하면서 구체화 시킬 수 있다고 하셨습니다. 물론 요즘은 요구분석 전문 협업 도구가 있어서 쉽게할 수 있다고도 설명하셨구요.
![SW공학 요구분석 SRS 및 툴체인 특집 SW공학 요구분석 SRS 및 툴체인 특집]()
60명 규모였던 스페이스 노아에 좌석이 많이 불편하리라 예상되었는데, 아니나 다를까 세미나 내용은 좋았는데 장소가 많이 불편하다고 피드백을 받았습니다. 까페 노아에서 제공해 주신 음료 및 샌드위치 서비스가 좋아하셔서 다행이었습니다. 60명 정원 신청 완료는 물론 대기자만 50분이나 계셔서 저희도 적잖이 당황했고, 또한 많은 생각을 하게 했습니다. 올바른 개발 방법론, SW공학에 대한 갈망이라고 해야하나요? 우리도 외국과 동일한 SW엔지니어링, SW공학적 문화를 보급해서, 개발자/IT엔지이어가 올바로 행복하게 일할 수 있는 문화를 이뤄야겠다는 소명감 마저 들었습니다.
![SW공학 요구분석 SRS 및 툴체인 특집 SW공학 요구분석 SRS 및 툴체인 특집]()
총 4시간 중에 3시간을 SRS 필요성, 중요도, 난이도, 구성, 질의답변에 대해서 이야기했고, 마지막 1시간20분여를 SRS 템플릿의 구성 및 주의점에 대한 이야기를 나눴습니다. 어찌보면 이 부분이 핵심이기도 했고, 이 내용을 하기 위해서 총론 과정을 거친거죠.
![SW공학 요구분석 SRS 및 툴체인 특집 SW공학 요구분석 SRS 및 툴체인 특집]()
![SW공학 요구분석 SRS 및 툴체인 특집 SW공학 요구분석 SRS 및 툴체인 특집]()
첫날 대상자분들께 SW개발의 모든 것 책을 60분 모두에게 전규현 상무님 저자 서명해서 한권씩 나눠드렸어요.. ^^
![SW공학 요구분석 SRS 및 툴체인 특집 SW공학 요구분석 SRS 및 툴체인 특집]()
피드백은 대체로 좋은 편이었습니다. SRS를 처음 접하시는 분은 좋은 내용이었으나, 이미 SRS를 조금이나마 경험해보신 분들은 뒤의 템플릿 설명 부분에 좀 더 시간을 할애했으면 하는 사항이 많았습니다.
![SW공학 요구분석 SRS 및 툴체인 특집 SW공학 요구분석 SRS 및 툴체인 특집]()
세미나 이후의 9분이 함께한 저녁 식사때 많은 이야기를 나눴습니다. 저녁 식사 때 나눈 정보가 SRS 이상의 정보를 이야기 나눴습니다. 휴대폰 개발 이야기, 회사 개발 문화 등등…
![SW공학 요구분석 SRS 및 툴체인 특집 SW공학 요구분석 SRS 및 툴체인 특집]()
2. SW개발 자동화 도구 아키텍처 분석 및 개선
둘째날은 아키텍트그룹 유승우 부사장님의 3세대 개발환경에 대해서 트렌드와 데모 화면을 가지고 이야기 나눴습니다.
![SW공학 요구분석 SRS 및 툴체인 특집 SW공학 요구분석 SRS 및 툴체인 특집]()
처음 음양오행과 SW Lifecycle의 접목 관계로 시작하셨습니다.요구분석이 물 水 로 요구사항에 해당하며 가장 SW 개발의 가장 근본이 되는 것이다. , 이것이 되어야지만 제대로 된 소프트웨어 나무 木 열매를 맺을 수 있고….의 음양오행과 맞아 떨어졌습니다. 제가 한국형 프로젝트DNA로 우리것과 글로벌 PM 표준을 서로 접목시켜 전파하는 일을 하고 있는데, SW공학 분야 역시 음양오행의 이야기에 접목을 시켰다는 것이 흥미로운 발상의 시작이었던 것 같습니다.
![ARGP_Solutions_for_System&SoftwareEngineergin1.png ARGP Solutions for System SoftwareEngineergin1]()
이후 아래 소프트웨어 라이프사이클 한 장으로 1시간을 할애하셨습니다. 어찌보면 SW 공학, 선임 개발자가 다뤄야할 항목의 모든 것을 이 한 장이 이야기해준 것 같습니다.
요구사항 정의(SRS) 및 관리, 테스트케이스 설계 및 관리, 리스크 관리, 버그트래킹, 아키텍쳐 디자인, UX 디자인, 보안 및 취약성 관리 (SAST, DAST), 정적 분석 ( Architecture , Metric 분석, 정적에러검출, Depency 구조 매트릭스), 동적 테스트 및 분석( 단위시험 및 코드커러리지, Fuction 시험, 부하/스트레스 시험, 디버깅 & Profiling), 성능 분석 및 모니터링, SCM ( 변경분석, 코드리뷰, 현황 모니터링, Hybrid 개발), ALM & SW Ecosystem ( Idea > WIKI KM > Tracker > Integration > Social Dashboard) 의 각 항목에 대한 Trends 및 장/단점에 대해서 이야기 했습니다. 그 한시간 동안 쉬지 않고 이 한장을 이야기한 것 자체가 대단하네요.
![ARGP_Solutions_for_System&SoftwareEngineergin.png ARGP Solutions for System SoftwareEngineergin]()
이후에는 종류별로 데모 시연을 가졌습니다. 각 Demo 시연은 다음과 같았습니다.
요구분석 도구 Jama Contour 의 템플릿 기반 SRS 정의 및 Rolling Wave, 변경 추적 데모로 SRS 템플릿은 물론 기존에 검증된 요구사항의 템플릿화해서 보여주는 데모를 보여주셨습니다.
분산 SCM 인 Plastic SCM에 대한 소개 및 장단점 이야기로 소스 LOC(Line Of Code)가 1억 라인 이상이 넘는 대규모 프로젝트에서의 Time, Mission, Risk Critical한 경우에 분산 SCM의 유용성의 사례를 들어주셨습니다.
Imagix 4D에 의한 Data Precision, High Level, Drill down, Data Flow, Complementary Display, Automated Analysis , 100개 이상의 Software Metrics, Data Flow Checks, 20개 이상의Source Check 로 SW 아키텍처에 대해 정량,정성 분석에 데모 시연을 했습니다. Imagix 4D로 코드 오류 정보에 대한 수정 및 영향도 분석을 시각화된 아키텍처로 보여줌으로써 결함 빈도와 밀도, 그리고 각 오류에 대한 고유 trace를 분석 및 통합해서 코드 수정의 우선 순위와 영향도 및 결함 패턴을 식별할 수 있어 SW 아키텍처 구조 분석에서의 수정 요소와 코드 오류상에서의 수정의 상관 관계등을 지표화할 수 있는 사항을 보여주었습니다.
Goanna 에 의한 컴파일을 통해 성숙도가 낮은 QA 조직에서 사용하면 바로 효과를 볼 수 있는 정적/동적코드분석의 Metrics 결과에 대한 데모로, 어느 소스가 어떤 오류 가능성이 있는지에 대해 알려주는 기능
Lattix에 의한 DSM (의존도 구조 매트릭스 Dependency Structure Matrix)로 소프트웨어 아키텍처의 To-Be 모델에 대한 거버넌스 활동을 구체화 및 자동화 하기위한 기술로 Function, Class, Type, Local Variable, Function Point 등 하부 단에서의 세밀한 밀도룰 재구조 및 사전 설계할 수 있는 도구를 보여주었습니다. 또한 일본의 카메라 제조사가 본 도구를 이용해 정량적으로 아키텍쳐 분석 리포트를 하는 사례를 보여주었습니다.
Checkmarx로 Virtual Compiler 기반의 빌드 환경에 대해 로그 분석이나 사전 컴파일러 전 처리 작업 없이 즉각적 코드 오류와 보안 취약 사항을 점검할 수 있는 도우에 대해 OWASP나 CSW 근거로 하는 보안 취약 사항과 Null, Resource 누수 에러를 잡아내는데의 탁월성을 이야기 했습니다.
![SW공학 요구분석 SRS 및 툴체인 특집 SW공학 요구분석 SRS 및 툴체인 특집]()
![SW공학 요구분석 SRS 및 툴체인 특집 SW공학 요구분석 SRS 및 툴체인 특집]()
이 역시도 애자일 회고 기법으로 많은 피드백을 받았습니다. 도구에 대해서는 저희는 각 글로벌 기업, 국내 대기업/리더 기업들이 사용하는 예를 위주로 보여드렸는데, 오픈소스에 대한 니즈와 요구분석, 형상관리, 정적코드, 동적코드, ALM, 지식관리 등 넓은 분야에서 보다 깊은 내용의 실무 실습 까지도 원하는 사실에서 약간은 암울한 IT 환경을 어떻게든 개선하고자 하는 의지를 많이 보여주신 것 같습니다. 첫날과 둘째날의 피드백을 바탕으로 보다 아키텍처, 개발자, QA, 빌드관리자, 지식관리자 및 PM/PMO를 만족시킬만한 실무 아카데미를 제공해야겠다는 소명감까지 들었습니다.
![SW공학 요구분석 SRS 및 툴체인 특집 SW공학 요구분석 SRS 및 툴체인 특집]()
3. 배포자료 다운로드
배포자료에 대한 가이드는 첫 공지한데로 표준에 대해서는 먼저 공지하였습니다. 워낙 자료들이 현업에서 사용하시는 자료여서 공개 승인 받는게 어려웠습니다. 특히나 SRS에 대해서는 발표 자료는 어렵고 마지막 시간에 사용했던 템플릿을 받았습니다. SRS에 대해서는 상기 발표 스냅샷을 참고해주시면 감사하겠습니다. SW공학 툴 체인은 발표 자료는 받았으나 설명 없이 자료만 배포하기에는 무리가 있어 우선 세미나 참석/대기 대상자 분들에 한해 공유합니다. (패스워드는 신청하신 온오프믹스 메일로 보내드렸습니다.)
- SRS 템플릿 (영문/한글 혼용) - ”SWEng배포-201303228.pdf” 문서의 p1-30 페이지
- SW툴체인발표자료 (한글) - ”SWEng배포-201303228.pdf” 문서의 p31-40 페이지
- PDU 등록 가이드 (8 PDU 인정) - ”SWEng배포-201303228.pdf” 문서의 p41-42페이지
- SWEBOK (Software Engineer Body of Knowledge) (영문)
- SRS (Software Requirement Specifications) / IEEE830 표준 가이드 (영문)
- 산자부 SW표준 프로세스 (한글)
- 서울시 프로젝트 관리 방법론 및 템플릿 (한글)
- 서울시 SW 개발방법론 및 템플릿 (한글)
이번 세미나는 많은 것을 느끼게 한 시간이었습니다. 정말 월화수목금금금의 IT현실의 돌파구를 찾는 분위기라든가, 올바른 개발 환경 문화에 대한 열정이 단지 가이드해 줄 선배,멘토,문화가 없지 않았나 싶습니다. 제대로 일하시는 Guru 들이 올바른 개발 문화를 만들어 나가는 환경을 만들고, 이에 많은 개발자들이 같이 참여하고 개선시키는 개발 환경 혁신 활동 및 전파가 절실히 필요함을 느꼈습니다. 저희 프로젝트리서치, 아키텍트그룹, ABCTech 이 3개 회사가 힙을 합쳐서 올바른 SW 개발 환경 및 IT-PM 환경 문화 만들어나가는데 노력하겠습니다.