그러면 우리의 현상은?

실제로 고객으로부터 사양의 변경이 빈번하게 일어나고 있다는 목소리가 높은데, 이에 대한 실체는 무엇일까요?

이런 경우 컨설턴트에 의뢰를 하기 전, 나름대로 요건변경 건수 데이터 등을 모으고 있습니다. 이런 변경건수를 산정해 보면 보통 기본 베이스의 40%에 육박하는 경우가 많습니다. 이런 변경건수의 증가를 분석해 보면 또 프로젝트 후반에 집중되어 있는 양상이 대부분 입니다.

한편, 이를 설계자가 작성한 사양에 대한 문의(질문) 건수 데이터와 비교를 해 보면 시간, 건수가 요구사항 변경건수와 어느 정도 同期化가 되어 있음을 알 수 있습니다. 결국 설계자가 프로그램 코딩을 하는 중에 애매한 표현의 사양을 만나면 이것이 곧 사양변경의 시발점이 될 수 있습니다.

그럼 이런 변경을 만들어 내는 주체는 결국 누구인가?

위에서 알 수 있는 것은, 결국 사양 변경을 만들어내는 주체는 결국 설계자 자신이라는 겁니다. 프로젝트 후반에 사양변경이 빈번하게 일어나는 것은, 코딩이 시작되는 시점에 대부분 프로젝트 중, 후반부터 이며 이때부터 개발자들이 사양에 대한 문의가 발생하기 때문입니다.

결국 현상은

ü  의뢰자는 ‘사양’이라 불리우는 것을 쓸 줄 모른다.

ü  사양의 변경은 설계자에 사양에 대한 문의로부터 시작된다.

ü  게다가 설계단계로부터 Deploy단계까지 변경이 다발적으로 일어나고 있어 프로젝트가 제대로 진행되지 않는다.

입니다.

설계자의 잘못된 사양의 원인은 의뢰자(고객)의 적절하지 못한 사양서 입니다. 이를 설계자는 “읽는 것 만으로” 사양의 누락이 있는지를 체크하는 것이 대부분 입니다. 처음에는 사양서를 읽으며 애매한 부분을 수정해 나가지만 이것이 길어지게 되면, 언제까지 사양서 수정만 할 수 없기 때문에 결국 “탐색적 진행” 모드로 전환, 코딩해 가면서 수정하는 경우가 많습니다. (초창기 대기업 IT개발관리자들, 그리고 현재 경험부족의 중소기업들의 현실입니다)

여기서 더 악화되는 상황을 이야기해 보면, 사양과 사양의 충돌이 발생하게 됩니다. 빈번한, 무계획적인 수정에 의해서죠. 결국 이러다 보면 충돌을 피하기 위해 사양 자체에 제한을 걸게 됩니다. 의뢰자(고객)은 이를 기쁘게 볼 리 없겠죠.  고객 입장에서는 어떻게든 제한된 요구를 관철하기 위해 결국 새로운 요구사항을 만들어 내게 됩니다. 요구사양의 증가, 변경이 결국 정리가 안되는 상황으로 치닫게 됩니다.

이런 현상을 막으려면 초기에, 의뢰자가 사양서를 쓰는 단계에서, 제대로 사양서를 쓰게 하도록 유도하는 작업이 필요합니다. 의뢰자가 사양서를 ‘쓰는’ 때부터 설계자의 관여가 필요합니다.

리뷰작업으로 사양 누락을 막을 수 있을까?

사양의 누락을 파악하는 시점은 대부분 QA테스트를 진행할 때 입니다. 이 QA테스트에서 사양의 누락 발견으로 “요구사양서의 리뷰가 부족함” 이라는 지적이 나오곤 합니다. 그럼 정말로 리뷰가 부족해서 사양의 누락이 발생한 것일까요?

성과물의 리뷰가 보통 성과물의 불비나 결함을 발견하기 위해 행하여 집니다만 그럼 사양에 대한 리뷰는 어떤 형태로 진행되어야 할 까요? 사양서의 리뷰는 대상 문서 자체가 사양서의 형태를 제대로 갖추지 못하였다면 리뷰 자체가 진행되기 어렵습니다. 좀 구제척으로 얘기하면 아래 2가지의 조건을 만족시키지 못하면 리뷰를 통하여 사양의 누락이나 충돌을 막을 수 없다는 이야기 입니다.

ü  설계와 실제 Deploy단계에서 행해지는 모습이 이미지로 떠올릴 정도로 표현되어야 한다.

ü  사양의 기술이 산문적으로 되지 않기 위해, 그루핑으로 정리되어야 한다.(분류, 정리되어야)

사양서를 이렇게 쓰도록 의뢰인에게 요구를 해야 하는데 보통 일반적인 워드 프로세서를 이용한 산문식 요구사양서는 그렇게 하기가 어렵습니다. 결국 리뷰단계에서 효율적으로 사양 누락, 충돌을 잡아내기 위해서는 사양서 쓰는 양식이 바뀌어야 합니다.

왜 이런 것일까?

대부분의 회사들이 이런 상태를 반복하게 됩니다. 대부분 처음 작성된 요구사양서 양식을 다시 재사용하는 경우가 많기 때문이죠. 요구와 요구사양과의 구분없이 작성된 요구사양서가 옛날부터 사용되었었고 이것이 재사용되면서 악순환이 일어나는 것입니다. 추후에 이런 결과가 다시 나타나게 하지 않으려면 개선의지가 중요합니다.

종래 일반 소프트웨어 개발회사들은 소프트웨어 공학 기술을 자사 개발~출시 프로세스에 별로 적용시키지 않고 있었으며 설령 적용을 시키고 있다 하더라도 겨우 ‘설계기술’ 정도입니다. 나아가서, 요구분석에서 발견된 사양을 어떻게 표현해야 하는지에 대해서도 별로 생각을 안하고 있었던 것이 사실입니다.

이의 개선을 위해서는 요구와 요구사양과의 구별, 그리고 요구 표현 방법의 고안이 필요합니다.

이런 사양과 사양간의 충돌, 사양의 누락이 발생할 때 조정할 수 있는 방법은 있는 것일까요? 그냥 요구사양서를 산문 형태로 남긴다면 이런 조정이 매우 어려울 것입니다. 산문 형태가 아닌, 추후 조정이 쉬운 형태로 남겨놓아야 가능합니다.(Excel을 이용합니다.)

요구를 사양화 하기 위해서는 “결정 과정” 이 필요합니다. 각 사양 결정 포인트마다 選擇肢가 있으며 이를 따라 가는 결정과정의 표현이 필요합니다(중간에 요구를 보는 시각이 바뀌면 사양이 바뀔 수 있도록). 많은 사람들이 사양은 ‘결정한 결과’ 라 생각하고, 결정과정은 머릿속에만 담아두고 결과만 사양에 표현합니다.

얽혀있는 사양들 사이에서는, 어느 사양의 선택지중 하나가 선택되면 다른 얽혀있는 사양에 영향을 주게 됩니다. 「A1을 선택하면, 다음의 사양으로 B2나, B4중 하나가 선택되며, A2가 선택되면, B2나 B3중 하나가 선택되며….」 식으로 된다는 것입니다.  선택지로 표현된 사양 체크(리뷰)시 이런 관계들에 주의를 해야 겠죠.

또한 앞에서도 이야기 했지만, 조정하기 쉬운 구성으로 의뢰자는 적지 못하는 경우가 대부분 입니다. 이를 보충해 주는 역할은 설계자의 몫입니다.

결정의 과정…

결정 과정을 진행해가는 방법은 여러가지가 있습니다. 중요한 것은 결정 과정은 설계단계에서 마무리를 져야 한다는 것입니다. 이것이 Deploy단계에서 발생한다면 안되겠죠.

요즘 자주 언급되는 ‘Agile 방법’은 각 납기 포인트를 잘게 쪼개어 각 구간에서 실현할 요구를 한정시키는 것입니다. 이는 사양의 결정이 쉬워지는 효과를 나타내지만 현재 요구의 사양화가 전회, 또는 전전회의 요구와 충돌이 일어나는 현상에 대해서 솔루션을 주지는 못하는 것 같습니다.

많은 SE들은 ‘무엇을 실현시킬 것인가?’ 만 안다면 대부분 문제없이 요구사양을 실현시킬 능력을 가지고 있습니다. 제가 컨설팅을 하면서 이런 장면을 자주 보았습니다. 하지만 ‘무엇을 실현시킬 것인가?’ 를 모른 채 설계에 뛰어드는 것이 현실이며, 이것이 프로젝트 혼란의 근본 원인이 됩니다.

이런 혼란을 한방에 해결 할 수 있는 방법이 있을까?

혼란 상태가 지속되면  “CMM을 도입하여 이를 한방에 해결하고 싶다” 라고 생각하는 관리자도 있습니다. 아쉽지만 CMM도입을 통한 단기처방은 불가능 합니다. CMM에서 제시하는 조직구성, 엔지니어링, 프로세스, 설계기법등이 조직에 베어야 하는데 단기간에 이것이 어렵기 때문입니다. 하지만

l  요구의 사양화

l  프로세스의 명확화

는 어느 정도 단기간에 효과를 볼 수 있습니다. 물론 요구의 정도가 어느 정도인가 등에 따라 결과는 달라지겠지만 이 두 가지가 어느 정도 레벨에 올라서면 “납기” 와 “품질” 에 어느 정도 맞추었다는 것이 제 경험 입니다.

특히 요구의 사양화 효과를 극대화 시키기 위해서는 프로세스의 명확화라는 것이 필요합니다. 이는 요구 사양화 후에 정리차원에서 시행되면 효과가 없습니다. (요구 사양화 전에 해야 효과가 있습니다.) 이는 프로젝트에서 발생하는 많은 문제들이 애매한 요구사양, 애매한 프로세스에서 발생한다는 것을 의미하기도 합니다.

설계서에 대하여..

요구사양서가 제대로 나오지 않는 조직들의 공통점 중 하나가 바로 「적절한 設計書」가 없다는 것입니다.

적절한 설계서란, 요구사양의 실현방법이 적혀있어 이에 따라 작업을 하면 실현이 가능한 것이며 유지보수(Side 개발 발생)시에도 이를 보고 설계자의 의도, 사고방식을 알 수 있어 바로 눈 앞의 소스코드를 이해할 수 있게 하는 문서입니다.

원래 「설계」라는 행위는 데이터 구조, 처리구조, 제어구조 이 3가지의 방향으로부터 실현 방법을 적은 것입니다.  설계기법의 차이는 이들의 표현방법, 시각 등의 차이에서 발생한 것입니다.

하지만 요구사양서가 「사양」 이라는 레벨에 도달하지 않으면, 그 이후의 설계작업이 진행되기가 어렵습니다. 이런 부족한 사양서를 가지고 설계를 하면 분명 부족분이 발견되며, 결국은 어떻게 사양서를 땜질해 가면서 설계를 해 나갑니다. 당연 좋은 설계서가 나올 리 만무합니다. 설계서에 「구체적으로 어떤 것이 실현되면 좋을까」 의 내용만이 적혀 버립니다.

13p. Safe Management System의 잇점

- Risk Management의 방어적 관리
- 대상을 같이 맞붙여 볼 수 있는 시각
- 설비의 특정화, 설계, 구매
- 자기 조절의 가능.

14p. 고려해야 할 기술들

15p. Safety Related System 의 범위
EUC (Equipment Under Control) --> Sensor --> Programmable Electronics --> Actuator

16p. Overall Model... Protection Layer
plant(EUC) --> inherent design feature -->process control system -->designated SRS -->external risk reduction facilities

17p. Example of SRS
각종 플랜트 시스템. 크레인 등의 위험성 있는 장비.

18p. 리스크 관리
리스크의 평가(Assess risk) --> 맞는 엑션을 취한다.

19p. 리스크정의, 구분
Risk : The probable rate of occurence of a hazard causing harm

degree :
- 정성적 : Words
- 정량적 : 형상(Figure)

20p. Levels of Risk and ALARP
ALARP은 뭔가? : as low as reasonably practicable의 약자. - 실제 가능한 최소한의 위험도

1. 받아들일 수 없는 영역 | Risk cannot be justified except in extraordinary circ
2. 위험 감수가능 영역 (이익을 위해 리스크를 감수할 수 있는 영역) | 위험도 저하 자체가 좀 불합리적이라든가 비용이 개선결과에 비해 많이 들어 갈 때 + 위험 저하노

력을 하지 않으면 나중에 이 노력을 따로 해야 한다. 역삼각형 모형(감소모형)을 참조하라.
3. 다 받아 들일 수 있는 모형. (No Need for detailed working to demonstrate ALARP)| 이 범위의 risk는 여기에 머물 수 있도록 관리를 해야 한다.

21p. Risk Reduction

22p. SRS 의 구분
Safety functions requirments --> 작동되어야 하는 안전 기능
Safety integrity requirments --> 작동되어야 하는 안전기능의 신뢰성

23p. Functional safety
1. 안전상태(safe state)에 도달하게 하는, 또는 안전상태에 유지하게 하는 능력
2. 안전(Safety)와 비교 : 받아들일 수 없는 위험으로부터 자유롭다.

24p. Safety integrity(핵심개념)

SRS가 일정기간, 일정조건에서 Safety function을 수행 할 수 있는 가능성(likelihood)
신뢰성(reliability)와는 구분되어야 한다.

25p. IEC61508의 Failure 분류
A= Random H/W Failures

B= Systematic Failures
@규격문제
@시스템적 하드웨어
@소프트웨어 문제
@유지보수문제
@모든 Failure는 Random 하지 않다.

26p. SIL(Safety Integrity Level)의 산출 방법 예제(Example)
위험의 분석(Hazard Studies), HAZOPs(Hazard and operability Studies)
-->가능 결과를 예측한다(Evaluate)
-->수용 가능할 만한 빈도 및 ALARP를 정의한다.
-->이벤트 체인(Event Chain)을 구성한다.
-->요구율(Demand rate)을 측정한다.
-->필수 보호 부분(protection required)을 지정한다.
-->요구되는 SIL을 정의한다.

27p. SIL1~4를 Probability of Failure on Demand와 매치애 본 것

28p. 다른 각도에서 SIL을 분석한 것. SIL의 값은 3번째 칼럼의 값이 될 것이다.

29p. Protective System Tech
SIL1 : 표준 컴포넌트, Single 또는 분리되지 않은 2개의 체널
SIL2 : 표준 컴포넌트, 2 to 1, 3 to 2, 분리 개념이 들어간다. 통상적원인에 의한 Failure를 허용한다.
SIL3 : 센싱, 엑튜에이터가 조합된 Multiful channel.통상적 원인에 의한 Failure가 주 관심 대상(허용하면 안된다.)
       Process Industry(가공업)에서는 드물게 요구될 수 있다.
SIL4 : 스페셜리스트가 디자인한 경우. 가공업에서는 절대로 요구되면 안된다.

30P. 각 단계별 요구되는 Action
SIL1 : 상대적으로 저렴한 설계, 시공, 유지보수 대상. 테스트 인터벌은 3개월을 넘지 않는다.
SIL2 : 다소 비용이 드는 설계, 시공, 유지보수 대상. 테스트의 인터벌은 3월 이상으로...
SIL3 : 비용이 드는 설계, 시공, 유지보수 대상. 테스트 인터벌은 1개월 정도로 잡는다.
SIL4 : 아주 비싼(Extremely expensive) 설계, 시공, 유지보수 대상. 테스트 인터벌은 SIL3과 같이 잡는다.(점차적으로 1개월 아래로 감소하도록)

31P. 라이프 사이클의 개략도

32P. 왜 이 라이프 사이클인가?

프로젝트의 시작~끝까지의 보통의 패턴에 Mapping을 할수 있다.
자산의 라이프 사이클에 바로 Mapping할 수 있다.
관리자(Regulatory Autorities)들에 베스트 프랙티스로 보일 수 있다.
Any industry, Any Sector에 적용가능
모든 Supply chain의 엔드 유저들의 관점에 적용시킬 수 있다.
규제(Regulatory)에 대한 응대로서 사용될 수 있다.
안전 비용(Costs of Safety)의 산정효과가 있다.

33p. IEC 61508 의 오너쉽 : P31의 그림 설명...
3가지 Phase로 그림을 분류
...

37p. Protective Function의 3가지 상태

Set the Target SIL | Pre design (Phase 1-5) | End user / Operator
Design SIL | Design & installation | Engineering / Equipment Supplier
Demostrate Target | Operation | End user / Operator

38p. 각 상태에 대한 책임

p31에 대한 세부 사항 설명들...

42p. 주로 시스템이 Fail이 나는 이유들(Seveso 리뷰에서 나온 것들)...
...

pl.nunnss.pdf

● Agile 개발 컨설팅 등을 통해 테스트에 대해서는 어느 정도 이해하고 있다. 하지만, 적용을 하려다 보니 테스트 프로세스가 좀 비대해진다는 느낌이 든다. 현 시대는 제품 출시 速度의 효과를 무시 할 수 없다.

● QA팀에서 테스트를 하는 경우도 있으며 테스팅 팀을 별도로 운영하는 경우도 있는 것 같다. 어느 것이 맞는 것이며 만일 분리를 한다고 하면 QA팀의 Role과 테스팅팀의 Role은 무엇인가?

● Agile 개발 컨설팅 등에서 제시하는 프로세스는 개발에 대한 간섭으로 이해된다. 반드시 이런 간섭이 필요한 것인가?

● Gate Keeper 단계에서(우리용어로 하면 인수테스트 단계)의 테스팅은 테스터 역량에 따라 품질이 좌우 되는것 같다. (경험많은 테스터 VS 경험없는 테스터) 이 단계에서 만일 수정이 일어나면 Side effect를 잡아내는 것도 현재로서는 경험 많은 테스터들에 의해(경험에 의해) 수행되는 실정이다. 이런 현상을 조금이라도 개선할 방법은 없는가?

● 5년, 10년 묵은 결함이 나오더라. 이런 것도 가급적 빨리 찾아 낼 수 있는 프로세스를 갖추고 싶다.

● 리스크 분석을 이야기 하셨는데 리스크를 어떻게 판별해야 하나? 예를 들어 비정상적인 Operation시 시스템이 다운되는 경우, 결과는 치명적이지만 ‘비정상적’ 인 케이스가 과연 실제 출시 이후 발생할 수 있을지에 대해 개발팀과 QA팀간에 자주 다툼이 있다. 이런 경우 Risk를 어떻게 봐야 하는가?

● 유지보수 테스팅시 단위 테스트부터 다시 시작해야 하는가? (첫 단계부터 다시 다 해야 하는가)

● 단위테스트에서 개발자가 테스트 하는 것과 별도의 조직에서 테스트 하는 것중 어느것이 더 나은가?

● 개발자와 QA사이에 별도 중재 조직을 두어 Risk조정 등에 대해 책임을 지우는 관리법도 필요할 것 같다. 어떤가?

1. 테스트의 단계화가 출시속도에 영향을 주지는 않은지...

2. 개발팀과 QA팀의 갈등문제.(Risk관련)

3. 리그레션 테스트의 문제.

빈번한 사양변경…