부록 - 시험대비) 요약정리

충남대학교 컴퓨터공학과 김현수 교수님의 "소프트웨어 공학" 강의를 필기한 내용입니다.

다소 잘못된 내용과 구어적 표현 이 포함되어 있을 수 있습니다.

일단 핵심 포인트 §

• 프로젝트 관리 방법론
• 프로젝트 개발노력 추정 - Function point model, Object point model
• 프로젝트 일정 관리 - PERT / CPM차트(간략한버전, 임계경로, 최소시간, 여유시간), 간트차트
• (인적자원관리 / 위험관리) - 보너스
• 도메인 분석
• 기능성 / 비기능성 요구사항 (예시를 적고 그렇게 분류한 이유를 적으라는 식으로 나오는듯)
• 요구사항 명세서 작성했던거 한번 쭉 검토하며 복기
• 유스케이스 모델링
• 클래스 모델링

프로젝트 관리 방법론 §

Waterfall(Phased) Model §

• 구분이 명확한 단계가 존재하고 이전 단계가 끝난 이후에 다음 단계로 진행하며 피드백은 바로 전 단계한테 하는 구조
• 장점은 요구사항이 한정된 대규모 프로젝트에서 도움이 되고
• 단점은 요구사항 변경에 유연하지 못하고 단계가 전환될때 많은 노력이 필요하며 초기단계가 너무 오래걸릴 위험이 있고 쓸데없는 문서를 생산해낼 가능성이 있다는 것이다.

Prototype Model §

• 인간-기계 상호작용 프로토타입 : 피그마로 UI 시나리오 그려보는거
• Working prototype : 프로젝트의 핵심적인 부분만 만들어보는 것
• Throw-away prototype : 요구사항을 이해하기 위해 대충 만들어보는거
• 과정은
  1. 요구사항 분석과 시스템 분석, 설계를 모두 끝내고
  2. 프로토타입을 만들어보고 평가한 뒤
  3. Full-scale development에 들어가는 것

Incremental Model §

• 얘는 기능별로 쪼개서 릴리즈 계획을 잡거나 완성도를 기준으로 쪼개서 릴리즈 계획을 잡아 단계적으로 배포내가나는 것
• 분석과 계획은 처음 한번만 하고, 이후 계단을 올라가듯이 단계적으로 설계 / 구현 / 릴리즈하는 것이 특징

Spiral Model §

• 계획 - 위험분석 - 구현 - 평가의 과정을 계속해서 반복하며 나선형으로 점점 원이 커저가는 느낌으로 개발하는 것

Evolutionary Model §

• 얘는 Spiral Model이랑 비슷하게 계획 - 설계 - 구현 - 배포의 과정을 반복하지만 Spiral Model이랑의 차이점은
• 위험분석의 과정을 하지 않는 다는 것, 계획 / 설계 / 구현 / 배포의 경계가 명확하지 않고 4개를 병렬적으로 진행하되 비중의 차이만 두는 것이다

Agile Model §

• 기획에서 배포까지의 사이클을 짧게 여러번 반복적으로 하는 것
• 점증적 설계를 하기 때문에, 설계가 자주 변경될 수 있는 경우 적합하다

프로젝트 모델 선정 §

• 일반적인 구축 - Waterfall model
• 소규모 - Agile model
• 연구, 타당성 검토 - Spiral / Prototype model
• 대규모, 임베디드 - Spiral / Evolutionary model

Verification & Validation §

• V-Model을 이용
• 기획, 설계에서 어떤 테스트를 진행할 것인지도 기획했다가 개발 이후 기획한 테스트를 진행하는 것

프로젝트 관리 §

Function Point Model §

• 먼저 Unadjusted Function Point를 계산함
  • 컴포넌트의 갯수 * 컴포넌트 분류에 대한 가중치 총합을 더함
  • 컴포넌트 분류에 대한 가중치는 외부 입력, 외부 출력, 외부 질의, 내부 논리파일, 외부 인터페이스 파일이고 각각에 대해 높음, 중간, 낮음의 가중치가 있음
• 그리고 Value Adjust Factor를 계산함
  • 뭐 데이터통신, 유지보수성 등등에 대한 14개 기술적 분야에 대해 0~5의 점수를 매겨 이걸 다 더한 후 0.01을 곱해서 더함
• 그리고 UFP랑 VAF를 곱해주면 Adjusted Function Point가 나옴
• AFP는 프로젝트 규모에 대한 지표이고, 이것을 사람 1명이 1개월동안 할 수 있는 능력치인 nFP / MM를 나눠주면 해당 프로젝트를 사람 1명이 몇개월동안 해야 다 끝내는지 결론내려지게 되는 것

Object Point Model §

• 클래스가 몇개나 필요할지에 대한 숫자인 Cc를 구한다
• 클래스 구현의 복잡도인 Wi에 대한 점수를 부여하고, 여기에 1을 더해 Cc와 곱한다. - 이것이 TCc임
• TCc에다 사람 한명이 클래스 하나를 개발하는데 걸리는 일수인 MD를 곱하면 최종적으로 사람 한명이 모든 클래스를 개발하는데 걸리는 일수 추정치가 나오게 된다

PERT / CPM Chart §

• Activity : 가시적인 산출물이 나오는 활동
• Duration : 영업일수 기준 걸리는 일수
• Dependencies : 이 활동을 하기 위해서 어떤 활동이 선행되어야 하는지
• Milestone : 배포 등과 같은 중요한 이벤트
• PERT / CPM차트는 Activity와 Milestone을 Node로 하고, Dependency를 Edge로 하는 그래프이다
• 그리고 Activity Node들에 대해서는 Duration을 명시하고 영업휴일을 고려한마감일자를 적어주면 PERT / CPM차트 그리는 것은 끝난다
• Critical Path라는 것은 프로젝트를 마무리하기 위한 최소시간으로, 모든 노드를 병렬적으로 다 방문하는데 걸리는 최소 시간을 의미한다
• 이것을 구하는 방법은 시작부터 끝까지의 경로 중 제일 오래 걸리는 경로를 구하면 된다

Gantt Chart §

• 뭔지는 알제? 가로축을 시간으로 하고 세로축을 Activity로 하는 차트
• 여기서 여유시간 개념만 좀 알아두라 - 해당 Activity의 Dependency를 고려해서 언제까지 지연되어도 문제가 없는지

Agile Process Planning §

• Activity와 그에 들어가는 노력들이 종합적으로 측정된 Story Card를 준비하고
• 우선순위가 높고 선행조건이 없는 Story Card부터 먼저 시작하는 것으로 하되 한 사이클당 Story Card의 총점이 일정 수준(보통 9점)을 넘지 않도록 배치한다

인적 자원 관리 §

• 계층구조를 가진 Hierarchy Team
• 수평구조를 가진 Egoless Team
• 계층구조와 수평구조를 섞은 Chief Programmer Team : 메인 개발자와 서브가 있어 어느정도 수평적인 구조를 가지면서도 메인 개발자가 중요한 결정을 내리게 해 의사결정이 지체되지 않도록 함

프로젝트 위험 분류 §

• 팀원이 나가는 Staff turnover 경우에는 일정과 인적 자원에 영향을 미치므로 Project Risk
• 제품을 개발하는데 필요한 케이스 도구(뭐 코드 생성기 같은 느낌인듯)의 성능이 생각보다 좋지 않은 CASE tool under-performance의 경우에는 제품의 품질이 안좋아지므로 Product Risk가 되는 것
• 경쟁사에서 먼저 상품을 내놓는 Product competition의 경우에는 우리 제품의 판매량이 저조할 우려가 있으므로 Business Risk가 되는 것

요구사항 분석 §

도메인 분석 §

• ATM을 개발한다고 할 때의 도메인은 은행 업무 이고 도메인 전문가는 은행원 이 된다
• 우리의 프로젝트가 해결할 수 있는 모든 문제에 대해 생각해보고 그 중에서 특정 문제만 골라 그것으로 범위를 한정하는 식으로 범위를 설정한다

요구사항 분석 §

• 기능적 요구사항은 일반적으로 생각했을 때의 기능
• 비기능적 요구사항은 아래와 같음
  • 소프트웨어의 품질 특성 측면
    • 반응시간 : 요청에 대한 결과가 얼마나 빠르게 나오는 지
    • 처리량 : 분당 처리 트랜잭션의 수가 몇개인지
    • 자원 사용량 : 사용하는 메모리, 전기 등의 자원은 얼마정도인지
    • 신뢰성 : 시스템이 고장나지 않고 제대로 동작할 가능성은 얼마나 되는지
    • 가용성 : 시스템이 실행되고 준비되어있는 시간은 얼마나 되는지 - Down-Time(DT) 은 기준 시간(예를들어 1년) 중에 얼마나 되는지
    • 고장에서의 회복 : 고장으로 인해 발생할 수 있는 피해의 최대치는 어느정도인지
    • 유지보수, 확장, 재사용성의 허용 : 유지보수나 시스템의 확장, 그것을 재사용하는 것이 어느 정도까지 가능한지
  • 환경과 기술적 측면
    • 플랫폼 : 소프트웨어가 돌아가는 환경 - 뭐 예를 들면 최소 램 4Gb짜리 윈도우 컴퓨터에서 돌아갈 수 있도록 해라
    • 사용 기술 : 소프트웨어를 만드는데 사용할 프로그래밍 언어나 프레임워크, 라이브러리 등의 기술 - 뭐 예를 들어 전자정부 프레임워크를 이용해 자바로 개발해라
  • 계획과 방법론적인 측면
    • 방법론 : 사용할 개발 프로세스(방법론) - 뭐 애자일을 이용해라 등
    • 비용과 납기일 : 얼마를 이용해서 개발해라, 언제까지 개발해라 - 보통 계약서에 많이 명시됨

요구사항 추출 §

• Joint Application Development : 브레인스토밍을 도와줌
  • 사회자가 한명 있고
  • 각자 앞에 종이를 한장씩 주고
  • 토론의 주제인 아이디어가 유도되는 질문을 사회자가 던짐
  • 참가자들은 종이에 아이디어를 하나 적고 옆으로 넘김
  • 옆사람이 준 종이를 받으면 거기에 적힌걸 읽어보고 관련된걸 적거나 아니면 또 다른 아이디어를 내도 됨 - 단, 한번에 하나의 아이디어만 적어야됨
  • 더이상 아이디어가 안나올때까지 돌림

요구사항 명세 §

• 얘네들을 적어라
• User Interface : 사용자와 상호작용하는 인터페이스
• Hardware Interface : 하드웨어와 상호작용하는 인터페이스 - 대표적으로 어떤 머신에서 소프트웨어가 돌아가는지
• Software Interface : 소프트웨어와 상호작용하는 인터페이스 - 대표적으로 어떤 OS에서 소프트웨어가 돌아가는지, 어떤 다른 소프트웨어와 상호작용하는지
• Communication Interface : 통신 프로토콜과 관련됨 - 어떤 프로토콜을 써서 다른 sw와 통신하는지
• 그리고 기능적, 비기능적 요구사항을 적되 각각의 요구사항에는 유일하게 구별이 가능한 식별자, 요구사항 분류, 세부 내용, 산출 정보, 관련된 요구사항을 적어라

유스케이스 모델링 §

분석하기 §

• 유스케이스 : 계좌 출금 요청 이라는 유스케이스는 잔고가 충분한 계좌에서의 출금 이랑 잔고가 부족한 계좌에서의 출금 이라는 시나리오들로 구성될 수 있는 것
  • 반드시 액터에 의해 개시되어야 함
  • 반드시 액터에게 결과물을 주어야 함
  • 특정 기능의 일부만 제공하는 것이 아닌 완전한 기능 전부를 제공해줘야됨
• 액터 : 은행 시스템의 경우에 대출을 담당하는 사람은 대출 담당 역할 을 맡고 있는 것이고 해당 은행에 계좌를 가지고 이용하는 사람은 고객의 역할 을 맡고 있는 것
  • 주 액터 : 시스템을 사용하는 대상
  • 부 액터 : 기능이 잘 작동하도록 도와주는 대상
  • Initiating Actor : 유스케이스를 실행시키는 대상
  • Participating Actor : 유스케이스를 사용하는 대상

Use Case Diagram §

• 가운데 사각형이 시스템, 그 밖에 액터, 사각형 안에 유스케이스 타원형으로 그림
• 각 액터가 사용하는 유스케이스를 선으로 이음
• 유스케이스와 액터들은 일반화할 수 있음
• 반복해서 사용되는 유스케이스는 include관계를 이용해 별도로 분리할 수 있음
• 특정한 경우에만 추가적으로 수행되는 유스케이스는 extend관계를 이용해 별도로 분리할 수 있음 - 이 때에 분리된 놈이 Extension Usecase이고 이놈이 실행되는 특정 지점이 Extension point가 됨
• 주의할 점은 일반화, include, extend의 관계는 유스케이스가 단순화되는 것이 명백할 때에만 사용해야 된다는 것과
• 기능별로 include를 다 쪼개는 식으로 구성하면 안된다는 것 - 계층구조는 최대 2단계가 적당하다
• 또한 순서에 대한 것은 유스케이스 다이어그램에 표현되면 안된다 - 화살표같은거 쓰지 말아라 이거야

Use Case Description §

• 각각의 유스케이스들에 대해 설명
• Precondition : 해당 유스케이스가 실행될 수 있는 선행조건
• Postcondition : 해당 유스케이스가 종료되고 나서 만족해야 할 조건
• Main flow : 유스케이스의 핵심적인 진행과정
• Alternative flow : 에러가 나거나 했을 때의 진행과정

클래스 모델링 §

선의 종류 §

• 그냥 실선은 서로 연관이 있다는 것
• 일반 화살표, Aggregation, Composition은 모두 이 연관관계의 서브셋임
  • 일반 화살표는 화살표가 나오는 놈이 가르키는 놈을 참조할 수 있고 반대는 안된다는 것
  • Aggregation은 전체와 부분의 관계를 나타냄 : 마름모가 있는 곳이 전체
  • Composition은 전체와 부분이긴 한데 해당 전체에 독점적일때 : 다른 곳에서는 사용될 수 없는 부분에 대해서 - 검은색 마름모가 있는 곳이 전체
• 세모꼴 화살표는 일반화 관계 : 세모가 있는 곳이 부모

라벨의 종류 §

• Cardinality, Multiplicity, 다중성 : 1이면 생략가능, 0이상이면 * , 범위표현은 1..*
  • 다중성 읽는 방법은 주어에 들어갈 놈을 설정하고 그놈과 연관되어 있는 놈 하나를 목적어로 한다음 목적어에 가까이 있는 숫자가 주어와 연관될 수 있는 목적어의 갯수가 되는 것
• 관계의 이름 : 관계의 이름도 적어줄 수 있고 읽는법은 다중성과 동일하며 해당 이름은 클래스의 필드명으로 사용됨

연관 클래스 §

• 두 클래스가 연관되었을 때 의미가 있는 필드가 있다면 해당 필드는 연관 클래스에 명시함
• 연관 클래스는 두 클래스 연관관계 실선 중간에 점선으로 이어서 명시할 수 있음
• 또는 A ( 1..* ) B ( *..1 ) C 의 연관관계로도 표현이 가능

재귀 연관관계 §

• 과목 A는 과목 B의 선행과목일때 A와 B는 모두 과목이므로 과목 클래스를 재귀 연관관계로 표현해줄 수 있는 것
• 실선이 자기자신에게로 돌아가는 환형형태로 그리면 됨
• 그리고 선후를 관계 이름으로 양쪽에 적어주면 됨
• 잘 모르겠으면 일단 두 클래스를 그리고 관계 다중성이랑 이름 적고 클래스 두개를 겹치면 된다

인스턴스 다이어그램 §

• 다른건 다 동일한데 이것만 지키면 됨
• 인스턴스 이름 : 클래스 이름 → 인스턴스와 클래스 이름을 모두 적고 :로 구분해주며 밑줄그어줘야 한다.