Basics to have competitive advantage of S/W in global Market

SW 아키텍트포럼

- 2007. 10. 18 -- 2007. 10. 18 -

글로벌 S/W 경쟁력 확보를 위한 전략

- S/W 아키텍처 , 프로세스 & 재사용


- 목 차 -

1. 들어가며

2. S/W 아키텍쳐

3. S/W 프로세스

4. 재사용


S/W 에 대한 요구는 ? 기술이 발전함에 따라 산업 전분야에 걸쳐 S/W 에 대한 의존도가

갈수록 심화되고 있으며 , 전투기 S/W 기능 의존도 : 1960 - F4 8%, 1982 - F16 45%, 2000 - F22 80%

지속적인 경비절감 , 품질 및 생산성 향상을 요구하고 있음

비지니스에서 S/W 에 대한 주요 요구 사항 High quality Quick time to market Market agility Low cost production Low cost maintenance Mass customization

1. 들어가며

0

10

20

30

40

50

60

70

80

1960 1970 1982 2000Year of introduction

Percent of FunctionalityProvided by

Software

(Source: Humphrey, 2003)

- 1/33 -


Standish Group - CHAOS Study

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 억 )

구분 1994 1998 2002

Successful 16% 26% 34%

Challenged 53% 46% 51%

Failed 31% 28% 15%

(Source: Standish Group, 2003)

1. 들어가며

- 2/33 -


Global Demand For IT Workers *

S/W 전문가에 대한 공급 부족이 더욱 심화될 것으로 예측되고 있음 미숙련자는 어느 정도 충족되나 , 고급기술자는 많이 부족함 국내의 경우도 초급기술자는 취업난 , 고급기술자는 구인난이 점차 심화됨

1. 들어가며

- 3/33 -


Best practices – Indian companies

차별화된 품질 경쟁력을 토대로 해외시장에서 연 평균 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)

1. 들어가며

- 4/33 -


Best practices – Indian companies

풍부하고 저렴한 인력 & 영어 사용 No Captive 마켓

전 임직원의 참여를 통한 개선 활동 글로벌 표준 프로세스 모델 기반의 개선

ISO9000, CMM/CMMI, PCMM, Six Sigma 등

모든 임직원이 일관된 품질 목표와 오너쉽를 가지고 활동 데이타중심 & 고객 중심 People, Process, 기술의 통합

프로세스 모델 내재화 방향 국제 표준 , 프레임웍의 올바른 이해 철저한 프로세스의 적합성 검토 (mapping) 적용 가능한 분야에 필요한 만큼 도입하여 , 엄격하게 이행 강력한 Feedback Loop & 지속적인 개선

1. 들어가며

- 5/33 -


글로벌 경쟁력 확보를 위해서는 S/W Architecture

S/W Process

Reuse

1960 1970 1980 1990 2000 2007

Structured

Information Engineering

Object-Oriented

CBD

SOA, Web 2.0

1. 들어가며

- 6/33 -


S/W ArchitectureS/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}

2. S/W architecture

- 7/33 -


Software architecture positioning

Relation of software architecture to other development tasks 설계 단계를 아키텍처설계와 상세설계로 세분화 아키텍처설계는 중요한 설계 의사결정 , 아키텍처 검증 및 상세 설계를 위한

가이드를 제공 업무 분석 , 인프라 설계 , 데이터 설계를 기반으로 아키텍처를 결정하고 ,

설계자에게 가이드를 제공

SoftwareArchitecture

Design

Domain Analysis,Requirement Analysis,

Risk Analysis

HardwareArchitecture

Design

Detailed Design,Coding,

Integration,Testing

Requirements,Desired Qualities

Modifications torequirements

Hardwarearchitecture

Modifications tohardwarearchitecture

Implementationconstraints

Softwarearchitecture

Development tasks

feedforward

feedback

참조 : Applied Software Architecture, C. Hofmeister, Addison Wesley, 2000

2. S/W architecture

S/W 공학

- 8/33 -


Why is software architecture important?

Represents earliestdesign decisions

First design artifact addressing

Key to systematic reuse

Hardest to change

Most critical to get right

Communication vehicle among stakeholders

Performance

Modifiability

Reliability

Security

Transferable, reusable abstraction

The right architecture paves the way for system success.The wrong architecture usually spells some form of disaster.

2. S/W architecture

Software Product Lines: Reuse That Makes Business Sense, Linda Northrop, 2007

- 9/33 -


Typical categories of influencing factors

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

Staff skills, interests,

strengths, weaknesses

Process and

development

environment

Development schedule

Development budget

General-purpose

hardware

Domain-specific

hardware

Software technology

Architecture technology

Standards

Functional

features

User interface

Performance

Dependability

Failure detection,

reporting,

recovery

Service

Product cost

참조 : Applied Software Architecture, C. Hofmeister, Addison Wesley, 2000

2. S/W architecture

- 10/33 -


logical, implementation, process, deployment 4 개의 뷰를 usecase view로 묶어 주며 , view간의 균형을 이루어야함

Kruchten’s 4+1 View Architecture 2. S/W architecture

- 11/33 -


Why S/W Process?

The quality of a software product is governed by the quality of the proces

ses 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

3. S/W process

Dan Lee, 2006

- 12/33 -


Process reference model & OSSP

CMMI, PSP/TSP, Software Product Lines, ISO/IEEE12207, Six Sigma, SWEBOK, LEAN (Toyoda Production System), …

ISO9000 & CMMI L3 인증 조직은

3. S/W process

John D. Vu

- 13/33 -


CMMI

Disciplined ProcessProject Management

Consistent ProcessOrganizational Standardization

Predictable ProcessManagement by Facts & Data

Continuously Improving Process Operational Excellence

3. S/W process


내재화 도구 - PDCA & IDEAL Deming

85% of all quality problems – 프로세스를 바꾸거나 경영진의 참여가 필요 15% of quality problems – 실무자가 해결 가능

실행 중심 (Check-Act) 으로 전환이 필요함

Plan

DoCheck

Act

• Immediate remedies• Future actions

• Against objectives• How methods executed

• Objectives• Methods

• Train• Execute

Deming Cyclefor Improvement

Deming’s PDCA

IDEAL in CMM

3. S/W process

- 15/33 -


S/W Process 성숙도 3. S/W process

- 16/33 -


S/W Process 성숙도 - CMMI general goals and practices

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

3. S/W process

- 17/33 -


국내의 현황 국내는 방법론 , 프로세스가 비교적 적극적으로 도입되어 왔음

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 managemen

t, PPQA in level 2 Risk management, V&V (Inspection), Defect, PAL in level 3

3. S/W process

- 18/33 -


’95 33 LOC/MD -> ’02 80 LOC/MD

아웃소싱시 요구되는 메트릭스 자료 (Forrester)- 결함 (LOC당 , 단계별 , 이관후 )- 사용자승인테스트 전후 재작업 비용- 1 차 사용자 승인 테스트 통과율- 비용 준수율- 납기 준수율

측정지표 – Indian companies ISO9000 도입시점 부터

결함율 , 납기준수율 , 생산성 (LOC) 등 메트릭스가 관리되고 있음 다양한 벤치마킹을 통한 지속적인 개선을 추구함

3. S/W process

- 19/33 -


Time to move up a maturity level

Global average to level 5 99 months 국내 기업은 얼마나 걸리는지 ?

CMMI 도입 효과를 달성하기 위해서는 내재화 중심으로 전환이 필요함

Based on 216 organization assessments conducted between 1991-2000, John D. Vu, 2003

Level 2

Level 5

Level 3

Level 4

Avera

ge t

ime t

o m

ove t

o n

ext

l evel

34 months

25 months

30 months

20 monthsLevel 4 + PSP/TSP

10 months

3. S/W process

- 20/33 -


ROI in S/W Process Improvement

CMMI Performance Results (December 15, 2005)

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

http://www.sei.cmu.edu/cmmi/results.html

3. S/W process

- 21/33 -


Software Reuse

소스코드와 문서의 재사용을 통한 생산성 향상P

erce

nt o

f Sof

twar

e R

euse

40%

35%

30%

25%

20%

15%

10%

5%

0%

CodeOthers

3%

10%

25%28%

15%

33%

Code reuse: No modificationOther reuse: Templates, Test cases etc.

36%

Level 2 Level 3 Level 4 Level 5

7%

3. S/W process

John D. Vu, 2003

- 22/33 -


Review & Inspection Benefit Ratio

결함의 조기 발견 및 제거를 통한 재작업 비용 절감

Req. Design Code Test Post-Release

Rew

ork

Eff

ort

Before Review/InspectionAfter Implemented Review/Inspection

8%

1%

12%

3%

19%

4%

Formal Review & Inspection increased design effort by 4% decreased rework effort by 31%

Reduce 31% in rework

Cost: Benefit ratio is 4% : 31% or 1 : 7.75

Based on 6 organizations assessed at level 4 & 5, John D. Vu, 2003

3. S/W process

- 23/33 -


PSP/TSP Benefits

System Test time

Release # 6 Release # 7 Release # 8 Release # 9PSP/TSP trained

2.36X moreSloc count

32 days 41days

4 days

94% less time(75% lower defect)

Software Size

Source: SEI industry Study of PSP/TSP in 18 U.S companies, John D. Vu, 2003

28 days

3. S/W process

- 24/33 -


Five keys to look for…

1. Can the organization demonstrate actual business benefit of process im

provement ? (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 appro

priate)?

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)

3. S/W process

- 25/33 -


Software 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. I

t 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.

4. Reuse


- 26/33 -


Component Based Programming

Component Based Analysis

Programmer Led

ProjectLed

Enterprise Initiative

Components are GUI controlsActiveX, or JavaBeans components are used to implement client applications

Components are implementation conceptProgrammers/designers structure code implementation as components

Components are business conceptAnalysts model business concepts as components

Components are reusedAd-hoc reuse of components across projects

Components are enterprise standardEnterprise-wide agreement on components

CBD maturityFully utilized component repository

1

2

3

4

5

6

Architecture

Reuse

Butler Group,1998

Technology

Reuse

전사 차원의 재사용 전략 수립을 통한 Reuse Governance 확보 전문가 재사용 - 기술별 , 업무 영역별 , … S/W 공학 - 체계적인 분석 , 설계를 통한 재사용 PAL (Process Asset Library) & KM 전사 재사용 라이브러리

4. Reuse

- 27/33 -


Reuse

관리Plan, fund, prioritize, coordinate, learn

생산Engineer domain, framework,

components, tools

지원Certify, classify, package,distribute, advise, maintain

재사용Select, customize, assemble

Product requirementsand existing software

Products

성공적인 재사용을 위해서는 재사용 자산 (Core Assets) 의 개발과 함께 체계적인 지원 및 관리가 중요한 것으로 보고되고 있음

4. Reuse

Software reuse, Ivar Jacobson, 1997

- 28/33 -


Software Product Lines

Reuse 을 위한 29 개 영역의 best practices 를 제공하고 있음 http://www.sei.cmu.edu/productlines/framework.html

4. Reuse



Software Product Lines

재사용 관점에서 OO, CBD 의 연장선으로 볼 수 있으며 특정 산업 도메인의 Core Asset 을 만들어 새로운 Product 개발시 Variation만 추가

4. Reuse


- 30/33 -


Payoff Point

Commonality

- 공통 요구사항정의서- 아키텍처 설계서- 테스트계획서 ,

테스트케이스- 프로세스 정의서

Core AssetDevelopment

ProductDevelopment

구현된공통기능

차이구현 방안

새로운Product

Variation

- 차별화된 요구사항- 차별화 요소 구현 Com

ponent- 특화된 아키텍처- 조립 방안 등

보통

예금 청

약예금

정기예금

Core Assets

Core Assets

보통에금

정기예금

정약예금

--예금

▪▪

은행

도메인

S/W Product Line 4. Reuse

- 31/33 -


ROI - Nokia Mobile Phones

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

4. Reuse


- 32/33 -


글로벌 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.js

p

Open Sources & Web2.0

wikipedia (http://en.wikipedia.org/)

Eclipse 프로젝트 – Open UP, ….

포럼 , blog, Community 의 적극적인 참여

Programming, 즉 구현이 기본이 되어야 함

- 33/33 -


감사합니다 .

김 영온

[email protected]