Software & Software Engineering · 2018-03-11 · CSE4006: Software Engineering - Scott Lee Software 정의: 1. 실행 시 원하는 특징, 기능, 성능을 제공하는 지침

CSE4006: Software Engineering - Scott Lee

Scott Uk-Jin Lee

Division of Computer Science, College of Computing Hanyang University ERICA Campus

1st Semester 2018

Software & Software Engineering

CSE4006 Software Engineering


Software• 세계에서 가장 중요한 단일 기술 • 모든 분야에서 사용/적용 :

- 교통, 의료, 통신, 군사, 산업, 엔터테인먼트, 교육, 사무실, 가정, …

Section

2


Software• 우리 시대의 가장 중요한 제품인 정보 제공

- 지정 컨텍스트에 적합하도록 데이터 변환 - 비지니스 정보 관리를 통한 경쟁력 강화

- 전세계 정보 (인터넷)에 대한 게이트웨이 제공 - 정보 수집 수단 제공

Section

3


Software

• 지난 반 세기 동안의 큰 변화 - 하드웨어의 발전 : 성능 향상, 컴퓨터 아키텍처의 심오한 변화, 메모리 및 저장 용량의 방대한 증가, 다양한 I/O 옵션 사용 가능

➡ 보다 정교하고 복잡한 소프트웨어 개발 ➡ 소프트웨어 산업이 경제의 지배적 요소로 변화 ➡ 고독한 프로그래머 → 소프트웨어 전문가 팀

Section

4


Software• 소프트웨어와 이를 개발하는데 있어 변함없는 의문 :

- 왜 소프트웨어 개발은 오래걸리나요? - 왜 소프트웨어 개발은 비싼가요? - 왜 소프트웨어 납품 전 모든 오류를 찾을 수 없는 건가요? - 왜 기존 소프트웨어 유지보수에 많은 돈과 시간을 소비해야 하나요? - 왜 소프트웨어 개발 및 유지보수의 진행사항 측정은 매우 어렵나요? - 왜…, 왜…, 왜 … ???

➡ 소프트웨어 공학 실무의 채택/적용 필요!

Section

5


Software정의 :

1. 실행 시 원하는 특징, 기능, 성능을 제공하는 지침 (프로그램)

2. 프로그램이 정보를 적절하게 조작할 수 있게하는 자료구조

3. 프로그램의 운영 및 사용을 설명하는 하드 카피 및 가상 양식의 설명 정보

• 위와 같은 (혹은 교과서 및 사전에서 찾은) 정의가 소프트웨어가 무엇인지에 대해서 더 잘 이해할 수 있게 하나요?

Section

6


Hardware vs. Software

• 실패 곡선

• 소프트웨어는 물리적인것이 아니라 논리적인것 ➡ 마모되지 않지만 나빠짐

Section

7


Software는 …• 구성(configuration)을 생성하는 항목 또는 객체의 집합

- 프로그램, 문서, 데이터, …

- \ ➡ 프로그램 + 프로그램의 개발, 운영, 유지보수를 위하여 필요한 전체 정보

- 무형 - 제조되지 않으며 개발/설계 됨 - 정교하고 복잡함 - 맞춤식 구축

Section

8


Software 응용 도메인

• 시스템 소프트웨어 • 응용 소프트웨어 • 엔지니어링 / 과학적 소프트웨어 • 임베디드 소프트웨어 • 제품 라인 소프트웨어 • 웹 / 모바일 애플리케이션 • 인공지능 (AI) 소프트웨어

Section

9


Software: 새로운 도전

• 사물 인터넷 (IoT) • 빅데이터 • 이동성 (웨어러블) • 보안

• 추가적으로: - 교육, 레거시, 라이센스, 통합, …

Section

10


신흥 Software 기술 및 동향Section

11


Legacy Software• 수십년 전 개발, 핵심 비지니스 기능 지원, 비지니스에 없어서는 안됨

- 사용기간 및 비지니스 중요도로 특징 지음

• 비지니스 요구사항 및 컴퓨팅 플랫폼의 변화에 맞게 지속적으로 수정

• 아래의 경우 진화해야 함: - 영 컴퓨팅 환경 / 기술의 요구를 충족해야 할때 - 새로운 비지니스 요구사항을 구현할 수 있도록 향상되어야 할때 - 다른 (더 현대적) 시스템 / 데이터베이스와 상호운영이 필요할때 - 진화하는 컴퓨팅환경에 다시 사용될 수 있도록 재설계 되어야 할때

Section

12


Software Engineering

1. 역사

2. 정의 및 목적

3. 소프트웨어 유지 보수

4. 명세 및 설계의 중요성

5. 팀 프로그래밍의 개념

6. 계층구조와 프로세스

7. 실무 및 오해

Section

13


Software Engineering: History소프트웨어 위기 • 소프트웨어 개발 프로젝트의 문제점

- 비용 초과, 기간 지연, 성능 저하, 불안정성 - 유지 보수 불가능 / 매우 큰 비용 필요

• 수요와 공급 능력간의 차이가 계속 커짐

Section

14


Software Engineering: History

• 1967년 - NATO 그룹은 “소프트웨어 공학”이라는 용어 만들어 냄

• 1968년 - NATO 회의에서 “소프트웨어 공학”은 소프트웨어 위기 문제를 해결하기 위하여 확립된 공학 분야의 철학과 패러다임을 사용하여 해야한다고 결론지음

Section

15


Software Engineering: Definition정의 : • 고품질의 소프트웨어를 경제적으로 생산하기 위하여 공학, 과학, 수학적 원리 및 방법론을 적용하는 것 [Humphrey, SEI]

• 소프트웨어 개발, 운영, 유지보수, 파괴에 대한 체계적인 접근방식 [IEEE Computer Society]

• 실제 기계에서 안정적이고 효과적으로 작동하는 소프트웨어를 경제적으로 개발, 운영, 유지보수하기 위한 건전(sound)한 공학 원칙의 수립 및 사용 [Stephen Schach]

Section

16


Software Engineering: Definition

• 소프트웨어 공학의 출현 이유 - 소프트웨어 개발 비용, 기간, 노력 예측에 있어 경영자의 무능력 - 저품질의 소프트웨어 - 유지보수의 중요성 증가 - 하드웨어 및 소프트웨어 기술의 발전 - 소프트웨어에 대한 수요 증가

Section

17


Software Engineering: Objectives

품질: • 품질에 대한 견해는 관점에 따라 다름

Section

18


Software Engineering: Objectives생산성: • 생산 공정에 큰 영향을 미침

- 프로세스 개선 • 개발 경험의 성숙에 달려 있음

- CMM (Capability Maturity Model) Level 1~5

• 생산성 향상의 요인 - 프로그래머의 능력 - 팀 커뮤니케이션 - 제품의 복잡성 - 기술 수준 - 관리 기술

Section

19


Software Engineering: Facts

• 소프트웨어에 소비되는 노동의 대부분은 현 시스템 유지보수 • 오류 발견이 늦어질 수록 수정 비용도 높아짐 • 많은 오류들이 부정확한 요구사항 정의에서 발생 • 프로그래밍 오류가 디자인 오류보다 덜 심각함 • 지연된 프로젝트에 더 많은 인력을 투입하면 프로젝트 완료가 더욱 늦어짐

• 소프트웨어가 제대로 유지보수 되지 않으면 복잡해 짐

Section

20


Software Engineering: MaintenanceSection

21



명세 및 설계의 중요성:• 오류 감지 및 수정 비용

Section

22


Software Engineering팀 프로그래밍:• 다중 버전 소프트웨어에 대한 다중 인력 구성

- 프로그래밍: 개인활동 - 소프트웨어 공학: 팀 활동

• 프로그래밍의 초기 단계 - 문제가 잘 정의되어 있음 - 대부분 과학적 응용 - 분야 전문가들이 작성 - 사용자 = 프로그래머 = 관리자

• 사용자와 프로그래머 분리 - 사용자: 문제 (작업) 명시 - 프로그래머: 해석 후 코드 변환

Section

23



소프트웨어 위기를 위한 솔루션:• 관리 기법 • 팀 구성

- 수석 프로그래머 팀 - 민주적, 계층적 팀

• 더 낳은 언어 및 도구 • 표준 제정

➡ 공학적 접근법 적용

Section

24


Software Engineering소규모 프로그래밍:• 좋은 프로그래밍 기술 • 프로그래밍 언어에 능통 • 데이터 구조와 알고리즘에 능통

대규모 프로그래밍:• 의사소통 능력 • 설계 접근법 (예, 시스템 추상화)가 중요

- 하향식 설계, 분할 및 정복 합패러다임, 컴포넌트 기반 통합 - 모호한 요구사항의 정확한 명세 및 해석 - 모델링이 필요 - 일정에 따라 업무를 관리하는 능력

Section

25


Software Engineering TopicsSection

26

Field Case Metaphor

Tool automated systemdesign tool,

programming tool, testing tool

cooking utensils (frying pan, pressure

cooker, oven, …

Methodtechniques or

procedures used in software construction

structural analysis / design,

OO analysis / design

way to cook (grilled, steamed,

smoked, …)

Process order of tasks using tools and techniques

unified process, agile / extreme programming

cooking order (recipe)

Paradigm approach, style

structural methodology, OO methodology, component-based methodology, SoA

different type / style of food

(Korean, Chinese, fusion, …)


Software Engineering Layers

Quality Focus (품질 중점):• 모든 공학적 접근방식은 품질에 대한 조직의 헌신에 달려 있음

Process (프로세스) - 다음을 위한 기초를 형성:• 소프트웨어 프로젝트 관리 제어 • 기술 / 방법 적용의 상황 수립 • work product (모델, 문서, 데이터, 보고서, 등) 생성 • 이정표 설립 • 품질 보장 • 변화를 적절하게 관리

Section

27


Software Engineering LayersMethods (방법) - 소프트웨어 작성을 위한 기술적 방법 : • 각 기술 분야를 관리하는 기본 원칙들에 의존

• 소통, 요구사항 분석, 설계 모델링, 프로그램 구축, 테스트 및 지원

Tools (도구) - 다음을 제공:• 프로세스 및 방법에 대한 자동 / 반자동 지원 • 도구 통합

→ 컴퓨터 지원 소프트웨어 공학

Section

28


Software Process

일반적 프로세스 프레임워크:

1. 소통 (communication)

2. 기획 (planning)

3. 모델링 (modeling)

4. 구축 (construction)

5. 배포 (deployment)

Section

29


Software Processumbrella activities:• 소프트웨어 공학 프레임워크 활동 보완 • 프로젝트 전반에 걸쳐 적용되어 소프트웨어 개발 팀이 진행, 품질, 변경, 위험 등을 관리 및 제어할 수 있도록 지원

1. 소프트웨어 프로젝트 추적 및 제어

2. 위험(risk) 관리 3. 소프트웨어 품질 보장

4. 기술 리뷰 5. 측정

6. 소프트웨어 구성 (configuration) 관리 7. 재사용 관리

8. 작업 제품 준비 및 생산

Section

30


Software Development Framework

• 소프트웨어 개발 생명 주기 (Software Development Life Cycle: SDLC) • 소프트웨어 개발 프로세스

Section

31


Software Engineering Practice

업무:• 소프트웨어 개발 계획 및 구현 시 고려할 개념, 원칙, 방법 및 도구 집합

• 특정 세부 사항을 나타냄

• 소프트웨어공합 업부의 핵심 (essence of software engineering practice) [George Polya - 1945]

1. 문제 이해 (소통 및 분석)

2. 솔루션 계획 (모델링 및 설계)

3. 계획 수행 (코드 생성)

4. 정확도 (테스트 및 품질)에 대한 결과 검토

Section

32



1. 문제 이해:• 이해 관계자는 누구인가 ?

• 미지의 부분은 ? - 문제를 올바르게 해결하기 위하여 필요한 데이터 및 기능

• 문제가 분류될 수 있는가 ? - 이해가 쉬운 작은 문제들로 나타낼수 있는가? (Divide & Conquer)

• 문제를 시각적으로 표현할 수 있는가 ? - 분석 모델 생성이 가능한가?

Section

33


Software Engineering Practice2. 솔루션 계획:• 이전에도 비슷한 문제를 본적이 있는가 ?

- 잠재적 솔루션에서 인식할 수 있는 패턴이 있는가 ?

- 필요 데이터 및 기능을 구현하는 기존 소프트웨어가 있는가 ?

• 비슷한 문제가 해결되었는가 ? - 그렇다면 솔루션은 재사용 가능한가 ?

• 하위 문제가 정의될 수 있는가 ? - 그렇다면 하위 문제에 대하여 바로 사용가능한 솔루션이 있는가 ?

• 효과적 구현을 유도하는 방식으로 솔루션을 표현할 수 있는가 ? - 디자인 모델 생성이 가능한가 ?

Section

34



3. 계획 수행:• 솔루션이 계획을 준수하는가 ?

• 소스 코드가 디자인 모델로 추적 가능한가 ?

• 솔루션의 각 구성요소가 정확한가 ? - 디자인과 코드가 검토되었는가 ? - 알고리즘에 정확성 증명이 적용되었는가?

Section

35



4. 정확도에 대한 결과 검토:• 솔루션의 각 구성요소를 테스트할 수 있는가 ?

• 합리적인 테스트 전략은 구현되어 있는가 ?

• 솔루션이 필요 데이터 및 기능을 준수하는 결과를 산출하는가 ?

• 소프트웨어가 모든 이해관계자의 요구사항에 대하여 검증되었는가 ?

Section

36


Software Development FactorsSection

37



일반적 원칙:

1. 존재의 이유 - 소프트웨어 시스템은 사용자에게 가치를 제공

2. 간단하게! (KISS - Keep It Simple Stupid!)

3. 비전유지 (프로젝트 및 제품)

4. 내가 생산하는 제품을 다른 이들이 소비

5. 미래를 대비하라 (가변성 및 확장성)

6. 재사용을 미리 계획하라

7. 생각하라!

Section

38


Software Engineering: Myth

경영/관리 측면 :• 모든 소프트웨어 개발에 필요한 표준 및 절차를 가지고 있음 • 일정이 뒤쳐지면 더 많은 프로그래머를 고용하여 따라잡으면 됨 • 소프트웨어 프로젝트를 제 3자에게 아웃소싱 하기로 결정했다면, 그냥 긴장 풀고 편히 기다리면 됨

고객 측면 :• 목표에 관한 일반적인 진술만으로 프로그램 작성을 시작 가능 -필요 세부 정보는 나중에 제공하면 됨

• 소프트웨어 요구사항은 지속적으로 변하지만 소프트웨어는 유연하기 때문에 변경을 쉽게 수용할 수 있음

Section

39


Software Engineering: Myth

개발자 측면 :• 프로그램을 작성하고 작동하게 하면 모든 일은 끝난다 • 프로그램을 실행하기 전까지 품질을 평가할 방법이 없다 • 성공적인 프로젝트를 위한 유일한 산출물은 작동하는 프로그램이다

• 소프트웨어 엔지니어링은 방대한 양의 불필요한 문서를 작성하게 하여 프로젝트 진행 속도를 는춘다

Section

40

Documents

Software & Software Engineering · 2018-03-11 · CSE4006: Software Engineering - Scott Lee Software 정의: 1. 실행 시 원하는 특징, 기능, 성능을 제공하는 지침