소프트웨어 공학 (Software Engineering)

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

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

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

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

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

Y2K? 소프트웨어 공학 개요

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

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

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

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

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

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

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

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

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

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

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

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

We are now … 소프트웨어와 시스템 소프트웨어 위기와 소프트웨어 공학 좋은 소프트웨어의 조건

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

소프트웨어 위기(Software Crisis) (2/2)
소프트웨어 공학 개요 소프트웨어 공정의 문제점 비용 초과 (Cost Overruns) 기간 지연 (Late Delivery) 성능 저하 (Inadequate Performance) 신뢰성 저하 (Unreliability) 유지보수 불가능, 엄청난 유지보수 비용 (Prohibitive Maintenance Costs)  SMSC 경험 소프트웨어 위기: 소프트웨어의 요구(demand)와 그 공급(supply) 능력 간의 차이가 갈수록 심화되고 있음 1965 – 1985 Increase Rate at 1983 Increase in Demand (요구의 증가) 100 times 12% Productivity (생산성) 2 times 4% Manpower Supply (인력 공급) 10 times

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

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

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

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

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

소프트웨어 공학에서 다루는 주제 (2/2) 분 야 의 미 사 례 요리 비유 방법 (method)
소프트웨어 공학 개요 분 야 의 미 사 례 요리 비유 방법 (method) 소프트웨어 제작에 사용하는 기법이나 절차 구조적 분석/설계 방법 객체지향 분석/설계 방법 익히는 방법 (구이, 찜, 훈제 등) 도구 (tool) 자동화된 시스템 설계 도구 프로그래밍 도구 테스트 도구 요리 도구 (프라이팬, 압력 솥, 오븐 등) 프로세스 (process) 도구와 기법을 사용하여 작업하는 순서 eXtreme Programming 조리 순서 패러다임(paradigm) 접근 방법, 스타일 구조적 방법론 객체지향 방법론 음식 스타일 (한식, 일식, 중식, 퓨전 등) XP(eXtreme Programming)란 단순성, 의사소통, 피드백, 용기 등 네 가지 가치를 매우 중요하게 생각하는 소프트웨어 개발방법론 중 하나로 “고객에게 최고의 가치를 가장 빨리” 전달하도록 하는 것을 최고의 가치로 삼는다. 특히 요구사항 많거나 잦은 변화가 예상되는 위험부담이 큰 프로젝트를 하는 경우에 개발자가 소규모(10명 내외)이고 같은 공간을 사용하는 경우에 높은 효과를 볼 수 있다고 알려져 있다. 이 방법론의 대표적인 방법으로는 팀워크와 고객가치를 중시, 2인조 프로그래밍, 우선순위가 높은 일 지속적으로 처리하기, 자료를 따로 보관하지 않고 지속적으로 통합하기, 테스팅 적극적으로 이용하기, 코드 공동 소유하기, 고객 현장에 참여하기, 설계를 단순하게 하기 등이 있다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

소프트웨어 공학 개요 계 획 요구 분석 설 계 구 현 시 험 인수설치

소프트웨어 공학 개요

소프트웨어 공학 개요 1970년대 소개 항공 방위 소프트웨어 개발 경험으로 습득 각 단계가 다음 단계 시작 전에 끝나야 함 순서적 - 각 단계 사이에 중복이나 상호작용이 없음 각 단계의 결과는 다음 단계가 시작 되기 전에 점검 바로 이전 단계로의 피드백만이 가능함 단순하거나 응용 분야를 잘 알고 있는 경우 적합 한 번의 과정, 비전문가가 사용할 시스템 개발에 적합 결과물(deliverable) 정의가 중요

폭포수 모형의 프로세스 및 결과물 요약 P 계획 R 요구 분석 D 설계 문제정의 타당성 분석 비용, 일정예측 DFD 자료사전
소프트웨어 공학 개요 P 계획 R 요구 분석 D 설계 문제정의 타당성 분석 비용, 일정예측 DFD 자료사전 소단위명세서 시스템구조설계 프로그램설계 UI 설계 구조설계서 상세설계서 계획서 요구 분석서 I 구현 T 시험 A 인수/설치 통합시험 기능시험 성능시험 프로그래밍 단위테스트 통합된 프로그램 설치된 소프트웨어 프로그램 설치 인수 시험 (활동) (결과물)

폭포수 모형 – 계획 (Planning) 소프트웨어 공학 개요 문제의 실현 가능성을 타진한다. (feasibility study)  영구 기관(엔진)을 만들 수는 없다?, 물로 가는 자동차는? 개발하고자 하는 시스템의 성격을 파악하여 비용과 기간을 예측한다.  예측을 잘못하면 소위 “열심히 하고 욕먹는 결과”를 초래한다. 개발 방법과 각 단계에 필요한 자원을 결정한다.  좋은 도구를 사용할 경우, 인력을 크게 줄일 수도 있다. 열역학 법칙을 깬 세계 최초 영구기관?

폭포수 모형 – 요구 분석 (Requirement Analysis)
소프트웨어 공학 개요 개발을 의뢰한 사용자(일반인, 운영자, …) 요구나 주어진 문제를 정확히 분석하고 이해하는 과정이다. 발주자와 개발자가 요구 분석 사항에 동의하여야 다음 단계 진행이 가능하다. 소프트웨어가 어떤 품질을 만족해야 하는지 결정한다. 소프트웨어가 어떤 기능을 제공해야 하는지 결정한다. ( 세부적으로 어떻게 구현할 지는 추후 설계 단계에서 생각한다.) 요구분석서는 사용자와 개발자의 의사 소통 수단으로서, 정확하고 간결하고 완벽하며 이해하기 쉽고 일관성을 유지하도록 작성해야 한다.

폭포수 모형 – 설계 (Design) 시스템 구조 설계 프로그램 설계 사용자 인터페이스 설계
소프트웨어 공학 개요 시스템 구조 설계 소프트웨어 구조를 어떻게 가져갈 것인가? 일반적으로, 소프트웨어 모듈을 정의하고, 각 모듈간의 관계를 정의한다. 프로그램 설계 각 모듈내의 알고리즘을 설계한다. 모듈간의 인터페이스 방법을 설계한다. 사용자 인터페이스 설계 입력 형식(메뉴, 음성입력 등)을 결정하고 설계한다. 출력 형식(화면, 소리 등)을 결정하고 설계한다.

(Inter/eXter Process Communication)
폭포수 모형 – 설계 (시스템 구조 설계 예제) 소프트웨어 공학 개요 SANTA PDSN/IWF GGSN LME SMSC IPLS AAA JUICE WISE INBH NMS WINGS IXPC (Inter/eXter Process Communication) MS LME SMSC IPLS AAA JUICE WISE INBH NMS WINGS SANTA 메시지 송수신 페이징 처리 과금 처리 기타 연동 단말 정보 처리 정보 관리 및 공유 데이터베이스 메시지 파일 메시지 정보 관리 제어 및 호처리 운용 및 유지보수 운용자 정합 데이터베이스 관리 메시지 상태 관리 통계/장애/상태 관리 Graphical UI 파일(메시지) 관리 호처리 제어 운용/형상/구성 관리 Textual UI

폭포수 모형 – 설계 (사용자 인터페이스 설계 예제)
소프트웨어 공학 개요 GUI(Graphical User Interface): Java 기반으로 이식성 높고 편리한 환경 제공 TUI(Textual User Interface): 원격지에서 MML을 사용한 운영 기능 제공 명령어 입출력 환경

폭포수 모형 – 구현 (Implementation)
소프트웨어 공학 개요 미리 정해진 모듈 설계에 따라 프로그래밍, 즉 코딩을 수행한다. 코딩된 각 모듈은 테스트의 기본 단위이다.  모듈 테스트는 테스트 단계가 아닌 구현 단계로 보기도 한다. 코딩 작업 자체도 개발회사 전체적인 표준이 있어야 한다. 헤더 주석, 변수 작명 규칙, 모듈의 최소 및 최대 크기 등 모듈 테스트도 회사 전체의 표준이 있어야 한다.  테스트 계획서, Code Inspection, …

폭포수 모형 – 구현 (모듈 테스트의 예제) 소프트웨어 공학 개요

폭포수 모형 – 시험 (Test) 소프트웨어 공학 개요 각 모듈들이 정의된 인터페이스에 따라 잘 동작하는지 통합 시험(integration test)을 수행한다. 여러 모듈을 조금씩 결합하면서 단계적으로 시험하는 방법을 취한다.  테스트: 개발 기관 내부에서 실제 사용해보는 시험이다.   version: 테일즈러너를 한게임 직원들을 대상으로 open한다. (라온엔터테인먼트)  테스트: 선택된 고객을 대상으로 실제 사용해보는 시험이다.   version: 테일즈러노를 프로게이머들을 대상으로 open한다.

폭포수 모형 – 인수 (Acceptance)
소프트웨어 공학 개요 패키지 소프트웨어인 경우, 사용자가 소프트웨어를 설치할 수 있도록 설치 안내서를 제공한다. 주문형 소프트웨어인 경우, 사용자 앞에서 직접 설치하며, 필요한 경우 인수 시험(acceptance test)을 실시한다. 설치 단계가 끝나면 소프트웨어 생명 주기에 있어서 운용 및 유지보수 단계로 넘어간다.

폭포수 모형의 결과물(Deliverable)
소프트웨어 공학 개요 단, 프로젝트의 규모 및 성격에 따라서 크게 달라질 수 있다.

폭포수 모형의 장단점 장점 단점 개발자가 어떤 작업을 수행하고 있는지 그 단계가 명확하다.
소프트웨어 공학 개요 장점 개발자가 어떤 작업을 수행하고 있는지 그 단계가 명확하다. 프로세스가 간단하여 일반인도 쉽게 이해할 수 있다. 중간 산출물이 명확하게 지정되어 있다. 단점 처음 단계를 지나치게 강조하면 코딩, 테스트가 지연된다. 각 단계의 전환에 많은 노력을 기울여야 한다. (뒤로 돌아가기 어렵다.) 소용없는 다종의 문서를 생산할 가능성 있음

프로토타이핑 모형 (1/3) 프로토타이핑이란 시스템의 일부 혹은 모형를 만드는 과정이다.
소프트웨어 공학 개요 프로토타이핑이란 시스템의 일부 혹은 모형를 만드는 과정이다. 시뮬레이션을 수행하거나, 데모 시스템을 만드는 방법 등이 있다. Rapid Prototyping Model ( 컬러링 예제) 요구 분석 프로토타입 개발/개선 google phone prototype 프로토타입 평가 구현 인수/설치

공동의 참조 모델 (reference model) 제공
프로토타이핑 모형 (2/3) 소프트웨어 공학 개요 시범 시스템의 적용 사용자의 요구를 더 정확하게 추출한다. 알고리즘의 타당성, 운영체제와의 조화, 인터페이스의 시험 제작을 통해 요구사항을 명확히 하고 위험을 줄일 수 있다. 프로토타이핑 도구 화면 생성기 비주얼 프로그래밍 4세대 언어 등 공동의 참조 모델 (reference model) 제공 개발 단계에서 유지보수가 이루어짐

프로토타이핑 모형 (3/3) 프로토타이핑의 단점 오해 (프로토타입을 보고, 전부 다 개발한 것 아니냐고 할 수 있음)
소프트웨어 공학 개요 프로토타이핑의 단점 오해 (프로토타입을 보고, 전부 다 개발한 것 아니냐고 할 수 있음) 기대심리 유발 (프로토타입이 이 정도이니, 최종 결과물은 …) 관리가 어려움(중간 산출물 정의가 난해)

점증적 모형 (1/2) 개발 싸이클이 짧은 환경 개발 시스템 개발자 사용자 완성 시스템 릴리스 1 구축 릴리스 2 구축
소프트웨어 공학 개요 개발 싸이클이 짧은 환경 빠른 시간 안에 시장에 출시하여야 이윤에 직결된다.  빨리 만들어 일단 반응을 보자. 개발 시간을 단축하는 법  시스템을 나누어 릴리스한다. 개발 시스템 개발자 릴리스 1 구축 릴리스 2 구축 릴리스 3 구축 릴리스 1 사용 릴리스 2 사용 릴리스 3 사용 사용자 완성 시스템

점증적 모형 (2/2) 릴리스 구성 방법 단계적 개발 점증적(incremental) 방법 – 기능별로 릴리스
소프트웨어 공학 개요 릴리스 구성 방법 점증적(incremental) 방법 – 기능별로 릴리스 반복적(iterative) 방법 – 릴리스할 때마다 기능의 완성도를 높임 단계적 개발 기능이 부족하더라도 초기에(빠른 시점에) 사용 교육이 가능 처음 시장에 내놓는 소프트웨어는 시장을 빨리 형성시킬 수 있음 자주 릴리스하면 가동 중인 시스템에서 일어나는 예상하지 못했던 문제를 신속 꾸준히 고쳐나갈 수 있음 개발 팀이 릴리스마다 다른 전문 영역에 초점 둘 수 있음  이번 Release에서는 성능 짱  이번엔 GUI 짱  … 좋은 점만 있니? 빈번한 업그레이드에 따른 피로도 누적 (예: 안드로이드)

나선형 모형 (1/3) 소프트웨어 공학 개요

나선형 모형 (2/3) 소프트웨어의 기능을 나누어 점증적으로 개발
소프트웨어 공학 개요 소프트웨어의 기능을 나누어 점증적으로 개발 실패의 위험을 줄임  위험 분석에 초점을 맞춘 개발 모형 테스트 용이 피드백이 용이 여러 번의 점증적인 릴리즈(incremental releases) 진화 단계 계획 수립(planning): 목표, 기능 선택, 제약 조건의 결정 위험 분석(risk analysis): 기능 선택의 우선순위, 위험요소의 분석 개발(engineering): 선택된 기능의 개발 평가(evaluation): 개발 결과의 평가

나선형 모형 (3/3) 대규모 시스템 개발에 적합 반복적인 개발 및 테스트 단점 Risk reduction mechanism
소프트웨어 공학 개요 대규모 시스템 개발에 적합 Risk reduction mechanism 반복적인 개발 및 테스트 강인성 향상 단점 관리가 중요 (상당히 복잡하고, 긴 과정 …) 위험 분석이 중요 상대적으로 새로운 모형 ( 적용이 쉽지 않음)

V 모형 폭포수 모형에 시스템 검증과 테스트 작업을 강조함 폭포수 모형에서 감춰진 반복과 재작업을 드러내 놓은 모형임
소프트웨어 공학 개요 폭포수 모형에 시스템 검증과 테스트 작업을 강조함 폭포수 모형에서 감춰진 반복과 재작업을 드러내 놓은 모형임 인수/설치 요구분석 검증 요구 분석 시스템 테스트 인터페이스 검증 시스템 설계 통합 테스트 모듈 검증 상세 설계 단위 테스트 구현(코딩)

소프트웨어 프로젝트 성패에 영향을 미치는 요소
소프트웨어 공학 개요 의사소통(Communication skill) 프로젝트의 성격 프로그래머의 역량(Maturity) 관리(Management) 팀의 프로젝트 경험(Experience)

Communication Skill 발주자와 개발자의 의사 소통 개발자들 사이의 의사 소통
소프트웨어 공학 개요 발주자와 개발자의 의사 소통 발주자는 컴퓨터 및 소프트웨어에 대한 지식이 부족하고, 개발자는 발주자의 전문 분야에 대한 지식이 부족함 인터뷰 기술 프로토타입 요구 취합 방법(설문지, 유저 그룹, 워크샵, ...) 정형적 방법 개발자들 사이의 의사 소통 Mythical man-month (개발자가 많이 투입된다고 해서 생산성이 높아지지는 않는다.  개발 인원이 많아질 수록 의사소통이 많아지기 때문) 문서화  궁극적으로 글로 표현을 해야 명확한 경우가 많다. (뒤탈도 없고) 기술회의 (BUT, 잦은 회의는 오히려 생산성을 떨어뜨릴 수 있다.)

프로젝트 성격 응용분야에 따라 성격이 달라짐 크기, 복잡도 자료처리 중심?, 제어 중심?, 시스템 소프트웨어?, 인공지능?
소프트웨어 공학 개요 응용분야에 따라 성격이 달라짐 자료처리 중심?, 제어 중심?, 시스템 소프트웨어?, 인공지능? 크기, 복잡도 분류 참여 프로그래머 기간 소프트웨어 규모 (원시코드 줄) 단순 규모 소규모 중규모 대규모 초대규모 극초대규모 1 2~5 5~20 100~1000 2000~5000 1~4주 1~6개월 1~2년 2~3년 4~5년 5~10년 500 1K~2K 5K~50K 50K~100K 1M 1M~10M 소규모: 단순한 데이터 처리, 과학 계산용 프로그램 중규모: 어셈블러, 컴파일러, 소규모 경영 정보 시스템, 재고 관리 대규모: 컴파일러, 실시간 처리 시스템, DBMS 초대규모, 극초대규모: 군사 명령 제어 체계, 통신 시스템, 은행 전산망 관리

프로그래머 역량 소프트웨어 개발 – 노동집약적 산업 프로그래머의 능력 Sackman의 실험
소프트웨어 공학 개요 소프트웨어 개발 – 노동집약적 산업 프로그래머의 능력 프로그래밍 능력 커뮤니케이션 능력 응용 분야에 대한 이해 프로세스, 도구에 대한 이해와 경험 Sackman의 실험 프로그래밍 생산성 차이  최대 1:25 (평균 1:16) 디버깅 능력  1:28 (미숙한 프로그래머가 작성한 모듈은) 전체 품질이나 일정에 영향 소프트웨어 공학의 체계적이고 조직적인 접근법을 통하여 일정 부분 상쇄가 가능하다. BUT, 개인의 차이는 어디서나 나타나기 마련…

프로젝트 관리 기술 소프트웨어 개발 관리 소프트웨어 프로세스 관리 CMM(Capability Maturity Model) 모델
소프트웨어 공학 개요 소프트웨어 개발 관리 프로그래밍 경험 관리 능력 소프트웨어 프로세스 관리 일정 관리 예산, 인력 관리 형상 관리 품질 관리 CMM(Capability Maturity Model) 모델 소프트웨어 품질 관리(Quality Assurance)

CMM (Capability Maturity Model)? (1/2)
소프트웨어 공학 개요 개요 (“09. 품질보증”에서 좀더 자세히 다룸) CMM(능력 성숙도 모델, Capability Maturity Model)은 Carnegie Mellon 대학의 소프트웨어공학연구소(SEI, Software Engineering Institute, Mark Paulk 교수가 중심이 되어 만든 소프트웨어 개발 Process에 대한 평가 모델이다. CMM은 1986년에 연구가 시작되어 1993년에 규격화된 CMM v1.1이 만들어졌으며, 현재 미국의 여러 정부 조직 등에서 소프트웨어 구매 시 해당 소프트웨어를 개발한 회사에 대한 평가 모델로서 채택하고 있다. CMM에서는 다섯 가지 단계의 비교적 추상적인 개념의 성숙도를 제시한다. 그리고, 소프트웨어 개발 조직은 그 조직에서 사용하는 개발 과정과 방법론에 따라 성숙도를 부여 받는다.

CMM (Capability Maturity Model)? (2/2)
소프트웨어 공학 개요 CMM 레벨 단계 1 (Initial Level): 초기 단계로서 개발 및 관리를 위한 환경을 제공하지 못하는 단계이다. 계획이 수시로 변하여 미래를 예측할 수 없으며, 프로젝트의 성공은 개인의 능력에 크게 좌우된다. 단계 2 (Repeatable Level): 프로젝트에 대한 계획과 관리가 어느 정도 체계화되어 있다. 신규 프로젝트에 대해서는 과거 성공한 프로젝트에 기반하여 개발이 이루어지며, 어느 정도의 문서화, 훈련 등을 수행한다. 단계 3 (Defined Level): 개발 과정에 대한 표준 공정이 어느 정도 정착된 상태이며, 품질 향상을 위한 일정, 방법론 등이 정착된 상태이다. 정의된 프로세스에 대해서 조직 전체가 어느 정도 인식하고 있으나, 그 성숙도는 높지 않은 상태이다. 단계 4 (Managed Level): 조직적인 개발이 이루어지며, 소프트웨어에 대한 전반적인 테스트가 수행되고 그 결과가 피드백된다. 각 개발 단계에 대한 세분화를 통하여 생산 가능한 양적(quantitative) 측정이 가능해진다. 단계 5 (Optimizing Level): 품질 향상을 위한 지속적인 연구개발이 진행되며, 이를 위한 데이타 및 분석 자료 축적이 가능한 상태이다. 이러한 기반을 바탕으로 소프트웨어 개발을 위한 신기술의 비용 및 이윤 분석이 가능하다.

CMM 인증 관련 기사 소프트웨어 공학 개요

Homework #1 소프트웨어 공학 개요

소프트웨어 공학 (Software Engineering)

Similar presentations

Presentation on theme: "소프트웨어 공학 (Software Engineering)"— Presentation transcript:

Similar presentations

About project

지원

로그인

Auth with social network:

소프트웨어 공학 (Software Engineering)

Similar presentations

Presentation on theme: "소프트웨어 공학 (Software Engineering)"— Presentation transcript:

Similar presentations

About project

지원