소프트웨어 공학 (software engineering ) 소프트웨어 공학 개요 문양세...

소프트웨어 공학 (Software Engineer-ing)

소프트웨어 공학 개요

문양세강원대학교 IT 대학 컴퓨터과학전공

Software Engineeringby Yang-Sae Moon

소프트웨어 공학을 배우기에 앞서서 ,• 소프트웨어 및 소프트웨어 시스템에 대해서 정의해보고 ,• 소프트웨어 위기와 이에 따른 소프트웨어 공학의 필요성을 생각해 본다 .

또한 , • 좋은 소프트웨어란 무엇인지 정의해보고 ,• 소프트웨어 공학에서 사용하는 주요 모형들을 살펴본 후 ,• 소프트웨어 개발에 영향을 미치는 요소들을 생각해 본다 .

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

소프트웨어 공학 개요In this chapter …


소프트웨어 공학 개요In this chapter …

소프트웨어와 시스템

소프트웨어 위기와 소프트웨어 공학

좋은 소프트웨어의 조건

소프트웨어 개발 프로세스 모형

소프트웨어 개발에 영향을 미치는 요소


실생활과 소프트웨어 ( 컴퓨터 )• 디아블로 ?, 리니지 ? 스타크 ? 서든어택 ? 테일즈러너 ? Oh, NO!• 일상사에서… 공과금 고지서 , 항공기 예약 / 발권 , 병원 기록 , 초본 / 등본 , 스마트폰 ,

…• 학교로 보면… 수강 신청 , 성적 입력 및 열람 , 학사 관리 , …

정보 혁명의 토대는 컴퓨터이며 , 그 잠재력은 ? 물론 , 소프트웨어이다 .

소프트웨어는 과거 “편리” 추구에서 현재는 “생존”에 필수적 요소가 되어가고 있다 .• 정치 , 경제 (1 차 , 2 차 3 차 산업 공통 ), 사회 , 교육 , 국방 , 예술 , 의료 , 오락 , …• 경쟁에서의 승리 제품의 적기 공급 제품 ? 소프트웨어 자체 혹은 내재가 기본…

소프트웨어의 결함 생명과 재산에 치명적 결과• 우주왕복선 폭발 , 지진해일 ( 쓰나미 ) 예보 , …• Y2K 문제 ( 밀레니엄 버그 )

소프트웨어 공학 개요소프트웨어의 중요성


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


소프트웨어 공학 개요Y2K?


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


소프트웨어 정의• 협의 : 프로그램 자체• 광의 : 프로그램 + 프로그램의 개발 , 운용 , 보수에 필요한 정보 일체

( 소프트웨어 생산 결과물 일체 )

소프트웨어 ? 프로그램 ?• 소프트웨어는 프로그램의 동적인 실체• 프로그램은 형식 언어로 표현된 지적 노동의 결과물• 제조업 vs. 서비스업 ( 소프트웨어는 제작이 아니라 창조적 노력이 포함된 개발 )• 닳아 없어지는 것이 아니라 소용없어 못쓰게 됨• 논리적인 요소로 구성 ( 유지보수가 어려움 )• 소프트웨어 산업 (2007 년 현재 국내는 22.7 조 규모의 산업 - 정보통신산업통계연보 )

소프트웨어 공학 개요소프트웨어의 정의


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


비가시성 (Invisibility)테스트 가능 (Testability)복잡성 (Complexity) 특히 제 3 자가 보았을 경우

변형성 (Conformity)/ 변경성 (Changeability)장수 (Longevity) 죽지 않는다 . 단지 사라질 뿐이다 .복제 가능 (Duplicability) 생명공학의 모태 ?응용에 의존 (Application dependability) 일반적으로 , 몇 개 핵심 부품을 만들어 조립해 쓸 수가 없다 .

소프트웨어 공학 개요소프트웨어의 특성


기능적 분류• 응용 소프트웨어 (Application Software): 증권 처리 , 학사 관리• 시스템 소프트웨어 (System Software): 운영체제 , DBMS, Compiler, …

개발 과정에 따른 분류• Prototype• Product: 상품화 이전이나 완성된 소프트웨어• Package: 시험을 거쳐서 상품화된 소프트웨어

( 주문형 소프트웨어 : 고객의 목적에 맞도록 패키지된 소프트웨어 )

하드웨어 환경에 따른 분류• Mainframe• Parallel Processing or Distributed Processing• PC & Workstation• 모바일 디바이스 스마트폰

소프트웨어 공학 개요소프트웨어의 분류 (1/2)


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

소프트웨어 공학 개요소프트웨어의 분류 (2/2)


유기적으로 상호 작용하는 객체들의 모임• S/W 는 독립적으로 존재하는 것이 아니라 컴퓨터를 기반으로 여러 시스템이 유기적인

관계를 맺고 있다 .• 은행의 업무 전산화 예제 : 현금 자동 인출기 , 중앙 컴퓨터 , 계좌 DB, 은행 업무 처리 절차 , 입출금 전표 , 은행원 , …

특징• 시너지 효과 : 독립적인 의미를 갖지 않고 , 통합되었을 때 의미를 가짐• 역동적으로 발전 , 변경• 상충되는 요구와 이해 관계의 절충 (최적의 모범 답안이 아닌 절충안에 해당 ) 교통체계

소프트웨어 자체도 하나의 시스템임

소프트웨어 공학 개요소프트웨어 시스템


자료의 분류 , 저장 , 검색에 초점

데이터베이스를 대화식 (interactive) 으로 접근

조직의 문제 해결을 위한 도구

정보 시스템의 예제• 항공권 예약 시스템

• 신용 카드 검색 서비스

• 뱅킹 시스템

정보 시스템의 특징• 대규모 자료를 관리하며 , ( 일반적으로 ) 정적이 아님

• 시스템 분석과 유지보수가 중요함

MIS (Management Information System, 경영 정보 시스템 ) [ 위키]• 운영 , 관리 , 의사결정을 위하여 정보를 제공하는 시스템

• DSS(Decision Support System), KDD(Knowledge Discovery in Database)

소프트웨어 공학 개요정보 시스템 (Information System)

http://en.wikipedia.org/wiki/Management_information_system


사건을 감지하여 처리하고 자동적으로 보고• 센서의 감지 (Ubiquitous Sensors)• 제어 기기의 상태 보고

• 운영자의 입력 처리

• 사용자 및 운영자 인터페이스

제어 시스템 예제• 교통 제어

• 공정 제어 컨베이어 벨트 제어

• 수치 제어

• 의료 시스템 초음파 검사 , 메디슨…

• 무기 ( DARPA, FBI, … 테러 방지 )• 항공 제어

• 재난 , 방재 산업 산불 감지 , 지진 감지

소프트웨어 공학 개요제어 시스템 (Control System)


주된 기능이 계산이 아닌 시스템의 구성 요소의 일부(A system that is logically incorporated in a larger system whose primary function is not computation.)

탑재 시스템 예제• 전자 기계 장치 , 공정 제어 시스템• 비행기 유도 , 스위칭 시스템 ( 교환기 등 )• 환자 감시 시스템 , 레이다 추적 시스템

탑재 시스템 특징• 대규모 , 장기 사용 , 테스트하기 어려움• 인터페이스가 복잡 , 비동기 , 병렬 , 분산• 대규모 자료를 접근 , 변경 , 출력• 실시간 제어 인터페이스• 엄격한 요구 : 실시간 반응 , 고장에 대한 안전 , 신뢰성

소프트웨어 공학 개요( 오리지널 ) 탑재 시스템 (Embedded Sys-tem)


소형 디바이스에 들어가는 소프트웨어• PDA, 휴대폰용 운영체제 , 게임 , 영상 재생 , …• 소형 센서에 탑재되는 소프트웨어• …

Embedded Software를 어떻게 배워~• 프로그램 (C, Java, Assembly, …) 을 잘하고 ,• 운영체제 (Windows, UNIX/Linux), DBMS를 잘 이해하는 등의• 기본에 충실하면 쉽게 적응할 수 있어요…

• 안드로이드를 배워 봅시다 .

소프트웨어 공학 개요( 요즘의 ) Embedded System


소프트웨어 공학 개요We are now …







소프트웨어 공학 개요소프트웨어 위기 (Software Crisis) (1/2)

100

80

60

40

20

0 1955 1980 1995

총비용 %

하드웨어 비용 소프트웨어 개발 비용

소프트웨어 유지보수 비용

위키를 봅시다.

http://ko.wikipedia.org/wiki/%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4_%EC%9C%84%EA%B8%B0




소프트웨어 공학 개요소프트웨어 위기 (Software Crisis) (2/2)

소프트웨어 공정의 문제점• 비용 초과 (Cost Overruns)• 기간 지연 (Late Delivery)• 성능 저하 (Inadequate Performance)• 신뢰성 저하 (Unreliability)• 유지보수 불가능 , 엄청난 유지보수 비용 (Prohibitive Maintenance Costs) SMSC

경험

소프트웨어 위기 : 소프트웨어의 요구 (demand) 와 그 공급 (supply) 능력 간의 차이가 갈수록 심화되고 있음

1965 – 1985 Increase Rate at 1983Increase in Demand ( 요구의 증

가 ) 100 times 12%

Productivity ( 생산성 ) 2 times 4%Manpower Supply ( 인력 공급 ) 10 times 4%


소프트웨어 공학 개요소프트웨어 개발의 또 다른 문제점

개발 예산이 초과되고 , 일정이 지연되는 경우가 많다 .• 개발 일정과 비용 예측이 부정확하다 .• 과거 프로젝트에 대한 경험이 잘 축적되지 않을 뿐 아니라 , 과거 데이터가 현재에 잘 적용되지 않는 경우가 많다 .

프로그래머 개인 역량에 따라 소프트웨어 개발 성패가 좌우된다 .• 프로그래머 개인의 능력과 경험이 중요하여 , 작업의 정량적인 분석이 어렵다 .• 잘 키운 슈퍼 프로그래머 하나가 열 … 안 부럽다 .

소프트웨어 품질을 평가하기가 어렵다 .• 체계적인 시험이 없으면 , 운영 중에 많은 오류가 발생한다 .• 다른 공산품과 같은 불량품 관리 , 품질 보증에 대한 확실한 정량적 개념이 없다 .

다른 공산품의 경우 , “불량률 0 에 도전 ,” “ 무재해 100 만시간 달성 목표”


소프트웨어 공학 개요엔지니어링 원리의 발전 단계

대량생산

장인들의 기술

상업화

과 학

엔지니어링

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


소프트웨어 공학 개요소프트웨어 공학 (1/2)

복잡한 대규모 문제 해결을 위해서는 엔지니어링 ( 공학 ) 접근법이 필요• 요리를 잘하는 집안 식구가 음식점을 개업한다면… .

집안 식구가 먹기 위하여 만드는 음식과는 다른 접근법이 필요하다 . 재료 구입 , 조리 시간 , 서빙 , …

• 개업한 음식점이 잘 되어서 , 전국 체인점을 내려 한다면…

음식점 하나를 운영하는 것과는 다른 차원의 접근법이 필요하다 . 재료 전달 , 조리법 체계화 / 기계화 , 훈련 , …

한 사람이 프로그램을 작성할 때와 한 팀이 작성할 때 , 한 부서가 작성할

때는 각기 다른 공학적 접근법이 필요하다 .


소프트웨어 공학 개요소프트웨어 공학 (2/2)

소프트웨어 공학의 정의• 질 좋은 소프트웨어를 경제적으로 생산하기 위하여 공학 , 과학 및 수학적 원리와 방법을

적용하는 것 - Watts Humphrey, SEI• 소프트웨어의 개발 , 운용 , 유지보수 및 소멸에 대한 체계적인 접근 방법

- IEEE Computer Society• 품질 , 효율 , 비용 , 인정에 관한 공학적인 접근 원리 - F. Brooks

소프트웨어 공학의 목표• 품질 좋은 소프트웨어를• 최소의 비용으로• 계획된 일정에 맞추어 개발한다 . 품질 (Quality), 생산성 (Productivity)


소프트웨어 공학 개요소프트웨어 공학에서 다루는 주제 (1/2)

방법 (method): 어떻게 만들 것인가 ?도구 (tool): 무엇을 사용해 만들 것인가 ?프로세스 (process): 어떤 과정 / 단계로 만들 것인가 ?패러다임 (paradigm): 어떤 접근법 / 스타일을 사용할 것인가 ?

소프트웨어 공학 기술

프로세스 패러다임

방법 도구


소프트웨어 공학 개요소프트웨어 공학에서 다루는 주제 (2/2)

분 야 의 미 사 례 요리 비유

방법(method)

소프트웨어 제작에 사용하는 기법이나 절차

구조적 분석 /설계 방법 객체지향 분석 /설계 방법

익히는 방법 ( 구이 , 찜 , 훈제 등 )

도구(tool) 자동화된 시스템

설계 도구 프로그래밍 도구

테스트 도구

요리 도구 ( 프라이팬 , 압력 솥 , 오븐

등 ) 프로세스(process)

도구와 기법을 사용하여 작업하는 순서 eXtreme Programming 조리 순서

패러다임(paradigm

) 접근 방법 , 스타일

구조적 방법론 객체지향 방법론

음식 스타일 ( 한식 , 일식 , 중식 , 퓨전

등 ) XP(eXtreme Programming) 란 단순성 , 의사소통 , 피드백 , 용기 등 네 가지 가치를 매우 중요하게 생각하는 소프트웨어

개발방법론 중 하나로 “고객에게 최고의 가치를 가장 빨리’ 전달하도록 하는 것을 최고의 가치로 삼는다 . 특히 요구사항 많거나 잦은 변화가 예상되는 위험부담이 큰 프로젝트를 하는 경우에 개발자가 소규모 (10 명 내외 ) 이고

같은 공간을 사용하는 경우에 높은 효과를 볼 수 있다고 알려져 있다 . 이 방법론의 대표적인 방법으로는 팀워크와 고객가치를 중시 , 2 인조 프로그래밍 , 우선순위가 높은 일 지속적으로 처리하기 , 자료를 따로 보관하지 않고 지속적으로 통합하기 , 테스팅 적극적으로 이용하기 , 코드 공동 소유하기 , 고객 현장에 참여하기 , 설계를 단순하게 하기 등이 있다 .


소프트웨어 공학 개요Extreme Programming Sports








We are now …


소프트웨어 공학 개요소프트웨어 품질 (Software Quality) (1/4)

소프트웨어를 대하는 입장에 따라 품질에 대한 관점이 달라짐

최소 비용생산성융통성

기능의 정확성이해 용이성사용 용이성일관된 통합

이식성재사용성

유지보수성상호 운용성

신뢰성

효율성

발주자 사용자

유지보수자



정확성 (Correctness)• 기능적으로 맞게 동작하는가 , 표준에 적합한가

• 요구 분석서의 기능과 일치하는지 점검

신뢰성 (Reliability)• 소프트웨어가 주어진 기간 동안 바르게 작동할 확률

• 오류 발생 확률에 반비례

• 정확성 제공하기 위한 필요조건

강인성 (Robustness)• 요구 명세에 표시하지 않은 상황 ( 오류 입력 ) 에서도 제대로 작동하는 성질



성능 (Performance)• 수행 속도 , 데이터 / 트랜잭션 처리량

• 알고리즘의 시간 복잡도

• 시뮬레이션 , 스트레스 테스트

사용 용이성 (Usability)• 시스템을 친근하게 느낄 수 있는 성질

• 사용 대상에 따라 달라질 수 있음

• 사용자 인터페이스 , Human factor

유지보수성 (Maintainability)• 보수성 : 정해진 기간에 소프트웨어 결함을 해결할 수 있는 성질

• 진화성 : 잠재적 발전 가능성 ( 추가 요구사항에 따라 기능이 진화할 수 있어야 함 )



재사용성 (Reusability)• 소프트웨어 부품 ( 라이브러리 , 클래스 등 ) 의 성질

• 확장 가능성 – openness• 적응성 – adaptability• 이용 용이성 - closeness


소프트웨어 공학 개요소프트웨어 품질의 구분

프로덕트 품질• 소프트웨어 자체의 품질을 의미한다 .• 수돗물 비교 : 수돗물 자체의 품질 , 즉 , 맛 , 색깔 , 유해성분 , … 일반적으로 생각하는 품질을 의미한다 .

프로세스 품질• 소프트웨어를 개발하는 과정의 품질을 의미한다 .• 수돗물 비교 : 수돗물을 전달하는 파이프의 청결도 , 집수장의 위치 , … 과정의 품질이 좋지 않으면 궁극적인 프로덕트의 품질이 나쁘다는 인식에서 출발한다 . 프로세스의 품질이 높으면 S/W 에 내재된 잠재적인 오류를 줄일 수 있다 .

과거에는 프로덕트 품질을 중시했으나 , 현재는 모든 분야에 있어서

프로세스의 품질을 중시하고 있다 . (ISO 인증 ).


소프트웨어 공학 개요프로덕트 품질

소프트웨어 자체의 품질을 의미하나…

소프트웨어를 대하는 사람의 입장에 따라서 품질의 정의가 달라진다 .• 구매자 : 외부로 드러나는 품질요소 (external characteristics)를 중시한다 .

( 예를 들어 , 오류 횟수 , 판매 횟수 등 )• 유지보수 엔지니어 : 제조 과정에 내재된 내부 특성 (internal characteristics)를

중시한다 . ( 예를 들어 , 함수 재사용이 용이한가 ?)

McCall 의 품질 모델 교재 p. 32 의 [ 그림 1.6] 참조


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

개발하는 과정이 소프트웨어 품질에 많은 영향을 준다는 주장

개발 및 유지 보수하는 프로세스의 품질이 프로덕트 자체의 품질 못지

않게 중요하다는 입장

향상 방안• 특정 오류가 언제 어디서 발견되는가 ?• 어떻게 하면 개발 과정에 오류를 조기에 발견할 수 있는가 ?• 어떻게 하면 오류에 대한 내성이 있는 시스템 , 즉 오류가 소프트웨어를 정지시키는

확률이 적은 시스템으로 만들 수 있는가 ?• 프로세스가 좋은 품질을 보장하는 더 효율적이며 효과적인 다른 방법이 있는가 ?

( 일본의 농산품 관리 방법 )


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


소프트웨어 공학 개요소프트웨어 생산성 (Productivity)

생산 과정 (process) 에 크게 영향• Process improvement

개발 경험의 성숙도에 의해 좌우• CMM(Capability Maturity Model): Level 1~5

생산성에 영향을 미치는 요소• 프로그래머의 능력

• 팀 의사 전달

• 제품의 복잡도

• 기술 수준

• 관리 기술








We are now …


소프트웨어 공학 개요소프트웨어 프로세스 모형

소프트웨어 라이프 사이클

개념화 단계

유아 및 성장기 성년기

( 제품으로서 )유아기

개발 단계 개발 후개발 전


소프트웨어 공학 개요건축 프로세스

( 요구 분석 ) 집을 짓기 위해서는 건축설계사가 집주인과 만나 어떤

집을 원하는지 들어본다 .( 구조 설계 ) 건축설계사는 집주인의 요구를 반영하여 층별 배치도와

개략적인 조감도를 그린다 .( 상세 설계 ) 평면도 , 측면도를 필요한 자세한 설계 도면을 준비한다 .( 구현 ) 설계가 끝나면 시공단계에 들어가서 실제로 집을 짓는다 .( 테스트 ) 집을 지은 후에는 전등이 잘 켜지는지 , 난방이 잘되는지 등의

각종 점검을 수행한다 .( 유지보수 ) 집이 완성된 후에는 하자에 대한 유지보수를 수행한다 .


소프트웨어 공학 개요소프트웨어 프로세스 모형

개발 프로세스 : 개발 과정을 체계적으로 정리한 과정

실정에 맞는 개발 팀의 고유한 모형의 정립 필요

소프트웨어 개발에 필요한 작업• 요구 분석과 정의

• 시스템 설계 ( 건축의 구조 설계에 해당 )• 프로그램 설계 ( 건축의 상세 설계에 해당 )• 프로그램의 작성 ( 구현 )• 테스트 ( 단위 테스트 , 통합 테스트 , 시스템 테스트 )• 시스템 설치

• 유지보수


소프트웨어 공학 개요대표적인 소프트웨어 프로세스 모형

폭포수 모형 (Waterfall Model)프로토타이핑 모형 (Prototyping Model)점증적 모형 (Incremental Model)나선형 모형 (Spiral Model)V 모형 (V Model)


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



계 획

인수설치

시 험

구 현

설 계

요구 분석



1970 년대 소개항공 방위 소프트웨어 개발 경험으로 습득

각 단계가 다음 단계 시작 전에 끝나야 함• 순서적 - 각 단계 사이에 중복이나 상호작용이 없음

• 각 단계의 결과는 다음 단계가 시작 되기 전에 점검

• 바로 이전 단계로의 피드백만이 가능함

단순하거나 응용 분야를 잘 알고 있는 경우 적합• 한 번의 과정 , 비전문가가 사용할 시스템 개발에 적합

결과물 (deliverable) 정의가 중요


소프트웨어 공학 개요폭포수 모형의 프로세스 및 결과물 요약

계획 요구 분석 설계

구현 시험 인수 /설치

• 문제정의• 타당성 분석• 비용 , 일정예측

계획서• DFD• 자료사전 • 소단위명세서

요구분석서

• 시스템구조설계• 프로그램설계• UI 설계

구조설계서상세설계서

• 프로그래밍• 단위테스트

프로그램• 통합시험• 기능시험• 성능시험

통합된프로그램

• 설치• 인수 시험

설치된소프트웨어

( 활동 ) ( 결과물 )

P R D

I T A


소프트웨어 공학 개요폭포수 모형 – 계획 (Planning)

문제의 실현 가능성을 타진한다 . (feasibility study) 영구 기관 (엔진 ) 을 만들 수는 없다 ?, 물로 가는 자동차는 ?

개발하고자 하는 시스템의 성격을 파악하여 비용과 기간을 예측한다 . 예측을 잘못하면 소위 “열심히 하고 욕먹는 결과”를 초래한다 .개발 방법과 각 단계에 필요한 자원을 결정한다 . 좋은 도구를 사용할 경우 , 인력을 크게 줄일 수도 있다 .

열역학 법칙을 깬세계 최초 영구기관 ?


소프트웨어 공학 개요폭포수 모형 – 요구 분석 (Requirement Analy-sis)

개발을 의뢰한 사용자 ( 일반인 , 운영자 , …) 요구나 주어진 문제를

정확히 분석하고 이해하는 과정이다 .

발주자와 개발자가 요구 분석 사항에 동의하여야 다음 단계 진행이

가능하다 .• 소프트웨어가 어떤 품질을 만족해야 하는지 결정한다 .• 소프트웨어가 어떤 기능을 제공해야 하는지 결정한다 .

( 세부적으로 어떻게 구현할 지는 추후 설계 단계에서 생각한다 .)

요구분석서는 사용자와 개발자의 의사 소통 수단으로서 , 정확하고

간결하고 완벽하며 이해하기 쉽고 일관성을 유지하도록 작성해야 한다 .


소프트웨어 공학 개요폭포수 모형 – 설계 (Design)

시스템 구조 설계• 소프트웨어 구조를 어떻게 가져갈 것인가 ?• 일반적으로 , 소프트웨어 모듈을 정의하고 , 각 모듈간의 관계를 정의한다 .

프로그램 설계• 각 모듈내의 알고리즘을 설계한다 .• 모듈간의 인터페이스 방법을 설계한다 .

사용자 인터페이스 설계• 입력 형식 (메뉴 , 음성입력 등 ) 을 결정하고 설계한다 .• 출력 형식 ( 화면 , 소리 등 ) 을 결정하고 설계한다 .


소프트웨어 공학 개요폭포수 모형 – 설계 ( 시스템 구조 설계 예제 )

PDSN/IWFGGSN

IXPC(Inter/eXter Process Communication)

통계 / 장애 / 상태 관리 Graphical UI

데이터베이스메시지 파일

정보 관리 및 공유

MS LME

메시지 송수신

SMSC IPLS

페이징 처리

AAA JUICE

단말 정보 처리

SANTAWISE INBH

과금 처리

NMS WINGS

기타 연동

Textual UI

운용자 정합

운용 / 형상 / 구성 관리

운용 및 유지보수

데이터베이스 관리

파일 (메시지 ) 관리

메시지 정보 관리

메시지 상태 관리

호처리 제어

제어 및 호처리

LME SMSC IPLS AAA JUICE WISE INBH NMS WINGS

SANTA


소프트웨어 공학 개요폭포수 모형 – 설계 ( 사용자 인터페이스 설계 예제 )

GUI(Graphical User Interface): Java 기반으로 이식성 높고 편리한 환경 제공

TUI(Textual User Interface): 원격지에서 MML 을 사용한 운영 기능 제공

명령어 입출력환경

MMC Category 선택 Combo Box

MMC Command List

MMC Command Parameter Table

MMC Command Input Text Field

MMC Command Result Output Window

Command실행

Command도움말

Output Window

결과 삭제

Window닫기


소프트웨어 공학 개요폭포수 모형 – 구현 (Implementation)

미리 정해진 모듈 설계에 따라 프로그램 , 즉 코딩을 수행한다 .

코딩된 각 모듈은 테스트의 기본 단위이다 . 모듈 테스트는 테스트 단계가 아닌 구현 단계로 보기도 한다 .

코딩 작업 자체도 개발회사 전체적인 표준이 있어야 한다 .• 헤더 주석 , 변수 작명 규칙 , 모듈의 최소 및 최대 크기 등

• 모듈 테스트도 회사 전체의 표준이 있어야 한다 . 테스트 계획서 , Code Inspection, …


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


소프트웨어 공학 개요폭포수 모형 – 시험 (Test)

각 모듈들이 정의된 인터페이스에 따라 잘 동작하는지 통합 시험

(integration test) 을 수행한다 .

여러 모듈을 조금씩 결합하면서 단계적으로 시험하는 방법을 취한다 .

테스트 : 개발 기관 내부에서 실제 사용해보는

시험이다 . version: 테일즈러너를 한게임 직원들을 대상으로

open 한다 . ( 라온엔터테인먼트 )

테스트 : 선택된 고객을 대상으로 실제

사용해보는 시험이다 . version: 테일즈러노를 프로게이머들을 대상으로

open 한다 .


소프트웨어 공학 개요폭포수 모형 – 인수 (Acceptance)

패키지 소프트웨어인 경우 ,사용자가 소프트웨어를 설치할 수 있도록 설치 안내서를 제공한다 .

주문형 소프트웨어인 경우 ,사용자 앞에서 직접 설치하며 , 필요한 경우 인수 시험 (acceptance test) 을 실시한다 .

설치 단계가 끝나면 소프트웨어 생명 주기에 있어서 운용 및 유지보수

단계로 넘어간다 .


소프트웨어 공학 개요폭포수 모형의 결과물 (Deliverable)

Activity Output documentsRequirements analysis Feasibility study, Outline requirementsRequirements definition Requirements documentSystem specification Functional specification, Acceptance test plan

Draft user manualArchitectural design Architectural specification, System test planInterface design Interface specification, Integration test planDetailed design Design specification, Unit test planCoding Program codeUnit testing Unit test reportModule testing Module test reportIntegration testing Integration test report, Final user manualSystem testing System test reportAcceptance testing Final system plus documentation

단 , 프로젝트의 규모 및 성격에 따라서 크게 달라질 수 있다 .


소프트웨어 공학 개요폭포수 모형의 장단점

장점• 개발자가 어떤 작업을 수행하고 있는지 그 단계가 명확하다 .• 프로세스가 간단하여 일반인도 쉽게 이해할 수 있다 .• 중간 산출물이 명확하게 지정되어 있다 .

단점• 처음 단계를 지나치게 강조하면 코딩 , 테스트가 지연된다 .• 각 단계의 전환에 많은 노력을 기울여야 한다 . (뒤로 돌아가기 어렵다 .)• 소용없는 다종의 문서를 생산할 가능성 있음


소프트웨어 공학 개요프로토타이핑 모형 (1/3)

요구 분석

프로토타입개발 / 개선

프로토타입평가

구현

인수 /설치

프로토타이핑이란 시스템의 일부 혹은 모형를 만드는 과정이다 .시뮬레이션을 수행하거나 , 데모 시스템을 만드는 방법 등이 있다 .Rapid Prototyping Model ( 컬러링 예제 )

google phoneprototype



시범 시스템의 적용• 사용자의 요구를 더 정확하게 추출한다 .• 알고리즘의 타당성 , 운영체제와의 조화 , 인터페이스의 시험 제작을

통해 요구사항을 명확히 하고 위험을 줄일 수 있다 .

프로토타이핑 도구• 화면 생성기

• 비주얼 프로그래밍 , 4 세대 언어 등

공동의 참조 모델 (reference model) 제공

개발 단계에서 유지보수가 이루어짐



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


소프트웨어 공학 개요점증적 모형 (1/2)

개발 싸이클이 짧은 환경• 빠른 시간 안에 시장에 출시하여야 이윤에 직결된다 . 빨리 만들어 일단 반응을 보자 .• 개발 시간을 단축하는 법 시스템을 나누어 릴리스한다 .

릴리스 1 구축 릴리스 2 구축 릴리스 3 구축

릴리스 1 사용 릴리스 2 사용 릴리스 3 사용

개발

자사

용자

개발 시스템

완성 시스템


소프트웨어 공학 개요점증적 모형 (2/2)

릴리스 구성 방법• 점증적 (incremental) 방법 – 기능별로 릴리스

• 반복적 (iterative) 방법 – 릴리스할 때마다 기능의 완성도를 높임

단계적 개발• 기능이 부족하더라도 초기에 (빠른 시점에 ) 사용 교육이 가능

• 처음 시장에 내놓는 소프트웨어는 시장을 빨리 형성시킬 수 있음

• 자주 릴리스하면 가동 중인 시스템에서 일어나는 예상하지 못했던 문제를 신속 꾸준히

고쳐나갈 수 있음

• 개발 팀이 릴리스마다 다른 전문 영역에 초점 둘 수 있음

이번 Release 에서는 성능 짱

이번엔 GUI 짱 …

• 좋은 점만 있니 ? 빈번한 업그레이드에 따른 피로도 누적 ( 예 : 안드로이드 )


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

Riskanalysis

Riskanalysis

Riskanalysis

Riskanalysis Proto-

type 1

Prototype 2Prototype 3

Opera-tionalprotoype

Concept ofOperation

Simulations, models, benchmarks

S/Wrequirements

Requirementvalidation

DesignV&V

Productdesign Detailed

design

CodeUnit test

IntegrationtestAcceptance

testService Develop, verifynext-level product

Evaluate alternativesidentify, resolve risks

Determine objectivesalternatives and

constraints

Plan next phase

Integrationand test plan

Developmentplan

Requirements planLife-cycle plan

REVIEW



소프트웨어의 기능을 나누어 점증적으로 개발• 실패의 위험을 줄임 위험 분석에 초점을 맞춘 개발 모형

• 테스트 용이

• 피드백이 용이

여러 번의 점증적인 릴리즈 (incremental releases)

진화 단계• 계획 수립 (planning): 목표 , 기능 선택 , 제약 조건의 결정

• 위험 분석 (risk analysis): 기능 선택의 우선순위 , 위험요소의 분석

• 개발 (engineering): 선택된 기능의 개발

• 평가 (evaluation): 개발 결과의 평가



대규모 시스템 개발에 적합• Risk reduction mechanism

반복적인 개발 및 테스트• 강인성 향상

단점• 관리가 중요 ( 상당히 복잡하고 , 긴 과정 … )• 위험 분석이 중요

• 상대적으로 새로운 모형 ( 적용이 쉽지 않음 )


소프트웨어 공학 개요V 모형

폭포수 모형에 시스템 검증과 테스트 작업을 강조함

폭포수 모형에서 감춰진 반복과 재작업을 드러내 놓은 모형임

요구 분석

시스템 설계

상세 설계

구현 (코딩 )

단위 테스트

통합 테스트

시스템 테스트

인수 /설치

모듈 검증

인터페이스 검증

요구분석 검증








We are now …


소프트웨어 공학 개요소프트웨어 프로젝트 성패에 영향을 미치는 요소

의사소통 (Communication skill)프로젝트의 성격

프로그래머의 역량 (Maturity)관리 (Management)팀의 프로젝트 경험 (Experience)


소프트웨어 공학 개요Communication Skill

발주자와 개발자의 의사 소통• 발주자는 컴퓨터 및 소프트웨어에 대한 지식이 부족하고 , 개발자는 발주자의 전문

분야에 대한 지식이 부족함

• 인터뷰 기술

• 프로토타입

• 요구 취합 방법 (설문지 , 유저 그룹 , 워크샵 , ...)• 정형적 방법

개발자들 사이의 의사 소통• Mythical man-month ( 개발자가 많이 투입된다고 해서 생산성이 높아지지는 않는다 .

개발 인원이 많아질 수록 의사소통이 많아지기 때문 )• 문서화 궁극적으로 글로 표현을 해야 명확한 경우가 많다 . (뒤탈도 없고 )• 기술회의 (BUT, 잦은 회의는 오히려 생산성을 떨어뜨릴 수 있다 .)


소프트웨어 공학 개요프로젝트 성격

응용분야에 따라 성격이 달라짐• 자료처리 중심 ?, 제어 중심 ?, 시스템 소프트웨어 ?, 인공지능 ?

크기 , 복잡도

• 소규모 : 단순한 데이터 처리 , 과학 계산용 프로그램• 중규모 : 어셈블러 , 컴파일러 , 소규모 경영 정보 시스템 , 재고 관리• 대규모 : 컴파일러 , 실시간 처리 시스템 , DBMS• 초대규모 , 극초대규모 : 군사 명령 제어 체계 , 통신 시스템 , 은행 전산망 관리

분류 참여 프로그래머 기간 소프트웨어 규모( 원시코드 줄 )

단순 규모소규모중규모대규모

초대규모극초대규모

11

2~55~20

100~10002000~5000

1~4 주1~6 개월1~2 년2~3 년4~5 년

5~10 년

5001K~2K

5K~50K50K~100K

1M1M~10M


소프트웨어 공학 개요프로그래머 역량

소프트웨어 개발 – 노동집약적 산업

프로그래머의 능력• 프로그래밍 능력

• 커뮤니케이션 능력

• 응용 분야에 대한 이해

• 프로세스 , 도구에 대한 이해와 경험

Sackman 의 실험• 프로그래밍 생산성 차이 최대 1:25 (평균 1:16)• 디버깅 능력 1:28

( 미숙한 프로그래머가 작성한 모듈은 ) 전체 품질이나 일정에 영향

소프트웨어 공학의 체계적이고 조직적인 접근법을 통하여 일정 부분

상쇄가 가능하다 . BUT, 개인의 차이는 어디서나 나타나기 마련…


소프트웨어 공학 개요프로젝트 관리 기술

소프트웨어 개발 관리• 프로그래밍 경험

• 관리 능력

소프트웨어 프로세스 관리• 일정 관리

• 예산 , 인력 관리

• 형상 관리

• 품질 관리

CMM(Capability Maturity Model) 모델

소프트웨어 품질 관리 (Quality Assurance)


소프트웨어 공학 개요CMM (Capability Maturity Model)? (1/2)

개요 (“09. 품질보증”에서 좀더 자세히 다룸 )• CMM( 능력 성숙도 모델 , Capability Maturity Model) 은 Carnegie Mellon 대학의

소프트웨어공학연구소 (SEI, Software Engineering Institute, www.sei.cmu.edu)에서 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 ) 소프트웨어 공학 개요 문양세...

Documents