Zero's eye

rcm2 limited has considerable experience and expertise in Systems Engineering/System Integration processes, Requirements Management processes and IT tools, in particular the DOORS database from Telelogic. We have a number of DOORS licenses that are shared among our DOORS User Group for various client projects and internal consultancy as well as bespoke solutions. 

We also run specialist DOORS/DXL training courses as part of our consultancy and bespoke solutions for clients and so far over 100 people have been trained in the use of DOORS by our consultants. The various areas where DOORS is used by rcm2 team are as outlined below:

DOORS for Standards Traceability Management 
DOORS is a software tool for managing complex projects. It is used to store multiple Documents and Tables containing project requirements and other information. You can readily import Word and Excel documents and Access Tables into DOORS as it is both document-centred as well as spreadsheet-like. For example a typical standard may contain information notes, guidance notes and requirements. By importing the standard into DOORS:
• All individual requirements may be tagged (Attribute ‘Type’= Requirements, Guidance Note, etc.) and filtered from the rest of notes without losing the remainder of information;
• Requirements may be categorised (Attribute ‘Category’ = CAT1, 2, 3);
• Requirements from separate documents may be linked showing one-to-one, one-to-many, ... relationships. This is an important feature allowing traceability through the project lifecycle
• Any project, product supplier or vendor may use DOORS Links to individual standards for example to demonstrate compliance with mandatory CAT1 requirements. SEE OUR EXAMPLE WORK FOR LUL. 

DOORS is more than a document management software. It is a multi-user multi-access database environment. It ensures that all information, such as the history of the Standards documents, are stored. In long-term this ensures a full audit-trail of the justification and reasoning behind any particular mandated requirement or guidance note. DOORS allows coverage and gap analysis for example by means of suspect Links. It also provides strict configuration management and change control facility. 

DOORS for Safety Case Management 
We customised DOORS for management of safety information, such as a Hazard Log, Compliance with Safety Standards (e.g. RGS, TSI, HMRI Railway Principles and Guidance, LUL), project-specific safety requirements, and to implement safety case notations such as GSN and ASCAD. This led to our now acclaimed ISCaDE^TM product. 

Conclusions 
DOORS is a flexible tool that we have customised to support each of our client project’s needs. It is very configurable and adaptable. The key has been to identify in a project quality plan the set of procedures best fitting any particular project’s needs. These include, for example, what documents need to be imported into DOORS and which ones just referenced, who needs to be trained, how to use DOORS in conjunction with other Office tools such as Word and Excel. The aim has been to use ‘horses for courses’ and save the overall project costs and resources (staff time). Where it was decided to use DOORS on a particular project, it has led to efficiencies in time and cost of overall information management (traceability and retrieval as well as co-working). On simpler projects we have advised that simple Office tools would suffice. However, we also firmly believe it is wrong to re-invent the wheel. We have seen projects trying to invent a new bespoke requirements management tool using MS-Access. Our reply has been to demonstrate the considerable problems with this approach and explain why it is best to make most use of best breed Commercial Off-The Shelf (COTS) solutions instead.

  Water Fall 모델은 개발단계가 요구사항 수집부터 유지보수까지 순차적으로 진행되는 모델을 말하며, 각 단계를 완료하기 전까지 다음 단계로 진행하지 않는다. Water Fall 모델에서는 각 단계마다 요구되는 문서들이 있으며 이러한 문서들을 중심으로 개발단계가 흘러가게 된다. 

  Water Fall 모델은 다음과 같은 단계를 가진다.
요구사항 -> 상위 설계 -> 상세설계 -> 구현 -> 테스트 -> 릴리즈 -> 유지보수

[ Water Fall 모델에서 생성되는 산출물(문서)들 ]

Requirements analysis	Feasibility study, Outline requirements
Requirements definition	Requirements documents
System specification	Functional specification, Acceptance test plan Draft user manual
Architectural design	Architectural specification, System test plan
Interface design	Interface specification, Intergration test plan
Detailed design	Design specification, Unit test plan
Coding	Program code
Unit testing	Unit test report
Module testing	Module test report
Intergration testing	Integration test report, Final user manual
System testing	System test report
Acceptance testing	Final system plus documentation

  소프트웨어 공학은 대규모의 프로젝트에서 저비용 고효율을 창출하고 소프트웨어의 위험요소를 줄이기 위한 접근 방법이다.

  하지만 모든 소프트웨어 프로젝트가 성공하는 것은 아니다. 우리의 프로젝트 역시 성공할 것이라는 보장은 없다. 그렇다면 우리의 프로젝트를 성공으로 이끌려면 어떻게 해야 할까?

  정답은 실패한 프로젝트에서 그 원인을 찾는 것이다. 다양한 원인이 있을 수 있다. 하지만 오늘은 몇가지에 대해서 살펴보고자 한다.

• 초기 Requirement를 정확히 분석하지 못한경우
• 무리한 일정
• 정치적 압력

1. 초기 Requirement를 정확히 분석하지 못한경우
  최고의 설계 전문가, 최고의 개발자, 최고의 프로젝트 리더, 최고의 문서 전문가, 최고의 테스터가 한팀을 이뤄 소프트웨어 프로젝트를 진행하려고 한다. 고객을 만나 Requirement를 수집하고 이를 정리했다. 일정 계획을 수립하고 정리된 요구사항을 바탕으로 설계를 하고 구현을 하고 문서화까지 모두 착착 진행했다. 최종적으로 산출물을 고객에게 전달했을때 고객의 반응은 "이건 제가 원하던 그것이 아닙니다" 였다.

  왜 그랬을까? 이들은 최초에 고객이 전해준 요구사항을 명확하게 정리하지 못했고, 한번도 요구사항에 대해서 의심하지 않았을 것이다. 그들은 각 분야에 대해 최고의 전문가였고 요구사항에 만족할 만한 결과를 냈지만 그들이 정리한 요구사항과 고객의 생각이 다른 부분이 있었던 것이다.

  이론은 항상 말한다. 요구사항이 완벽하게 정리되기전에 디자인에 들어가지 말아라. 하지만 현실은 다르다. 빠르게 돌아가는 현실에 맞추기 위해서는 때론 설계가 되기 전에 요구사항이 정리되기도 전에 구현에 들어가는 경우가 많기 때문이다. 이는 그 만큼의 위험을 감수하고 서라도 프로젝트를 끝내야 하기 때문이다. 여기서 일정문제를 한번 생각해보자.

2. 무리한 일정
  지난번 실수를 만회하기 위해 요구사항을 모호함 없이 빠짐없이 기술한 후 프로젝트 리더가 설계 및 구현 일정 계획을 수립했다. 최대한 빨리 끝낼 수 있도록 한치의 오차도 없이 시간 안배를 했고 이를 프로젝트 팀원과 고객에게 설명하며 "우리는 이 프로젝트를 수행하는데 있어 5개월이  필요합니다." 라고 말하자 설계 담당자는 설계하는데 3개월이, 개발자는 2개월, 테스터는 3개월이 필요하다고 말했다. 옆에서 듣고 있던 고객은 "저희는 3개월의 시간밖에는 없습니다. 이 제품이 3개월 후에는 출시가 되어야 합니다."라고 말했다. 당신이 프로젝트 리더라면 어떻게 하겠는가? 이대로 진행 할 것인가? 아니면 포기하겠는가? 설계자, 개발자, 테스터는 어쩌란 말인가? 밤샘을 하라는 말인가? 인원을 더 투입하라는 말인가?

무리한 일정은 모든 단계에서 품질의 저하를 가져오고 결과적으로 산출물이 나왔더라도 완성도가 떨어지는 반쪽짜리가 될 가능성이 크다. 또한 팀원의 사기 저하를 불러올 수도 있고, 새로 인원을 더 투입한다면 비용이 그만큼 더 들어가고 숙련되지 않은 인원을 투입한다면 안쓰는 것만 못할 수도 있다.

3. 정치적 압력
프로젝트 리더는 한참을 고심한 후에 일단 사장에게 보고하여 조치를 취해야 겠다고 생각했다. 사장은 모든 이야기를 듣고 프로젝트 리더에게 이 프로젝트는 말도 안되는 일정임에 틀림없지만 고객사는 우리 회사의 가장 큰 고객입니다. "3개월안에 끝내도록 하세요."라고 결정을 해버린다. 이후 사장은 수시로 프로젝트 팀을 방문하여 일정은 잘 지켜지고 있는지, 고객의 기분을 상하게 한적은 없는지 끊임없이 물어본다.

어떤가? 당신이 그 프로젝트를 지금 하고 있다고 생각한다면, 3개월 안에 끝낼 수 있겠는가?
그렇다고 생각한다면 프로젝트를 끝마쳤을 때 품질에 대해 고려 해보았는가?

물론 프로젝트를 실패로 이끄는 이유에는 여러가지가 있겠다. 하지만 현재 본인이 처해있는 상황과 비슷한 실패의 이유를 예로 들어 소개하였다. 당신의 고객이라면, 회사의 사장이라면, 프로젝트의 리더라면, 혹은 팀원이라면 한번쯤 생각해 보길 바란다.

* 프로젝트를 성공으로 이끌기 위해서는 실패한 이유에 대해서 분석하여 동일한 실수를 하지 않아야 한다.

오늘부터 Software Engineering 관련 글들을 Posting 할 계획입니다. Software Engineering은 그 내용이 방대하기 때문에 때때로 필자가 다루는 부분만을 Posting 합니다.

본 블로그의 글은 전적으로 개인적인 글이므로 보다 많은 정보를 얻기 위해서는 다른 SE 관련 Web Site 들을
참조하실권을 권장드립니다.

또한 다음의 권장도서는 Software Engineering을 공부하실때 많은 도움을 줄 것으로 생각합니다.

Software Engineering 6/E:a Practitioner's Approach 카테고리 컴퓨터 지은이 Pressman (McGrawHill, 2004년) 상세보기

본 블로그의저작권은 Open 되어 있으며 옮겨 가실때는 출처만 기재해주시면 감사하겠습니다.

제가 Posting 하는 글을 보시는 분들에게 제 생각이 조금이나마 전달되기를 바랍니다.

감사합니다.