SonarQube와 함께하는 소프트웨어 품질 세미나 - 소프트웨어 품질의 중요성
•
0 likes•585 views
SonarQube와 함께하는 소프트웨어 품질 세미나 4번째 세션 소프트웨어 품질의 중요성 - 테스트웍스 윤석원 대표님
More Related Content
What's hot
What's hot (20)
Similar to SonarQube와 함께하는 소프트웨어 품질 세미나 - 소프트웨어 품질의 중요성
Similar to SonarQube와 함께하는 소프트웨어 품질 세미나 - 소프트웨어 품질의 중요성 (20)
SonarQube와 함께하는 소프트웨어 품질 세미나 - 소프트웨어 품질의 중요성
- 1. 소프트웨어 품질의 중요성 ㈜테스트웍스 윤석원 대표
- 2. BIO • ㈜ 테스트웍스 대표 • 삼성전자 반도체 총괄 수석 연구원 • 마이크로소프트 윈도우 사업팀 Senior SDET (Software Development Engineer in Test) • 미 코넬대 공학석사 (컴퓨터 공학 전공) • 기술 분야 • Embedded System, Platform, Web Brower, Application, Server/Cloud 등 • 품질 분야 • Software Testing • Software Process Improvement (CMMi, SPICE) • Software Quality Assurance • Globalization/Localization • Performance analysis and consulting • Test team management
- 3. 교육 아웃소싱 컨설팅 연구/개발 구직자를 위한 테스팅 기초/실무/ 실습과정 재직중 테스트 엔지니어들의 역량 향상을 위한 교육 과정 고객사 소프트웨어 테스트에 대한 맞춤형 서비스 제공 테스트 작업환경의 효율성을 높이기 위한 프로세스 및 자동화 컨설팅 ICT 전반에 대한 연구를 통한 신기술 개발 및 실무 적용 Testworks 소개
- 4. Why Software Quality is important?
- 6. Note 7 turns out disaster Case1 Galaxy Note 7
- 9. Case2 Toyota Recall Toyota 급발진 사태 정리 2007년 오클라호마 주에서 캠리(2005년 모 델)가 급발진하여 운전자와 동승자 2명 사망 2009년 8월 28일 일가족 네 명을 태운 렉서스 ES350이 125마일(195KM/H)의 속도로 가드레일을 넘어 추 락하여 일가족 모두 사망 2014년 3월 19일 미국 법무부와 도요타는 벌금 12억 달러 (1조 2880억) 합의 급발진의 원인 ETCS(전자 스로틀 제어 시스템)에 스택 오버플로우(Stack Overflow)를 막기위 한 메모리 보호기능 미탑재 순환복잡도(Cyclomatic Complecxity) 측정 결 과, 67개의 함수가 테스트 불능 ‘MISRA-C’ 준수 미비
- 10. 출시 후 시장에서 발견된 치명적인 불량 은 회사에 막대한 손실을 끼칠 수 있음 회사의 존폐 위기
- 12. Quality Definition ① Conformance To Requirement - 명확히 규정된 요구사항과 부합 고객이 제품(시스템)에 대해서 지불할 의향이 있는 비용
- 13. Let’s get the money from customers after fulfilling requirements! Quality Motivation – Money
- 14. Can save even more money? Cost of Quality 품질비용 일정 품질을 달성하기 위해 투자하는 비용 품질결여로 인한 비용 평가비용 (Appraisal Costs) 내부실패비용 (Internal Failure Costs) 외부실패비용 (External Failure Costs) 예방비용 (Prevention Costs)
- 15. 평가 비용 (Appraisal costs) - Verification - Testing - Audits 예방 비용 (Prevention costs) - Training - 품질 관리 및 프로세스 - Tool 평가 및 도입 - 결함 예방을 위한 모든 비용 내부실패비용 (Internal Failure Cost) - Rework - Retesting - ReInspection - Failure analysis 외부실패비용 (External Failure Cost) - Call center 비용 - AS 비용 - 교환/환불 비용 - 고객 불만족 Cost of Good Quality Cost of Poor Quality Cost of Quality
- 16. Cost of Quality Cost saving for Quality Improvment 평가 비용 내부 실패 비용 외부 실패 비용 평가 비용 내부 실패 비용 외부 실패 비용 예방 비용 평가 비용 내부 실패 비용 외부 실패 비용 A general rule of thumb is that costs of poor quality in a thriving company will be about 10 to 15 percent of operations.
- 17. Money is only motivation? 품질은 장인정신의 자부심이다
- 18. Quality Motivation – Money 품질을 추구한다(Quality Driven)는 표현에서 추구한다 (Driven)라는 말이 무슨 목적을 달성하려는 성취욕만을 뜻 하지 않는다. 그것은 본능적인 충동이나 욕구에 이끌리듯, 무슨 물건을 만드는 일이나 기능을 숙달하는 일에 집착하며 강박적으로 쏟아붓는 에너지를 뜻한다….. (중략) 이 정도면 충분하다는 만족과 그렇지 않다는 불만족이 구분 되지도 않고 구분할 수도 없는 마음상태다…. (중략) 모든 사례에 주목하고 부주의나 무관심으로 생기는 예외를 인정하지 않는다. 만족과 불만족의 경계를 두지 않고 쉴새 없이 집요하게 추적한다.
- 19. Quality in Japan • 전후의 일본 기업들은 Deming의 ‘총체적 품질 관리’를 적극적으로 수용함 • 집단적 장인의식 고취 • “관리자들은 손에 작업현장의 기름때를 묻히고 부하직원들은 상사에게 터 놓고 말해야 한다“ • 유능한 관리자는 예의와 격식에 신경 쓰지 않고 잘못된 일이나 충분치 못한 작업을 곧바로 경영진에 전달 가능 Good Practices① Toyota, Sony 등은 가격 대비 높은 품질을 갖춘 제품을 양산하여 전세계
- 20. Another Quality Definition by Dr. Juran “Quality is Fitness for Use” • Product Features that meet customer needs • Free from Product Deficiencies
- 21. What “Fitness for Use” means
- 22. Quality Definition(2) Conformance To Requirement - 명확히 규정된 요구사항과 부 합 Fitness for Use - 함축적/묵시적 필요 충족 고객 만족 정도 (Degree of Customer Satisfaction)
- 23. Quality above all else…
- 24. Ways to improve Software Quality
- 25. SW Quality Challenge (1) • Every line of code is a potential point of failure • 코드 라인 별 다양한 경우의 수 존재 • 모든 경우의 수를 테스트하는 것은 불가능 • Branch coverage 100% does not mean everything is covered. • Just do our best but no guarantee to cover everything. • Context Dependent • 조직 전체를 아우르는 표준 프로세스 및 도구 적용 어려움 • 동일한 제품을 서로 다른팀에서 개발할 경우에도 동일한 Output이 나오지 않음 • 제품 리스크 동일해도 프로젝트 리스크 상이 • Context에 맞는 프로세스, 개발/테스트 방법론, 도구 필요 • 무인자동차 개발 vs. 워드 프로세서 개발
- 26. SW Quality Challenge (2) • Change • SW는 개발 전단계 걸쳐 수많은 변경을 통해 완성 (HW는 특정 시점 이후 변경 불가) • 변경 1회에 1회 이상의 테스트 필요 (Retest, Regression Test) • 다수의 사람들이 산출물을 동시에 변경 • 개발 협업 체계 미 구축 시 품질 저하 • 개발 과정의 중간 결과 수시 확인 필요 • External Constraints • 독립적으로 실행되는 SW는 없음 • 외부 제약에 부합해야 함 • Hardware • 연동 Software • 정부 규정 • 표준 • 외부 요인이 결함의 원인인 경우에도 SW에서 결함이 발견되고 많은 경우 SW에서 결함 수정
- 27. SW Quality Challenge (3) • Always not enough time • 시스템 개발 시 SW는 개발 마지막에 수행 • 순수 SW 개발의 경우에도 수 많은 변경으로 결함 수정에 시간 소요 • SW Validation 시간 확보 부족
- 28. How to improve Quality? • QA(Quality Assurance) & QC (Quality Control) SW 품질 보증 (SQA) SW 품질 제어 (SQC) 목표 결함 방지 결함 발견 초점 프로세스 제품 기능 Staff Function Line Function 방법 품질 개선 노력을 통한 지속적인 개발 경험의 향상과 함께 작업 방식, 프로세스 개선의 도모 소프트웨어 개발 산출물이 출시되기 전에 이에 대한 결함을 발견하고 수정
- 29. QA/QC Pros and Con s QA QC Pros - 프로세스 개선, 지표 측정 등을 통한 전략적인 지속적 품질 개선 가능 - 단기 내 제품 품질 확보 Cons - 형식적인 문서 검토 - 실질적인 지원 미흡 - QA 조직의 현장감 부족 - Rule 만을 강조하는 탁상 행정 - 전략 부재 (테스트 실행 중심) - 과정 개선 미흡에 의한 동일한 실수 반복 - 개발 마지막 단계의 Heavy Resource
- 30. QA/QC – Which one is important? • QA/QC 중 더 중요한 것은? • 결국 결과만 좋으면 된다 (QC) => 그 결과는 지속 가능한가? • 과정의 품질의 높아지면 좋은 결과가 당연히 나올 것이다 (QA) => 소요 시간?, 고객이 진정으로 원하는 제품? • QA/QC의 Balance 필요 • QC만 강조하면 개발 과정의 품질 확인, 예방 활동 및 지속적 품질 개선 미흡 • QA만 강조하면 중간 및 최종 결과가 고객이 정말 원하는 것이지 확인
- 31. Most important one - Quality Leadership 품질 활동의 성공적인 수행을 위한 가장 중요한 필요 조건은 최고 경영진의 헌신이다 (Commitment from executive management) 핵심 필요 조건 성공적인 QA 및 QC를 수행하기 위한 핵심 조건!
- 32. CASE STUDY - SAMSUNG ELECTRONICS
- 33. 삼성전자 휴대폰 화형식 (1995)
- 34. SW 경쟁력 혁신 T/F (2005 ~) • HW 중심의 삼성전자가 SW 중요성 및 품질 불량에 대한 인지 • SW 경쟁력 및 품질 강화를 위해 전사 차원의 T/F 전개 • 사업부 별 SW 개발 및 품질 현황을 진단하고 개선 방향 제시 • 삼성 전자의 SW 경쟁력 강화 활동의 시발점이 됨 • 개발 기간 단축과 품질 향상을 최종 목표로 설정
- 35. SW 경쟁력 혁신 T/F - 개선 방향 (1) • SW 표준화 • SW는 HW처럼 부품 표준화가 되어 있지 않음 • SW의 Platform 도입 및 확산으로 SW 표준화 구축 • SW 공용화 • SW 모듈(HW의 부품과 유사하게 표현)은 공용화가 되어 있지 않음 • 공용화로 인한 SW 재사용을 유도하여 비용 절감 및 개발 공정 기간 단축 • SW 공용화 시스템 구축 후 SW 모듈 및 산출물 등록하고 SW 재사용율 측정 • SW 표준 개발 프로세스 구축 • 사업부 별 개발팀 별 프로세스가 서로 다름 • 표준 프로세스 구축 및 프로세스 준수 여부 확인하는 Audit 활동 전개 • 전사 표준 프로세스 기반 사업부 별 프로세스 Tailoring 허용
- 36. SW 경쟁력 혁신 T/F - 개선 방향 (2) • 개발 원류 품질 강화 • 결함이 유입되는 개발 초기 단계의 검증이 제대로 이루어지지 않음 • Unit Test 수행으로 조기 결함 검출 강화 • 개발 단계 품질 전담 조직 개설 (SE, SQE) • SW 품질 인력 충원 • 글로벌 회사들의 경우 SW 품질 인력이 개발자 대비 최소 20%에서 60% 수준 • 현황은 2% 미만, 향후 10% 까지 품질 인력 충원 • SW 표준 CASE 도구 사용 • 사업부 별 개발 팀 별 서로 다른 개발 도구 사용 • SW 개발 표준 도구 도입으로 비용 절감 • 요구 사항 관리/설계 도구 – Doors, Tau • 형상관리/결함 관리 도구 – ClearCase, ClearQuest
- 37. Limitation of SW 경쟁력 혁신 T/F (1) • SW 특성을 고려하지 않은 표준화/공용화 안 도출 • 표준화/공용화는 HW에 적합한 Approach • 자체 SW Platform 구축을 위한 SW Architect 및 개발자 역량 부족 • 표준화를 위한 SW Platform은 특정 Vendor로부터의 구매로 확보 불가 • SW Platform의 성공은 Ecosystem 구축 및 Ecosystem 품질 확보 필수 • Context 고려하지 않은 일괄적인 표준 프로세스 및 도구 적용 시도 • ISO 12207(SPICE)/CMM 모델 기반으로 표준 프로세스 구축 • 개발 기간이 짧은 일부 사업부 및 개발팀의 상황에 맞지 않는 과도한 프로세스 개발 및 적용 시도 • 개발 과제 별 특성을 고려하지 않은 표준 도구 적용 추진 • SW 개발 역량 및 품질 미확보 상태에서 성급한 공용화 추진 • SW는 HW처럼 모듈화하기 위해서는 고도의 설계 능력 필요 • 품질이 확보되지 않은 SW 모듈의 공용화는 재앙
- 38. Limitation of SW 경쟁력 혁신 T/F (2) • Big Change로 현업 부서의 저항 • 경영진으로부터 급격한 변화 요구로 현업 부서의 반감 증가 • 개발자의 저항 및 일부 허위 데이터 양산 • 문화 정착을 위한 보상 중심의 대책 미흡 • 작은 변화와 성과에도 칭찬과 보상이 주어져야 함 • 자발적인 품질 활동 정착 위한 팀/사업부 단위의 다양한 보상 정책 부족 • 단기적 성과 측정 시도 • SW 개발 인력 증가 및 집중적 SW 품질 활동 강화로 개발 과정 부하 가중 • 개발 기간 단축과 품질 강화는 지속적인 개선 (Continuous Improvement)으로 가능
- 39. Lesson from SW 경쟁력 혁신 T/F • 소프트웨어 품질 확보를 위한 경영진의 의지 • 삼성전자는 최고 경영층에서 SW 품질의 중요성을 인지하고 SW 품질 개선 의지 표명 • SW 품질 중요성을 현업 부서에 각인 • 철저한 감사와 사후 관리 • 조직의 품질 역량을 올리기 위한 전사 프로세스 및 정책 수립 • 삼성전자의 SW 품질 역량 미흡 사업부의 경우 SW 프로세스 및 도구 도입 등 SW 품질 기반을 구축하는 계기가 됨 • 원류 품질 개선을 위한 Unit Test 강화 및 개발팀 내 품질 전담 조직 및 인력 배치 • 개발팀 내 SE (Software Engineering) 조직 신설하여 SW 개발 생산성 및 품질 향상 지원 • SW 개발 원류 품질 확보를 위한 자주 검증 문화 강조
- 40. Wrap-up Let’s bring Steve Jobs again