소프트웨어 공학 (Software Engineering ) 소프트웨어 공학 개요 문양세 강원대학교 IT 대학 컴퓨터과학전공

1. 소프트웨어 공학 (Software Engineering) 소프트웨어 공학 개요 문양세 강원대학교 IT대학 컴퓨터과학전공

2. In this chapter … 소프트웨어 공학 개요 • 소프트웨어 공학을 배우기에 앞서서, • 소프트웨어 및 소프트웨어 시스템에 대해서 정의해보고, • 소프트웨어 위기와 이에 따른 소프트웨어 공학의 필요성을 생각해 본다. • 또한, • 좋은 소프트웨어란 무엇인지 정의해보고, • 소프트웨어 공학에서 사용하는 주요 모형들을 살펴본 후, • 소프트웨어 개발에 영향을 미치는 요소들을 생각해 본다. • We will cover … • 소프트웨어와 시스템 • 소프트웨어 위기와 소프트웨어 공학 • 좋은 소프트웨어의 조건 • 소프트웨어 개발 프로세스 모형 • 소프트웨어 개발에 영향을 미치는 요소

3. In this chapter … 소프트웨어 공학 개요 소프트웨어와 시스템 소프트웨어 위기와 소프트웨어 공학 좋은 소프트웨어의 조건 소프트웨어 개발 프로세스 모형 소프트웨어 개발에 영향을 미치는 요소

4. 소프트웨어의 중요성 소프트웨어 공학 개요 • 실생활과 소프트웨어(컴퓨터) • 리니지? 스타크? 서든어택? 테일즈러너? 블소?  Oh, NO! • 일상사에서… 공과금 고지서, 항공기 예약/발권, 병원 기록, 초본/등본, 스마트폰, … • 학교로 보면… 수강 신청, 성적 입력 및 열람, 학사 관리, … • 정보 혁명의 토대는 컴퓨터이며, 그 잠재력은? 물론, 소프트웨어이다. • 소프트웨어는 과거 “편리” 추구에서 현재는 “생존”에 필수적 요소가 되어가고 있다. • 정치, 경제(1차, 2차 3차 산업 공통), 사회, 교육, 국방, 예술, 의료, 오락, … • 경쟁에서의 승리  제품의 적기 공급  제품?  소프트웨어 자체 혹은 내재가 기본… • 소프트웨어의 결함  생명과 재산에 치명적 결과 • 우주왕복선 폭발, 지진해일(쓰나미) 예보, … • Y2K 문제 (밀레니엄 버그)

5. 콜롬비아, 챌린저호 폭발 소프트웨어 공학 개요

6. Y2K? 소프트웨어 공학 개요

7. NEIS 오류 소프트웨어 공학 개요

8. NYSE 주식 거래 오류 소프트웨어 공학 개요

9. 소프트웨어의 정의 소프트웨어 공학 개요 • 소프트웨어 정의 • 협의: 프로그램 자체 • 광의: 프로그램 + 프로그램의 개발, 운용, 보수에 필요한 정보 일체(소프트웨어 생산 결과물 일체) • 소프트웨어? 프로그램? • 소프트웨어는 프로그램의 동적인 실체 • 프로그램은 형식 언어로 표현된 지적 노동의 결과물 • 제조업 vs. 서비스업(소프트웨어는 제작이 아니라 창조적 노력이 포함된 개발) • 닳아 없어지는 것이 아니라 소용없어 못쓰게 됨 • 논리적인 요소로 구성(유지보수가 어려움) • 소프트웨어 산업(2012년 국내 SW 시장은 250억달러 규모)

10. 소프트웨어 산업 (1/8) 소프트웨어 공학 개요

11. 소프트웨어 산업 (2/8) 소프트웨어 공학 개요

12. 소프트웨어 산업 (3/8) 소프트웨어 공학 개요

13. 소프트웨어 산업 (4/8) 소프트웨어 공학 개요

14. 소프트웨어 산업 (5/8) 소프트웨어 공학 개요

15. 소프트웨어 산업 (6/8) 소프트웨어 공학 개요

16. 소프트웨어 산업 (7/8) 소프트웨어 공학 개요

17. 소프트웨어 산업 (8/8) 소프트웨어 공학 개요

18. 소프트웨어의 특성 소프트웨어 공학 개요 비가시성(Invisibility) 테스트 가능(Testability) 복잡성(Complexity)  특히 제3자가 보았을 경우 변형성(Conformity)/변경성(Changeability) 장수(Longevity)  죽지 않는다. 단지 사라질 뿐이다. 복제 가능(Duplicability)  생명공학의 모태? 응용에 의존(Application dependability) 일반적으로, 몇 개 핵심 부품을 만들어 조립해 쓸 수가 없다.

19. 소프트웨어의 분류 (1/2) 소프트웨어 공학 개요 • 기능적 분류 • 응용 소프트웨어(Application Software): 증권 처리, 학사 관리 • 시스템 소프트웨어(System Software): 운영체제, DBMS, Compiler, … • 개발 과정에 따른 분류 • Prototype • Product: 상품화 이전이나 완성된 소프트웨어 • Package: 시험을 거쳐서 상품화된 소프트웨어(주문형 소프트웨어: 고객의 목적에 맞도록 패키지된 소프트웨어) • 하드웨어 환경에 따른 분류 • Mainframe • Parallel Processing or Distributed Processing • PC & Workstation • 모바일 디바이스  스마트폰

20. 소프트웨어의 분류 (2/2) 소프트웨어 공학 개요 • 적용 분야에 따른 분류 • 통신용, 프로그래밍 언어, 사용자 인터페이스, 데이터베이스, 분산처리, … • 문서 작성, 거래 처리, 개발 도구, 멀티미디어, … • 전자 정부, 전자 상거래, 가상 도서관, …

21. 소프트웨어 시스템 소프트웨어 공학 개요 • 유기적으로 상호 작용하는 객체들의 모임 • S/W는 독립적으로 존재하는 것이 아니라 컴퓨터를 기반으로 여러 시스템이 유기적인 관계를 맺고 있다. • 은행의 업무 전산화 예제: 현금 자동 인출기, 중앙 컴퓨터, 계좌 DB, 은행 업무 처리 절차,입출금 전표, 은행원, … • 특징 • 시너지 효과: 독립적인 의미를 갖지 않고, 통합되었을 때 의미를 가짐 • 역동적으로 발전, 변경 • 상충되는 요구와 이해 관계의 절충 (최적의 모범 답안이 아닌 절충안에 해당) 교통체계 • 소프트웨어 자체도 하나의 시스템임

22. 정보 시스템 (Information System) 소프트웨어 공학 개요 • 자료의 분류, 저장, 검색에 초점 • 데이터베이스를 대화식(interactive)으로 접근 • 조직의 문제 해결을 위한 도구 • 정보 시스템의 예제 • 항공권 예약 시스템 • 신용 카드 검색 서비스 • 뱅킹시스템 • 정보 시스템의 특징 • 대규모 자료를 관리하며, (일반적으로) 정적이 아님 • 시스템 분석과 유지보수가 중요함 • MIS (Management Information System, 경영 정보 시스템) [위키] • 운영, 관리, 의사결정을 위하여 정보를 제공하는 시스템 • DSS(Decision Support System), KDD(Knowledge Discovery in Database)

23. 제어 시스템 (Control System) 소프트웨어 공학 개요 • 사건을 감지하여 처리하고 자동적으로 보고 • 센서의 감지 (Ubiquitous Sensors) • 제어 기기의 상태 보고 • 운영자의 입력 처리 • 사용자 및 운영자 인터페이스 • 제어 시스템 예제 • 교통 제어 • 공정 제어  컨베이어 벨트 제어 • 수치 제어 • 의료 시스템  초음파 검사, 메디슨… • 무기 ( DARPA, FBI, … 테러 방지) • 항공 제어 • 재난, 방재 산업 산불 감지, 지진 감지

24. (오리지널) 탑재 시스템 (Embedded System) 소프트웨어 공학 개요 • 주된 기능이 계산이 아닌 시스템의 구성 요소의 일부(A system that is logically incorporated in a larger system whose primary function is not computation.) • 탑재 시스템 예제 • 전자 기계 장치, 공정 제어 시스템 • 비행기 유도, 스위칭 시스템(교환기 등) • 환자 감시 시스템, 레이다 추적 시스템 • 탑재 시스템 특징 • 대규모, 장기 사용, 테스트하기 어려움 • 인터페이스가 복잡, 비동기, 병렬, 분산 • 대규모 자료를 접근, 변경, 출력 • 실시간 제어인터페이스 • 엄격한 요구: 실시간 반응, 고장에 대한 안전, 신뢰성

25. (요즘의) Embedded System 소프트웨어 공학 개요 • 소형 디바이스에 들어가는 소프트웨어 • PDA, 휴대폰용 운영체제, 게임, 영상 재생, … • 소형 센서에 탑재되는 소프트웨어 • … • Embedded Software를 어떻게 배워~ • 프로그램(C, Java, Assembly, …)을 잘하고, • 운영체제(Windows, UNIX/Linux), DBMS를 잘 이해하는 등의 • 기본에 충실하면 쉽게 적응할 수 있어요… • 안드로이드를 배워 봅시다.

26. We are now … 소프트웨어 공학 개요 소프트웨어와 시스템 소프트웨어 위기와 소프트웨어 공학 좋은 소프트웨어의 조건 소프트웨어 개발 프로세스 모형 소프트웨어 개발에 영향을 미치는 요소

27. 소프트웨어 위기(Software Crisis) (1/2) 소프트웨어 공학 개요 위키를 봅시다.

28. 소프트웨어 위기(Software Crisis) (2/2) 소프트웨어 공학 개요 • 소프트웨어 공정의 문제점 • 비용 초과 (Cost Overruns) • 기간 지연 (Late Delivery) • 성능 저하 (Inadequate Performance) • 신뢰성 저하 (Unreliability) • 유지보수 불가능, 엄청난 유지보수 비용 (Prohibitive Maintenance Costs)  SMSC 경험 • 소프트웨어 위기: 소프트웨어의 요구(demand)와 그 공급(supply) 능력 간의 차이가 갈수록 심화되고 있음

29. 소프트웨어 개발의 또 다른 문제점 소프트웨어 공학 개요 • 개발 예산이 초과되고, 일정이 지연되는 경우가 많다. • 개발 일정과 비용 예측이 부정확하다. • 과거 프로젝트에 대한 경험이 잘 축적되지 않을 뿐 아니라, 과거 데이터가 현재에 잘 적용되지 않는 경우가 많다. • 프로그래머 개인 역량에 따라 소프트웨어 개발 성패가 좌우된다. • 프로그래머 개인의 능력과 경험이 중요하여, 작업의 정량적인 분석이 어렵다. • 잘 키운 슈퍼 프로그래머 하나가 열 … 안 부럽다. • 소프트웨어 품질을 평가하기가 어렵다. • 체계적인 시험이 없으면, 운영 중에 많은 오류가 발생한다. • 다른 공산품과 같은 불량품 관리, 품질 보증에 대한 확실한 정량적 개념이 없다. 다른 공산품의 경우, “불량률 0에 도전,” “무재해 100만시간 달성 목표”

30. 엔지니어링 원리의 발전 단계 소프트웨어 공학 개요 과 학 대량생산 엔지니어링 상업화 장인들의 기술 초창기에는 소수의 재능 있는 장인 개개인에 기술이 머물다가, 대량 생산의 필요에 의해 경험과 노하우를 교환하면서 상업화가 이루어지고, 상업화가 되면 자원 공급, 비용 등의 경제적 고려가 필요하며, 결국 과학이 동원되어 엔지니어링으로 발전한다.

31. 소프트웨어 공학 (1/2) 소프트웨어 공학 개요 • 복잡한 대규모 문제 해결을 위해서는 엔지니어링(공학) 접근법이 필요 • 요리를 잘하는 집안 식구가 음식점을 개업한다면…. 집안 식구가 먹기 위하여 만드는 음식과는 다른 접근법이 필요하다. 재료 구입, 조리 시간, 서빙, … • 개업한 음식점이 잘 되어서, 전국 체인점을 내려 한다면… 음식점 하나를 운영하는 것과는 다른 차원의 접근법이 필요하다. 재료 전달, 조리법 체계화/기계화, 훈련, …  한 사람이 프로그램을 작성할 때와 한 팀이 작성할 때, 한 부서가 작성할 때는 각기 다른 공학적 접근법이 필요하다.

32. 소프트웨어 공학 (2/2) 소프트웨어 공학 개요 • 소프트웨어 공학의 정의 • 질 좋은 소프트웨어를 경제적으로 생산하기 위하여 공학, 과학 및 수학적 원리와 방법을 적용하는 것 - Watts Humphrey, SEI • 소프트웨어의 개발, 운용, 유지보수 및 소멸에 대한 체계적인 접근 방법 - IEEE Computer Society • 품질, 효율, 비용, 인정에 관한 공학적인 접근 원리 - F. Brooks • 소프트웨어 공학의 목표 • 품질 좋은 소프트웨어를 • 최소의 비용으로 • 계획된 일정에 맞추어 개발한다.  품질(Quality), 생산성(Productivity)

33. 프로세스 패러다임 소프트웨어 공학에서 다루는 주제 (1/2) 소프트웨어 공학 개요 방법 도구 소프트웨어 공학 기술 방법 (method): 어떻게 만들 것인가? 도구 (tool): 무엇을 사용해 만들 것인가? 프로세스 (process): 어떤 과정/단계로 만들 것인가? 패러다임 (paradigm): 어떤 접근법/스타일을 사용할 것인가?

34. 소프트웨어 공학에서 다루는 주제 (2/2) 소프트웨어 공학 개요 XP(eXtreme Programming)란 단순성, 의사소통, 피드백, 용기 등 네 가지 가치를 매우 중요하게 생각하는 소프트웨어 개발방법론 중 하나로 “고객에게 최고의 가치를 가장 빨리”전달하도록 하는 것을 최고의 가치로 삼는다. 특히 요구사항 많거나 잦은 변화가 예상되는 위험부담이 큰 프로젝트를 하는 경우에 개발자가 소규모(10명 내외)이고 같은 공간을 사용하는 경우에 높은 효과를 볼 수 있다고 알려져 있다. 이 방법론의 대표적인 방법으로는 팀워크와 고객가치를 중시, 2인조 프로그래밍, 우선순위가 높은 일 지속적으로 처리하기, 자료를 따로 보관하지 않고 지속적으로 통합하기, 테스팅 적극적으로 이용하기, 코드 공동 소유하기, 고객 현장에 참여하기, 설계를 단순하게 하기 등이 있다.

35. We are now … 소프트웨어 공학 개요 소프트웨어와 시스템 소프트웨어 위기와 소프트웨어 공학 좋은 소프트웨어의 조건 소프트웨어 개발 프로세스 모형 소프트웨어 개발에 영향을 미치는 요소

36. 소프트웨어 품질 (Software Quality) (1/4) 소프트웨어 공학 개요 소프트웨어를 대하는 입장에 따라 품질에 대한 관점이 달라짐 발주자 사용자 기능의 정확성 이해 용이성 사용 용이성 일관된 통합 최소 비용 생산성 융통성 효율성 신뢰성 이식성 재사용성 유지보수성 상호 운용성 유지보수자

37. 소프트웨어 품질 (Software Quality) (2/4) 소프트웨어 공학 개요 • 정확성(Correctness) • 기능적으로 맞게 동작하는가, 표준에 적합한가 • 요구 분석서의 기능과 일치하는지 점검 • 신뢰성(Reliability) • 소프트웨어가 주어진 기간 동안 바르게 작동할 확률 • 오류 발생 확률에 반비례 • 정확성 제공하기 위한 필요조건 • 강인성(Robustness) • 요구 명세에 표시하지 않은 상황(오류 입력)에서도 제대로 작동하는 성질

38. 소프트웨어 품질 (Software Quality) (3/4) 소프트웨어 공학 개요 • 성능(Performance) • 수행 속도, 데이터/트랜잭션 처리량 • 알고리즘의 시간 복잡도 • 시뮬레이션, 스트레스 테스트 • 사용 용이성(Usability) • 시스템을 친근하게 느낄 수 있는 성질 • 사용 대상에 따라 달라질 수 있음 • 사용자 인터페이스, Human factor • 유지보수성(Maintainability) • 보수성: 정해진 기간에 소프트웨어 결함을 해결할 수 있는 성질 • 진화성: 잠재적 발전 가능성 (추가 요구사항에 따라 기능이 진화할 수 있어야 함)

39. 소프트웨어 품질 (Software Quality) (4/4) 소프트웨어 공학 개요 • 재사용성(Reusability) • 소프트웨어 부품(라이브러리, 클래스 등)의 성질 • 확장 가능성 – openness • 적응성 – adaptability • 이용 용이성 - closeness

40. 소프트웨어 품질의 구분 소프트웨어 공학 개요 • 프로덕트 품질 • 소프트웨어 자체의 품질을 의미한다. • 수돗물 비교: 수돗물 자체의 품질, 즉, 맛, 색깔, 유해성분, …  일반적으로 생각하는 품질을 의미한다. • 프로세스 품질 • 소프트웨어를 개발하는 과정의 품질을 의미한다. • 수돗물 비교: 수돗물을 전달하는 파이프의 청결도, 집수장의 위치, … • 과정의 품질이 좋지 않으면 궁극적인 프로덕트의 품질이 나쁘다는 인식에서 출발한다. • 프로세스의 품질이 높으면 S/W에 내재된 잠재적인 오류를 줄일 수 있다. • 과거에는 프로덕트 품질을 중시했으나, 현재는 모든 분야에 있어서 프로세스의 품질을 중시하고 있다. (ISO 인증).

41. 프로덕트 품질 소프트웨어 공학 개요 • 소프트웨어 자체의 품질을 의미하나… • 소프트웨어를 대하는 사람의 입장에 따라서 품질의 정의가 달라진다. • 구매자: 외부로 드러나는 품질요소(external characteristics)를 중시한다.(예를 들어, 오류 횟수, 판매 횟수 등) • 유지보수 엔지니어: 제조 과정에 내재된 내부 특성(internal characteristics)를 중시한다. (예를 들어, 함수 재사용이 용이한가?)

42. 프로세스 품질 (1/2) 소프트웨어 공학 개요 • 개발하는 과정이 소프트웨어 품질에 많은 영향을 준다는 주장 • 개발 및 유지 보수하는 프로세스의 품질이 프로덕트 자체의 품질 못지 않게 중요하다는 입장 • 향상 방안 • 특정 오류가 언제 어디서 발견되는가? • 어떻게 하면 개발 과정에 오류를 조기에 발견할 수 있는가? • 어떻게 하면 오류에 대한 내성이 있는 시스템, 즉 오류가 소프트웨어를 정지시키는 확률이 적은 시스템으로 만들 수 있는가? • 프로세스가 좋은 품질을 보장하는 더 효율적이며 효과적인 다른 방법이 있는가? • (일본의 농산품 관리 방법)

43. 프로세스 품질 (2/2) 소프트웨어 공학 개요

44. 소프트웨어 생산성 (Productivity) 소프트웨어 공학 개요 • 생산 과정(process)에 크게 영향 • Process improvement • 개발 경험의 성숙도에 의해 좌우 • CMM(Capability Maturity Model): Level 1~5 • 생산성에 영향을 미치는 요소 • 프로그래머의 능력 • 팀 의사 전달 • 제품의 복잡도 • 기술 수준 • 관리 기술

45. We are now … 소프트웨어 공학 개요 소프트웨어와 시스템 소프트웨어 위기와 소프트웨어 공학 좋은 소프트웨어의 조건 소프트웨어 개발 프로세스 모형 소프트웨어 개발에 영향을 미치는 요소

46. 소프트웨어 프로세스 모형 소프트웨어 공학 개요 소프트웨어 라이프 사이클 개념화 단계 유아 및 성장기 성년기 (제품으로서) 유아기 개발 전 개발 후 개발 단계

47. 건축 프로세스 소프트웨어 공학 개요 (요구 분석)집을 짓기 위해서는 건축설계사가 집주인과 만나 어떤 집을 원하는지 들어본다. (구조 설계)건축설계사는 집주인의 요구를 반영하여 층별 배치도와 개략적인 조감도를 그린다. (상세 설계)평면도, 측면도를 필요한 자세한 설계 도면을 준비한다. (구현(코딩))설계가 끝나면 시공단계에 들어가서 실제로 집을 짓는다. (테스트)집을 지은 후에는 전등이 잘 켜지는지, 난방이 잘되는지 등의 각종 점검을 수행한다. (유지보수)집이 완성된 후에는 하자에 대한 유지보수를 수행한다.

48. 소프트웨어 프로세스 모형 소프트웨어 공학 개요 • 개발 프로세스: 개발 과정을 체계적으로 정리한 과정 • 실정에 맞는 개발 팀의 고유한 모형의 정립 필요 • 소프트웨어 개발에 필요한 작업 • 요구 분석과 정의 • 시스템 설계 ( 건축의 구조 설계에 해당) • 프로그램 설계 ( 건축의 상세 설계에 해당) • 프로그램의 작성(구현) • 테스트(단위 테스트, 통합 테스트, 시스템 테스트) • 시스템 설치 • 유지보수

49. 대표적인 소프트웨어 프로세스 모형 소프트웨어 공학 개요 폭포수 모형 (Waterfall Model) 프로토타이핑 모형 (Prototyping Model) 점증적 모형 (Incremental Model) 나선형 모형 (Spiral Model) V 모형 (V Model)

50. 폭포수 모형 (Waterfall Model) (1/3) 소프트웨어 공학 개요