2016년 10월 20일 목요일

소프트웨어 요구사항 명세서

소프트웨어 소프트웨어 품질 요구사항

템플릿 작성 가이드

<개발할 S/W 시스템의 특성 중 S/W 성능, S/W 용량, 신뢰성, 보안성, 사용성, 가용성, 유지보수성, 이식성, 확장성, 범위성, 구성용이성 등에 대한 비 기능적 요구사항들을 기술한다.>
소프트웨어의 품질을 측정할 수 있는 요구사항을 기록한다. 소프트웨어 요구사항으로는 다음과 같은 소프트웨어 품질을 다룬다.

응답성: 소프트웨어의 입력과 이에 대한 출력이 얼마나 빨리 계산할 수 있을지를 판단함
이식성: 일부 소프트웨어를 다른 하드웨어나 소프트웨어의 다른 레이어로 이식할 때 해당 이식작업이 얼마나 쉽고 효율적으로 진행되는지를 판단함

변경용이성: 소프트웨어 개선을 위해서 신규 소프트웨어 요구사항이 접수되었을 때 변경을 얼마나 쉽고 효율적으로 반영할 수 있을지를 판단함

유지보수성: 필드에서 발생하는 문제점의 원인 분석에서 수정 대응까지 걸리는 시간을 판단함. 혹은 유지보수 인원이 소프트웨어 개발 산출물을 사용하여 얼마나 쉽고 효율적으로 유지보수를 할 수 있을지를 판단함

이상의 품질 요구사항 이외에도, 각 팀에서 필요한 소프트웨어 품질 지표를 추가할 수 있다.




IoT 사례 연구 - LG 보안 사례

LG에서 제시하는 IoT 

보안 제품이 출시되기 전에 보안 취약점이 해결되지 않는다면 제품은 물론 서비스 자체에 큰 손실을 가져다 줄 수 있기 때문에 출시 전부터 보안에 대한 진단과 점검이 필요하다. LG에서는 디바이스, 앱, 게이트웨이, 네트워크, 서비스 등 IoT에서 발생할 수 있는 모든 영역에서 보안 취약점 분석이 이루어진다(그림6). 


<그림6> IoT 서비스 상의 보안 진단 범위 

 
출처: LG CNS 


LG는 각 영역 별로 상세한 보안 체크리스트가 제공되는데 IoT 보안, 스마트폰 앱 보안, 클라이언트/서버 보안, 클라우드 서버 보안으로 분류하고 있다. 클라이언트/서버 보안과 클라우드 서버 보안, 스마트폰 앱 보안의 경우는 기존 ICT에서 제시되는 보안 진단과 유사하게 구성되어 있고, IoT 보안 진단의 경우는 앞에서 얘기한 IoT 영역에 대해 전반적으로 진단되도록 구성되어 있다(그림7). 


<그림7> IoT 보안 체크리스트 


 출처: LG CNS 



애자일 프로젝트의 효율적인 협업 방안 - 2

Q: CBD 방법론이 처음에는 엄청난 반향을 일으켜 SI 프로젝트 방법론으로 많이 적용된 것으로 알고 있습니다. 오늘의 주제인 애자일과는 어떤 연관성이 있는지요? 
애자일이 처음 들어와서 CBD 방법론에 다소 오용된 경우가 있었는데요. 애자일도 점진적 반복이라는 기본 개념이 있기 때문이었습니다. 애자일이 좋아 보이는데 SI 프로젝트의 전체 프로세스에 적용하기는 어려울 것 같고, 이러다 보니 CBD 방법론의 이터레이션 부분에 애자일을 일부 적용해서 개발방법론을 수정한 경우가 종종 있었지요. 하지만, 이러한 시도는 애자일의 장점을 활용하는 것과는 거리가 있었습니다.


Q: 저도 기억이 납니다. 스크럼(Scrum) 개념을 개발방법론에 추가해서 사용했던 기억이 있네요. 애자일의 개념을 몰라서 그랬던 것으로 이해해야 할까요? 
아닙니다. 애자일의 장단점도 관점에 따라 여러 개가 나올 수 있죠. 그 때 당시에는 애자일이 대규모 SI 프로젝트에는 전면 적용하기가 어렵다는 의견이 많았습니다. 하지만, 새로운 시도를 위해 실패를 감내했던 것으로 봐야 할 것입니다. 여기서 말하는 새로운 시도는 스크럼에서 얘기하는 스프린트(Sprint)라는 일의 단위를 사용했다는데 의의를 둬야 할 것입니다(그림4). 


<그림4> 스크럼의 스프린트 

 출처: Wiki  


그림4를 보시면, 스프린트는 실행 가능한 제품 단위입니다. 다시 말해, 고객이 보면 이해를 할 수 있는 단위이지요. 이전의 SI 프로젝트에서는 고객에게 화면 설계, 데이터 설계, 프로세스 설계 같은 문서를 보여주는데 고객은 기술 단위가 아닌 자신이 일을 할 수 있는 단위로 보여주는 것이 이해하기가 훨씬 쉽습니다. 애자일을 적용하는 가장 큰 이유입니다. 
애자일 기반의 개발 순서에 대해 간략히 설명을 하면, 애자일에서는 개발 단위를 고객이 이해가 가능한, 완벽히 실행이 되는 단위로 계획을 세웁니다. 개발자들이 계획을 세우는 시점에 이것은 제품 백로그(Product Backlog)라고 불리고, 이 것은 개발이 되면서 스프린트라는 이름으로 완성이 됩니다. 마지막으로, 고객의 검수가 끝나면 완성된 스프린트는 다시 추가하거나 변경하는 작업을 하지 않습니다. SI 프로젝트와 가장 큰 차이가 있는 부분입니다. SI 프로젝트에서는 고객의 업무 단위가 아닌 개발자의 개발ID 단위이기 때문에 완성된 후에도 다른 개발ID에 따라 변경이 일어나는 경우가 다반사였지요. 

                                                   자세히 보기