software engineering #3 planning

33
2012 년년 N4tech ¼ 년년 년년년 이이이 2012.01.20( 이 ) 1

Upload: o-joun-lee

Post on 23-Jun-2015

240 views

Category:

Engineering


6 download

DESCRIPTION

Software engineering

TRANSCRIPT

Page 1: Software engineering #3 planning

1

2012 년도 N4tech ¼ 분기 세미나

이오준2012.01.20( 금 )

Page 2: Software engineering #3 planning

2

Schedule 소프트웨어 공학

1st weak - chapter 01. 소개

2nd weak - chapter 02. 프로세스

3rd weak - chapter 03. 계획

4th weak - chapter 04. 요구 분석

5th weak - chapter 05. 설계원리와 아키텍처

6th weak - chapter 06. 객체지향 설계

7th weak - chapter 07. 상세 설계와 UI 설계

8th weak - chapter 08. 코딩

9th weak - chapter 09. 테스팅

10th weak - chapter 10. 유지 보수

11th weak - chapter 11. 품질

12th weak - chapter 12. 첨단 소프트웨어 공학 기술

Page 3: Software engineering #3 planning

3

계획 – What? Who? Why?

WBS 작성작업 별

소요시간 및 노력 예측

작업 의존관계

정의

자원 할당

이정표 설정

일정 개발

프로젝트목적

프로젝트 계약

리스크 분석

Page 4: Software engineering #3 planning

4

문제의 정의

Page 5: Software engineering #3 planning

5

문제의 정의 – 현재 상황 , 구현될 시스템의 목표 , 제약 조건

문제의 정의서

1. 현 시스템의 상황 , 문제와 목표 , 소프트웨어 개발을 통해 달성할 목표

2. 개발되어야 할 시스템이 개괄적으로 갖추어야 할 기능→ 제약 조건 , 기능들 간의 우선순위

3. 프로세스 모델의 선택 , 자원 계획

Page 6: Software engineering #3 planning

6

노력 추정

Page 7: Software engineering #3 planning

7

규모 예측

모델 적용

예측한 노력

CPM 적용

소작업 정의

프로세스 모델 정의

상향식 방법각 소작업에 필요한 인원 ,

기간 , 참여도를 곱하여 비용을 추산 .

하향식 방법프로그램의 규모를 예측하

고 , 경험을 바탕으로 규모에 따른 노력을 추정 .

Page 8: Software engineering #3 planning

8

COCOMO 모델

1. 프로그램의 규모를 예측한 후 , 추정식에 대입하여 노력의 초벌 예측값을 구한다 .

PM = a

KDSI = 프로그램의 규모 a,b = 프로그램의 유형에 따른 상수

프로젝트 유형 공식 유형 해설

단순형 PM = 2.4 소규모 팀이 개발하는 잘 알려진 응용 시스템

중간형 PM = 3.0 단순형과 임베디드형의 중간형

임베디드형 PM = 3.6 하드웨어가 포함된 실시간 시스템

Page 9: Software engineering #3 planning

9

2. 프로젝트에 영향을 주는 요소들을 비용 승수로 표현하고 , 각 승수 값을 노력 예측 값에 곱함 .

1) 제품의 특성 – 신뢰성에 대한 요구 , 문제의 복잡도 , 데이터 베이스의 크기

2) 컴퓨터 실행 – 수행시간의 제약 , 주 기억 장치의 제약 , HW/SW 의 안전성

3) 개발 요원의 특성 – 응용분야에 대한 경험 , 프로그래밍 언어 숙련도

총 인건비 = 월 * 인원 평균 * 인건비

총 개발 시간 = 단순형 TDEV = 2.5

중간형 TDEV = 2.5

임베디드형 TDEV = 2.5

적정 인원 = 월 * 인원 / 총 개발 시간

Page 10: Software engineering #3 planning

10

기능 점수 모델소프트웨어가 갖는 기능의 개수로 규모나 복잡도를 나타내고 이를 통해 비용 산출 .

각 항목을 측정하고 복잡도에 따라 가중치를 매겨 규모를 산정한다 .

입력 개수 – 사용자가 시스템에 제공하는 입력 자료의 수출력 개수 – 시스템이 사용자에 제공하는 출력 자료의 수질의 개수 – 시스템의 특정 기능을 요청하는데 필요한 대화형 질의의 수파일 개수 – 시스템이 유지 보관하는 정보 그룹의 수인터페이스 개수 – 다른 외부 시스템과의 인터페이스 수

프로그램의 규모 = 기능 점수 * LOC/FPLOC/FP – 기능 점수 1 점을 구현하기 위한 해당 언어의 라인 수

Page 11: Software engineering #3 planning

11

계획

Page 12: Software engineering #3 planning

12

작업 분해

WBS – 소 작업들의 계층적 목록 → 최하위 노드들의 자원 예측을 통해 전 프로젝트 자원 예측

Page 13: Software engineering #3 planning

13

CPM 네트워크

노드에 작업을 표시하고 , 화살표로 작업간 선후관계를 표시한다 .

1) 소작업 리스트를 작성하고 , 소요시간과 선행 작업을 표시한다 .

2) 소작업들의 선후관계를 표시하고 , 소요기간을 표시한다 .

3) 주요 중간 결과를 산출하는 작업을 이정표로 설정하고 , 예상 완료 시간을 표시한다 .

Page 14: Software engineering #3 planning

14

간트 차트

자원의 활용을 계획하기 위해 사용되며 , 일정에 변화가 생기면 다시 그린다 .

Page 15: Software engineering #3 planning

15

조직 계획

Page 16: Software engineering #3 planning

16

책임 프로그래머 팀 구성팀 구성원들이 관리자의 명령에 따라 일하고 , 결과를 보고하는 방식 .

책임 프로그래머 : 중요한 부분의 프로그래밍 , 중요한 기술적 판단

프로그램 사서 : 프로그램 리스트 , 설계 문서 , 테스트 계획 등 관리

프로그래머 : 원시코드 작성 , 테스팅 , 디버깅 , 문서 작성

보조 프로그래머 : 책임 프로그래머를 보좌

Page 17: Software engineering #3 planning

17

분산형 팀 구성

민주적인 의사결정을 내리며 , 모든 일을 공통의 일로 간주하는 조직 .

Page 18: Software engineering #3 planning

18

혼합형 팀 구성프로젝트 관리자나 경험 엔지니어에게 지휘권이 주어지지만 ,의사교환은 초보 엔지니어나 중간 관리층으로 분산 .

Page 19: Software engineering #3 planning

Schedule 소프트웨어 공학

1st weak - chapter 01. 소개

2nd weak - chapter 02. 프로세스

3rd weak - chapter 03. 계획

4th weak - chapter 04. 요구 분석

5th weak - chapter 05. 설계원리와 아키텍처

6th weak - chapter 06. 객체지향 설계

7th weak - chapter 07. 상세 설계와 UI 설계

8th weak - chapter 08. 코딩

9th weak - chapter 09. 테스팅

10th weak - chapter 10. 유지 보수

11th weak - chapter 11. 품질

12th weak - chapter 12. 첨단 소프트웨어 공학 기술

Page 20: Software engineering #3 planning

요구 분석 – 요구의 범위와 성격을 이해하고 , 제약 사항을 알고 , 해법을 결정

문제 분석 문제 정의 프로토타이핑 , 시험

문서화와 검토

요구 추출과 분석 요구 정의 및 명세화

사용자의 요구를 모두 찾았는가 ?

올바른 기법과 관점을 사용하고 있나 ?

기능이 타당한가 ? 사용자가 요구하는바로 그것인가 ?

Page 21: Software engineering #3 planning

요구를 찾는 법

Page 22: Software engineering #3 planning

요구 추출

현재의 기관이나 시스템

발주자의 요구

도메인 모델

현재 상황에 대한 모델현존하는 문서

제안된 요구 유형재사용 가능한

요구

요구 템플릿 재사용 라이브러리

관찰 , 인터뷰 , 브레인스토밍 , 프로토타이핑

Page 23: Software engineering #3 planning

구조적 분석

Page 24: Software engineering #3 planning

구조적 분석

시스템을 기능적인 관점에서 다루는 방법 .

현재 시스템과 개발될 시스템의 모델을 만드는 것을 목표로 함 .

1) 배경도 작성

2) 상위 자료 흐름도 작성

3) 하위 자료 흐름도 작성

4) 자료 사전 작성

5) 소단위 명세서 작성

Page 25: Software engineering #3 planning

자료 흐름도

1) 시스템 경계의 입 / 출력을 식별 .2) 주요자료가 어떤 주요 과정을 거쳐 변형되는가를 파악하고 , 하향식으로 분할 .3) 입 / 출력 자료가 더 분할되지 않으며 , 한 계층이 한 입력자료의 흐름만을 갖을 때 , 중단4) 정확성 검사 , 완벽성 검사 , 일관성 검사 .

Page 26: Software engineering #3 planning

자료 사전

표제어 ‘ 가나다’순으로 정렬

자료 흐름도의 자료 항목에 대한 정의를 모은 것 .

설명 부분 표제어의 의미

정의부분 자료를 이루는 요소가 무엇인지 수식 형태로 나타냄

Page 27: Software engineering #3 planning

소단위 명세서자료 흐름도의 최하위 프로세스가 어떤 기능을 하는가를 기술한 것 .

Page 28: Software engineering #3 planning

객체지향 분석

Page 29: Software engineering #3 planning

객체지향 분석

- 문제 도메인을 쉽게 이해하고 설명할 수 있음 .

- 변화에 쉽게 대처할 수 있음 .

- 재사용이 용이함 .

1) 엑터 찾기

2) 사용 사례 찾기

3) 재사용이 용이함

Page 30: Software engineering #3 planning

사용 사례 다이어그램

확장 관계 – 예외적이며 , 선택적인 경우에 이용

포함 관계 – 두 개 이상의 사용 사례가 공유하는 동작

Page 31: Software engineering #3 planning

엑터 찾기

- 어떤 사용자 그룹이 작업을 수행하기 위해 시스템의 지원을 받는가 ?

- 어떤 사용자 그룹이 시스템의 주요 기능을 사용하는가 ?

- 어떤 사용자 그룹이 유지 보수나 관리 등의 부수적인 기능을

사용하는가 ?

- 시스템이 다른 외부 하드웨어 / 소프트웨어 시스템과 동작하는가 ?

Page 32: Software engineering #3 planning

사용 사례 찾기

- 시스템이 어떤 작업을 수행하기를 엑터가 원하는가 ?

- 엑터가 원하는 정보는 무엇인가 ? 누가 데이터를 생성하는가 ?

데이터는 조작 삭제할 수 있는가 ? 이런 작업이 누구에 의하여

행해지는가 ?

- 엑터가 시스템에 정보를 알리기 위해 필요한 것은 ?

- 얼마나 자주 , 언제 작업이 일어나는가 ?

- 엑터가 시스템으로 부터 정보를 알아내는데 필요한 이벤트는 ? 이런

사건의 빈도는 ?

Page 33: Software engineering #3 planning

33

감사합니다 .

질문 & 답변