학교 수업 정리/소프트웨어공학

소프트웨어공학 중간고사 정리 (1)

hjr067 2024. 10. 16. 02:30

내 맘대로 내가 헷갈리는 것들 위주로 정리해본 ...

1. An Introduction to Software Engineering

- sw? : 프로그램 자체, 모든 관련 문서, 라이브러리, 지원 웹사이트, 환경 설정 데이터

소프트웨어 제품은 특정 고객을 위해 개발되거나 범용으로 개발됨

 

[좋은 소프트웨어의 필수적인 특성]

1. 유지보수성(Maintainability)

소프트웨어는 고객의 변화하는 요구를 충족시킬 수 있도록 진화하도록 만들어야 한다. 소프트웨어의 변경은 변화하는 비즈니스 환경에서 필수적인 요구이므로 매우 중요

2. 확실성과 보안성(Dependability and security)

소프트웨어 확실성 : 신뢰성, 보안성과 안전성을 포함하는 여러 특성을 내포한다. 확실성을 보장하는 소프트웨어는 시스템에 장애가 발생하더라도 물리적이거나 경제적인 피해를 야기해선 안된다. 

보안 : 악의적인 사용자가 시스템에 접근하거나 피해를 주지 않도록 해야 한다.

3. 효율성 (Efficiency) - 응답성, 처리 시간, 자원 활용 등을 포함

소프트웨어는 메모리와 프로세서 사이클과 같은 시스템 자원을 낭비해서 사용하면 안된다. 

4. 수용성 (Acceptability)

sw는 설계한 목적에 부합하는 사용자 유형이 수용할 수 있어야 한다. 즉, 타켓층인 사용자가 이해할 수 있어야 하고, 사용하기 쉬워야 하며, 해당 사용자가 사용하는 다른 시스템과 호환도 되어야 한다.

 

[소프트웨어 개발 프로젝트가 실패하는 원인]

-> 예산 초과, 일정 지연(유지보수의 어려움), 낮은 품질의 소프트웨어 개발, 사용자 요구사항 불만족, 산출물 관리의 어려움 등으로 소프트웨어 개발 실패

 

소프트웨어 공학 vs 컴퓨터 과학 

실제적 문제 해결 /  이론

 

소프트웨어 공학 vs 시스템 공학

시스템에 포함된 소프트웨어 인프라, 제어, 응용 프로그램 및 데이터베이스 개발 / 컴퓨터 기반 시스템 개발의 모든 관점 - sw, hw 개발, 정책과 프로세스 설계 및 시스템 설치 등

 

 

2.Project Planning

프로젝트 계획 (프로젝트 팀과 고객이 소통할 때 / 프로젝트 진행 상황을 평가할 때)

: 작업을 여러 부분으로 나누어 프로젝트 팀 구성원에게 할당 → 발생할 수 있는 문제를 예상 →  해당 문제에 대한 잠정적 해결 방안 준비

 

  • 프로젝트 계획 수립은 프로젝트 시작 단계에서 최초의 프로젝트 만들 때 시작하는 반복적 프로세스(계획변경 필연적)

<stage>

- 제안 단계 : 소프트웨어 시스템을 개발 혹은 공급하는 계약을 얻기 위해 입찰할 때

- 프로젝트 시작 단계 동안 : 누가 일할 건지, 어떻게 작업들로 나눌건지, 자원 어떻게 할당할 건지

- 프로젝트 내내 주기적으로: 수정

 

  • 제안 단계에서의 계획의 목적은 고객에게 시스템의 가격을 책정하는데 사용될 정보를 제공하는 것
  • pricing
    • hw, sw, 출장, 교육 및 노력의 비용 고려
    • 조직적, 경제적, 정치적, 비즈니스적 고려 사항
  • sw pricing에 영향을 주는 요소들(시험 ✅)
    • 시장 기회 : 경험 얻기, 낮은 이윤을 수용하는 것은 나중에 더 많은 이윤에 대한 기회를 조직에게 제공 가능성 있음
    • 계약 조건 : 소스 코드의 소유권과 재사용 가능
      • 소스 코드의 소유권을 개발자에게 남겨두고, 재사용을 허용하면, 개발자는 그 코드를 다른 프로젝트에서도 활용할 수 있어 개발 비용이 절감되므로 고객에게 제공되는 가격도 더 저렴할 수 있다는 의미
    • 요구사항 변동성 (*계약을 수주하다 : 사업 계약을 따내거나 얻다)
      • 초기 계약 단계와 계약 후 단계의 가격 책정 방식의 차이
        1. 초기 계약을 수주하는 단계:
          • 요구사항이 변동될 가능성이 있을 때, 조직은 고객을 유지하기 위해 가격을 낮출 수 있다. 이는 타사와의 경쟁에서 우위를 점하고, 고객의 선택을 받기 위한 전략 (초기에는 가격을 낮춰서라도 계약을 따내는 것이 목표)
        2. 계약 후 단계 (변경 요구 발생 시): 
          • 계약을 수주한 이후, 고객이 요구사항을 변경하면, 추가적인 비용을 부과할 수 있다. (원래 계약서에 명시된 범위를 넘는 추가 작업에 대한 대가) 요구사항이 변동될 가능성을 고려하여, 처음에 상대적으로 낮은 가격을 제시하고 나중에 추가적인 수익을 창출할 수 있는 기회로 삼는 것! 이 전략은 실제로 고객과의 장기적인 협상에서 자주 사용된다. 초기에 낮은 진입장벽을 설정해 고객과 계약을 맺고, 나중에 발생할 수 있는 요구사항 변경에 대해 높은 가격을 부과하는 방식으로 리스크를 관리하고 추가 수익을 창출하는 것임
    • 재정 건전성 : 폐업하는 것보다는 적은 이윤을 내는 것이 더 좋음 (어려운 경제 상황에서는 현금 유동성이 이윤보다 더 중요)
    • 비용 추정의 불확실성 : 어떤 조직이 자신의 비용 추정에 대해 확신하지 못한다면, 비상 상황에 대비해 정상적인 이윤보다 많게 가격을 책정할 수 있다.
  • Plan-driven development 프로젝트 계획 : 수행될 작업, 담당할 사람, 개발 일정, 작업 산출물들을 기록하는 것
    • 계획 주도 개발
    • 사전 계획을 중시하는 접근 방법 (장 : 잠재적 문제들 종속성들이 프로젝트 시작전에 발견, 단 : 수정 ↑)
    • 대표적 예 : waterfall 모델 - waterfall 모델에서는 각 단계가 완료된 후 다음 단계로 넘어가며, 변경이 발생하면 추가적인 수정과 재검토 절차가 필요함.
  • Project plan supplements
    • 품질 계획 - 프로젝트에서 사용될 품질 절차와 표준들을 서술
    • 검증 계획 - 접근법, 자원들, 일정
    • 형상 관리 계획 - 형상 관리 절차, 구조
    • 유지보수 계획 - 유지보수 요구사항, 비용, 노력 예측
    • 인력 개발 계획 - 구성원의 기술과 경험을 개발할 방법 기술
  • Project Scheduling
    • 작업을 병행적으로 구성하여 인력을 최적으로 활용
    • 지연을 방지하기 위해 작업들 간 종속성 최소화
    • 프로젝트 관리자의 경험과 상식에 의존
  • MileStones : test를 위한 시스템 인계와 같이 진행 상황을 평가할 수 있는 일종의 지점 - 산출물과 짝궁 !
  • Schedule representation 일정 표현
    • 그래픽 표기법 - 프로젝트를 작업으로 분류한 것(작업은 1-2주 정도 소요)
    • 바 차트(간트 차트) : 달력 기반
    • 액티비티 차트 : 작업 종속성과 임계 경로를 보여줌
      • 임계경로란? 작업이 걸리는데 (끝나는데) 가장 긴 경로 -> 플젝을 완료하는데 필요한 최소 시간 추정가능
  • 비용 추정에 사용할 수 있는 두 가지 유형의 기술
    1. 경험 기반 기법
    2. 알고리즘 비용 모델: Effort = A x Size^B x M
      • A : 조직에 종속적인 상수
      • B : 소프트웨어의 복잡도 (단순.. 중간 정도 ..)
      • M : 제품, 프로세스 및 사람 속성을 반영하는 승수
      • M과 M에 기여하는 요인들의 추정치가 주관적이며, 추정자의 판단에 따라 달라짐
      • algorithm cost modelling
        • The COCOMO model : 경험에 기반한 실증적 모델, 문서화, 독립적, 개발, 재사용
  • Size related mesures
    • LOC 코드라인
    • 기능 점수(UFP) - 각각 연관된 가중치가 존재 - 각 유형의 요소에 가중치를 곱하고 모든 값을 합산하여 계산
      • 기술 복잡도 항목 TCF = 0.65 + 0.01 x DI
      • 최종 기능점수 FP 계산을 위한 기술인자
        • 영향도 DI ; 14개의 factor들 각각에 0~5의 가중치 값을 부여한 후 14 factor들의 가중치 값을 더한다.
        • FP =  UFP x TCF
      • 코드 크기 = AVC x 기능 점수
        • AVC (평균 코드 줄 수)
          • 200 - 300 LOC/FP → 어셈블리 언어
          • 2-40 LOC/FP → 데이터 베이스 프로그래밍 (SQL)
    • COCOMO 2 models
      • 더 자세한 추정치를 생성하는 여러 서브 모델
        • 애플리케이션 결함 모델 : 기존 컴포넌트들을 이용하여 소프트웨어를 구성할 때 사용
        • 초기 설계 모델 : 요구사항이 도출된 이후 시스템 설계의 초기 단계 동안 사용
        • 재사용 모델 : 재사용 가능한 구성 요소들을 통합하는 노력을 계산할 때 사용
        • 포스트 아키텍처 모델 : 시스템 아키텍처 설계이후, 시스템에 대한 추가정보가 제공되면 사용
    • COCOMO 81
      • 개발 영향력 추정(person per month)
      • KDSI
      • mode 결정
        • simple mode (simple, 잘 문서화 가능, 이미 다 알고 있는) 2.4(KDSI)^1.05
        • moderate mode 3.0(KDSI)^1.12
        • embedded mode (complex) 3.6(KDSI)^1.20
      • 총 계산 Nominal effort x M (person-months)

3. Software Processes

  • 반드시 포함되는 활동
    • 명세화 : 소프트웨어 시스템이 해야 할 일을 정의 (하기 위해 관련 스펙이 있어야 함)
      • 시스템 개발하기 위해 어떤 서비스가 필요한지를 이해하고 정의하며, 시스템의 운영과 개발에 대한 제약사항을 찾아내는 프로세스 
      • 타당성 조사(타당성 조사 보고서) → 요구사항 도출과 분석(시스템 모델) ↔ 요구사항 명세화(사용자/시스템 요구사항) ↔ 요구사항 검증(요구사항 문서) : 여기로는 다 올 수 있음
    • 설계 및 구현 : 시스템의 구조를 정의하고 구현
      • 설계와 구현은 밀접하게 관련되어 있으며 중첩될 수 있음
      • 설계 
        • 아키텍처 설계 : 시스템 전체 구조, 주요 구성 요소(모듈=하위시스템)
        • 인터페이스 설계
        • 컴포넌트 설계  : 각 시스템 구성 요소의 작동 방식
        • 데이터베이스 설계
    • 검증 및 확인 : 소프트웨어가 고객이 원하는 것과 일치하는지 확인
      • 컴포넌트 테스트(개별 구성요소 독립적으로) -> 시스템(전체) 테스트 -> 수락 테스트(고객측에서 진행)
    • 진화 : 변화하는 고객의 요구를 만족시키기 위해 진화 (계속 고쳐나갈 부분이 생기게 됨)
더보기

단계별 순서

1. 설계

2. 검증 및 확인

3. 진화

<Software Process> ; 일부 조합해서 사용

  1. 폭포수 모델(waterfall model) - 대규모 시스템
    • 개발 프로세스를 별도의 식별된 단계로 나누어 표현
    • 위에서 아래로 (진화 제외)
    • 각 단계가 끝나고 넘어가면 이전 단계로 돌아갈 수 X
    • 계획 중심 특성(Plan-driven development): 여러 사이트에서 개발되는 대규모 시스템 엔지니어링 작업 조정도움
    • 고객 요구사항 변경 요구 대응 어려움
  2. 점증적 개발(Incremental development model) - 변화에 유연 ! 내가 만들어야하는 덩어리 10개 → 1번에 싹 다 x 핵심 3가지 먼저 .. 이런식으로 !
    • 고객 요구사항 변경을 수용하는 비용이 절감
    • 초기에 아이디어 하나 개발해놓고, 여기서 사용자 등의 피드백 받아 계속해서 요구된 시스템이 될 때까지 진화하는 것.
    • 이미 진행된 개발 작업에 대한 고객 피드백을 더 쉽게 얻음
    • 개발 프로세스 중 요구가 변할 수도 있는 경우에 폭포수보단 점진적 개발이 더욱 적합
    • user에게 유용한 sw를 빠르게 전달, 배포 가능
    • 폭포수에 비해 갖는 세 가지 장점:
      1. 구현 요구 변화에 대한 비용 절감
      2. 사용자 피드백을 개발에 도입하기 쉬움
      3. 사용자에게 이른 시간에 유용한 소프트웨어 배달 및 배포 가능
      관리자적 측면에선 두 가지 문제:
      1. 프로세스가 가시적이지 않음
      2. 새로운 무언가가 추가될 때마다 시스템 구조가 악화됨
  3. 재사용 기반 소프트웨어 공학 모델(Reuse-oriented)
    • 기존 구성 요소 or COTS 통합되는 체계적인 재사용
    • 요구사항 명세화 -> 컴포넌트 분석 -> 요구사항 수정 -> 재사용 가능한 시스템 설계 -> 개발 및 통합 -> 시스템 검증
    • 개발할 소프트웨어의 양이 줄어 비용과 위험 부담이 줄어든다는 장점
    • 더 빠른 배포 가능하지만 요구 부분에서 감안하고 합의봐야만 하는 부분들이 있어 실제 사용자의 수요와 맞지 않을 수도...! (요구사항 타협은 불가피)
    • 게다가 재사용 성분의 새 버전이 나오면 시스템 진화에 제어가 떨어짐
  4. 애자일(Agile) : 점증적 개발과 유사한 상태, 최근 많이 사용됨!
    • 반복적이고 점진적인 개발
      • 반복주기 -> 스프린트(각 스프린트마다 새로운 기능이 개발된다 !!)
    • 팀의 협업 강화
    • 요구 명세가 시스템 개발의 독립된 개체가 아니라, 일부분으로 간주. 점진적 개발할 땐 각 시스템 개선 사항마다 비형식적으로 요구 명시.
    • 초기에 증가할 부분을 정하지만 나중에 어떻게 증가할지는 진행 상황과 소비자의 우선 순위에 따라 결정
    • 설계 프로세스가 딱히 문서가 아니라 프로그램의 코드 자체가 문서가 될 것(형식적 문서 X)
    • 애자일에서는 개발하는 코드에 집중하기에 의도적으로 형식이나 문서화를 피하려고 함.(프로세스 관리 어렵)
    • Agile Framework 중 린(Lean)
      • 낭비 요소를 제거하고 사회에 더 많은 혜택을 제공
      • 7원칙 : 전체를 최적화하라, 낭비를 제거하라, 학습을 확대하라, 통합체계를 구축하라, 팀에 권한을 위임하라, 최대한 빨리 배포하라, 최대한 늦게 결정하라(중간에 상황이 바뀔 수 있으니)

[변화에 대응하는 방법]

   [Reducing the costs of rework]

   - 모든 대규모 sw 프로젝트에서 변경은 불가피

  1. 프로토타이핑
    • 아이디어 시연 → 시스템의 초기 버전
    • 요구공학 프로세스에서, 시스템 요구사항 도출과 검증에 도움을 줌
    • 설계 프로세스에서 소프트웨어에 선택가능한 옵션 탐색, UI 개발을 위해 사용
    • 사용성 향상, 디자인 품질 향상, 개발 노력 감소
    • 보여주기식으로 빠르고 신속하게 만들어야 하기에 기능에만 집중 → 다른 요구사항을 만족시키기 어려울 수 O
    • 잘 이해되지 않는 제품 영역에 초점(신뢰성-오류 검사, 복구는 포함 안될지도?)
    • 비기능 요구사항 < 기능 요구사항
  2. 점증적 인도
    • 개발과 인도를 통합시켜서 개발 마친 증가분 일부를 고객에게 전달
    • 가장 높은 우선 순위 요구 사항이 초기 증분에 포함
    • 추가적 요구사항은 현재 증분에 대해서는 요구 사항 동결(요구사항 오더라도 다음 개발에 반영)

   3. Boehm's spiral model(나선형)

  • 리스크(개발자 탈주 등)에 특화된 개발 프로세스 모델
  • 리스크는 process 전반에 걸쳐 명시적으로 평가되고 해결
  • 나선형 모델은 폭포수 모델의 제어와 프로토타입 모델의 반복성을 결합한 단계적 모델. 점진적 모델과 비슷한 개념의 프로세스 모델. 프로토타입을 점진적으로 발전시켜, 누락되거나 추가된 요구사항을 반영 가능
  • 목표 설정 -> 위험 평가 및 감소 -> 개발 및 검증 -> 계획(검토 후 나선형의 다음 단계를 계획)