Brief introduction of S/W architecture, process and reuse, which might have not been succeeded to deliver the committed benefits in Korean market. I presented it in 2007, revisited today and felt to share this presentation with you.

1. 글로벌 S/W 경쟁력 확보를 위한 전략
- S/W 아키텍처 , 프로세스 & 재사용
- 2007. 10. 18 -
SW 아키텍트포럼

2. - 목 차 -
1. 들어가며
2. S/W 아키텍쳐
3. S/W 프로세스
4. 재사용
SW 아키텍트포럼

3. S/W 에 대한 요구는 ? 1. 들어가며
 기술이 발전함에 따라 산업 전분야에 걸쳐 S/W 에 대한 의존도가
갈수록 심화되고 있으며 ,
 전투기 S/W 기능 의존도 : 1960 - F4 8%, 1982 - F16 45%, 2000 - F22 80%
 지속적인 경비절감 , 품질 및 생산성 향상을 요구하고 있음
 비지니스에서 S/W 에 대한 주요 요구 사항
 High quality 80
 Quick time to market 70
 Market agility 60
 Low cost production Percent of 50
Functionality
 Low cost maintenance Provided by 40
Software
 Mass customization 30
20
10
0
1960 1970 1982 2000
Year of introduction
(Source: Humphrey, 2003)
- 1/33 - SW 아키텍트포럼

4. 1. 들어가며
Standish Group - CHAOS Study
구분 1994 1998 2002
Successful 16% 26% 34%
Challenged 53% 46% 51%
Failed 31% 28% 15%
 Challenged:
 Cost Overruns: 43% vs. 189% (2002 vs. 1994)
 Time Overruns: 82% vs. 222%
 Required Features: 52% vs. 61%
 IT 실패 비용
 $550 억 /$2550 억
(’94 년 $1400 억 /$2500 억 )
(Source: Standish Group, 2003)
- 2/33 - SW 아키텍트포럼

5. Global Demand For IT Workers * 1. 들어가며
 S/W 전문가에 대한 공급 부족이 더욱 심화될 것으로 예측되고 있음
 미숙련자는 어느 정도 충족되나 , 고급기술자는 많이 부족함
 국내의 경우도 초급기술자는 취업난 , 고급기술자는 구인난이 점차 심화
됨
- 3/33 - SW 아키텍트포럼

6. Best practices – Indian companies 1. 들어가며
 차별화된 품질 경쟁력을 토대로
 해외시장에서 연 평균 30~40% 대의 지속적인 성장과 함께
 매출액 대비 20% 이상의 순이익을 실현하고
 R&D 아웃소싱 , 컨설팅 , 테스팅 등 고부가가치 분야로 사업 영역을 확
대하고
 미국 , 유럽 , 일본 중심의 시장 개발에서 국내 시장 진출이 시작되고 있
음
 Wipro
 Chairman Azim H. Premji
 2007 년 포브스 선정 세계 부호 21 위
 Wipro’s offshore engagements offerings
 30-40% lower Total Cost of Ownership
 20-30% higher productivity
 On-time deliveries (93% projects completed on time)
 Lower field defect rates (67% lower than industry average)
- 4/33 - SW 아키텍트포럼

7. Best practices – Indian companies 1. 들어가며
 풍부하고 저렴한 인력 & 영어 사용
 No Captive 마켓
 전 임직원의 참여를 통한 개선 활동
 글로벌 표준 프로세스 모델 기반의 개선
 ISO9000, CMM/CMMI, PCMM, Six Sigma 등
 모든 임직원이 일관된 품질 목표와 오너쉽를 가지고 활동
 데이타중심 & 고객 중심
 People, Process, 기술의 통합
 프로세스 모델 내재화 방향
 국제 표준 , 프레임웍의 올바른 이해
 철저한 프로세스의 적합성 검토 (mapping)
 적용 가능한 분야에 필요한 만큼 도입하여 , 엄격하게 이행
 강력한 Feedback Loop & 지속적인 개선
- 5/33 - SW 아키텍트포럼

8. 글로벌 경쟁력 확보를 위해서는 1. 들어가며
 S/W Architecture
 S/W Process
 Reuse
SOA, Web 2.0
CBD
Object-Oriented
Information Engineering
Structured
1960 1970 1980 1990 2000 2007
- 6/33 - SW 아키텍트포럼

9. S/W Architecture 2. S/W architecture
 The fundamental organization of a system, embodied in its
components, their relationships to each other and the environment,
and the principles governing its design and the evolution [ANSI/IEEE Std 1471]
 The structure or structures of the system, which comprise software
elements, the externally visible properties of those elements, and the
relationships among them [Bass, et.al., 2003]
 Documenting software architecture facilitates communication between
stakeholders, documents early decisions about high-level design, and
allows reuse of design components and patterns between projects.
 {Structure/Organization, Components, Relationships, Principles}
- 7/33 - SW 아키텍트포럼

10. Software architecture positioning 2. S/W architecture
 Relation of software architecture to other development tasks
 설계 단계를 아키텍처설계와 상세설계로 세분화
 아키텍처설계는 중요한 설계 의사결정 , 아키텍처 검증 및 상세 설계를
위한 가이드를 제공
 업무 분석 , 인프라 설계 , 데이터 설계를 기반으로 아키텍처를 결정하고 , 설
계자에게 가이드를 제공
Requirements, Hardware
Desired Qualities architecture
Domain Analysis, Software Hardware
Requirement Analysis, Architecture Architecture
Risk Analysis Design Design
Modifications to
Modifications to hardware
requirements architecture
Software
Implementation
architecture
constraints
Detailed Design, Development tasks
Coding,
S/W 공학 Integration, feedforward
Testing feedback
참조 : Applied Software Architecture, C. Hofmeister, Addison Wesley, 2000
- 8/33 - SW 아키텍트포럼

11. Why is software architecture important? 2. S/W architecture
 Hardest to change
 Represents earliest
design decisions  Most critical to get right
 Communication vehicle
among stakeholders
 Performance
 First design artifact
addressing  Modifiability
 Reliability
 Security
 Key to systematic reuse  Transferable, reusable
abstraction
The right architecture paves the way for system success.
The wrong architecture usually spells some form of disaster.
Software Product Lines: Reuse That Makes Business Sense, Linda Northrop, 2007
- 9/33 - SW 아키텍트포럼

12. Typical categories of influencing factors 2. S/W architecture
 Many kinds of view
 Quality attributes, ISO9126
 functionality, reliability, usability, efficiency, maintainability, portability
 Quality attribute scenarios
 availability, modifiability, performance, security, testability, usability
 Global analysis
Organizational Factors Technological Factors Product Factors
 Management  General-purpose hardware  Functional features
 Staff skills, interests,  Domain-specific hardware  User interface
strengths, weaknesses  Software technology  Performance
 Process and development  Architecture technology  Dependability
environment  Standards  Failure detection,
 Development schedule reporting, recovery
 Development budget  Service
 Product cost
참조 : Applied Software Architecture, C. Hofmeister, Addison Wesley, 2000
- 10/33 - SW 아키텍트포럼

13. Kruchten’s 4+1 View Architecture 2. S/W architecture
 logical, implementation, process, deployment 4 개의 뷰를 usecase
view 로 묶어 주며 , view 간의 균형을 이루어야함
- 11/33 - SW 아키텍트포럼

14. 3. S/W process
Why S/W Process?
 The quality of a software product is governed by the quality of the
processes used to develop and maintain it.
 To improve the quality of the product, one must improve the quality of the
processes used to create the product.
 Fundamental theories are based on Crosby, Deming and Juran, and
therefore, the roots are TQM (Total Quality Management).
 S/W process is
 A description of current practice
 A baseline for analysis and comparison of software processes
 A repository of organization software manufacturing "know-how"
 A template for planning software development
 A vehicle for implementation and enactment
 A measure for software process improvement
Dan Lee, 2006
- 12/33 - SW 아키텍트포럼

15. Process reference model & OSSP 3. S/W process
 CMMI, PSP/TSP, Software Product Lines, ISO/IEEE12207, Six Sigma,
SWEBOK, LEAN (Toyoda Production System), …
 ISO9000 & CMMI L3 인증 조직은

 
 
John D. Vu
- 13/33 - SW 아키텍트포럼

16. CMMI 3. S/W process


Disciplined Process
Project Management




Consistent Process
Organizational Standardization

Predictable Process
Management by Facts & Data
Continuously Improving
Process Operational Excellence
SW 아키텍트포럼

17. 내재화 도구 - PDCA & IDEAL 3. S/W process
 Deming
 85% of all quality problems – 프로세스를 바꾸거나 경영진의 참여가 필요
 15% of quality problems – 실무자가 해결 가능
 실행 중심 (Check-Act) 으로 전환이 필요함
Deming’s PDCA
• Immediate remedies • Objectives
• Future actions • Methods
Deming Cycle Act Plan
IDEAL in CMM
for Improvement
Check Do
• Against objectives • Train
• How methods executed • Execute
- 15/33 - SW 아키텍트포럼

18. S/W Process 성숙도 3. S/W process
- 16/33 - SW 아키텍트포럼

19. S/W Process 성숙도 - CMMI general goals and practices 3. S/W process
 GG 1 Achieve Specific Goals
 GP 1.1 Perform Specific Practices
 GG 2 Institutionalize a Managed Process
 GP 2.1 Establish an Organizational Policy
 GP 2.2 Plan the Process
 GP 2.3 Provide Resources
 GP 2.4 Assign Responsibility
 GP 2.5 Train People
 GP 2.6 Manage Configurations
 GP 2.7 Identify and Involve Relevant Stakeholders
 GP 2.8 Monitor and Control the Process
 GP 2.9 Objectively Evaluate Adherence
 GP 2.10 Review Status with Higher Level Management
 GG 3 Institutionalize a Defined Process
 GP 3.1 Establish a Defined Process
 GP 3.2 Collect Improvement Information
 GG 4 Institutionalize a Quantitatively Managed Process
 GP 4.1 Establish Quantitative Objectives for the Process
 GP 4.2 Stabilize Subprocess Performance
 GG 5 Institutionalize an Optimizing Process
 GP 5.1 Ensure Continuous Process Improvement
 GP 5.2 Correct Root Causes of Problems
- 17/33 - SW 아키텍트포럼

20. 국내의 현황 3. S/W process
 국내는 방법론 , 프로세스가 비교적 적극적으로 도입되어 왔음
 90 년대 초부터 방법론 도입
 정보공학  객체지향  CBD  SOA
 90 년대 중반부터 ISO9000 중심의 품질 시스템 도입
 90 년대 말부터 CMM/CMMI 도입
 Certification/just buy or institutionalization?
 방법론
 Domain, Platform, Phase-Activity-Task 별 투입공수 /each role
 ISO9000
 PDCA: PD 중심 ?
 프로세스에 대한 데이터를 측정 , 개선에 활용 (metrics)
 CMM/CMMI
 Project monitoring & control, requirement management, configuration
management, PPQA in level 2
 Risk management, V&V (Inspection), Defect, PAL in level 3
- 18/33 - SW 아키텍트포럼

21. 측정지표 – Indian companies 3. S/W process
 ISO9000 도입시점 부터
 결함율 , 납기준수율 , 생산성 (LOC) 등 메트릭스가 관리되고 있음
 다양한 벤치마킹을 통한 지속적인 개선을 추구함
아웃소싱시 요구되는 메트릭스 자료
(Forrester)
- 결함 (LOC 당 , 단계별 , 이관후 )
- 사용자승인테스트 전후 재작업 비용
- 1 차 사용자 승인 테스트 통과율
’95 33 LOC/MD -> ’02 80 LOC/MD
- 비용 준수율
- 납기 준수율
- 19/33 - SW 아키텍트포럼

22. Time to move up a maturity level 3. S/W process
 Global average to level 5  99 months
 국내 기업은 얼마나 걸리는지 ?
 CMMI 도입 효과를 달성하기 위해서는 내재화 중심으로 전환이 필요함
Average time to move to next level
Level 2 34 months
Level 3 25 months
Level 4 30 months
Level 4 + PSP/TSP
20 months
Level 5 10 months
Based on 216 organization assessments conducted between 1991-2000, John D. Vu, 2003
- 20/33 - SW 아키텍트포럼

23. ROI in S/W Process Improvement 3. S/W process
 CMMI Performance Results (December 15, 2005)
http://www.sei.cmu.edu/cmmi/results.html
 Analysis of Return on Investment

1. 10,000 LOC 개발 , 개발자 4 명 프로젝트 기준
2. ROI of Software Process Improvement: Metrics for Project Managers and Software Engineers, David F. Rico, J. Ross Publishing, 2004
- 21/33 - SW 아키텍트포럼

24. Software Reuse 3. S/W process
 소스코드와 문서의 재사용을 통한 생산성 향상
40%
Code
Others 36%
35%
33%
Percent of Software Reuse
30%
28%
25% 25%
20%
15% 15%
10% 10%
7%
5%
3%
0%
Level 2 Level 3 Level 4 Level 5
Code reuse: No modification
Other reuse: Templates, Test cases etc. John D. Vu, 2003
- 22/33 - SW 아키텍트포럼

25. Review & Inspection Benefit Ratio 3. S/W process
 결함의 조기 발견 및 제거를 통한 재작업 비용 절감
Before Review/Inspection
After Implemented Review/Inspection
19%
Reduce 31% in rework
Rework Effort
12%
8%
3% 4%
1%
Req. Design Code Test Post-Release
Formal Review & Inspection increased design effort by 4%
decreased rework effort by 31%
Cost: Benefit ratio is 4% : 31% or 1 : 7.75
Based on 6 organizations assessed at level 4 & 5, John D. Vu, 2003
- 23/33 - SW 아키텍트포럼

26. PSP/TSP Benefits 3. S/W process
Software Size
2.36X more
Sloc count
System 41days
32 days
Test time 28 days
94% less time
(75% lower defect)
4 days
Release # 6 Release # 7 Release # 8 Release # 9
PSP/TSP
trained
Source: SEI industry Study of PSP/TSP in 18 U.S companies, John D. Vu, 2003
- 24/33 - SW 아키텍트포럼

27. 3. S/W process
Five keys to look for…
1. Can the organization demonstrate actual business benefit of process
improvement ? (improvement trends or results?)
2. Which projects follow (or not follow) the standard processes?
3. Are these processes being verified independently that they are used
and controlled at the project level?
4. Is day-to-day decision making based on measurement data (where
appropriate)?
5. How are business goals prioritized and intergroup conflicts resolved?
(John D. Vu, 2003)
 Maturity levels and certification are meaningless, if they cannot be
explained in terms of business objectives.
 Provide faster service, deliver higher quality products, and achieve
customer satisfaction. (Dan Lee, 2006)
- 25/33 - SW 아키텍트포럼

28. Software Reuse 4. Reuse
 Adapting existing software components to new applications is easy;
 If it does not fit, modify it until it fits.
 Any code can be reused since it’s “modularized” already.
 Opportunistic reuse
 Adapt existing software components to new applications by modifying them.
It is not cost effective since you still have to modify and test it.
 Systemic reuse
 Reuse “well-defined” and “well designed” software components without any
modification.
Software Product Lines: Reuse That Makes Business Sense, Linda Northrop, 2007
- 26/33 - SW 아키텍트포럼

29. Reuse 4. Reuse
 전사 차원의 재사용 전략 수립을 통한 Reuse Governance 확보
 전문가 재사용 - 기술별 , 업무 영역별 , …
 S/W 공학 - 체계적인 분석 , 설계를 통한 재사용
 PAL (Process Asset Library) & KM
 전사 재사용 라이브러리
Programmer Project Enterprise
Led Led Initiative
CBD maturity
Reuse 6 Fully utilized component repository
Component Component
Based Based Components are enterprise standard
Programming Analysis 5 Enterprise-wide agreement on components
Architecture
4 Components are reused
Ad-hoc reuse of components across projects
Components are business concept
3 Analysts model business concepts as components
Technology
2 Components are implementation concept
Programmers/designers structure code implementation as components
1 Components are GUI controls
ActiveX, or JavaBeans components are used to implement client applications
Butler Group,1998
- 27/33 - SW 아키텍트포럼

30. Reuse 4. Reuse
 성공적인 재사용을 위해서는 재사용 자산 (Core Assets) 의 개발과
함께 체계적인 지원 및 관리가 중요한 것으로 보고되고 있음
관리
Plan, fund, prioritize, coordinate, learn
생산
Engineer domain, framework,
components, tools
지원
Certify, classify, package,
distribute, advise, maintain
재사용
Select, customize, assemble Products
Product requirements
and existing software
Software reuse, Ivar Jacobson, 1997
- 28/33 - SW 아키텍트포럼

31. Software Product Lines 4. Reuse
 Reuse 을 위한 29 개 영역의 best practices 를 제공하고 있음
 http://www.sei.cmu.edu/productlines/framework.html
Software Product Lines: Reuse That Makes Business Sense, Linda Northrop, 2007 SW 아키텍트포럼

32. Software Product Lines 4. Reuse
 재사용 관점에서 OO, CBD 의 연장선으로 볼 수 있으며 특정 산업
도메인의 Core Asset 을 만들어 새로운 Product 개발시 Variation 만
추가
Software Product Lines: Reuse That Makes Business Sense, Linda Northrop, 2007
- 30/33 - SW 아키텍트포럼

33. S/W Product Line 4. Reuse
Core Assets
정기예금
보통에금
금
청
예
약
통
보
예
은 정기예금
금
행
도 정약예금 Core Assets Payoff Point
메
인 ▪
▪
--
예금
Commonality Variation
Core Asset - 공통 요구사항정의서 - 차별화된 요구사항
Development - 아키텍처 설계서 - 차별화 요소 구현
- 테스트계획서 , 테스트 Component
케이스 - 특화된 아키텍처
- 프로세스 정의서 - 조립 방안 등
Product 구현된 차이 새로운
Development 공통기능 구현 방안 Product
- 31/33 - SW 아키텍트포럼

34. ROI - Nokia Mobile Phones 4. Reuse
 Product lines with 25-30 new products per year versus 5 per year
originally.
 Across products there are
 varying display sizes
 varying sets of features
 58 languages supported
 130 countries served
 multiple protocols
 configurable features
 Organizational Benefits
 Improved productivity by as much as 10x
 Increased quality by as much as 10x
 Decreased cost by as much as 60%
 Decreased labor needs by as much as 87%
 Decreased time to market (to field, to launch...) by as much as 98%
 Ability to move into new markets in months, not years
Software Product Lines: Reuse That Makes Business Sense, Linda Northrop, 2007
- 32/33 - SW 아키텍트포럼

35. 글로벌 S/W 경쟁력 확보를 위해서는
 Paradigm shift
 from certification to institutionalization for real business value
 Global standards
 국제표준 (IEEE, ISO, PMBOK, SWEBOK, CMMI, Six Sigma…)
 정보통신단체표준 (TTAS) http://www.tta.or.kr/Home2003/library/ttasList.jsp
 Open Sources & Web2.0
 wikipedia (http://en.wikipedia.org/)
 Eclipse 프로젝트 – Open UP, ….
 포럼 , blog, Community 의 적극적인 참여
 Programming, 즉 구현이 기본이 되어야 함
- 33/33 - SW 아키텍트포럼

36. 감사합니다 .
김 영온
yokim31@hanmail.net
SW 아키텍트포럼