Wicked Problem

SW 요구사항 및 SW의 복잡성에 대한 이해를 주는 핵심 key work 중 하나.

A wicked problem is a problem that is difficult or impossible to solve because of incomplete, contradictory, and changing requirements that are often difficult to recognize. The use of the term "wicked" here has come to denote resistance to resolution, rather than evil.

Rittel and Webber's 1973 formulation of wicked problems in social policy planning specified ten characteristics:^[3][4]

1. There is no definitive formulation of a wicked problem.
2. Wicked problems have no stopping rule.
3. Solutions to wicked problems are not true-or-false, but good or bad.
4. There is no immediate and no ultimate test of a solution to a wicked problem.
5. Every solution to a wicked problem is a "one-shot operation"; because there is no opportunity to learn by trial and error, every attempt counts significantly.
6. Wicked problems do not have an enumerable (or an exhaustively describable) set of potential solutions, nor is there a well-described set of permissible operations that may be incorporated into the plan.
7. Every wicked problem is essentially unique.
8. Every wicked problem can be considered to be a symptom of another problem.
9. The existence of a discrepancy representing a wicked problem can be explained in numerous ways. The choice of explanation determines the nature of the problem's resolution.
10. The social planner has no right to be wrong (i.e., planners are liable for the consequences of the actions they generate).

Conklin later generalized the concept of problem wickedness to areas other than planning and policy.

The defining characteristics are:^[5]

1. The problem is not understood until after the formulation of a solution.
2. Wicked problems have no stopping rule.
3. Solutions to wicked problems are not right or wrong.
4. Every wicked problem is essentially novel and unique.
5. Every solution to a wicked problem is a 'one shot operation.'
6. Wicked problems have no given alternative solutions.

https://en.wikipedia.org/wiki/Wicked_problem

오늘을 '첫날'처럼 살았다… 아마존에 '둘째날'은 없다

오늘을 '첫날'처럼 살았다… 아마존에 '둘째날'은 없다

"당연한 것에 대한 의심, 외부 트렌드 수용과 빠른 의사결정이 성공 비결"
사내 연봉 1위는 3560만달러… 베조스 본인은 168만달러


http://biz.chosun.com/site/data/html_dir/2017/04/14/2017041400026.html

#아마존, #제프 베조스

SW아키텍처와 SW공학 프랙티스

7월 16일 KOSTA 제8회 SW아키텍트 대회 발표 자료
- back to the basic

SW아키텍처와 SW공학의 본질 이해를 돕기 위한 자료 정리 ---

http://www.slideshare.net/100000892759687/sw-sw-50626907?qid=571f1583-b4ab-4e5b-b9d7-9d27778836ba&v=qf1&b=&from_search=10

#Software Architecture, #소프트웨어 아키텍처, #SW공학, #SW아키텍처, #Software Engineering

ESSENCE at Google Zunich

SEMAT ESSENCE에 대한 Ivar의 Google의 발표 자료로서, Essence를 어떻게 사용할 수 있는지 설명해주는 좋은 자료...

A presentation on ESSENCE given by Ivar Jacobson and Ian Spence at Google in Zurich is now available as Google Tech Talk at http://www.youtube.com/watch?v=WNlERrVxYjs&list=UUtXKDgv1AVoG88PLl8nGXmw. The talk has three parts: 1) Welcome to the State Club (by Ivar Jacobson), 2) Welcome to the world of Practices (by Ian Spence), 3) Q&A.

The presentation slides are also availabe from IJI athttp://www.ivarjacobson.com/uploadedFiles/Pages/Knowledge_Centre/Resources/Presentations/Resources/SEMAT presentation at Google.pdf

#SEMAT #Essence

ICT 에 대한 잼나는 기사가 있어서.....

                                 ㈜미라위즈 송경모 대표·피터 드러커 연구가, 조선일보에서 scrap

컴퓨터가 잘 하는 것

①복잡 절차 간소화 ②신속한 정보 전달 ③내부 정보의 분석

경영자가 잘 해야 할 일

①중요한 의사 결정 ②내·외부 의사소통 ③외부 정보의 활용

알두스 마누티우스(Aldus Manutiu·1449~1515)의 이름을 기억하는 사람은 많지 않다. 이탈리아 르네상스 시절에 첨단 기술이었던 활판 인쇄술을 응용해 과거에 필사본으로만 돌던 그리스 고전을 대량 출판함으로써 거부가 된 인물이다.

구텐베르크를 튜링이나 폰 노이만에 비유한다면, 마누티우스는 빌 게이츠 정도에 해당하는 인물이다. 흔히 알려진 이탤릭체, 그리고 세미콜론이나 콤마를 처음 사용한 사람도 바로 그다.

그가 인쇄와 출판 산업을 정착시킨 이후 인쇄 기술은 점점 보편적인 지식이 되었다. 물론 세부적으로는 개량이 거듭되어 왔지만, 오늘날 인쇄 기술을 첨단 기술이라고 보는 사람은 아무도 없다.

드러커는 과거 문자와 서적의 발명에 이어, 구텐베르크 이후의 인쇄 혁명을 3차 정보 혁명, 20세기 후반의 컴퓨터와 인터넷 혁명을 4차 정보 혁명이라고 보았다. 이 4차 혁명은 아직도 진행 중이다. 그런 면에서 오늘날 컴퓨터 기술자들은 본질적으로 500년 전 인쇄 기술자와 같은 역할을 하고 있다.

기업들은 수시로 거액을 들여 IT 시스템에 투자한다. 우리나라는 특히 정보통신기술 강국이라는 명칭에 걸맞게 잘 구축된 IT 환경에 많은 기업이 자부심을 느끼는 것 같다. 그럼에도 IT 시스템 때문에 기업의 성과가 크게 개선됐다는 이야기는 잘 들어보지 못했다. 왜일까?

드러커에 의하면, 그 이유는 현재의 ICT(정보통신기술) 시스템이 경영자가 해야 할 중요한 일들을 아직 대체하지 못하기 때문이다. 컴퓨터가 아직 대체할 수 없는 경영자 본연의 과업은 의사 결정(decision-making), 의사소통(com munication), 외부 정보(outside in formation)라는 세 가지 영역에서 나타난다.

첫째, 컴퓨터는 의사 결정에 필요한 정보를 제공할 뿐, 가장 중요한 의사 결정은 결국 사람이 해야 한다. 컴퓨터는 기존의 잡다한 관리 업무와 지루한 절차를 간소화하는 데 혁혁한 공을 세웠다. 그러나 컴퓨터가 아무리 복잡한 업무를 잘 처리하더라도 정해진 조건들에 따른 일련의 흐름일 뿐 결코 의사 결정은 아니다. 경영자는 관행과 어긋나는 상황에 수시로 직면하는데, 그런 상황에서 컴퓨터는 스스로 의사 결정을 할 수 없다.

둘째, 경영자가 내부 인력이나 외부의 시장을 상대로 하는 의사소통은 IT 시스템이 해줄 수 없다. 왜냐하면 정보는 비트(bit)와 알고리즘(algorism)이지만, 의사소통은 지각(perception)이자 전체 상(configuration)이기 때문이다. IT 시스템은 통로는 될 수 있을지 몰라도, 정작 필요한 소통은 사람만 할 수 있다. 어느 사업부가 연 매출 10억원을 달성했다는 사실은 정보이지만, "겨우 그것밖에 못 했느냐" 또는 "대단한 일을 해냈구나" 하고 말할 수 있는 것은 철저하게 소통의 문제다. 소통이 사라지는 순간 조직은 시체가 된다.

셋째, 경영자의 큰 의사 결정은 항상 내부가 아니라 외부에서 나온다. 인터넷 정보 검색이 대중화되기 전에도 미국의 종합 유통업체 시어스로벅의 전설적인 CEO 우드는 침대 머리맡의 미국통계연감에서 인구의 변화와 이동 추세를 늘 연구하면서 새로운 고객을 발견했다. 인터넷이 보급되고 정보가 넘쳐나기 시작한 2000년대에 들어서조차, 기업가들은 외부에서 서브프라임 위기가 진행되고 있다는 사실을 눈치조차 채지 못했다.

오늘날 첨단 MIS(경영정보시스템)나 ERP(전사적 자원관리시스템)는 주로 내부의 정보를 다루며, 경영자에게 정작 필요한 외부 정보는 찾기 힘들다. 특히 기존 고객이 아닌 비고객(non-customer)에 대한 정보는 거의 없다. 비고객을 고객으로 전환시키는 것이야말로 경영자의 큰 역할임에도 말이다.

IT 붐이 한창이던 1998년에 드러커는 포브스(Forbes)지에서 말했다. "컴퓨터는 경영자가 내부의 비용에 치중하는 나쁜 습관을 가중시키고 있는 것 같다." "앞으로 10~15년 사이에 외부의 정보를 수집하는 일이 정보기술의 다음 과제로 등장할 것이다."

2005년에 드러커가 타계하고, 최근에 빅데이터(big data)가 각광을 받고 있다. 하지만 아직 외부 정보를 분석하는 걸음마 단계에 불과하다. 빅데이터가 경영자에게 의미 있는 외부 정보를 효과적으로 제공하는 수준으로 발전하려면 상당한 시간을 더 기다려야 할 것이다.

현재 ICT는 아직 T(기술)에 중점을 두고 있으며, 정작 I(정보)는 걸음마 단계이고, C(소통)는 요원할 뿐이다. 과거 인쇄 기술이 처음 등장한 뒤 서적의 지식이 기업 경영에 응용되기까지 오랜 시간이 걸렸던 것처럼 ICT가 경영자의 일을 상당 부분 대신해 주기 위해서는 아직도 많은 시간이 필요하다. 그때까지는 컴퓨터가 뭔가를 해줄 수 있을 것이라는 과도한 기대를 품기보다는, 경영자 본연의 일을 자각하고 정보의 홍수 속에서 중심을 잃지 말아야 한다.

Back to the basic

Back to the basic이라는 말이 자주 생각난다. 소중한 것 중요한 것이 나한테 또는 내 주위에 있는데 그것을 경시하거나 모르고 뭔지도 모르는 새로운 것을 찾아 헤메는 삶이 아니었는지 되돌아 본다. SW 개발을 잘하려면 아래의 기본적인 것을 점검해 보아야 하지 않을까? 당연하다면 당신의 조직은 비교적 성숙된 조직일 것이다.

1. 역량을 알고 계획 수립

2. 단계 말 재 견적

3. 제대로 알고 방법론 테일러링

4. 프로젝트 헌장  작성

5. 예방적 품질관리

6. 아키텍처 주도 프로젝트 진행

ü 검증된 아키텍처, 가이드, 템플릿

7. 전향적 위험관리

8. 변경 및 형상 관리

9. CMMI  level  1부터 하기

10. 분석 제대로 하기 (DDD, MDA, MDD, MDE와 뭐가 다른가?)

11. 이해당사자 관리

12. PMO, 아키텍트, QA의 고객은 개발자

13. 답을 내부에서 찾기 – 외부 사람은 조언자일 뿐

14. 신기술은 가치 (value) 를 먼저 생각하기

15. 항상 고객님 우선...

나에게 소중한 것이 있다는 것을 모르고 답을 외부에서 찾는 불나방같은 인생이 아니기를....

McConnell의 Code Complete, 2nd edition에서 추천하는 SW 공학 추천 도서

Software Project Survival Guide, Code Copmlete 등 실용적인 SW서적의 저자인 McConnell이 자신이 대표로 있는 Construx Softwrae사의 직원들에게 추천하는 도서 목록. 최신 도서는 빠져있지만 SW공학 관련 좋은 책들이 많이 포함되어 있습니다.

A Software Developer’s Reading Plan

Introductory Level

n   Adams, James L. Conceptual Blockbusting: A Guide to Better Ideas, 4th ed. Cambridge, Mass.: Perseus Publishing.

n   Bentley, Jon. Programming Pearls, 2d Ed. Reading, Mass.: Addison-Wesley, 2000.

n   Glass, Robert L. Facts and Fallacies of Software Engineering, Boston, Mass. Addison Wesley, 2003.

n   McConnell, Steve. Software Project Survival Guide. Redmond, WA: Microsoft Press, 1998.

n   McConnell, Steve. Code Complete, 2d Ed.. Redmond, WA: Microsoft Press, 2004.

Practitioner Level

n   Berczuk, Stephen P. and Brad Appleton. Software Configuration Management Patterns: Effective Teamwork, Practical Integration, Boston, Mass.: Addison Wesley, 2003.

n   Fowler, Martin. UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3d Ed, Boston, Mass.: Addison Wesley, 2003.

n   Glass, Robert L. Software Creativity, Reading, Mass.: Addison Wesley, 1995.

n   Kaner, Cem, Jack Falk, Hung Q. Nguyen. Testing Computer Software, 2d Ed., New York: John Wiley & Sons, 1999.

n   Larman, Craig. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process, 2d Ed., Englewood Cliffs, N.J. Prentice Hall, 2001.

n   McConnell, Steve. Rapid Development. Redmond, WA: Microsoft Press, 1996.

n   Wiegers, Karl. Software Requirements, 2d Ed. Redmond, WA: Microsoft Press, 2003.

n   “Manager’s Handbook for Software Development”, NASA Goddard Space  Flight Center. Downloadable from sel.gsfc.nasa.gov/website/documents/online244doc.htm.

Professional Level

n   Bass, Len, Paul Clements, and Rick Kazman. Software Architecture in Practice, Third Edition, Boston, Mass.: Addison Wesley, 2012.

n   Fowler, Martin. Refactoring: Improving the Design of Existing Code, Reading, Mass.: Addison Wesley, 1999.

n   Gamma, Erich, et al. Design Patterns, Reading, Mass.: Addison Wesley, 1995.

n   Gilb, Tom. Principles of Software Engineering Management. Wokingham, England: Addison-Wesley.

n   Maguire, Steve. Writing Solid Code. Redmond, WA: Microsoft Press, 1993.

n   Meyer, Bertrand. Object-Oriented Software Construction, 2d Ed. New York, Prentice Hall PTR, 1997.

n   “Software Measurement Guidebook”, NASA Goddard Space Flight Center, Available from sel.gsfc.nasa.gov/website/documents/online-doc.htm.