CS

소프트웨어 공학 이론과 실제 5장 ~ 8장

Wibaek 2025. 8. 10. 20:34
728x90

C05 프로젝트 관리

1. 프로젝트 관리 필요성

  • 프로젝트 실패의 원인: 소프트웨어 마인드 부족, 적절한 기술 활용 못함, 프로젝트 관리 기술 부족

프로젝트 관리의 정의

  • 프로젝트 관리의 정의: 개발자 또는 개발 팀이 프로젝트 목표를 효율적이고 효과적으로 달성하는 데 필요한 내적 환경 요소를을 준비하고 유지하는 활동

프로젝트 관리 단계

  • 프로젝트 관리 단계
    • 계획 수립: 개발 목적, 필요 자원, 정보의 흐름, 소요 인력, 산출물 정의
    • 자원 획득: 계획단계에서 예측한 장비/시설/ 확보, 팀 구성, R&R 지정
    • 실행: 수행 계획서에서 정의한 일정대로 개발, 진도 관리, 품질/리스크 관리
    • 모니터링: 계획한 베이스라인에 근거하여 진척도를 관리
  • 소프트웨어 개발의 가장 중요한 요소는 능력있는 개발 팀을 구성하는 것

프로젝트 관리의 실패 원인

  • 부정확한 요구사항
  • 사용자 환경 이해 부족
  • 부정확한 프로젝트 계획
  • 부족한 자원
  • 높은 사용자 기대치
  • 변경 관리 부족
  • 자원 관리 실패
  • 개발자 기술 부족
  • 프로젝트 관리 기술 부족

2. 프로젝트 관리 기법

  • 사람 한명이 하루에 작성하는 코드를 알 수 있다면 일정을 산정할 수 있을것이다, 그러나 예측만이 가능하다

일정 관리 기법

  • 일정 관리의 2요소
    • 어떤 프로세스 모델을 선정하였는가(폭포수/프로토타입/반복적 모델)
    • 어떤 베이스라인을 정의할 것인가
  • 베이스라인 관리
    • 베이스라인을 너무 많이 정의 → 빈번한 회의
    • 너무 적은수의 베이스라인 → 수정반영에 대한 의사결정이 이루어지지 못함 → 재작업하는 상황 발생
  • 3가지 종류의 베이스라인
    • 요구사항 베이스라인: 요구사항 수집, 프로젝트 계획 수립후 설정
    • 기능 베이스라인: 요구사항 분석 단계 후 설정, 요구사항 명세서 바탕으로 설정
    • 제품 베이스라인: 소프트웨어 개발 완료한 후에 정의하는 베이스라인
  • 스케쥴 계획과 관리
    • 작업 분할도(WBS, Work Breakdown Structure)
      • 프로젝트의 전체 목표를 세부 목표로 쪼개어 나타낸 작업 목록
      • 트리형태로 표시, 태스크는 추정 가능한 양의 작업이며 독립적으로 이루어질 수 있을정도로 분할
      • 에자일에서는 백로그가 태스크
    • 일정 차트
      • 간트 차트: 바 형태로 소요기간 표시
      • 퍼트 차트: 원/박스와 화살표로 표시

비용 관리 기법

  • COCOMO/COCOMO 2(Constructive Cost Model)
    • KDSI(Kilo Delivered Source Instructions)를 기반으로 비용을 산정
    • KDSI를 기반으로 PM(Person-Month)를 계산
    • PM을 기반으로 PMDEV(PM * Effort Multiplier)를 계산
    • PMDEV를 기반으로 TDEV(프로젝트 소요 개월)을 계산
  • 전문가 판단(WBD, Wide Band Delphi)
    • 전문가 판단에 따라서 SW 개발 비용을 산정하는 방법
  • 파킨슨의 법칙(Parkinson’s Law)
    • 조직에서 확보한 인력이 SW를 개발하기에 충분한지에 무관하게, 조직 인력에 개발 일정이 맞춰서 진행된다는 것
  • 기능 점수 산정법
    • 제공하는 기능의 필요 정도와 복잡도를 기준으로 평가

위험 관리

  • 요구사항의 빈번한 변경
    • 재작업, 의사소통의 증가
  • 프로젝트 팀원의 부적절성
    • 프로젝트 퍼포먼스 저하

3. 프로젝트 조직

성공적인 SW 프로젝트를 위해 가장 중요한 요소는 프로젝트에 적합한 우수한 인력을 확보하는 것.

  • 구성원의 역할
    • 프로젝트 관리자(PM, Project Manager): 전반에 걸친 관리 활동, 중요 이슈 해결
    • 프로젝트 리더(PL, Project Leader): 설계/구현 무결성 검증, 팀 간의 기술적 조율, 일정 조정 및 모니터링, 프로젝트 문서 작성 및 통합
    • 프로젝트 팀장(TL, Technical Leader): 프로젝트 팀을 다수의 팀으로 구성했을 때 팀을 주도적으로 이끈다. 특히 아키텍처 개발에 집중
    • 프로그램 엔지니어(PE, Program Engineer): SW 개발
    • 형상 관리자(CM, Configuration Manager): 개발 과정에서 베이스라인 산출물 관리, 변경 요청 처리 담당
    • 품질 관리자(QE, Quality Engineer): 개발 산출물 테스트, 프로젝트 단위가 아닌 전사 차원에서 지원하는 조직
    • 리어종 그룹(Liasion Group): BM과 개발을 모두 이해, 비즈니스 그룹과의 의사소통을 담당

프로젝트 팀 구조

  • 중앙집중형 팀 구조
    • 문제해결이 신속하게 이루어지고, 의사소통도 단순, 짧은 기간에 정확한 업무를 수행하는데 적합
  • 분산형 팀 구조
    • 주요 의사결정이 팀 구성원의 합의에 의해 이루어짐
    • 대규모 구성원 프로젝트에 비적합, 장기간 걸쳐 수행하는 프로젝트에 적용
  • 하이브리드 팀 구조
    • 위 둘을 합친 구조. 팀 내부의 운영은 분산형 구조를 채택, 팀 간의 문제는 PM이 조정
  • 팀 구조 선정 전략
    • 프로젝트 수행 시 비용 절감 측면에서 효과적인가
    • 팀 구성원의 이직이나 교체가 발생할 가능성이 있는가
    • 신입 엔지니어에게 프로젝트에 대한 이해나 경험을 높일 수 있는 기회를 제공하는가
    • 최신 기술 또는 특정 지식에 대하여 공유하고 전파할 수 있는가

전사적 운영 조직

  • 품질 관리 팀: 산출물 리뷰, 익스펙션, 테스트 지원
  • PMO(Project Management Office): 프로젝트 생성, 진행 모니터링, 프로젝트 단위 리스크 해결 지원

4. 프로젝트 관리 계획서

계획서를 작성시에는 다음의 사항에 유의.

  • 문서의 목적: 문서의 작성 목적, 어떠한 내용을 포함하는지
  • 관련 문서: 문서와 관련된 이전 베이스라인 산출물, 관련 표준
  • 팀 구조: 집중형/분산형/계층형 팀 구조중 선정
  • 품질 관리 적용 기법: 리뷰, 인스펙션, 테스트와 같은 활동 정의, 또한 도구/적용 표준 등
  • 작성 목차 예시

5. 프로젝트 지원 도구

  • 비용 산정/일정 관리/회의 진행/문서 저장 및 관리/형상 관리/테스트 도구등이 있다

프로젝트 관리 기능

  • 작업 계획 수립, 팀 구성, 진도 관리등 수명주기 관리를 도와주는 도구
  • 기능 종류
    • 계획 기능: 팀 구성 WBS 생성/할당
    • 진도 관리 기능: 이슈 관리
    • 협업 기능: 협업 목표 설정
    • 배포 기능: 저장소에 저장
    • 보고서 생성 기능
    • 통합 기능: 일정 달력, 드롭 박스등

PMO 도구

  • 기능 종류
    • 프로젝트 통합 관리 기능: 실현 가능성 분석, 모니터링
    • 프로젝트 범위 관리 기능: WBS 생성 결과를 기반으로 범위 타당성 검토
    • 일정 및 진도 관리 기능
    • 산출물 품질 관리 기능
    • 인정, 물적 자원 관리 기능
    • 이슈 및 위험 관리 기능
    • 의사소통 관리 기능
    • 성과 관리 기능
    • 조직의 능력 관리 기능

엔지니어링 도구

  • UML 기반의 객제치향 분석 및 설계 도구, 코딩 도구, 테스트 도구

C06 소프트웨어 비용 산정

1. 기능 점수 개요

소프트웨어 비용과 기능 점수

옛날에는 프로젝트 비용 산정을 위해 규모를 측정했고, 흔히 LOC(Lines of Codes)로 측정했다. 그러나 LOC만으로 SW 규모를 언급하는것은 적절하지 않다. 그래서 기능 점수(Function Point) 방법이 제시되었다.

기능 점수 구성 요소

  • 기능점수 산정 방법: SW 시스템을 처리 기능(Transaction Function)과 데이터 기능(Data Function) 두 관점에서 접근한다
  • 기능 점수 구성 요소 = 데이터 기능 + 처리 기능
    • 데이터 기능 = 내부 논리 파일 + 외부 인터페이스 파일
    • 처리 기능 = 외부 입력 + 외부 출력 + 외부 질의

2. 기능 점수 산정 절차

단계 1: 기능 점수 산정 유형(Type) 결정

처음으로 프로젝트 타입을 결정한다.

  • 개발 프로젝트: 처음부터 개발
  • 개선 프로젝트: 새로운 기능을 추가
  • 유지보수 프로젝트: 기존 기능에서 수정만 진행

단계 2: 범위 및 경계(Boundary) 선정

기능 점수 산정을 위해 범위와 SW 경계를 선정한다.

  • 기능 점수 산출 범위
  • 소프트웨어 획득 방식
  • 대상 시스템의 세부 내용(중요)

을 정의한다.

이후 처리 기능과 데이터 기능에 따라 기능 점수를 산정한다.

단계 3: 데이터 기능 산출 및 복잡도 식별

데이터 기능 산출을 위해 우선

  • 내부 논리 파일(ILF): SW 범위 내에서 유지되야 하는 파일 또는 레코드 타입(구조체 타입)
  • 외부 인터페이스 파일(EIF): 응용 소프트웨어 밖에 존재하며 단순히 참조하는 데이터 파일

을 식별해야 한다.

이를 식별했으면 레코드 항목의 유형 수와 데이터 항목 수를 바탕으로 복잡도를 Low, Average, High로 찾는다.

단계 4: 처리 기능 산출 및 복잡도 식별

처리 기능은 SW가 데이터를 처리하여 사용자에게 제공하는 기능으로 입력/출력/질의 타입으로 나뉜다.

데이터 기능에서 식별된 ILF와 EIF에 대해 CRUD + Inquery(질의 함수, AGGREGATE 느낌인듯?) 총 5개의 처리 함수를 고려한다.

위 5가지 함수가 각 파일에서 몇개의 데이터 항목이 관련있는지 카운트한다.

이후 데이터 기능 산출단계와 마찬가지로 매트릭스를 이용해 Low/Average/High 복잡도를 얻는다.

단계 5: 예비 기능 점수 산정

모든 데이터/처리 기능에 대해 복잡도가 산정되면, 가중치값 3~15를 곱해서 결정해준다. 이 점수들을 모두 더해주면 예비 기능 점수를 산정할 수 있다.

단계 6: 조정 인자 값 산출

산정된 점수는 SW만 고려된 것이기에 사용자가 뛰어난 수준의 UI를 요구하거나 SW가 분산환경에서 동작해야 한다면 추가적인 노력이 필요하다.

  • 데이터 통신, 분산 데이터 처리, 성능, 비중 있는 구성, 처리율, 온라인 데이터 입력, 사용자 효율성
  • 온라인 갱신, 복잡한 처리, 재사용성, 설치 용이성, 운영 용이성, 다수의 사이트, 변경 지원

각 인자에 대해 0~5의 스케일 값으로 영향도를 결정한다.

이후 영향도의 합(TDI, Total Degree of Influence)를 구한 후, 조정 인자 값(VAF, Value Adjustment Factor) = (TDI*0.01) + 0.65를 구한다.

단계 7: 최종 기능 점수 산출

VAF를 예비 기능 점수에 곱해준다.

3. 정규법과 간이법

4. 기능 점수 활용

기능 점수와 프로그래밍 언어

  • 기능점수 * a = LOC
  • 기능점수 * 표준 단가 = 시스템 개발비

기능 점수와 품질 척도

  • 기능 점수를 이용해 기능 점수당 개발 시간, 결함 밀도, 신뢰성 계산 가능

C07 요구사항 도출

1. 요구사항 개요

  • 요구사항: 소프트웨어 시스템이 수행해야 할 것과 소프트웨어 시스템에 있어야 할 특성을 기술한 문장

요구사항의 분류

  • 기능적 요구사항
    • 사용자의 업무처리와 관련되어 SW 시스템이 수행해야하는 요구 내용
    • 다음 요소를 고려: 기능성, 데이터, 사용자
  • 비기능적 요구사항
    • SW 시스템이 제공해야하는 행위적 속성
    • ex) 고장이 나지 않고 적절한 성능을 계속 제공 해야함
    • 다음 요소를 고려: 운영 요구사항, 자원 요구사항, 성능 요구사항, 보안 요구사항, 문화적/정책적 요구사항, 품질 요구사항
  • 인터페이스 요구사항
    • GUI, 기존 시스템과의 연동

요구사항 정의 품질

  • 다음 현상이 발생하지 않게 주의
    • 노이즈 발생
    • 침묵 발생: 언급되야할 사항이 누락됨
    • 과도한 스펙 명세
    • 모순 발생
    • 모호성
    • 전방 참조: 아직 정의하지 않은 것을 앞서 참고
    • 사실이 아닌 기대 사항: 사실에 근거하지 않고 추측에 근거하는 기대 사항
  • 문서의 품질 요구사항
    • 정확성, 모호성이 없는, 완전성, 일관성, 추적성

2. 요구사항 수집 기법

대면 수집 방법

  • 인터뷰
  • JAD(Joint Application Development) 세션
    • PM, 관리자, 사용자, 개발자가 모여 요구사항 도출을 위해 상호 토론

비대면 수집 방법

  • 문서 분석
  • 설문지 활용
  • 관찰
  • 소셜 네트워크

3. 요구사항 정의서 작성

  • 중대형 프로젝트에서는 요구사항 정의서가 Requirement Baseline을 정하기에 중요하다
  • 모든 요구사항에는 식별자를 부여해야 한다
  • 각문장은 문장의 5형식을 따라 의미를 정확히 표현해야 한다
  • 각 요구사항을 정의하는 문장은 복문이 아닌 단문으로 작성되야 한다
  • 요구사항별 우선순위를 부여한다
  • 요구사항을 그룹핑해서 체계화한다

C08 객체지향 분석

1. 객체지향과 UML

객체지향 모델링

  • 객체지향 모델링: 실세계의 사물과 개념을 객체로 정의하여 표현하고자 하는 시도
  • 다음 특징을 반영: 클래스와 오브젝트, 캡슐화와 정보 은닉, 상속, 다형성

UML 모델링 언어

  • UML(Undified Modeling Language)을 구성하기 위한 다양한 다이어그램이 존재한다
    • ex) 유즈 케이스 다이어그램, 클래스 다이어그램, 순차 다이어그램
  • 이런 다이어그램을 표현하기 위한 기본 모델 요소는 정의되어 있다

2. 기능 모델링

기능 모델링 개요

  • 기능 모델링: 사용자로부터 도출한 요구사항을 입력받아 SW 시스템이 해야 할 기능이 무엇인지를 식별해가는 과정

유즈 케이스 다이어그램

  • 유즈 케이스 다이어그램: 시스템의 최상위 수준에 해당하는 기능을 사용자 관점으로 나타내는 것
    1. 요구사항 정의 내용을 검토한다
    2. 요구사항을 토대로 시스템의 경계를 설정한다
    3. 경계가 설정된 시스템에 대한 명칭(시스템 명)을 정의한다
    4. 시스템 외부에 존재하는 액터를 식별하고, 각 엑터의 역할을 정의한다
    5. 각 액터가 시스템에서 사용하는 기능을 식별한다 → 유즈 케이스
    6. 식별된 사용자 기능과 액터 간의 관계를 정의한다
    7. 식별된 사용자 기능에 대한 설명서를 작성한다

유즈 케이스 설명서

  • 유즈 케이스 설명서는 유즈 케이스 식별 정보와 유즈 케이스에서 처리해야 하는 기능의 상세한 흐름을 나타낸다
  • 유즈 케이스 설명서는 유즈 케이스 식별부, 정상 시나리오 정의부, 예외 처리 정의부로 이루어져 있다
  • 유즈 케이스 식별부
  • 정상 시나리오 정의부
    • 단계별로 유즈 케이스의 내부 기능을 작성한다
  • 예외 처리 정의부

3. 구조 모델링

  • 구조 모델링은 비즈니스에서 사용되는 용어들을 이용하여 객체들을 정의함으로써, 실세계와 SW의 의미적 차이를 줄이는 작업

객체 식별

  • 객체를 클래스로 정의한다, 이때 기능 모델링을 통해서 작성된 유즈 케이스 설명서를 이용하여 식별한다
  • UML에서 클래스는 클래스명, 클래스 속성, 클래스 연산의 3요소로 구성된다
  • 구조 모델링 과정에서 클래스를 식별하기 위한 4가지 방법
    • 문장 분석
    • 일반 객체 목록
    • 브레인스토밍
    • 패턴 적용

클래스 명세

  • 클래스가 식별되면 클래스에 대한 명세가 필요하다
  • 클래스 명세는 CRC(Class-Responsibility-Collaboration) 카드를 이용해 작성된다
  • 구성 요소
    • 기본 정보 명세: 클래스 이름, 식별자, 클래스 타입, 클래스 설명, 관련된 유즈 케이스 식별자, 클래스의 책임, 협업 관계
    • 속성 및 연산 명세: Attributes(멤버 변수, 속성 목록)과 Relationship(연산, 다른 클래스와의 관계)를 나타낸다

클래스 다이어그램 작성

  • 클래스 다이어그램은 SW의 구조를 나타내는 정적 모델이다
  • 각 클래스가 갖는 속성과 연산을 점검하고 정제한 후 클래스 간의 관계를 부여한다
  • 관계의 유형
    • 일반화 관계: ~ 이후 정리 ~
    • 집합 관계
    • 연관 관계
    • 속성 가시성
    • 관계 기수성

4. 행위 모델링

  • SW에 대한 기능 모델링과 구조 모델링이 이루어지면 행위 모델링을 수행한다
  • 행위 모델은 시스템의 내적인 동작을 표현하는 다이어그램으로, 객체 간의 어떤 상호작용이 발생하는지를 나타낸다
  • 행위 모델링은 클래스가 아닌 객체를 기준으로 작성된다
  • 행위 모델링은 UML의 동적 모델에 해당하며, 엑티비리 다이어그램, 순차 다이어그램, 통신 다이어그램, 상태기계 다이어그램 등을 이용하여 모델링된다.

순차 다이어그램 구성 요소

  • 순차 다이어그램은 객체간의 상호작용, 즉 메시지 패싱에 대한 행위를 시간 축을 중심으로 나타낸다.
  • 구성 요소
    • 참여 객체: 클래스 다이어그램에 존재하는 클래스의 객체, 상호작용은 왼쪽에서 오른쪽으로 진행하도록 표현
    • 시간 축: 시간의 흐름을 나타내면 위에서 아래 방향으로 나타낸다, 점선으로 표시
    • 실행 사건: 메시지 전달은 실행 동작내에서 이루어져야 하는데, 실행 동작 발생 기간을 길쭉한 사각형의 실행 사건으로 표현
    • 메시지 전달: 객체간의 함수 호출을 의미한다. 화살표로 표시하며 화살표에는 메서드와 매게변수가 나타난다
    • 제어 로직: 선택, 반복, 벙렬 처리등의 SW 행위를 표현한다. 순차다이어 그램에서 표현할 때 결합형 심볼이라고 한다
    • 결합형 심볼
      • Alternative: 선택을 나타내는 제어 로직
      • Loop: 반복 처리를 나타내는 제어 로직
      • Parallel: 행위들을 병렬로 처리하는 경우를 나타내는 제어 로직

순차 다이어그램 작성

  • 순차 다이어그램은 기능 모델링의 결과로 식별된 유스 케이스별로 작성한다

상태기계 다이어그램 작성

5. 분석 산출물 점검

  • 기능 모델과 구조 모델: 유즈 케이스 설명서와 CRC 카드 간의 일관성을 점검한다
  • 기능 모델과 행위 모델: 순차 다이어그램 개수 = 유스 케이스 개수
  • 구조 모델과 행위 모델: 상태기계 다이어그램은 클래스의 인스턴스와 맵핑, 순차 다이어그램에서 객체 간의 메시지는 반드시 클래스의 연산으로 정의
728x90