Sw 아키텍처와 sw 공학

제8회 2015 한국 소프트웨어 아키텍트 대회
2015(제8회) 한국 소프트웨어 아키텍트 대회
아키텍처와 SW공학 프랙티스
- Back to the basic
2015. 07. 16
회사명 : SW공학 전문가 포럼
발표자 : 김 영온

1. SW 프로젝트는?
□ Biz.에서 S/W에 대한 요구 사항
○ 고 품질 (High Quality)
○ 짧은 납기 (Quick Delivery)
○ 낮은 개발과 유지보수 비용
○ Market agility
○ Mass customization
○ 그런데 요구사항은
• 불분명하고
• 끊임없이 변하고
• 너무 많고
- 2 -

□ 프로젝트 현황은?
○ 품질 비용
• 피할 수 있는 재작업 비용 40 ~ 50% (Barry Boehm)
• 재작업 비용 46.3% (NIPA 2012)
– 내부 실패 27.2%, 외부 실패 19.1%
○ 기능 사용 현황 (Standish Group)
• 자주 사용 20%
• 거의 사용 안함 30%
• 사용 안함 50%
- 3 -

□ Hot technologies and practices
○ Software architecture
○ Agile
• XP, SCRUM, …..
○ Testing
○ Software product line
• Platform
○ Cloud computing
• SaaS, PaaS, IaaS, DaaS, …..
○ Big data
• Hardoop, ….
○ Open sources
○ What about practices in software engineering?
4

제8회 2015 한국 소프트웨어 아키텍트 대회- 5 -
2. Software architecture
What is Software architecture?
○ SW 아키텍처 정의
• 시스템의 SW아키텍처는 SW요소와
요소간의 관계, 각각의 속성으로 구성된
시스템에 필요한 구조의 집합이다.
– 아키텍처는 추상화이다.
– 모든 SW 시스템은 SW아키텍처를 가지고 있다.
– 아키텍처는 행위를 포함한다.
• ISO/IEC 42010: 2007 아키텍처 정의:
– 컴포넌트와 컴포넌트 상호간 그리고 환경과의 관계, 설계와 개선 시 지켜야
하는 원칙을 포함하는 시스템의 기본적인 조직 (fundamental
organization of a system)
Software architecture in practice, 3rd edition, Len Bass, Paul Clements, 2013

Applied Software Architecture, C. Hofmeister, Addison Wesley, 2000
S/W 아키텍처
설계
도메인 분석,
요구사항 분석,
위험 분석
상세 설계,
코딩,
통합 테스트
요구사항,
요구 속성
요구사항
변경요청
기술
아키텍처
기술아키텍처
변경요청
이행
고려사항
S/W
아키텍처
유형별 아키텍처간 상관 관계
소프트웨어 아키텍처는 비즈니스 요구사항에 따라 개발한 기
술과 데이터 아키텍처와 상호 영향을 미치면서 개발함
- 6 -
기술 아키텍처
설계
비즈니스 요구사항,
비지니스 아키텍처
개발 타스크
feedforward
feedback
이행
고려사항
Biz.
아키텍처
정보시스템 아키텍처
어플리케이션 아키텍처
데이터 아키텍처
정보시스템

□ SW아키텍처 주요 활동
1. 시스템 타당성 수립
(Making a business case for the system)
2. 중요한 아키텍처 요구사항 이해
(Understanding the architecturally significant requirements)
업무 분석 ???
아키텍처 설계
(focused)
상세 설계/코딩 ???
검토/테스팅 ???
6. 아키텍처 기반 시스템 구축과 테스트
(Implementing and testing the system based on the architecture)
7. 아키텍처에 따라 구축되었는지 확인
(Ensuring that the implementation conforms to the architecture)
- 7 -
3. 아키텍처 생성 또는 선택
(Creating or selecting the architecture)
4. 아키텍처 문서화와 의사소통
(Documenting and communicating the architecture)
5. 아키텍처 분석 또는 평가
(Analyzing or evaluating the architecture)
Software architecture in practice, 3rd edition, Len Bass, Paul Clements, 2013

□ SW아키텍처의 추가 고려 영역
○ Domain knowledge
• Link to business analysis, conceptual & logical modeling
○ Technology expertise
• Positioning among SA, AA, DA & TA
○ 상세 설계에서 SW 아키텍처 설계 적용 (conformance)
○ 구현에서 SW 아키텍처 적용 (conformance)
○ SW 아키텍처 준수 검증 방법은?
• Review, testing, …..
8

3. SW공학 프랙티스
□ No Silver Bullet – Essence and Accident in Software Engineering
○ 기술적이나 관리적인 측면에서 생산성, 신뢰성, 단순성 측면에서 획
기적인 개선을 가져올 혁신 (no silver bullet) 은 없다.
○ 권장 사항
• 자체 개발 대신 검증된 자산 재사용 (COTS, open sources, …)
• SW요구사항 확정을 위해 계획적으로 반복하는 빠른 prototyping
• Growing software organically (실행, 사용, 테스트하면서 기능 추가)
• 우수한 개념 설계자 (분석가, 아키텍트) 의 확보 및 양성
○ 권장 사항을 내재화하기 위한 원칙에 따른 일관된 노력 disciplined,
consistent effort 을 통해 획기적인 개선을 달성할 수 있다.
• 왕도는 없지만 길은 있다. There is no royal road, but there is a road.
- 9 -
The Mythical Man-Month, Frederick P. Brooks, Addison-Wesley, 1975/1995
Good Practices

□ 과거로부터 배우지 못하면 그것을 반복한다.
“Those who cannot remember the past are condemned to repeat it.” - George Santayana
○ 잘 못된 것은 반복하지 않고 (lessons learned)
○ 좋은 것을 공유하여 널리 적용한다 (best practices)
○ SW공학 프랙티스 (software engineering practices)
• 상대적으로 변하지 않는 (relatively timeless)
• 낡은 (aging)
- 10 -
A view of 20th and 21th century software engineering, Barry Boehm, University of Southern California University Park Campus, Los Angeles, ICSE ’06, May 20-28, 2006, Shanghai, China
Good Practices

- 11 -
베스트 프랙티스
BEST PRACTICES 년도
Project planning and management practices
Automated estimation tools 1973
Evolutionary delivery 1973
Measurement 1973
Productivity environments 1973
Risk management planning 1973
Requirements engineering practices
Change board 1978
Throwaway user interface prototyping 1975
JAD sessions 1985
Design practices
Information hiding 1972
Design for change 1979
Construction practices
Source code control 1980
Incremental integration 1979
Quality assurance practices
Branch-coverage testing 1979
Inspections (review) 1976
Process improvement
CMU SEI's SW CMM 1987
Software Engineering Process Groups 1989
Software Professional Development, Steve McConnell
Question
현재 새로 등장한 가장 조명을 받고, 유망한
SW공학 아이디어나 기법이 무엇입니까?
Answer
현재 새로운 유망한 아이디어는 없습니다. 그
것은 이미 오래 전부터 알려져 있는데 제대로
사용되지 않고 있을 뿐입니다.
- DAVID L. PARNAS
Good Practices

Top 10 Factors 평균
1. Inadequate requirements specification 4.5
2. Changes in requirements 4.3
3. Shortage of systems engineers 4.2
4. Shortage of software managers 4.1
5. Shortage of qualified project managers 4.1
6. Shortage of software engineers 3.9
7. Fixed price contact 3.8
8. Inadequate communications of systems integration 3.8
9. Insufficient experience as a team 3.6
10. Shortage of application domain experts 3.6
5 : Very Serious, 3 : Serious, 1: Not Serious CMU, SEI
□ 프로젝트 10대 실패 요인
업무 분석

□ SW개발에서 가장 어려운 영역은 무엇을 개발할 것인지를
정확하게 결정하는 것이다.
○ 사람, 기계 그리고 다른 시스템과 연동을 포함하여, 상세한 기술 (솔
루션) 요구사항을 확정하는 것이 가장 어렵다.
○ 진실은 고객도 무엇을 원하는지 모른다.
• 시스템 요구사항 정의 시 반복적으로 고객과 분석가가 작업을 진행하도
록 계획에 반영하여야 한다.
• 원하는 제품을 실제로 사용해 보기 전에는 SW엔지니어와 일하는 고객이
정확하고, 완벽한 요구사항을 정의하는 것은 거의 불가능하다.
○ Incremental development—grow, not build, software.
“No Silver Bullet: Essence and Accidents of Software Engineering” - Frederick Brooks in 1987 essay
□ 요구사항을 작성하는 것이 어려운 것이 아니고, 요구사항을
결정하는 것이 어렵다. - Boehm
- 13 -
The Mythical Man-Month, Frederick P. Brooks, Addison-Wesley, 1975/1995
업무 분석

□ 잘못된 요구사항은…
○ SW 개발 비용의 30 ~ 50%를 재작업에 사용 (Shull, et al. 2002; GAO 2004),
○ 요구사항 오류는 전체 재작업 비용의 70 ~ 85% (Leffingwell 1997)
- 14 -
Software Requirements, Third Edition, Karl Wiegers and Joy Beatty, Microsoft Press, 2013
Average Cost of Fixing Defects Based on When They’re Introduced and Detected
Time Detected
Time Introduced Requirements Architecture Construction System Test Post-Release
Requirements 1 3 5-10 10 10-100
Architecture ㅡ 1 10 15 25-100
Construction ㅡ ㅡ 1 10 10-25
Code Complete, 2nd edition
업무 분석
○ 이전 단계에서 발생한 결함의 수정 비용은 10배 정도 많은 재작업
비용 발생 (phase containment)

□ 요구사항 분석 공수
○ 소규모 프로젝트는 전체 공수의 15 ~ 18%를 요구공학에 사용
(Wiegers 1996), 적정 비율은 프로젝트 규모와 복잡성에 따라 다름.
• 통신사와 은행 산업의 15개 프로젝트에서 요구공학에 자원의 28%를 사
용한 프로젝트가 가장 성공적이었음 (Hofmann and Lehner 2001).
• 평균적으로 요구공학에 자원의 15.7%, 기간의 38.6%를 사용한다.
- 15 -
Software Requirements, Third Edition, Karl Wiegers and Joy Beatty, Microsoft Press, 2013
요구공학 공수 요구공학 수행 기간
빠른 프로젝트 14% 17%
늦은 프로젝트 7% 9%
Investing in requirements accelerates development
업무 분석
*. BA vs Developer = 1:6 (Package - COTS = 1:3)
• 유럽 연구에 의하면, 아래 표와 같이 더 납기가 빠른 프로젝트는 늦은
프로젝트 보다 요구사항에 더 많은 자원과 기간을 사용하였다. (Blackburn,
Scudder, and Van Wassenhove 1996).

□ 결함 발견과 수정 시간
○ 유능한 개발자도 10 LOC 마다 하나의 결함을 발생시킨다.
○ 결함이 늦게 발견될수록 결함을 발견하고 고치는 비용이 증가한다.
○ SW를 개발한 개발자가 결함을 가장 잘 발견하고, 고친다.
• 결함 데이터 분석을 통하여 엔지니어가 반복하는 동일한 실수를 최소화
• Disciplined methods와 특화된 교육 필요
- 16 -
Xerox 결함 발견과 수정 시간 (분)
3 25 32
1400
0
200
400
600
800
1000
1200
1400
1600
Code review Code inspection Unit test System test
PRACTICE
12-MONTH
ROI
36-MONTH
ROI
Formal code inspections 250% 1200%
Formal design inspections 350% 1000%
Long-range technology planning 100% 1000%
Cost and quality estimation tools 250% 1200%
Productivity measurements 150% 600%
Process assessments 150% 600%
Management training 120% 550%
Technical staff training 90% 550%
ROI in SW Practices (Caper Jones)
Winning the Software – An Executive Strategy, Watts S. Humphrey, Addison-Wesley, 2002
검토/테스팅

□ 결함 제거 전략
○ 100,000 LOC의 프로그램의 경우
• Testing (to test) – 문제의 증상 만을 밝혀준다
– 결함 발견 제거 23,400 시간, 많은 결함
• Inspection (to inspect and test)
– 결함 발견 제거 11,000 시간, 절반 이하의 결함
• Review (to review, inspect and test)
– 결함 발견 제거 6,000시간, 1/8 이하의 결함
- 17 -
결함 제거 전략
0
5
10
15
20
25
Testing Inspection Review
시간(1,000시간)
결함(100건)
6,000시간
1/8 이하
11,000시간
1/2 이하
23,000시간
많은 결함
검토/테스팅

□ 결함을 가진 모듈의 비율
○ A사의 제품 Release 후 3년 동안 수정한 686건의 결함 분포 현황
• 총 1,643 모듈 중 결함이 없는 모듈 81%
• 4%가 전체 결함의 48%를 차지
• 결함이 많은 모듈 72개를 5개월 만에 고쳐서 유지보수 비용을 ½로 줄
이고 적자에서 흑자로 전환
○ 결함의 약 80%는 20%의 모듈에서 발생하고, 50% 정도의 모듈은
오류가 없다 (Boehm).
- 18 -
결함을 가진 모듈의 비율
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
0 결함 1결함 2 결함 3 이상 결함
% 결함
% 모듈
81%
48%
4%
선택하여 집중

해야 하는 것 중, 할 수 있는 것부터 제대로 하고, 불가능한 것은 협상을 통
해 조정하고, 불필요한 것을 최소화
- 19 -
Requirements
Must
Can
Difficult
Impossible
Do
Don’t
Do
Don’t
Do
Don’t
Should be
Can
Difficult
Impossible
Do
Don’t
Do
Don’t
Do
Don’t
Nice to have
Can
Difficult
Impossible
Do
Don’t
Do
Don’t
Do
Don’t
 Product
기능 & 비기능
 Process
표준, 가이드, 프로세스
필수
선택
불필요
OK
Optimize
Minimize
20%
30%
50%
사악해지지 말 것
Don’t be a evil!
Who is first?
Customer vs User?
지원, OT
협상,
의사결정
X
OK
관리
OK
OK
협상,
의사결정
X
X
선택하여 집중

마무리하며
□ Software architect는…..
○ 적용하는 기술에 대한 전문 지식과 경험을 보유하고,
• Balancing among SA, AA?, DA & TA
○ 전체 프로젝트 관점에서 업무 분석을 주도할 업무 전문성을 갖고,
• 도메인 지식, 모델링 기술
○ 설계와 구현에 대한 의사결정을 주도한다.
○ 아키텍처 설계 의사결정이 상세 설계와 구현에서 제대로 적용되는
것을 보증하여야 한다.
• Review, inspection, testing, …
○ SW아키텍트는 기본에 충실하면서, 새로운 것을 받아 들이고, SW개
발을 실질적으로 주도해야 한다.
20

Any questions &
comments?
Software 공학 이야기 http://youngseolsan1.blogspot.kr/
프로젝트에서 SW아키텍트의 역할 http://www.slideshare.net/yokim31/sw-20140717
yokim31@daum.net 김 영온

Sw 아키텍처와 sw 공학

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (6)

Semelhante a Sw 아키텍처와 sw 공학

Semelhante a Sw 아키텍처와 sw 공학 (20)

Sw 아키텍처와 sw 공학