신현묵 기술고문/CTO

소프트웨어개발 방법론을 건축가에게서만 배워야 하는가?

Why?

Experience

Quality

SW 아키텍팅 품질 관리

H/W(Computer) Device

Information

Computer…

IoT(Computer) Open Hardware

Meaningful information

Open Collboration Service

IoC(Inversion of Control)

Homo faber

도구와 가장 밀접한 분야… 개발자와 가장 밀접한 분야…

Medical world 1 Cardiovascular

2 Cardiovascular, Genreal Surgery

3 Common

4 Common(ICU)

5 Common(Neuro-surgery)

6 Dental

7 ENT

8 ENT, Respiratory Medicine

9 Gastrointestinal Medicine

10 Gastrointestinal Medicine, Cardiovascular

11 Genreal Surgery

12 Genreal Surgery, OB/Gyn

13 Genreal Surgery, Orthopedic Surgery

14 Genreal Surgery, Orthopedic Surgery, Rehabitalation

15 Internal Medicine

16 Internal Medicine, Genreal Surgery, OB/Gyn

17 Laboratory

18 Main Supply

18 Main Supply, Dental & Pediatric

19 Neonatal ICU

20 Neuro-Surgery

21 Nurology, Neuro-Surgery

22 Nurology, Neuro-Surgery, Genreal Surgery

23 OB/Gyn

24 Ophthalmology

25 Orthopedic Surgery

26 Orthopedic Surgery, Rehabitalation, Genreal Surgery

27 Others

28 Pharmacy

29 Rehabilitation medicine

30 Respiratory Medicine

31 Urology

Medical world

사람과 컴퓨터…

그리고, 소프트웨어 개발자들…

Computer Science

Q&A

흡입기 단지, 흡입기 + 블루투스, 위치정보 얼마자 자주 호흡? 패턴인식 의료진이 수집된 데이터를 기준으로 맞춤형 질병관리 대책

Asthmapolis

천식 지도, 천식 환자가 가지 말아야 할곳.

아프다

신호 경험과 직관

경험의학 -> 근거중심의 의학

의료의 흐름…

80% Vinod Khosla

Do We Need Doctors Or Algorithms?

Doctor Algorithm or Dr.A

?

•  관습에 기반한 의학 – Practice of Medicine

•  과학적이고 데이터 주도적 – Data-Driven

•  Science / Scientism /

HealthCare

계량화, 객관화

40,500

To Err is Human

Q&A

Order(처방) 1년차, 2년차…

1년차 약속처방 검사

의사들의 처방패턴

약제

재활

식사

루틴 routine

Q&A

Scientific evidence level 이슈에 대해서 연구 교류

수십번, 수백번 비슷한 임상연구결과를 기반으로 토론, 관리, 연구

자신의 처방패턴을 바꾼다.

그것이 의무다.

처방패턴!

의사들은…

Q&A

process 학문의 속성 자체가 이러한 process를 지속적으로 반복하고 전문화하기를 요구

구식 regimen

Updated knowledge

신약 affiliation

항암치료, oncologist

Malpractice 과실!

현대의학 Evidence / Scientific

‘언제나 근거를 찾고, 대비를 하며, 프로세스를 표준화하려하고,

실수를 최소화하려 한다’,

그리고

자신이 처방에 대해서 끊임없는 되돌이표를 통해서 토론을 한다.

그리고,

그것을 의무로 생각한다.

근거…

실수, 그것을 관리한다.

Q&A

Evidence Based Madicine 전세계에 발표된 임상 연구의 최신 정보에 근거해 환자 개개인에 적절한 치료법을 제안하는

확률적 방법론 근거중심의학이 주목 받을수록, 이를 뒷받침해주는 소프트웨어와 알고리즘에 대한 의존도는

더욱 높아지게 된다.

Evidence-based Development Methodology 근거중심의 개발방법론…

EBM

Q&A

진단, 치료, 예방

분석, 개발, 대비 대비 : 위험, Risk와는 다른것, 미래의 가치에 대해서 오랜기간 지속되는 ‘지식’ 아마도, 미래의 개발조직

- 수련과 경험을 동시에 터득하는 방법 -  절차와 프로세스의 중요성을 얻는 방법

의료/개발

요구사항

미래의 가치 (FV)

품질의 가치(QV)

유지보수의 가치(MV)

지식화의 가치(KV)

Q&A

증거/증명 -  확실한 것

-  축적이 가능한 지식의 형태

-  의사들은 ‘질’을 위해서 프로세스를 단순화하려면 많은 case와 증명을 한다.

-  병원의 의료서비스 ‘품질’, ‘비용’ 복잡하다.

-  ‘명세화’된 지침에 근거한다.

-  여러 개의 복잡한 ‘액티비티’를 거쳐서 실행됨과 동시에 모든 환자를 대상으로 동일하게 제

공하기 어렵다. – 의료와 IT의 다른점.

-  의사결정

-  어떤 상황에 맞는 적절한 의료

-  여러 단계를 고려한 의료지식을 기반으로 구축

-  효율적인 사용과 품질지수

Evidence-based

실수관리!

사람

effect

시간 ->

복합적인 증상

열이 오른다!

* 수많은 케이스!!

Q&A

술기 개념과 정의

그리고, 방법과 경험

무엇을 해결하는가?

Clinical Procedures

의사 의사는 ‘사람’을 살린다고 약속하지 않는다. 의사는 언제나 최선을 다한다. 의사는 ‘일정’을 위해서 절차를 어기거나 넘어가지 않는다.

의사도 천시를 받았다?

Q&A

그들은 동급이었다 이발사와 외과의사가 동급인적이 있었다. 종기제거, 간단한 외상 치료 ( 외과의사의 경우… )

우리는 이발사를 지향하는가? 의사를 지향하는가? 이발사 같은 개발자? 의사/과학자 같은 개발자?

이발사와 의사?

시대의 변화 Paradiam Shift…

과학기술 공학(engineering) + 자연과학(natural science) -  공학 : 과학지식의 응용 -  자연과학 : 근본적인 지식의 탐구

건축공학과 소프트웨어공학

시스템공학 기술적 측면(Technical) + 관리적 측면(Management) -  시스템 개발, 운용, 유지보수를 위한 사고 방법, 절차, 조직, 기법 총칭. -  기술적 측면 : 물적 요소의 적합성 + 효율성 -  관리적 측면 : 시스템 개발업무

-  ( 인원, 설비, 자재 등 통제 + 계획 ) -  인간의 욕구와 사회적 필요성, 평가기준

-  ( 성능 + 시간 + 비용 + 신뢰성 + 보전성 + 안전성 … )

매우 닮았던…

일반 공학에서, 설계가 끝나면 설계 문서는 제작팀에게 넘어가서 제품을 만들게 된다. 만약 설계 문서가 정말 완벽한 설계 문서를 표현한다면, 제작팀은 제품을 만들 수 있다.

이러한 공학 설계 기준을 만족하는 소프트웨어 문서는 오직 소스코드 뿐이다.

- Jack Reeves(http://www.developerdotstar.com/mag/articles/reeves_design.html)

Q&A

공학적인 접근 소프트웨어를 개발하고, 운영하며, 유지보수하고, 폐기하기 까지의 과정에 적용되는 시스템적

접근방안(IEEE)

소프트웨어 공학

method Tool Procedure

과정 What(정의), How(개발), 변경(유지보수)

Q&A

원리 정형성(Formality), 엄격(Rigor), 관심사의 분리(Separation of Concern),

모듈화(Modularity), 추상화(Abstraction), 일반화(Generality),

점진화(Incrementally)

소프트웨어 공학의 원리

건축학과의 공통점 설계자, 아키텍트, 디자인패턴, 재활용 등 건축공학에서 쓰이는 용어 건축공학과 소프트웨어 공학은 절차지향적 다만, 건축공학의 절차를 그대로 활용하기에는 한계점이 존재

Q&A

과정

-  사용자 요구사항 분석 + 설계 + 구현 + 감리 + 유지보수

-  대형 프로젝트 성공 핵심요인

-  사용자의 요구사항 분석(System analysis)

-  요구사항 분석(Requirements analysis)

-  설계(design) : 사용자 요구사항 분석 후에 실행 가능

해결된 문제들

Q&A

문제들 -  완벽하지 않은 요구사항?

-  기술과 문서화가 모든 것을 해결해주지 못함. -  건축은 To-be Model이 명확하다.

-  SW는 명확하지 않고, 논리적으로만 Model이 존재함. 시간에 따라 계속 변화해야함. -  완벽한 설계, 완벽한 분석은 없다.

-  가장 완벽한 설계도는 ‘소스코드’ – 리뷰가능한 ‘소스코드＇ -  소프트웨어 설계를 검증할 도구가 없다. -  많은 사람들이 공동작업한다. -  고객과 이야기할 설계도구가 부족하다.

-  UML도 한계

-  건축공학과 기계공학과 같은 공학분야와 닮으려 했지만, 너무도 다르다. 일반공학으로는 ‘소프트웨어’를 설명할 수 없다.

해결 안되는 문제들

Q&A

배워야할 것!

문제를 인식하는 방법 문제를 지식화하는 방법 문제를 전파하는 방법 문제를 끊임없이 연구하는 자세 어떤 원인과 행위가 100% 일치하지 않는다. 수술환자의 50~75%가 통증관리에 만족하지 않는다. 수술환자의 64~90%가 심한 통증을 경험한다. 무엇을 진행했고, 어떤 것을 얻었으며, 어떤 것을 실패하였는가? ‘기록하고 관리하고, 연구하고, 루틴과 패턴을 바꾼다＇

의사들이 일하는 방식…

실수관리!

Q&A

근거중심의 소프트웨어 개발방법론

1. 문제점으로부터 명료한 질문을 파악 2. 이에 상응하는 과거의 아키텍처와 패턴 탐색 3. 해당 내용에서 타당도와 유용성에 대한 비평적 평가 수행 4. 실무에서 찾아진 유용한 내용을 적용 이 바탕에는 어떤 방식이든 ‘잠재성’과 ‘정확도’, ‘예측력’에 대한 타당한 연구를 기반으로 한다.

언제나 ‘예후’를 고려하고, ‘대비’한다.

Evidence based S/W Development

Q&A

접근방법

거시적, 중시적, 미시적 수준의 다양한 수준의 의사결정에 있어서 전문적 식견을 가진 의사결정자들을 만들고, 이를 통하여 과학적이고 체계적인 방식을 찾고 비평적으로 평가하여 얻은 최신, 최상의 근거를 사용하여 합리적인 의사결정을 하는 것이다. ( SW아키텍처 과정에 추가, 품질과 결과 관점 ) 소프트웨어 개발에 있어서 소프트웨어 아키텍처링 과정에서

비즈니스 이슈와 품질속성, 그리고. 미래의 가치에 대해서 충분한 비평을 해야 한다. 거시적인 관점, 중시적인 관점, 미시적인 관점을 모두 고려해야 한다.

보건의료분야에서의 접근방법

Q&A

100% 고품질(?) 소프트웨어 개발이 모두 '품질'이 높은것인가? 정말 100% 고품질인가? 내가 만들어야 할 소프트웨어가 우주로켓이나 비행기인가? 간단한, 자판기에서 동작하는 소프트웨어 인가? 어떤 목표를 이루기 위해서 많은 투자와 인력이 들어가는 작업인가? 목표를 최소화하고, 요구사항과 맞추어 나가는 일인가? 고객이 심지어, 자신이 무엇을 요구하는지 모르는 일인가?

무엇을 만들어야 고객에게 가장 만족도가 높은 서비스인가?

고품질(?)/품질(!)

설계도?, 요구사항? 건축학적 관점에서는 이것에 실패하면…

Q&A

귤이 회수를 건너면 탱자가 된다. 귤의 고향은 인도 아쌈지역… 동쪽으로 가면 만다린… 서쪽으로 가면 탄제린. 모르코 항구도시 탕해르(Tangier) 귤도 배경이 달라지면 변한다.

서양에서 만들어진 방법론이 우리에게 정말 잘 어울리는가?

방법론/귤화위지(橘化爲枳)

Q&A

애자일 선언의 진정한 의미…

연봉 10억짜리 NASA의 과학자들과 연봉 2억짜리 MIT의 수재들을 위해서 만들어진 방법론이

연봉 6천만원짜리 아키텍트와 연봉 3천만원짜리 개발자들을 위해서 동일하게 사용될 수 있을까요? 근거와 비약이 너무 황망하다. 우리에게 적합한, 아니. 우리팀에 적합한 조직의 구성과 커뮤니케이션 방법, 환경과 목표에 적합한 것을 사용해야한다.

그들의 방법론이 우리에게 맞지 않는 이유...

정말 우리에게 어울리는가?

Q&A

삶의 여유가 다르다. 동일한 이익 동일한 비전 아니다. 그들의 방법론은 전혀 맞지 않다.

'문화'는 삶의 태도와 삶의 구현 방식이 비슷해야 한다. 특히나, CMM처럼 실패를 기반으로 실패하지 않는 방법으로는 창의적인 소프트웨어 개발에 방해됩니다. 문제를 해결하기 위한 접근법을 사용해야 합니다.

방법론 = 개발문화

Q&A

새로운 기술 1. 신기술에 대한 적절한 프로토타이핑을 거쳤는가? 2. 최소한 기존의 방법과 상응하는 유지보수체계와 안정성을 가지고 있는가? 3. 적합한 환경이 명확한가? 4. 비용적인 측면에서 타당한가? 이것을 따집니다.

건설에서도 메가건물을 다룰때에 신기술의 최고를 따지는 것이 아니라. 사람의 생명에 대한, 적정하고 타당한 형태로 적용이 가능한지에 대해서 접근합니다. 의료역시 환자들이 요구하는 모든 진료를 다 보장하기는 불가능하다고 인정하고 의료기술의 비용증가와 환자 건강상태의 증진은 같이 않다고 봅니다. 이는 건축적인 관점과 매우 접근을 달리 합니다. 소프트웨어의 관점을 건축학적인 관점에서 자꾸 접근하기 때문에 잘 모르는 사람들은 사람이 많이 투입되면 어떻게든 완성한다는... 특정 '시점'에만 초점을 맞춥니다.

고신뢰성

Q&A

특정 시점만 주목하지 말라! 건축물은 만들어진 순간의 요구사항 이후에는 언제나 누더기가 되고, 걸레가 되어갑니다. 사람들이 그것을 바꾸니까요.

건축물과 소프트웨어는 다르다!

하지만, 의료는 다릅니다. 일정이 문제가 된다고. 산모가 40주를 보내는 것이 답답하다고 산모 10명을 동원하면 4주로 줄어드는 것이 아니기 때문이죠. 의료에서 '의사'들이 프로세스를 다루는 것처럼 소프트웨어 개발자들도 접근해야 합니다. 그리고, 프로세스는 그것에 맞추어진것입니다.

생략된 프로세스는 이미 결과를 포기한 것이죠

Q&A

잘못된 인과성 추정의 결과를 안다. -  '우리 할아버지는 매일 담배를 두갑반씩 피웠지만 감기 한번 안걸리셨는데. 99살에 등반하시다가 추락사고로 돌아가셨다.‘

-  염소젖 요구르트를 먹은 할아버지가 100수를 누리다. 우리가 알고 있는 글루코사임, 비타민과 같은 건강식품들은 대부분 임상시험에서 '아이고 의미없다'라는 것으로 나왔습니다. '충분한 임상시험을 거쳐 안전성과 유효성 및 비용-효과성을 입증하여 근거를 갖고 치료를 해야한다'는 것입니다. 대표적으로 가짜 약과 가짜 의료기기를 구분하는 것은 간단합니다. 정말 좋은 것이고, 정말 처리가 가능한 것이라면.. '병원'은 사용합니다. 비용이 조금 많이 들더라도. 물론, 로렌조오일과 같은 결과물들을 본다면 아주 예외적으로 특이한 '질병'에 대한 과학자들의 관심이 적은 것은 매우 당연합니다. 자본주의 니까요.

의료도 그것을 안다!

Q&A

근거중심의사결정체계의 반대의견들… 슬프지만. 의사들은 이러한 의료분야의 근거중심의사결정체계에 대해서 수많은 논란과 반대가 있습니다.

- 의사의 권위나 지위를 낮추는 행위 - 이미 누구나 다 그렇게 하던것 - 요리책 처럼 치료하라는 것 - 비용절감목적으로 오용될것 - 무작위배정 비교임상시험이나 메타 분석자료만이 제한적으로 사용된다. 이런 이유때문이죠 --- 소프트웨어 개발자는?!

의사의 권위

그런거 없습니다!!!

Q&A

나 혼자 만들고, 나 혼자 쓰면 된다. 하지만, 다른 사람의 요구사항이 생기고, 여러 사람이 개발 하다보면. 커뮤니케이션 수단과 비용의 지불이 기하급수적으로 증가합니다. 특정 요구사항에 맞춘다. - 근대적인 개발방법론입니다. 미래 지향적인 개발방법론은...

'미래 가치를 생각하며, 변화한다.' - 현대적인 개발방법론입니다. 그래서, MBT, 빨리 만들고, 빨리 시장에서 보여지고, 빨리 피드백 받습니다. 공학은 이제 당연합니다. 과학적 원리, 지식, 도구를 활용하여 새로운 제품, 도구등을 만드는 것이죠.

소프트웨어 개발의 최선!

Q&A

나 혼자 만들고, 나 혼자 쓰면 된다. IoC(Inversion of Control) fomal language Architecture pattern/style

미래의 개발

Q&A

프로세스 이기는 하지만, 프로세스가 전부는 아니다. 한사람의 아키텍트의 방향성에 맞추어서 수많은 공정과 방법, 필요한 컴포넌트를 일정에 맞추어서 조립하는 방법은 '특정 시점에 특정 요구사항'을 만족하는 것에는 최선의 방법. 이 맞습니다. '뚜렷한 목표'와 '모델'이 정확하다면 이 방법은 가장 구체적인 결과물을 보여준다. 만약, 아키텍트급이나 '모델'이 뚜렷한 모델링이 있다면... 요구사항이 정확하게 도출되고... 그 요구사항에 필요한 품질 지수나 속성들이 명확하다면... 이 방법은 가장 최상의 방법을 보여준다. 의사결정을 할 수 있는 아키텍트가 똑똑하면 되기는 되는 방법이죠. ~.~

현재의 개발방법론

Q&A

프로세스 이기는 하지만, 프로세스가 전부는 아니다. '사용자의 요구사항'이 계속 변화한다면? '시간'에 따라 변화하는 소프트웨어를 지속적으로 관찰하면서 피드백을 받아야 한다면?

이러한 '건축학'적인 방법은 특정 시점에는 맞지만, 그 이후에는 맞지 않는다. 이러한 환경과 가장 유사한 환경을 발견했다. 의사들이 일하는 방법이다.

목표가 불명확하다면?

Q&A

그들과 소통한다 1. 개발자들이 현재 일하는 방식에 주목한다. 2. 개발자들과 개발자들, 또는 기획자나 디자이너들과 대화하는 방법을 주목한다. 3. 커뮤니케이션 비용을 어디까지 처리해야하는지 생각한다. 4. 매일 매일 회의를 해야하는가? ( 공통의 목표를 가지고 있다면 해야한다. )

애자일과 스크럼이 이야기하는 것에 대해서 의사들은 매일 매일 반복한다. 자신이 속한 문제에 대한 해결책은 모두 공유한다. 그리고, 그것에 대한 가장 합당한 방법을 찾는다. 조직과 팀, 개인에게 적용되는 프로세스는 모두 같을 수 없다.

지식수준, 경험, 소통하는 방법이 모두 다르기 때문이다. 의사, 간호사, 물리치료사, 보조인력까지 모두 역활과 프로세스가 모두 다르다. '의료인'이기도 하다. '응급실'에서의 역활이 다르고, '병실'에서의 역활이 다르고, '외래환자'를 볼때에 다르다.

내가 일하는 방법

Q&A

최선은 의사소통과 우리에게 맞는 방법을 찾는것! 반복점진개발이 모든 것의 해결책도 아니다. QP(Quality Practice)라는 용어도 최선이 아니다. 방법론을 '글'로 배우지 못한다. '경험'으로 터특해야 한다. 소프트웨어 개발은 '특정 API'를 호출하는 것만으로 충분할 수 있다. 서로 일하는 방식과 일을 결정하는 방법에 대해서 이야기를 해야 한다. '동일한 목표'를 가지고 있는 '사람'이라면 소통해야 한다. 방법론과 아키텍처의 테일러링(tailoring) 문서는 '의사소통', '인수인계'를 지양한다. - (발생 하지 않을 수 없다.? 다만 얼마나?) 소수의 인원이라면... 필요시 '인수인계'시에 만드는 것이 정답이다. 그 비용은 '경영진'이 알고 있어야 한다. 그러면 된다.

은빛 탄환은 없다!

Q&A

의료에게서 배워야할 4가지 1.  요구사항과 환자의 진단이 명확해야 합니다.

2. 그리고, 세심하게 관리합니다. 3. 책임을 누군가가 가지고 주도합니다 4. 당연 비용을 고려합니다.

애자일을 실천하라!

그리고, 기록합니다.

•  접근성 (사용자 접근성) –  재정적, 지리적, 사회문화적인 이유로 인해 주민들에게 필요한 의료서비스를 제공하는데 있어서 장애를 받아서는 안된다.

•  질(기술과 사용에 대한 동시 달성) –  의학적 적정성과 사회적 적정성이 동시에 달성될 수 있도록 적절하게 제공

•  포괄성(실제 서비스 운용의 전체적인 관점에서 생각) –  예방, 치료, 재활 및 건강 증진 사업 등 관련되는 다양한 서비스가 조정, 포함되어야한다.

•  지속성(시간적, 지리적 상관성을 모두 고려) –  각 개인에게 제공되는 의료는 시간적, 지리적으로 상관성을 갖고 적절히 연결되어야 한다.

•  효율성(자원의 양에 대한 적절성) –  의료의 목적을 달성하는데 투입되는 자원의 양을 최소화하거나 일정한 자원의 투입으로 최대의 목적을 달성 할 수 있어야 한다.

Myser의 정의

•  효능 (바람직한 환경) –  의료의 과학과 기술을 가장 바람직한 환경하에서 사용 하였을때 건강을 향상시키는 능력

•  효과 (전체적인 수준의 향상) –  의료서비스를 제공하는 일상적인 환경에서 성취할 수 있는 건강 수준의 향상

•  효율 (비용의 효율성) –  특정건강 수준을 획득하는데 사용한 비용을 측정

•  적정성 (비용이 지불되면 효과가 있어야 한다) –  비용에 대한 상대적인 의료의 효과 또는 편익

•  수용성 (기대감을 만족시킨다) –  의료의 효과에 대한 환자와 환자 가족의 기대

•  합법성 (윤리적이다) –  사회적 선호도(윤리적 원칙, 가치, 법, 규제)와 개인의 수용성의 일치 강도

•  형평성 (사용자의 공평한 사용 편익을 고려한다. ) –  의료서비스의 분포와 의료의 편익이 인구 집단에게 얼마나 공평하게 제공되는가

의료 질관리 7가지 속성

•  Safe (의료의 핵심) –  의료는 의료시설에서 집만큼 환자에게 안전해야 한다.

•  Effective (기준에 따른 전달) –  의료에 대한 과학과 경험은 의료전달의 기준에 맞춰서 적용되고 제공되어야 한다.

•  Efficient (비용효과적) –  의료와 서비스는 비용-효과적이고 낭비는 시스템으로부터 제거되어야 한다.

•  Timely (시간적인 관점) –  환자가 의료서비스를 제공 받음에 대기나 지연이 없어야 한다.

•  Patient centered (고객중심의 접근법) –  의료체계는 환자를 중심으로 운영되어야 하며, 환자의 선호를 중시하고 환자를 관리해야 한다.

•  Equitable (형평성, 사람에 대한 배려) –  의료에서 형평에 어긋나는 것은 반드시 제거되어야 한다.

Berwick의 정의(2002)

•  효과성 (Effectiveness) •  기술 수준 (Technical quality) •  접근성 (Accessibility) •  가용성 (Availability) •  의료 이용자의 만족 (Consumer Satisfaction) •  지속성 (Continuity) •  안전성 (Safety)

질의 구성요소

•  전문가 중심 정의 •  이용자 중심 정의 •  사회적 정의

제공자 (지식/기술 중시)

지불자 (비용/자원 중시)

소비자(환자) (인간관계/환경중시)

품질지수 이슈트리 입장차이에 대한 고려

입장차이!

Q&A

근거중심의 방법론이 필요한곳 1.  다국어와 시장이 다변화된 환경 2.  코드의 복잡도가 높음 3.  단순 기능 나열의 요구사항이 아님 4.  소프트웨어 아키텍처가 구성됨 5.  사용자의 경험성을 증가하기 위한 예측 6.  개발되는 서비스가 지속적으로 발전해야함 7.  요구사항이 계속 변화함

필요한 곳

Q&A

근거중심의 방법론이 필요없는 곳 1.  특정 도메인만 다루는 팀이나 회사 2.  지난 2~3년간 솔루션이 변한것 없으며, 기업이나 팀에서 투자가 없을 것으로 예상되는 경우

3.  개발자들이 5년 이상의 경험 동안 변화가 없는 곳 4.  기능위주의 SI성 업무, 복잡도 없는 경우 5.  비용과 일정상 개발팀 리소트 투여 불가능한 경우 6.  실험적인 코드를 만드는 경우 7.  향후 버려질 가능성이 높은 코드의 경우

필요하지 않은 곳

Q&A

실제 비용 환산이 필요하다 -  품질과 질관리는 곧. ‘비용’

-  표준화, 정보의 활용, 정보의 소통

-  품질 측정, 공공화되는 정보

소프트웨어 품질도 ‘비용’환산이!

Q&A

의료도 비슷하다. 하지만, 의료는 강력한 위원회의 힘과. 의료인이 아니면 병원을 열 수 없는 자격. 하지만. IT는 다르다.

경영진의 몰이해…

삽질하는 경영진을 이길 수 없다.

Q&A

시간의 축과 코딩 코딩스타일 버릇 변화예측 상세한 준비 코딩은 ‘미래’를 담고 있다. 개발중인 코드는 변화한다. 정량적인 검토는 자동화하고 정성적인 검토는 기준을 명확하게 하라. 자신만의 ‘표기법’을 만들고, 타인의 ‘표식’과 호흡하라. Code quality / Architecture Quality / Evidence Quality

코드…

Q&A

근거가 필요하다. 기록이 중요하다. 원인과 근거, 대비를 표시하라. Legible 표기법을 통일하고, 자동화를 지향하라. Flexible 초기코드가 80%이상이다. 제대로 유연하게. Testable 검증하기 쉬운 코드여야 한다. Economic 경제적인 메모리와 컴퓨팅 파워 Compliant 기능에 대한 명세를 명확하게 하라

‘근거’는 ‘자동화’에 의해서 처리한다. 의사들은 ‘의무기록’을 자동화하기전에 60~70%가 ‘근거’를 남기는 것이 일이었다.

Evidence Quality

Q&A

어떤 리뷰를 할 것인가? -  코드리뷰는 어렵다. 시간의 축이 있어서. 그래서, 예측해야 하고, 예측에 대한 근거가 있어야 한다.

-  상호합의, 객관성, 객관적 – 3원칙을 준수하라 TDD -  비기능, 성능에 집중하려면 Peer Review -  지식 전달, 문제 해결? Code Inspection -  규칙과 가이드라인 중심이라면 Team Review -  간단한 경험을 전달, 최소한의 가치 전달 Walkthrough - 특정 도메인, 처리방법, 경험 교환

EQ는 Review에서…

프로세스가 중요하기는 하나, 전부는 아니다.

코딩의 시간에 대해서 표시하는 방법을 나누어야 한다. 나와 우리팀에 어울리는 방법론은 우리들 스스로가 알고 있다. 대화하고 소통하면 만들어진다.

Q&A

THANK YOU