소프트웨어 개발단계 : 계획 / 요구 분석 / 위험

1. 계획단계

1. 계획의 이해 

소프트웨어 개발 계획

> 비용, 기간, 자원 계획 필요

 

계획 없는 소프트웨어 개발 
일정 지연, 비용 초과, 품질 저하 → 유지보수 비용 증가

 

2. 문제의 정의

문제 정의

> 소프트웨어 개발의 첫 작업

> 무엇을 개발할 것인지 명확히 정의

> 개발 범위를 결정 -> 프로젝트의 초기 타당성과 초기 계획을 작성할 수 있는 기초로 활용

 

문제 정의를 위한 필요 사항
> 개발하고자 하는 영역의 배경 지식 필요

> 문제를 파악하기 위해 현재 운영 중인 시스템을 사용

> 실무 담당자와 면담하여 자료를 수집한 후 면밀히 분석

 

 

3. 타당성 분석 

경제적 타당성(economic feasibility)

> 투자 효율성 / 시장성

> 경영자: 투자 효율성(cost benefit analysis)에 관심

> 분석가: 투자 대비 효과 검토 후 경영자에게 정확한 정보 제공

> 시장 분석을 통한 시장성(marketability)확인 -> 개발 여부 판단

 

기술적 타당성technical feasibility

> 구현 가능한지?

> 하드웨어 성능

> 개발자의 기술력

 

법적 타당성(legal feasibility)
> 개발용 소프트웨어와 도구의 사용이 법적으로 문제가 없는지 검토

> 지적 소유권과 프로그램 보호법이 강화되었으므로 법적 문제 검토

 

4. 개발비 산정

소프트웨어 개발 비용 예측
> 개발자의 능력에 따른 생산성의 차이  -> 기간과 품질에 영향

> 다양한 개발 프로세스로 인한 표준화/자동화의 어려움 -> 다양한 생산성과 품질

 

  => 명확한 개발비 산출의 어려움

 

소프트웨어 개발 비용에 영향을 주는 요소

> 프로그램 자질

: 초급 프로그래머와 고급 프로그래머의 생산성 차이가 큼 => 프로그램의 자질 : 개발 비용에 영향을 줌

> 소프트웨어 복잡도

: 브룩스의 법칙: 애플리케이션 개발 < 유틸리티 개발 < 시스템 프로그램 개발

: 소프트웨어 복잡도: 개발 비용에 영향을 미침

> 소프트웨어 크기

: 참여 인력 증가, 개발 기간 길어짐, 복잡도 커짐

> 가용 기간

: 관리자들의 잘못된 생각: 인력/자원 증가는 개발 기간 단축

: 보헴: "정상적인 계획에서 최대 75%가 줄일 수 있는 한계"

> 요구되는 신뢰도 수준

: 높은 신뢰도의 소프트웨어 개발은 개발 비용의 증가

> 기술 수준

: 고급언어 사용하면 저급 언어의 사용보다 5~10배의 생산성 증가

 

- 하향식 산정 기법

> 전문가 판단 기법

: 경험이 많은 전문가가 개발 비용을 산정 = 신뢰성 높음

: 짧은 시간에 개발비를 산정하거나 입찰에 응해야 하는 경우 많이 사용

: 단점 : 수학적 계산 방법보다 경험에만 의존할 경우 부정확할 수 있음

: 대표 기법 : 델파이 기법 

 

- 상향식 산정 기법

> 세부 작업 단위별로 비용 산정한 후 전체 비용 합산

: 단점 : 수학적 계산 방법보다 경험에만 의존할 경우 부정확할 수 있음

> 원시 코드 라인 수LOC 기법 => 원시 코드 라인 수의 비관치, 낙관치, 중간치를 측정 후 예측치를 구해 비용 산정

> 개발 단계별 노력(effort per task) => 기법생명주기의 각 단계별로 노력(M/M)을 산정

 

> LOC : 개발하려는 소프트웨어의 총 코드 라인수를 예측하여, 구현단계에 대한 M/M산정.

> 실제 소프트웨어 개발 : 코딩뿐 아니라 요구 분석, 설계 등의 단계에서도 인력과 자원이 많이 필요

> 보완책 :  개발 단계별 노력 기법

                     - M/M을 소프트웨어 개발 생명주기의 각 단계에 적용하여 단계별로 산정

                     - 장점: 코딩만 대상으로 산정하는 LOC보다 더 정확하여, LOC를 보완

 

- 수학적 산정 기법

> 상향식 비용 산정 기법

> 경험적 추정 기법 또는 실험적 추정 기법

> COCOMO 방법

 : SW 규모(LOC - 라인수 중심) 예측한 후, SW 종류에 따라 각 비용 산정 공식에 대입하여 비용 산정

> Putnam방법

 : 소프트웨어 생명주기의 전 과정에 사용될 노력의 분포를 가정해 줌

> 기능 점수(FP) 방법 
 : 기능 점수를 구한 후, 이를 이용해 비용 산정

 

 

2. 일정 계획

- 소프트웨어 개발 프로젝트에서의 일정 계획

> 일정 계획

 : 작업 순서 결정, 소작업의 개발 기간, 순서, 필요한 자원 등의 일정 계획

 

> 작업 분할 구조도(WBS: Work Breakdown Structure)

프로젝트 목표를 달성하기 위해 필요한 활동과 업무를 세분화하는 작업

프로젝트 구성 요소들을 계층 구조로 분류

프로젝트의 전체 범위 정의프로젝트 작업을 세분화

작업 패키지(work package)

계층 구조에서 최하위에 있는 항목

 

 >  WBS 사용 목적과 용도

• 사용자와 개발자 간의 의사소통 도구로 사용함.
• 프로젝트 업무 내역을 가시화할 수 있어 관리가 용이함.

• 프로젝트 팀원의 책임과 역할이 분명함.

• 필요 인력과 일정 계획을 세우는 데 기초로 활용함.

• 개발비 산정 시 기초로 활용함.

• 성과 측정 및 조정 시 기준선으로 활용할 수 있음.

 

> PERT/CPM

: WBS의 작업 순서, 소요 기간 등을 네트워크 형태의 그래프로 표현한 후 어떤 작업이 중요한지, 또 일정에 여유가 있는 작업은 어떤 것이지 찾아내 중점 관리를 해야 하는 작업을 명확히 하는데 사용

: 프로젝트를 완료할 수 있는 최소 기간은 얼마인지, 완료 기간을 맞추기 위해서는 각 작업을 언제 시작하고 완료해야 하는지, 지연되지 않으려면 어떤 작업에 특히 주의를 기울여야 하는지, 또 전체 프로젝트 완료 기간을 단축하기 위해서는 어떤 작업들을 단축하는 것이 가장 경제적인지 등 관리자의 고민에 답을 주기 위해 필요한 도구

 

> 간트 차트(Gantt chart)

: 프로젝트 일정 관리를 위한 바(bar) 형태의 도구

 

3. 위험 분석

 

4. 요구 분석

SW 개발의 목적 : 개발된 소프트웨어의 고객 만족

 

고객만족을 위한 특성 : 적시성 / 유연성 / 통합

 

고객 만족의 개발 조건 : 고품질 / 정해진 기간 / 주어진 예산

 

요구사항 : 사용자와 개발자 간에 합의한 개발 범위에서 시스템이 제공해야 하는 기능

 

요구분석 명세서 : 개발 초기에 사용자의 요구사항(비기능 요구사항 포함)을 추출하여 정리한 문서

 

 

요구 분석 과정

: 사용자 요구 분석 -> SW 목표 수립 -> 모델링 -> 요구분석 명세서

 

요구 분석

> 소프트웨어 요구 사항 정의를 위해 사용자의 요구사항을 조사하고 확인하는 과정.

> 소프트웨어 개발 생명주기의 첫 단계

> 소프트웨어 개발 성패의 열쇠

 

요구 분석 절차

1. 자료 수집 : 현행 시스템 파악, 실무 담당자와 인터뷰, 현재 사용하는 서류 검토

2. 요구 사항 도출 : 수집한 자료 정리 및 분류 -> 개발에 반영할 요구 사항 도출

3. 문서화 : 요구 분석 명세서 작성

4. 검증 : 요구 분석 명세서 검토 -> 모순 사항, 빠트린 사항 등 점검

 

요구사항 분류

요구사항 -> 기능적 요구 사항

              -> 비기능적 요구 사항 : 품질 / 제약 사항

요구사항 -> 사용자 요구 사항

              -> 시스템 요구 사항

 

- 품질

신뢰성 -> 소프트웨어를 믿고 사용할 수 있는 것

신뢰도 : 장애 없이 동작하는 시간의 비율

 

성능

: 사용자가 시스템에 어떤 요구를 했을 때, 해당 기능을 정상적으로 수행하는 것 + 사용자가 원하는 조건(응답시간, 데이터 처리량 등)을 만족 시키는 것

보안성

: 인증을 받지 않은 사람이 시스템에 접근하는 것을 막아 처음부터 시스템과 데이터 보호

안전성 

: 작동하는 모든 시스템이 소프트웨어 오류로 인해 인명 피해가 발생하지 않아야 함.

사용성

: 소프트웨어를 사용할 때 혼란스러워하거나 사용하는 순간에 고민하지 않게 하는 편의성

 

신뢰도 측정 

> 고장 간 평균 시간(MTBF)과 이용 가능성(가용성)을 척도로 사용.

- MTBF = MTTF + MTTR

> MTBF(고장 간 평균 시간, Mean Time Between Failure) : 고장에서 다음 고장까지의 평균 시간

> MTTF(평균 실패 시간, Mean Time To Failure) : 수리한 후 다음 고장까지의 평균 시간

> MTTR(평균 수리 시간, Mean Time to Repair) : 고장 발생 시점에서 수리 시까지의 평균 시간

- 이용 가능성 : MTTF/(MTTF+MTTR) * 100%

    = 주어진 시점에서 프로그램이 요구에 따라 작동되고 있을 가능성

 

 

소프트웨어 개발에서의 모델

: UML 다이어그램을 이용해 표현

장점 : 유지보수 용이. 개발될 소프트웨어에 대한 이해도 향상. 이해 당사자간의 의사소통 향상

단점 : 과도한 문서작업으로 일정 지연 가능성. 형식적인 산출물로 전락할 수 있음.

 

 

모델링 언어

: 애매모호한 표현 등의 문제점을 해결하기 위해 모델링을 할 때, 사용하는 기호, 표기법, 도구

ex) 악보 기호, 수학 기호, UML 다이어그램, Z 언어

> 개발 방법론에 따른 모델링 언어

: 구조적 방법론 : DFD(Data Flow Diagram), DD(Data Dictionary), 프로세스 명세

: 정보공학 방법론 : DB 설계 시 ERD(Entity Relationship Diagram)

: 객체지향 방법론 : UML 표기법