소프트웨어 공학.md

소프트웨어 공학 수업 기말고사 대비 정리입니다.

---

소프트웨어 공학

• 공학에는 정해진 기간과 주어진 비용이라는 제한이 있기에, 문제 해결을 위한 기술과 공학적 원리를 활용해야 한다.
• 그리고 이를 실무에 적용해 문제 해결의 절차를 만들고 반복적인 절차를 개선해 표준을 만들어낸다.
• 소프트웨어 개발의 어려움을 해결하기 위해 공학을 적용하는 것이 소프트웨어 공학이다.

비용 산정 기법

• 하향식
  • 전문가 판단 기법
  • 델파이 기법: 전문가의 편견에 영향받지 않도록 조정자를 둠
• 상향식
  • 코드 라인 수(Line Of Code): 코드 라인 수를 구하고 노력 산정
  • 개발 단계별 노력 기법: 각 단계의 노력 투여를 맨먼스(M/M)로 구함
• 수학적
  • COCOMO: 라인 수를 추정하고, 이를 준비된 식에 대입해 M/M 계산 (가중치 및 보정 계수 반영)
  • COCOMO 2: 개발 초기에서 라인 수를 예측하기 어려운 점을 고려해, 애플리케이션 설계 정보로 계산
  • 기능 점수 산정 방법: Function Point로 구함
  • 간이 기능 점수법: 내부 논리파일, 외부 연계 파일, 입출력, 조회에 따른 가중치로 측정

일정 계획

• 작업 분할 구조도(WBS): 일정 계획의 시작
• 일정 계획 기법
  • 네트워크 차트: CPM 네트워크를 그리고, ES(가장 빠른 시작 시간)과 EF(가장 빠른 완료 시간), LS(늦어도 시작해야하는 시간), LF(작업을 가장 늦게 끝낼 수 있는 시간), ST(여유 시간)을 구한다.
  • 간트 차트: 프로젝트의 주요 활동을 파악한 후, 각 활동의 일정을 시작하는 시점과 끝나는 시점을 연결한 막대 모양으로 표시해 전체 일정을 한눈에 볼 수 있게 한다.

디자인 패턴

• 여러가지 설계 사례를 분석해 비슷한 문제를 해결하기 위한 설계로 분류하고 유형별로 가장 적합한 설계를 일반화해 패턴으로 정립한 것
• 노하우를 문제 유형별로 구체화 및 일반화한 것임.

애자일

https://resources.scrumalliance.org/Article/key-values-principles-agile-manifesto

애자일 개발 4가지 핵심 가치

1. 프로세스와 도구보다는 개인과 상호작용에 더 가치를 둔다.
2. 방대한 문서보다는 실행되는 SW에 더 가치를 둔다.
3. 계약 협상보다는 고객과 협업에 더 가치를 둔다.
4. 계획을 따르기 보다는 변화에 반응하는 것에 더 가치를 둔다.

애자일 개발 12가지 실행 지침

1. 유용한 소프트웨어를 빠르고, 지속적으로 제공하여 고객을 만족시킨다.
2. 개발 막바지라도 요구사항 변경을 적극 수용한다.
3. 몇 개월이 아닌 몇 주 단위로 실행되는 소프트웨어를 제공한다.
4. 고객과 개발자가 프로젝트 기간에 함께 일한다.
5. 개발에 대한 참여 의지가 확실한 사람들로 팀을 구성하고, 필요한 개발 환경과 지원을 제공하며, 일을 잘 끝낼 수 있도록 신뢰한다.
6. 같은 사무실에서 얼굴을 맞대고 의견을 나눈다.
7. 개발의 진척도를 확인하는 1차 기준은 작동하는 소프트웨어이다.
8. 지속 가능한 개발을 장려하고 일정한 속도로 개발을 진행한다.
9. 기술적 우수성과 좋은 설계에 지속적인 관심을 기울이면 민첩성이 향상된다.
10. 단순화를 추구한다.
11. 최상의 아키텍처, 명확한 요구사항, 최상의 설계는 자기 스스로 일을 주도하는 조직적인 팀으로부터 나온다.
12. 더 효과적인 팀이 될 수 있는 방안을 정기적으로 깊이 고민하고 그에 따라 팀의 행동을 조정한다.

스크럼

• 서비스 개발 중 지속적으로 개선을 시도할 수 있도록 ‘스프린트(Sprint)’라는 짧은 개발 사이클을 활용하는 프로젝트 관리 방법론.

• 스크럼 팀은 제품 책임자, 스크럼 마스터, 개발팀 3가지 핵심 역할로 구성된다.

• 스프린트(Sprint): 스크럼 패턴을 따르는 일정한 기간

• 제품 백로그(Product Backlog): 제품 개발에 필요한 모든 요구사항(User Story)을 우선순위에 따라 나열한 목록이다.

  • 제품 백로그에 있는 모든 아이템에는 순서, 설명, 추정, 가치라는 4개의 속성이 있다.

• 사용자 스토리(User Story): 제품 기능이 도출되면 각 기능을 간략하게 서술

  • 사용자 스토리는 언제든 변경할 수 있어야 하므로 자세히 서술할 필요가 없음
  • 사용자가 이해할 수 있는 언어와 용어로 작성해야 함
  • 개발 규모가 어느 정도이고 투입 공수는 얼마나 필요할지 개발자들이 짐작할 수 있어야 함
  • 사용자 스토리의 구성 요소 확인을 위해 테스트가 가능한 테스트 케이스를 만들어야 함

UML(Unified Modeling Language)

• 모델링 방법

  • 부치 방법론(Booch Method): 시스템을 분석한 뷰를 모델 다이어그램으로 표현
  • 야콥슨의 OOSE(Object-Oriented Software Engineering): 유스케이스를 강조한 방법론
  • 럼바의 OMT(Object-Modeling Technique): 하나의 시스템을 기술하기 위하여 Object, Dynamic, Functional 모델 세가지를 활용
  • UML: 부치 방법론과 OOSE, OMT를 하나로 합한 방법론, 표준 분석 설계 방법론으로 채택 됨

• UML은 표준화된 통합 모델링 언어, 시스템 개발을 위한 시각적인 설계 표기 제공

• 객체 지향 시스템을 개발할 때 산출물을 명세화, 시각화, 문서화, 구축하는 데 사용

• 개발하는 시스템을 이해하기 쉬운 형태로 표현하여 분석가, 설계자, 의뢰인이 효율적으로 의사소통할 수 있게 해줌

UML 구성 요소

• 사물(Things), 관계(Relationship), 다이어그램(Diagram)의 세 가지 구성 요소로 이루어짐
• 사물로는 정적 사물(클래스, 인터페이스, 통신, 컴포넌트, 패키지, 노드), 동적 사물(인터랙션, 유스케이스, 상태머신), 주해 사물(주석) 등이 있음
• 관계로는 의존 관계, 연관 관계, 일반화 관계, 실체화 관계 등이 있음
• 다이어그램으로는 클래스 다이어그램, 컴포넌트 다이어그램, 배치 다이어그램, 패키지 다이어그램, 유스케이스 다이어그램, 순차 다이어그램과 통신 다이어그램, 활동 다이어그램 ,상태 다이어그램 등이 있음

유스케이스 다이어그램

• 액터(사용자)와 유스케이스로 구성됨
• 유스케이스 사이의 관계
  • 포함 관계: 하나의 유스케이스를 수행할 때, 같은 기능이 있는 다른 유스케이스가 반드시 수행되는 관계 (--<<include>>-->)
  • 확장 관계: 특정 조건에 의해 수행되며 새로운 유스케이스를 만들어내는 관계 (<--<<extend>>--)

클래스 다이어그램

• 클래스 사이의 관계

  • 집합 관계: 하나의 객체가 독립적인 객체 여러 개로 구성되는 경우

  • 복합 관계: 집합 관계보다 좀더 더 강한 관계로 구성되는 경우, 복합 관계는 단독 사용이 불가능하며 반드시 슈퍼 클래스와 함께 사용

  • 집합 관계와 복합 관계는 연관관계에 포함된다.