2012 년도 N4tech ¼ 분기 세미나

이오준2012.01.06( 금 )

Contents

소프트웨어 공학 chapter 01. 소개

1.1 소프트웨어와 시스템

1.2 다루는 문제

1.3 도전 과제

1.4 접근 방법

1.5 근본 지식

1.1 소프트웨어와 시스템 1.1.1 소프트웨어

1.1.2 시스템

소프트웨어란 ?

• 프로그램과 프로그램의 개발 , 운용 , 보수에 필요한 관련 정보 일체

• 프로그램이 컴퓨터를 가동시킨다는 동적인 의미 포함

소프트웨어의 특성

• 비가시성 : 생산물의 구조가 코드 안에 숨어 있어 파악하기 어려움

• 복잡성 : 개발 과정의 복잡함 , 소프트웨어 시스템 자체가 난해함

• 순응성 : 정형적인 구조가 없으며 , 환경에 따라 적절히 변형 가능

1.1.1 소프트웨어

소프트웨어의 분류

• 기능에 따른 분류o 응용 소프트웨어 : 사용자가 원하는 목적에 맞게 개발된 소프트웨어o 시스템 소프트웨어 : 응용 소프트웨어가 컴퓨터와 상호작용할 수 있게 하고 , 컴퓨터가

내부 및 외부 지원을 제어할 수 있게 하는 소프트웨어

• 개발되는 과정의 성격에 따른 분류o 프로토타입 : 실현 가능성을 타진하고 , 사용자의 요구를 파악하기 위해 표본으로 만들어진

소프트웨어o 연구 생산물 : 아직 상품화되지 않은 연구과정에서 생산된 소프트웨어o 페키지 : 다수의 사용자를 위해 상품으로 개발된 소프트웨어o 주문형 소프트웨어 : 계약에 의하여 특정한 사용자의 요구에 맞추어 개발된 소프트웨어

1.1.1 소프트웨어

시스템이란 ?

• ‘ 필요한 기능을 실현시키기 위하여 관련 요소를 어떤 법칙에

따라 조합한 집합체’

• 서브시스템은 다른 서브시스템들과 상호작용하고 이들이 통합되어 하나의

거대한 시스템을 형성

• 소프트웨어 또한 독립적으로 존재하는 것이 아니라 컴퓨터를 기반으로

하는 여러 시스템들과 관계를 맺음

• 소프트웨어 또한 하나의 시스템이며 , 따라서 소프트웨어는 시스템이라는

관점에서의 접근이 필요함

1.1.2 시스템

소프트웨어

하드웨어

유지 보수

데이터베이스

문서

인간

시스템

입력 출력

1.1.2 시스템

1.1.2 시스템

• 소프트웨어 시스템을 개발하기 위해 파악해야 할 사항들

– 대상을 시스템으로 파악할 수 있어야 한다 .

– 서브시스템을 찾아낼 수 있어야 한다 .

– 시스템의 특성과 기능을 찾아낼 수 있어야 한다 .

– 시스템의 경계가 어디인지 찾아낼 수 있어야 한다 .

– 시스템에 대한 입력과 출력을 찾아낼 수 있어야 한다 .

– 서브시스템 사이의 관계를 찾아낼 수 있어야 한다 .

1.2 다루는 문제 1.2.1 고비용

1.2.2 지연과 낮은 신뢰도

1.2.3 유지보수와 재 작업

소프트웨어 위기• 시스템의 규모가 커지고 , 복잡성이 증가함에 따라 , 소프트웨어의

신뢰도는 떨어지고 개발비는 증가함 .

1.2.1 고비용

구성율

0%

50%

100%

1955 1978

1985

소프트웨어 유지 보수

소프트웨어 개발하드웨어

• 하드웨어 비용은 감소하고 성능은 증대되지만 , 소프트웨어 비용은 급격히 증가 .

소프트웨어의 지연과 낮은 신뢰도

• 소프트웨어 개발 프로젝트의 35% 이상이 계획에서 벗어남 .o 이는 지연되거나 예산이 초과한다는 것이 아니라 관리할 수 없을

정도임을 의미 .

• 장비나 기기 고장의 70% 이상이 소프트웨어에 의한 것임 .o 이는 시스템 제작에서 소프트웨어가 가장 취약한 부분임을 의미함 .

o 소프트웨어에서 고장은 모두 설계나 개발 단계에서 유입된 것임 .

1.2.2 지연과 낮은 신뢰도

유지보수의 목적

• 시스템에 남아있는 오류가 있기 때문에

• 더 많은 기능과 서비스를 제공 하기 위해 업그레이드 되기 때문에

1.2.3 유지보수와 재 작업

유지보수의 어려움

• 현재 소프트웨어를 이해하는데 상당한 노력과 비용이 듦 .

• 사용자의 요구를 파악하기 힘듦 .

재 작업의 이유

• 사용자의 요구는 개발의 진행에 따라 지속적으로 변경됨 .

→ 요구의 변경에 따른 재작업이 필요해진다 .

이는 소프트웨어 개발 비용의 상당 부분을 차지한다 .

1.2.3 유지보수와 재 작업

분석 , 설계 , 코딩 수정 및 재작업 요구 , 환경 변경

1.3 도전 과제 1.3.1 규모

1.3.2 품질과 생산성

1.3.3 일관성과 재현성

1.3.4 변경

규모에 따른 방법론의 필요성

• 같은 문제라도 규모에 따라 필요한 요소가 달라짐 .

→ 소규모 프로젝트에서는 비정형적인 방법을 사용할 수도 있지만 ,

대규모 프로젝트에서는 개발과 관리 방법이 정형화된 것이어야 한다 .

1.3.1 규모

소규모 프로젝트

대규모 프로젝트정형

비정형

정형 비정형

프로젝트

관리

비용 , 일정

• 소프트웨어 개발은 노동집약적인 작업이기 때문에 프로젝트의

비용은 월 - 인원으로 측정한다 .

• 소프트웨어의 생산성은 월 - 인원 당 생산하는 라인 수로 나타낸다 .

→ 생산성이 높아진다면 월 인원으로 나타내진 비용은 줄어들고 ,

팀은 더 적은 인원으로 할 수 있는 작업량은 늘어나게 된다 .

1.3.2 품질과 생산성

품질

• 품질은 소프트웨어 공학이 지향하는 근본 목표이다 .

1.3.2 품질과 생산성

소프트웨어 품질

기능성 신뢰성 사용 용이성 효율성 유지보수성 이식성

적합성

보안성

적응성

설치용이성

변경용이성

시험용이성

확장성

이해용이성

학습용이성

운용성

품질

• 기능성 – 소프트웨어가 사용될 때 원래 정한 또는 내재된 요구를 만족시키는 능력o 적합성 , 보안성

• 신뢰성 – 소프트웨어가 정해진 수준의 성능을 유지할 수 있는 능력o 품질 기준을 대표함 . 신뢰성이 없다 → 결함이 있음

• 사용용이성 – 쉽게 이해되고 배울 수 있고 사용될 수 있는 능력o 이해용이성 , 학습용이성 , 운용성

• 효율성 – 사용되는 자원의 양에 따라 적정한 성능을 제공할 수 있는 능력

• 유지보수성 – 정정 , 개선 , 적응시킬 목적으로 수정될 수 있는 능력o 변경용이성 , 시험용이성 , 확장성

• 이식성 – 별도의 작동이나 수단 없이 다양한 환경에서 적응될 수 있는 능력o 적응성 , 설치용이성

1.3.2 품질과 생산성

품질

1.3.2 품질과 생산성

품질 다차원적인 개념

프로젝트 마다 개발 전에 품질 목표 설정이 필요함

소프트웨어의 품질을 하나의 숫자로 축약할 수 없음

품질의 개념은 프로젝트에 따라 달라짐

일관성 , 재현성

1.3.3 일관성과 재현성

소프트웨어 공학의 목적 개발하는 시스템마다 높은 품질과 생산성을 갖도록 만드는 것

사용하는 방법론이 프로젝트 전체에 반복 재현되어 생산된 소프트웨어 품질에 일관성 있어야

⇒ 프로젝트 결과 예측 가능 , 품질과 생산성 향상

기관은 방법론을 표준화하고 , 일관되게 사용할 필요 있음

변경

• 소프트웨어는 비교적 변경이 쉽고 변경을 예측하기 용이하다 .

• 시장의 급격한 변화는 소프트웨어에도 빠른 변화를 요구한다 .

→ 소프트웨어가 변경에 잘 견딜 수 있도록 제작하고 ,

변경을 조절하고 수용할 수 있도록 해야 한다 .

1.3.4 변경

1.4 접근 방법 1.4.1 단계적 프로세스

1.4.2 프로세스의 관리

품질

생산성

기술 인력

프로세스

⇒체계적인 접근법으로 프로세스를 제품과 분리하여 , 제작 과정에 집중하도록 함 .

단계적 프로세스• 개발하는 소프트웨어의 문제를 나누어 여러 개발 단계에서 다른 관점을 다룬다 .

• 개발하는 동안 품질과 진행을 적절히 체크할 수 있다 .

1.4.1 단계적 프로세스

요구 분석

테스팅

설계

코딩

계획

유지보수

단계적 소프트웨어 개발

문제를 이해 명확히 정의

해결책을 결정 , 설계

해결책을 구현

프로그램을 검증

단계적 프로세스 - 요구분석

요구 분석 – 시스템이 무엇을 필요로 하는가 ?

1.4.1 단계적 프로세스

문제를 이해하고 분석

요구를 체계적으로 정리

시스템의 요구를 찾아내는 것

모든 기능과 성능 요구입력과 출력의 형식 , 제한 사항설계에 영향을 주는 모든 요인

소프트웨어 요구 명세서

단계적 프로세스 - 설계설계 – 문제의 솔루션을 계획

소프트웨어의 품질에 영향을 주는 가장 결정적인 요인

1.4.1 단계적 프로세스

아키텍처 설계

상세 설계

시스템을 컴포넌트들의 집합으로 보고컴포넌트들의 상호작용에 초점을 맞춤

각 모듈들의 내부 논리를 작성함

아키텍처 설계는 어떤 컴포넌트나 모듈이 필요한지 찾는 것이 초점이고 ,상세 설계는 모듈이 어떻게 구현될 것인지가 초점이다 .

단계적 프로세스 - 코딩

코딩 – 설계를 프로그래밍 언어로 변환시키는 일

1.4.1 단계적 프로세스

단순함

주어진 설계에 대해 최선의 방법으로 구현하는 것이 목표이며 ,프로그래밍 언어에 의해 좌우되므로 설계에 세부사항을 명시하지는 않는다 .

잘 작성된 코드는 테스팅과 유지 보수를 쉽게 하므로 ,읽기 쉽고 , 이해하기 쉬운 프로그램이 되어야 한다 .

명확성

단계적 프로세스 - 테스팅

테스팅 – 중요한 품질 제어 수단 , 결함을 찾아내는 기능

요구 분석이나 설계의 결과물은 시험할 목적으로 실행하는 것이 불가능하다 .

따라서 , 테스팅은 코딩의 오류 뿐 아니라 요구와 설계의 오류 또한 밝혀야 한다 .

①단위 테스팅 – 모듈이나 컴포넌트를 개별적으로 테스트

②통합 테스팅 – 모듈 사이의 연결을 테스트

③시스템 테스팅 – 시스템이 모든 요구를 만족하는지 테스트

④인수 테스트 – 고객의 데이터를 가지고 , 시스템이 잘 실행되는지 테스트

1.4.1 단계적 프로세스

단계적 프로세스 - 테스팅

1.4.1 단계적 프로세스

테스트 계획

테스팅 작업

시험되어야 할 조건 , 시험할 단위 , 모듈을 통합하는 방법

테스트 단위마다 테스트 케이스와 예상 결과

실제 결과와 예상 결과를 비교

테스트 케이스 명세서

테스트 보고서

오류 보고서

테스트 케이스 , 실행된 코드와 결과

발견한 오류 , 오류를 제거하기 위한 조취

프로세스의 관리

단계적 개발 프로세스는 소프트웨어 공학적 접근 방식의 핵심이다 .o 하지만 , 개발 프로세스는 작업 과정에서 어떤 자원을 어떤 작업에 할당할 것인지는 알지 못한다 .

o 따라서 , 프로젝트 관리자가 프로젝트의 개발 프로세스를 관리 해야 한다 .

1.4.2 프로세스의 관리

• 프로세스 관리는 객관적인 데이터를 필요로 하므로 , 소프트웨어 메트릭을 이용한다 .

소프트웨어 메트릭 시스템의 특성에 대한 정량적인 측정

프로덕트 메트릭

프로세스 메트릭

소프트웨어 자체의 특성을 계량화

프로세스의 생산성을 계량화

1.5 근본 지식 1.5.1 다른 분야와의 관계

1.5.2 SWEBOK

다른 분야와의 관계소프트웨어 공학은 컴퓨터 공학의 원리나 기술과 관련된 분야와 응용 도메인 분야의 중간 가교 역할을 한다 .

1.5.1 다른 분야와의 관계

소프트웨어 공학컴퓨터 과학 및 기술 응용 도메인

신뢰성 공학 안전 및 보안

품질 관리프로젝트 관리 시스템 공학

SWEBOK

SWEBOK 는 IEEE 산하의 소프트웨어 공학 표준 위원회와 ACM 이 정의한 소프트웨어 개발

엔지니어가 가져야 할 근본 지식이다 .

1.5.2 SWEBOK

감사합니다 .

질문 & 답변