시험에 자주 출제되는 것만 정리했음. 기본서는 따로 공부할 것.(왜냐면 시험이 일주일 남았음..)

소프트웨어 개발 모형

소프트웨어 생명주기(Software Life Cycle)

• 소프트웨어 제품의 개념 형성에서 시작하여 운용/ 유지보수에 이르기까지 변화의 모든 과정이다.
• 타당성 검토 → 개발 계획 → 요구사항 분석 → 설계 → 구현 → 테스트 → 운용 → 유지/보수

SW 개발 설계 모델

폭포수 모형 (waterfall model)

• 선형 순차 모형으로, 각 단계가 끝날 경우 결과물이 명확히 나와야한다.
• 개발 단계는 위의 생명 주기와 같으며 총 6단계의 과정을 거친다.
• 상위 단계를 완료하지 않으면 후에 심각한 영향을 준다는 것이 특징이며 고객의 요구가 개발 단계의 후반이 돼서야 확인 할 수 있다는 점이 있어 소규모 개발에 적합하다. 고전적

프로토타입 모형 (prototype model)

• 폭포수 모형의 요구사항 변경에 따른 어려움을 보완한 모형으로 사용자의 요구사항을 충실히 반영한다.
• 실제 상황 전에 가상의 시뮬레이션을 통하여 최종 결과물에 대한 예측을 할 수 있다.
• 프로젝트의 관리가 용이하고, 노력과 비용을 절감한다.
  

나선형 모형 (spiral model)

• 폭포수 모형과 프로토타입 모형의 장점을 융합한 모델.
• 소프트웨어 개발 중 발생할 수 있는 위험을 관리하고 최소화하는 것이 목적이다.
• 비용이 많이 들거나 시간이 많이 소요되는 대규모 프로젝트에 구축 시 유리하다.
  

예시: 프로토타입을 지속적으로 발전시켜 최종 소프트웨어 개발까지 이르는 개발 방법으로 위험 관리가 중심인 소프트웨어 생명주기 모형은?

나선형 모형(spiral model) - 위험 관리가 핵심. 위험+모형이 나오면 무조건 나선형 모형(spiral model)

애자일(Agile) 개발 방법론

• Agile: 날렵한, 재빠른 이란 사전적 의미, 양궁으로 쏴서 날라가는
• 특정 방법론이 아닌 소프트웨어를 빠르고 낭비 없이 제작하기 위해 고객과의 협업에 초점 두고 소프트웨어 개발 중 설계 변경에 신속히 대응하여 요구사항을 수용할 수 있다.
• 절차와 도구보다 개인과 소통을 중요시하고 고객과의 피드백을 중요하게 생각한다. 고객이 원하는 기능과 맞는지 아닌지만 중요.
• 소프트웨어가 잘 실행되는데 가치를 두며, 소프트웨어 배포 시차를 최소화할 수 있다.
• 특징
  짧은 릴리즈와 반복, 점증적 설계, 사용자 참여, 문서 최소화, 비공식적인 커뮤니케이션 변화
• 종류 21.5
  • 익스트림프로그래밍(XP, eXtremeProgramming)
  • 스크럼(SCRUM)
  • 린(Lean)
  • DSDM(Dynamic System Development Method): 동적 시스템 개발 방법론
  • FDD(Feature Driven Development): 기능 중심 개발
  • Crystal
  • ASD(Adaptive Soflware Development): 적응형 소프트웨어 개발 방법론
  • DAD(Disciplined Agile Delivery): 학습 애자일 배포

XP(eXtremeProgramming)

걍 고객 중심 소통, 빠르게 개발, 유지/보수 쉽게 이런 키워드를 생각하자.

• 1999년 Kent Beck이 제안하였으며, 개발 단계 중 요구사항이 시시각각 변동이 심한 경우 적합한 방법론이다.
• 요구에 맞는 양질의 소프트웨어를 신속하게 제공하는 것을 목표로 한다.

XP 핵심 가치 20.9, 20.6

• 소통(Communication) : 개발자, 관리자, 고객 간의 원활한 소통을 지향한다.
• 단순성(Simplicity) : 부가적 기능 또는 미사용 구조와 알고리즘은 배제한다.
• Feedback : 소프트웨어 개발에서 변화는 불가피하다. 이러한 변화는 지속적 테스트와 통합, 반복적 결함 수정 등 빠르게 피드백한다.
• 용기(Courage) : 고객 요구사항 변화에 능동적으로 대응한다.
• 존중(Respect) : 개발 팀원 간의 상호 존중을 기본 으로 한다.

XP 과정

• Spike : 어려운 요구사항, 잠재적 솔루션을 고려하기 위해 작성하는 간단한 프로그램
  
• User Story
  일종의 요구사항으로 UML의 유즈케이스와 같은 목적으로 생성되나 형식이 없고 고객에 의해 작성된다는 것이 다르다.
• Release Planning
  몇 개의 스토리가 적용되어 부분적으로 기능 이 완료된 제품을 제공하는 것으로 부분/전체 개발 완료 시점에 대한 일정을 수립한다.
• Iteration
  • 하나의 릴리즈를 세분화한 단위이며 1~3주 단위로 진행된다.
  • 반복(teration) 진행 중 새로운 스토리가 추가 될 때 진행 중 반복(teration)이나 다음 반복에 추가될 수 있다.
• Acceptance Test
  • 릴리즈 단위의 개발이 구현되었을 때 진행 하는 테스트로 사용자 스토리에 작성된 요구사항을 확인하여 고객이 직접 테스트한다.
  • 오류가 발견되면 다음 반복(teration)에 추 가한다. 테스트 후 고객의 요구사항이 변경 되거나 추가되면 중요도에 따라 우선순위가 변경될 수 있다.
  • 완료 후 다음 반복(teration)을 진행한다.
• Small Release
  • 릴리즈 단위를 기능별로 세분화하면 고객 의 반응을 기능별로 확인할 수 있다.
  • 최종 완제품일 때 고객에 의한 최종 테스트 진행 후 고객에 제공한다.
• 스토리/스파이크 → 릴리즈계획 → 주기 → 인수테스트 → 릴리즈
• 주기 중 스토리 업데이트되면 릴리즈 계획 단계로, 인수테스트 중 오류나면 주기 단계로 반복
• 릴리즈계획, 주기, 인스테스트를 거의 동시에 진행하면서 왔다갔다 한다. (3주정도)

스크럼(SCRUM)

얘도 애자일(쉽게 개발, 고객 소통 용이)에 연장선이다. 빠른 소통으로 고객이 원하는 기능을 얼른 개발하도록 하는 방식이다. 작은 업무를 쪼갠 뒤 스프린트라는 단위를 사용한다.
하나의 스프린트에 2~4주 정도 걸린다.

SCRUM팀의 역할

• 제품 책임자(Product Owner) : 우선순위 결정 등
• 스크럼 마스터: 업무 배분, 스크럼 원칙 감시 등
• 스크럼 팀: 나머지

요구사항

• 요구 사항은 설계/개발 단계가 아닌 사용자의 요구 사항을 도출-분석-명세-검증 하는 단계.
• 사용자의 요구 사항을 잘 중재 해 설계/개발을 잘 하도록 해야함

요구사항 확인 기법

20년 1, 2, 3회 기출문제

• 요구사항 검토
• 프로토타이핑 : 시제품 만들고 확인, 사용자에게 직관적
• 모델 검증 : 정적 분석(명세 확인해 검증), 동적 분석(직접 실행해 검증)
• 인수 테스트(알파 테스트, 베타 테스트)

UML(다이어그램) - 관계, 종류, 기본 구성 요소 등

• 객체지향 소프트웨어 개발 과정에서 시스템 분석. 설계, 구현 등의 산출물을 명세화, 시각화, 문서화 할 때 사용하는 모델링 기술과 방법론을 통합하여 만든 범용 모델링 언어이다.
• UML 스테레오 타입을 입력할 때 길러멧(Guillemet)-<<>>을 사용한다.

팁: 정적/동적에 맞는 UML 다이어그램 맞추기

영어도 같이 생각하자 막 시퀀스-Sequence-순차 이런 식으로 내서 모를 수도 있음.

• 구조(Structural) 다이어그램(정적) : 클래스, 객체, 복합체 구조, 배치, 컴포넌트, 패키지
• 행위(Behavioral) 다이어그램(동적) : 유스케이스, 활동, 상태(머신), 콜라보레이션, 상호작용(순차, 상호작용 개요, 통신, 타이밍)

시퀀스(순차) 다이어그램 구성요소

생명선(LifeLine), 통로(Gate), 상호작용(Interaction Fragment), 발생(Occurrence), 실행(Execution), 상태불변(State Invariant), 상호작용(Interaction Use), 메시지(Messages), 활성(Activations), 객체(Entitiy), Actor

Use Case Diagram 구성 요소

액터, 관계만 보자.

1. System Boundary(시스템 경계): 시스템의 범위 또는 시스템이 담당하는 영역을 나타냅니다. 일반적으로 박스로 표현되며, 내부에 Use Cases를 포함합니다.
2. Actors(액터): 시스템 외부에서 시스템과 상호작용하는 역할(사용자, 다른 시스템, 조직 등). 시스템에 특정 작업을 요구하는 외부 객체를 지칭한다.
3. Use Cases(유스케이스): 시스템이 제공하는 기능이나 서비스를 나타낸다. 사용자가 시스템을 통해 달성하려는 목표를 설명한다.
4. Relationships(관계): 구성 요소 간의 관계를 나타낸다.
   • Uses(사용): 여러 개의 유스케이스에서 공통으로 사용해야하는 기능 모델링 위해 사용.
   • Extend(확장): 기본 유스케이스에 선택적 기능을 추가할 수 있는 유스케이스 간의 관계. 특정 조건 하에서만 활성화되는 부가적인 행동을 모델링한다.
   • Communicaion Association(접속 관계): Actor와 Use Case 간의 상호작용을 나타낸다. 액터나 유즈 케이스가 다른 유즈 케이스의 서비스를 이용하는 상황을 표현한다.

순서

1. 액터 식별 : 행위자 구분
2. Use Case 식별 : 행위 정의
3. 관계 정의 : 행위자 - 행위 관계 정의
4. Use Case 구조화 : 어떤 형태의 관곈지 구조화

UML 관계

일반화 중요!!

• 연관 : 서로 관련 (단방향, 양방향)
• 집합 : 사물이 다른 사물에 포함
• 포함 : 포함한 사물 변화가 포함된 사물까지 영향
• 일반화 : 객체지향에서 상속 관계(IS-A) 를 표현하며, 한 클래스가 다른 클래스를 포함하는 상위 개념일 때 사용
• 의존 : 연관은 있으나 짧은 시간만
• 실체화 : 할 수 있거나 해야 하는 기능으로 그룹화

럼바우

모델링마다 다이어그램을 매칭하는 문제 多, 동적 모델링은 특히 다이어그램 이름만으로 추론 가능하니 잘 보자.

• 소프트웨어 구성 요소를 그래픽으로 모형화.
• 럼바우 객체지향 분석 절차 순대로 설명
  • 객체 모델링(객체, 정적) : 시스템에서 요구되는 객체를 찾아내어 속성과 연산 식별 및 객체들 간의 관계를 규정하여 객체를 다이어그램으로 표시한다.
    Class Diagram 사용.
  • 동적 모델링(상태, 동작, 순서) : 제어 흐름, 상호작용, 동작 순서 등의 상태를 시간 흐름에 따라 상태 다이어그램으로 표시한다.
    순차 다이어그램(Sequence), 상태 다이어그램(State), 활동 다이어그램(Activity)을 사용.
  • 기능 모델링(DFD, 데이터흐름도) : 여러 프로세스 간의 자료 흐름을 표시 한다. 어떤 데이터를 입력하여 어떤 결과를 가져올 수 있을지를 표현한다.
    Use Case Diagram 사용.

자료 흐름도(Data Flow Diagram, DFD)

1. 자료 흐름도(DFD)를 작성하는 데 지침이 될 수 없는 항목은?
   • 자료 흐름은 처리(Process)를 거쳐 변환될 때마다 새로운 이름을 부여한다.
   • 어떤 처리(Process)가 출력자료를 산출하기 위해서는 반드시 입력 자료가 발생해야 한다.
   • 자료 저장소에 입력 화살표가 있으면 반드시 출력 화살표도 표시되어야 한다.
   • 상위 단계의 처리(Process)와 하위 자료 흐름도의 자료 흐름은 서로 일치되어야 한다.
2. DFD(data flow diagram)에 대한 설명으로 틀린 것은?
   • 자료 흐름 그래프 또는 버블(bubble)차트라고도 한다.
   • 구조적 분석 기법에 이용된다.
   • 시간 흐름을 명확하게 표현할 수 있다.
   • DFD의 요소는 화살표, 원, 사각형, 직선(단선/이중선)으로 표시한다.
3. 자료흐름도(DFD)의 각 요소별 표기 형태의 연결이 옳지 않은 것은?
   • Process : 원
   • Data Flow : 화살표
   • Data Store : 삼각형
   • Terminator : 사각형
4. 데이터 흐름도(DFD)의 구성요소에 포함되지 않는 것은?
   • Process
   • Data Flow
   • Data Store
   • Data Dictionary

응집도, 결합도 (강한 순서)

모듈을 만들때 중요함.

결합도(Coupling)

서로 다른 모듈 2개 중 서로 얼마나 같냐, 기능적인 연관 정도를 나타냄.
=> 당연히 결합도가 낮아야, 기능 중복이 없어야 각 모듈의 독립성(재사용성)이 좋아진다.

결합도 정도

(약함) 데이터 결합도 < 스탬프 결합도 < 제어 결합도 < 외부 결합도 < 공통 결합도 < 내용 결합도 (강함)

• 데이터 결합도(Data Coupling): 모듈 간에 데이터만을 전달합니다. 가장 약한 형태의 결합도로, 높은 독립성을 의미합니다.
• 스탬프 결합도(Stamp Coupling): 구조화된 데이터를 전달합니다. 데이터 결합도보다는 강하지만 여전히 낮은 결합도를 의미합니다.
  자료 구조 + 결합도 = 스탬프 결합도
• 제어 결합도(Control Coupling): 한 모듈이 다른 모듈의 제어 흐름을 결정합니다. 결합도가 중간 정도입니다.
• 외부 결합도(External Coupling): 외부에서 선언된 데이터를 공유합니다. 결합도가 높아지는 경향이 있습니다.
• 공통 결합도(Common Coupling): 여러 모듈이 같은 전역 데이터를 공유합니다. 매우 높은 결합도를 나타냅니다.
• 내용 결합도(Content Coupling): 한 모듈이 다른 모듈의 내부를 변경합니다. 가장 높은 결합도로, 피해야 합니다.

결 : 데스제외공내 - DSCECC

응집도(Cohesion)

서로 다른 모듈들이 있을 때 한 모듈에 다른 모듈의 기능을 많이 썼냐, 서로의 모듈-요소에 관련도가 어느 정도냐를 나타냄.
=> 당연히 응집도가 높아야, 서로의 기능들을 재사용을 많이 해야 더 좋다!

응집도 정도

(높음) 기능적 응집도 > 순차적 응집도 > 교환적 응집도 > 절차적 응집도 > 시간적 응집도 > 논리적 응집도 > 우연적 응집도 (낮음)

• 기능적 응집도(Functional Cohesion): 모듈 내의 모든 요소가 단일 기능을 수행하기 위해 서로 밀접하게 관련되어 있습니다. 가장 높은 응집도입니다.
• 순차적 응집도(Sequential Cohesion): 모듈 내의 한 요소의 출력이 다른 요소의 입력으로 사용됩니다.
• 교환적 응집도(Communicational Cohesion): 모듈 내의 요소들이 같은 데이터를 작업합니다.
• 절차적 응집도(Procedural Cohesion): 모듈 내의 요소들이 특정 순서에 따라 실행됩니다.
• 시간적 응집도(Temporal Cohesion): 모듈 내의 요소들이 시간적으로 관련된 작업을 수행합니다.
• 논리적 응집도(Logical Cohesion): 관련된 기능들이 하나의 모듈에 모여 있으나, 사용되는 시점에 따라 실행됩니다.
• 우연적 응집도(Coincidental Cohesion): 모듈 내의 요소들이 논리적으로 관련이 없습니다. 가장 낮은 응집도이며, 피해야 합니다.

응 : 기순교절시논우 - FSCPTLC

결론

컴포넌트 간 결합도는 낮아야, 응집도는 높아야 좋은 것!!@@! 결낮응높
또한 응집도/결합도 용어는 그냥 질문의 키워드(시간, 자료구조 + 응집/결합 등)를 추론해 맞추자.. 영어도 잘 보자.
결합도와 응집도의 경우 보기 중 가장 강한(or 약한) 것을 고르라는 류의 문제가 여러번 기출에 등장.

소프트웨어 개발 모형 중 가장 높은 빈도로 폭포수 모형, 나선형 모형, 애자일 모형이 나옵니다. 세 개를 구별하실 정도만 알고 계시면 돼요. GoF 디자인 패턴은 빠짐없이 출제되며 어떤 패턴이 생성/구조/행위 중 어디에 해당하는지 아시는 것이 좋습니다.

SW 아키텍쳐

요구사항에 기반하여 소프트웨어의 기본 구조를 설계하고, 다수의 이해관계자 간의 이해, 타협, 의사소통을 체계적으로 지원하는 전체 시스템의 구조적 설계 과정
아키텍쳐의 기본 뼈대는 프레임워크라 칭함

*주요 아키텍처 패턴(MVC, 파이프-필터 등)

아키텍쳐 패턴 : 효율적인 아키텍쳐를 아주 멋진 사람들이 미리 만들어논 설계도 같은 거임. 사용하면 당연히 시간 단축, 고품질, 안정적, 의사소통 굿 등의 장점이 있음.

MVC 패턴

Model : 핵심 기능 + 데이터
View : 사용자에게 정보 표시, 다수 가능
Controller : 사용자의 입력 처리

• 장점
  같은 모델에서 다수의 뷰를 생성할 수 있으며, 실행 시간에 동적으로 연결 및 해제할 수 있다.
• 단점
  사용자 행동에 대한 불필요 업데이트가 발생할 수 있으며 복잡성이 증가할 수 있다.
• 활용
  일반적인 웹 애플리케이션 설계 아키텍처, Django나 Rails와 같은 웹 프레임워크

파이프-필터 패턴

• 데이터 흐름(Data Stream)을 생성하고 처리하는 시스템을 위한 구조이다.
  • 데이터 흐름 : 데이터 송•수신이나 처리의 연속적 흐름
• 필터는 파이프를 통해 받은 데이터를 변경시키고 그 결과를 파이프로 전송한다.
  • 즉, 파이프는 자료를 보내고 - 필터는 자료를 가공함
• 각 처리 과정은 필터 컴포넌트에서 이루어지며, 처리되는 데이터는 파이프를 통해 흐른다. 이 파이프는 버퍼링 또는 동기화 목적으로 사용될 수 있다.
• 컴파일러, 연속한 필터들은 어휘 분석, 파싱, 의미 분석 그리고 코드 생성을 수행한다. 노드와 간선으로 이뤄짐.

• 장점
  필터 교환과 재조합을 통해서 높은 유연성을 제공한다.
• 단점
  상태정보 공유를 위해 비용이 소요되며 데이터 변환에 과부하가 걸릴 수 있다.
• 활용
  컴파일러, 어휘 분석, 구문 분석, 의미 분석, 코드 생성

그 외 패턴

• Client-Server Pattern
  한 서버와 여러 개의 클라이언트로 이뤄짐
• Peer To Peer
• Broker
• Black Board
• Event-Bus
  이벤트 소스, 이벤트 리스너, 이벤트 채널, 이벤트 관리 등으로 이뤄져 있음. 이벤트 처리함.
• Interpreter
  SQL, 통신 프로토콜 언어를 정의하기 위한 언어

Software Architecture 시스템 품질 속성 7

• 성능 (Performance)
• 사용 운용성 (Operability)
• 보안성 (Security)
• 시험 용이성 (Testability)
• 가용성 (Availability)
• 변경 용이성 (Modifiability)
• 사용성 (Usability)

객체 지향

객체 지향 특징

1. 캡슐화(Encapsulation): 데이터(속성)와 데이터를 처리하는 함수(메서드)를 하나로 묶음. 이렇게 하면 객체의 세부 구현 내용을 숨기고 사용자에게 필요한 부분만 제공할 수 있음.
2. 정보 은닉(Information Hiding): 객체 내부 속성 및 메소드를 숨기고 공개된 인터페이스 통해서만 메세지 통신이 가능하도록 함. 사이드 이펙트 예방.
3. 상속성(Inheritance): 한 클래스가 다른 클래스의 속성이나 메서드를 물려받을 수 있음. 코드 재사용성을 높여주고 유지보수를 쉬움.
4. 다형성(Polymorphism): 같은 이름의 메서드가 여러 클래스에서 다른 작업을 수행 가능. 이는 오버로딩(Overloading)과 오버라이딩(Overriding)을 통해 구현됨.
   • 오버로딩: 같은 이름 순서 재사용
   • 오버라이딩: 재정의
5. 추상화(Abstraction): 복잡한 실제 세계를 간단한 모델로 표현. 필요한 정보만을 추출해서 프로그래밍에 활용함.
   종류: 기능, 제어, 자료 추상화

객체 지향 설계 원칙(SOLID)

• 단일 책임의 원칙(SRP : Single Responsibility Principle)
  모든 클래스는 단일 목적으로 생성되고, 하나의 책임만 가져야 한다.
• 개방/폐쇄의 원칙(OCP : Open Closed Principle)
  소프트웨어 구성 요소는 확장에 대해서는 개방되어야 하나 수정에 대해서는 폐쇄적이어야 한다.
• 리스코프 치환 원칙(LSP : Liskov Substitution Principle)
  부모 클래스가 들어갈 자리에 자식 클래스를 교체-대체하여도 계획대로 작동해야 한다. 시험 잘나옴(교체, 대체 키워드)
• 인터페이스 분리 원칙(ISP : Interface Segregation Principle)
• 의존 역전 원칙(DIP : Dependency Inversion Principle)

디자인 패턴

디자인패턴이란?

자주 사용하는 설계 형태를 정형화하여 유형별로 설계 템플릿을 만들어 두고 소프트웨어 개발 중 나타나는 과제를 해결하기 위한 방법임.
다시 말해 특정 문제를 해결하는, 아키텍쳐 등과 달리 작은 개념의 문제를 해결하기 위한 템플릿/솔루션이라고 생각하면 됨.

---

GoF(Gangs of Four) 디자인 패턴(생성, 구조, 행위 패턴)

• 에릭 감마(Eric Gamma), 리처드 헬름(Richard Helm), 랄프 존슨(Ralph Johnson), 존 브리시데 스(John Vlissides)가 제안하였다.
• 객체지향 설계 단계 중 재사용에 관한 유용한 설계를 디자인 패턴화하였다.
• 생성 패턴, 구조 패턴, 행위 패턴으로 분류한다.
  • 생성 패턴 : Abstract Factory, Builder, Factory Method, Prototype, Singleton
  • 구조 패턴 : Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy
  • 행위 패턴 : Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, Visitor

생성 패턴

객체 생성에 관련된 패턴으로, 객체의 생성 과정을 캡슐화하여 객체 생성을 더 유연하게 만듦.

팩토리 메서드(Factory Method)

상위 클래스에서 객체를 생성하는 인터페이스를 정의하고, 하위 클래스에서 인스턴스를 생성하도록 하는 방식임.
Virtual-Constructor 패턴도 맞음.

싱글톤(Singleton)

전역 변수를 사용하지 않고 객체를 하나만 생성하도록 한다.
생성된 객체를 어디에서든지 참조할 수 있도록 하는 패턴이다.

Prototype

prototype을 먼저 생성하고 인스턴스를 복제하여 사용하는 구조이다.
일반적인 방법으로 객체를 생성한다.
비용이 많이 소요 되는 경우 주로 사용한다.

추상 팩토리(Abstract Factory)

구체적인 클래스에 의존하지 않고 서로 연관되거나 의존적인 객체들의 조합을 만드는 인터페이스를 제공하는 패턴이다.
관련된 서브 클래스를 그룹 지어 한 번에 교체할 수 있다.

구조 패턴

클래스나 객체를 조합해 더 큰 구조를 만드는 패턴. 다양한 구성요소들이 서로 잘 작동하도록 도와줌.

어댑터(Adapter)

기존에 구현되어 있는 클래스에 기능 발생 시 기존 클래스를 재사용할 수 있도록 중간에서 맞춰주는 역할을 한다.

Bridge

기능 클래스 계층과 구현 클래스 계층을 연결하고, 구현부에서 추상 계층을 분리하여 각자 독립적으로 변형할 수 있도록 해주는 패턴이다.

그 외

Composite, Decorator, Facade(퍼사드), Flyweight, Proxy

행위 패턴

객체 간의 통신 방법과 책임 분배에 초점을 맞춘 패턴. 객체 간의 상호작용이나 알고리즘을 정의하는 데 유용.

Chain of Responsibility(책임 연쇄), Command(명령), Interpreter(해석자), Iterator(반복자), Mediator(중재자), Memento, Observer, State, Strategy, Template Method, Visitor(방문자)

=> 그냥 이름 단어 해석하면 뭔가 생성 및 빌드 후 느낌이 난다. 잘 해석해 풀 것.

그 외 짜잘

시험에 나왔던 것들임. 다 봐둬.

목업과 프로토타입

• 목업은 Interaction이 없는 시각적 디자인만 구현한 모형. 정적임.
• 프로토타입은 실제 구동이 되는 모형. 동적임.
  • 프로토타입은 '최초' 개발 단계임.

감성 공학 요소 기술

기초 기술, 구현 기술, 응용 기술

구조 vs 행위

• 구조 관련 : 정적 - 인터페이스 - 비기능 - 객체 - 클래스 - 집합 - 패키지 - 컴포넌트
• 행위 관련 : 동적 - 상태 - 이벤트 - 기능 - 순서(순차) - 활동 - 프로세스 - 함수 - 상호 작용

소프트웨어 구조도

복잡도 최적화를 위한 조건 : Fan-in은 높이고 Fan-out은 낮추도록 설계한다.

• Fan-in: 한 모듈을 호출하거나 사용하는 상위 모듈의 수를 의미. Fan-in이 높을수록 해당 모듈의 재사용성이 높음을 나타냄.
• Fan-out: 한 모듈이 호출하거나 사용하는 하위 모듈의 수를 나타냄. Fan-out이 높을수록 모듈의 복잡성이 높아짐.
• Depth: 최상위 모듈로부터 특정 모듈까지의 계층적 깊이를 의미. 깊이가 깊을수록 시스템의 계층 구조가 복잡함을 의미.
• Width: 동일한 계층 레벨에 위치한 모듈의 수를 의미. 너비가 넓을수록 해당 레벨의 모듈이 많음을 나타냄.
• Superordinate: 다른 모듈을 제어하는 상위 모듈을 말함. 일종의 "부모" 모듈 역할을 함.
• Subordinate: 다른 모듈에 의해 제어되는 하위 모듈을 의미. "자식" 모듈로 볼 수 있음.

객체 지향 방법론

Coad와 Your-don 방법
객체 식별, 구조 식별, 주체 정의, 속성 및 관계 정의, 서비스 정의 등의 과정으로 구성된다.
객체지향 분석 방법론에서 E-R 다이어그램을 사용하여 객체의 행위를 모델링한다.

협약에 의한 설계(Design by Contract) 3가지 타입 20.8

• 선행조건(Precondition) : 오퍼레이션이 호출되기 전에 참이 되어야 할 조건
• 결과조건(Postcondition) : 오퍼레이션이 수행된 후 만족 해야 하는 조건
• 불변조건(Invariant) : 클래스 내부가 실행되는 동안 항상 만족하여야 하는 조건

인터페이스(UI) 요구사항

프로토타이핑, 테스트 설계, CASE 도구 활용, 요구사항 검토 등의 방법이 있다.

• 요구사항 검토
  • 동료 검토 : 명세 작성자가 동료들에게 함께 도움 받음.
  • 워크스루 : 검토회의 전 명세서 배포 - 짧은 검토 회의 - 결함 발견
  • 인스펙션 : 명세 작성자 외 다른 전문가의 감사를 받음.

틀린 문제

6. 파이프 필터 형태의 소프트웨어 아키텍처에 대한 설명으로 옳은 것은?

 1.	노드와 간선으로 구성된다.
 2.	서브시스템이 입력데이터를 받아 처리하고 결과를 다음 서브시스템으로 넘겨주는 과정을 반복한다.
 3.	계층 모델이라고도 한다.
 4.	3개의 서브시스템(모델, 뷰, 제어)으로 구성되어 있다.

 입력한 답 : 1
 정답 : [2] 

아키텍처(architecture)란 영어 뜻으로는 구조, 건축물, 건축학 등의 뜻
소프트웨어 아키텍처 : 소프트웨어 구조
1. 레이어 패턴 (Layers Pattern): 시스템을 계층으로 구분하여 구성,ex)OSI 참조 모델
2. 클라이언트-서버 패턴 (Client-Server Pattern):하나의 서버 컴포넌트와 다수의 클라이언트 컴포넌트로 구성되는 패턴
3. 파이프-필터 패턴 (Pipe-Filter Pattern):데이터 스트림 절차의 각 단계를 필터 컴포넌트로 캡슐화하여 파이프를 통해 데이터를 전송하는 패턴 ex)UNIX의 쉘
4. 모델-뷰-컨트롤러 패턴 (Model-View-Controller Pattern):서브시스템을 3개의 부분으로 구조화하는 패턴
5. 마스터-슬레이브 패턴 6. 브로커 패턴 7. 피어-투-피어 패턴 8. 이벤트-버스 패턴 9. 블랙보드 패턴 10. 인터프리터 패턴

---

10. 소프트웨어 개발 영역을 결정하는 요소 중 다음 사항과 관계있는 것은?

• 소프트웨어에 의해 간접적으로 제어되는 장치와 소프트웨어를 실행하는 하드웨어
• 기존의 소프트웨어와 새로운 소프트웨어를 연결 하는 소프트웨어
• 순서적 연산에 의해 소프트웨어를 실행하는 절차

 1.	기능(Function)
 2.	성능(Performance)
 3.	제약 조건(Constraint)
 4.	인터페이스(Interface)

 입력한 답 : 0 
 정답 : [4] 

인터페이스: 서로 다른 두 시스템이나 소프트웨어 등을 서로 이어주는 부분 또는 접속 장치를 의미

11. UML의 기본 구성요소가 아닌 것은?

 1.	Things
 2.	Terminal
 3.	Relationship
 4.	Diagram

 입력한 답 : 0 
 정답 : [2] 

UML의 구성요소로는 사물, 관계, 다이어그램 3가지로 이루어져있으며,
Things은 사물, Relationship은 관계, Diagram은 다이어그램입니다.
UML은 띵다리~로 외우세요!
UML은 뒷다리로 쏙~♬외우세요 팔딱팔딱 개구리 됐네~~
뒷(Thing)
다(Diagram)
리 Relationship)

14. 다음 중 요구사항 모델링에 활용되지 않는 것은?

 1.	애자일(Agile) 방법
 2.	유스케이스 다이어그램(Use Case Diagram)
 3.	시퀀스 다이어그램(Sequence Diagram)
 4.	단계 다이어그램(Phase Diagram)

 입력한 답 : 1
 정답 : [4] 

단계 다이어그램: 물리 화학 등에서 사용하는 다이어그램, 요구사항 모델링과 관계 없음

15. UML 모델에서 한 객체가 다른 객체에게 오퍼레이션을 수행하도록 지정하는 의미적 관계로 옳은 것은?

 1.	Dependency
 2.	Realization
 3.	Generalization
 4.	Association

 입력한 답 : 1
 정답 : [2] 

Dependency(의존) : 한 사물의 명세서가 바뀌면 그것을 사용하는 다른 사물에게 영향을 끼치는 것을 말합니다 (Cascade 생각하셈)
Realization(실체화) : 한 객체가 다른 객체에 의해 오퍼레이션을 수행하도록 지정
Generalization(일반화) : 일반화된 사물과 좀 더 특수화된 사물 사이의 관계를 말합니다.('is-a')관계
Association(연관) : 두 사물간의 구조적 관계로, 어느 한 사물 객체가 다른 사물 객체와 연결되어 있음을 말함 ('has-a')관계라고도 합니다

---

---

---

여기는 쓰다가 너무 많아서 그만 둠.

_Legacy 소프트웨어 공학의 개념

소프트웨어의 특징

• 상품성 : 소프트웨어를 개발하면 상품이 되어 판매가 된다.
• 복잡성 : 개발하는 과정이 복잡하고 관리가 어렵다.
• 변경 가능성 : 프로그램을 일부 수정하여 업그레이 드 및 오류 수정 등을 할 수 있다.
• 복제성 : 복제가 용이해 쉽게 복사, 유통이 가능하다.

시스템(System) 기본 요소

• 입력, 처리, 출력, 제어, 피드백
  

소프트웨어 위기의 원인 및 문제

• 하드웨어 비용을 초과하는 개발 비용의 증가
• 개발 기간의 지연
• 개발 인력 부족 및 인건비 상승
• 성능 및 신뢰성 부족
• 유지 보수의 어려움에 따른 엄청난 비용

예시: 소프트웨어 위기를 가져온 원인으로 가장 옳지 않은 것은?

① 소프트웨어 규모 증대와 복잡도에 따른 개발 비용 증가
② 프로젝트 관리 기술의 부재
③ 소프트웨어 개발 기술에 대한 훈련 부족
④ 소프트웨어 수요의 감소 - 소프트웨어 개발에 대해 관계가 무관함.

소프트웨어 공학의 기본 원칙

• 현대적인 프로그래밍 기술을 적용해야 한다.
• 신뢰성이 높아야 한다. : 기능의 결론이 틀리면 안됨
• 사용의 편리성과 유지보수성이 높아야 한다.
• 지속적인 검증 시행을 해야 한다.

예시: 소프트웨어 공학에 대한 설명으로 가장 옳지 않은 것은?

① 소프트웨어의 개발, 운영, 유지보수, 그리고 폐기에 대한 체계적인 접근이다.
② 소프트웨어 제품을 체계적으로 생산하고 유지보수와 관련된 기술과 경영에 관한 학문이다.
③ 과학적인 지식을 컴퓨터 프로그램 설계와 제작에 실제 응용하는 것이며, 이를 개발 및 운영하고 유지보수하는데 필요한 문서화 작성 과정이다.
④ 소프트웨어의 위기를 이미 해결한 학문으로, 소프트웨어의 개발만을 위한 체계적인 접근이다. - 소프트웨어 위기를 해결하기 위한 학문

소프트웨어 재공학

저번에 만든 소프트웨어 다시 쓰기, 재문서화

재공학의 장점, 목표, 과정

• 장점
  개발 시간 및 비용 감소, 품질 향상, 생산성 향상, 신뢰 성 향상, 구축 방법에 대한 지식의 공유, 프로젝트 실패 위험 감소
• 목표
  • 소프트웨어의 유지보수성 향상이 최우선 목표이다.
  • 복잡한 시스템을 다루는 방법 구현, 다른 뷰의 생성, 잃어버린 정보의 복구 및 제거
  • 재사용을 수월하게 하며 소프트웨어의 수명을 연장 하기 위해서이다.
  • 유지보수 측면에서 Preventive(예방)의 문제를 해결하기 위한 방법
• 과정
  분석(Analysis) → 구성(Restructuring) → 역공학(Reverse Engineering) → 이식(Migration)

역공학(Reverse Engineering)

• S/W를 분석하여 분석 및 설계 정보를 재발견 하거나 다시 만들어 내는 작업
• 현재 프로그램으로부터 데이터, 구조, 절차에 관한 정보를 추출하는 과정
• 가장 간단하고 오래된 형태는 재문서화
• 기존 코드를 복구하는 방법

예시: 소프트웨어를 분석하여 소프트웨어 개발 과정과 데이터 처리 과정을 설명하는 분석 및 설계 정보를 재발견하거나 다시 만들어내는 과정을 무엇이라고 하는가?

역공학 - 틀렸음; 재공학이 아니고 역공학임

예시: 소프트웨어 재공학이 소프트웨어의 재개발에 비해 갖는 장점으로 거리가 먼 것은?

① 위험 부담 감소
② 비용 절감
③ 시스템 명세의 오류 억제
④ 개발 시간의 증가 - 재개발은 아예 다시 짓는 거, 재공학은 재사용하는 거. 상대적으로 개발 시간이 당연히 줆.

예시: S/W 재공학 관점에서 가장 연관 깊은 유지보 수 유형은?

① Adaptive Maintenance
② Perfective Maintenance
③ Corrective Maintenance
④ Preventive Maintenance - 재공학은 예방 차원에서 하는 거임.

CASE(Computer Aided Software Engineering)

CASE는 소프트웨어 설계/개발을 도와주는 문서화 도구-Tool이다. 즉, 개발 비용 절약과 SW 생산성을 향상시킨다.

제공하는 기능

• 개발을 신속하게 할 수 있고, 오류 수정이 쉬워 소프트웨어 품질이 향상된다.
• 소프트웨어 생명주기의 전체 단계를 연결해 주고 자동화시켜 주는 통합된 도구를 제공해주는 기술이다.
• 소프트웨어 시스템의 문서화 및 명세화를 위한 그래픽 기능을 제공한다.
• 소프트웨어 개발 단계의 표준화를 기할 수 있으며 자료 흐름도 작성 기능을 제공한다.
• 모델들 사이의 모순 검사 기능을 제공하며 다양한 소프트웨어 개발 모형을 지원한다.
• 원천 기술 : 구조적 기법, 프로토타이핑 기술, 정보 저장소 기술

CASE의 분류

• 상위(Upper) CASE : 요구분석 및 설계 단계 지원(모델 간 모순 검사 기능, 모델 오류 검증 기능, 자료 흐 름도 작성 기능)
• 하위(Lower) CASE : 소스 코드 작성, 테스트, 문서화 과정 지원
• 통합(Integrate) CASE : 소프트웨어 개발 주기 전체 과정 지원

요구사항 분석을 위한 CASE 내 도구들

굵은 글씨만 보기

• SADT(Structured Analysis and Design Technique) : SoftTech 사에서 개발한 것으로 시스템 정의, 소프트웨어 요구사항 분석, 시스템/소프트웨어 설계를 위해 널 리 이용되어 온 구조적 분석 및 설계 도구이다. 구조적 요구분석을 하기 위해 블록 다이어그램을 채택한 자동화 도구다.
• REM(Software Requirements Engineering
  Methodology) = RSL/REVS : TRW 사가 우주 국방 시 스템 그룹에 의해 실시간 처리 소프트웨어 시스템에서 요구사항을 명확히 기술하도록 할 목적으로 개발한 것으 로, RSL과 REVS를 사용하는 자동화 도구이다.
  • RSL(Requirement Statement Language) : 요소, 속 성, 관계, 구조들을 기술하는 요구사항 기술 언어이다.
  • REVS(Requirement Engineering and Validation System)
    : RSL로 기술된 요구사항들을 자동으로 분석하여 요구 사항 분석 명세서를 출력하는 요구사항 분석기이다.
• PSL/PSA : 미시간 대학에서 개발한 것으로 PSL과 PSA
  를 사용하는 자동화 도구이다.
• TAGS(Technology for Automated Generation of
  Systems) : 시스템 공학 방법 응용에 대한 자동 접근 방 법으로 개발 주기의 전 과정에 이용할 수 있는 통합 자동 화 도구이다.

예시: SoftTech 사에서 개발된 것으로 구조적 요구 분석을 하기 위해 블록 다이어그램을 채택한 자동화 도구는?

SADT - Bold 키워드 확인

예시: CASE(Computer Aided Software Engineering)의 주요 기능으로 옳지 않은 것은?

① S/W 생명주기 전 단계의 연결
② 그래픽 지원
③ 다양한 소프트웨어 개발 모형 지원
④ 언어 번역

소프트웨어 개발 방법론

소프트웨어 생명주기(Software Life Cycle)

• 소프트웨어 제품의 개념 형성에서 시작하여 운용/ 유지보수에 이르기까지 변화의 모든 과정이다.
• 타당성 검토 → 개발 계획 → 요구사항 분석 → 설계 → 구현 → 테스트 → 운용 → 유지/보수

SW 개발 설계 모델

폭포수 모형 (waterfall model)

• 선형 순차 모형으로, 각 단계가 끝날 경우 결과물이 명확히 나와야한다.
• 개발 단계는 위의 생명 주기와 같으며 총 6단계의 과정을 거친다.
• 상위 단계를 완료하지 않으면 후에 심각한 영향을 준다는 것이 특징이며 고객의 요구가 개발 단계의 후반이 돼서야 확인 할 수 있다는 점이 있어 소규모 개발에 적합하다.

프로토타입 모형 (prototype model)

• 폭포수 모형의 요구사항 변경에 따른 어려움을 보완한 모형으로 사용자의 요구사항을 충실히 반영한다.
• 실제 상황 전에 가상의 시뮬레이션을 통하여 최종 결과물에 대한 예측을 할 수 있다.
• 프로젝트의 관리가 용이하고, 노력과 비용을 절감한다.
  

나선형 모형 (spiral model)

• 폭포수 모형과 프로토타입 모형의 장점을 융합한 모델.
• 소프트웨어 개발 중 발생할 수 있는 위험을 관리하고 최소화하는 것이 목적이다.
• 비용이 많이 들거나 시간이 많이 소요되는 대규모 프로젝트에 구축 시 유리하다.
  

예시: 프로토타입을 지속적으로 발전시켜 최종 소프트웨어 개발까지 이르는 개발 방법으로 위험 관리가 중심인 소프트웨어 생명주기 모형은?

나선형 모형(spiral model) - 위험 관리가 핵심. 위험+모형이 나오면 무조건 나선형 모형(spiral model)

HIPO(Hierarchy Input Process Output)

• 입력, 처리, 출력으로 구성되는 시스템 분석 및 설 계와 시스템 문서화용 기법이다.
• 일반적으로 가시적 도표(Visual Table of Contents), 총체적 다이어그램(Overview Diagram), 세부적 다이어그램(Detail Diagram)
  으로 구성된다.
• 구조도(가시적 도표, Visual Table of Contents), 개요, 도표(Index Diagram), 상세 도표(Detail Diagram)로 구성된다.
• 가시적 도표는 전체적인 기능과 흐름을 보여주는 구조이다.
• 기능과 자료의 의존 관계를 동시에 표현할 수 있다.
• 가시적 도표 덕분에 보기 쉽고 이해하기 쉬우며 유지보수가 쉽다.
• 하향식 소프트웨어 개발을 위한 문서화 도구이다. - 폭포식 모델과 비슷함.

V-모델

1과목 뿐만 아니라 2~과목부터 많이 나옴.

• 폭포수 모형에 시스템 검증과 테스트 작업을 강조한 모델이다.
• 세부적인 프로세스로 구성되어 있어서 신뢰도 높은 시스템 개발에 효과적이다.
• 개발 단계의 작업을 확인하기 위해 테스트 작업을 단계 별로 수행한다.
• 생명주기 초반부터 테스트 작업을 지원한다.
• 코드뿐만 아니라 요구사항과 설계 결과도 테스트할 수 있어야 한다.
• 폭포수 모형보다 반복과 재처리 과정이 명확하다.
• 테스트 작업을 단계별로 구분하므로 책임이 명확해진다.
• V 모양 그림 꼭 기억, 정적은 설계, 동적은 실행
  

예시: HIPO(Hierarchy Input Process Output)에 대한 설명으로 거리가 먼 것은?

① 상향식 소프트웨어 개발을 위한 문서화 도구이다. - 하향식, 폭포수 모형과 동일.
② HIPO 차트 종류에는 가시적 도표, 총체적 도표, 세부적 도표가 있다.
③ 기능과 자료의 의존 관계를 동시에 표현할 수 있다.
④ 보기 쉽고 이해하기 쉽다.

애자일(Agile) 개발 방법론

• Agile: 날렵한, 재빠른 이란 사전적 의미, 양궁으로 쏴서 날라가는
• 특정 방법론이 아닌 소프트웨어를 빠르고 낭비 없이 제작하기 위해 고객과의 협업에 초점 두고 소프트웨어 개발 중 설계 변경에 신속히 대응하여 요구사항을 수용할 수 있다.
• 절차와 도구보다 개인과 소통을 중요시하고 고객과의 피드백을 중요하게 생각한다. 고객이 원하는 기능과 맞는지 아닌지만 중요.
• 소프트웨어가 잘 실행되는데 가치를 두며, 소프트웨어 배포 시차를 최소화할 수 있다.
• 특징
  짧은 릴리즈와 반복, 점증적 설계, 사용자 참여, 문서 최소화, 비공식적인 커뮤니케이션 변화
• 종류 21.5
  • 익스트림프로그래밍(XP, eXtremeProgramming)
  • 스크럼(SCRUM)
  • 린(Lean)
  • DSDM(Dynamic System Development Method): 동적 시스템 개발 방법론
  • FDD(Feature Driven Development): 기능 중심 개발
  • Crystal
  • ASD(Adaptive Soflware Development): 적응형 소프트웨어 개발 방법론
  • DAD(Disciplined Agile Delivery): 학습 애자일 배포

XP(eXtremeProgramming)

걍 고객 중심 소통, 빠르게 개발, 유지/보수 쉽게 이런 키워드를 생각하자.

• 1999년 Kent Beck이 제안하였으며, 개발 단계 중 요구사항이 시시각각 변동이 심한 경우 적합한 방법론이다.
• 요구에 맞는 양질의 소프트웨어를 신속하게 제공하는 것을 목표로 한다.

XP 핵심 가치 20.9, 20.6

• 소통(Communication) : 개발자, 관리자, 고객 간의 원활한 소통을 지향한다.
• 단순성(Simplicity) : 부가적 기능 또는 미사용 구조와 알고리즘은 배제한다.
• Feedback : 소프트웨어 개발에서 변화는 불가피하다. 이러한 변화는 지속적 테스트와 통합, 반복적 결함 수정 등 빠르게 피드백한다.
• 용기(Courage) : 고객 요구사항 변화에 능동적으로 대응한다.
• 존중(Respect) : 개발 팀원 간의 상호 존중을 기본 으로 한다.

XP 과정

• Spike : 어려운 요구사항, 잠재적 솔루션을 고려하기 위해 작성하는 간단한 프로그램
  
• User Story
  일종의 요구사항으로 UML의 유즈케이스와 같은 목적으로 생성되나 형식이 없고 고객에 의해 작성된다는 것이 다르다.
• Release Planning
  몇 개의 스토리가 적용되어 부분적으로 기능 이 완료된 제품을 제공하는 것으로 부분/전체 개발 완료 시점에 대한 일정을 수립한다.
• Iteration
  • 하나의 릴리즈를 세분화한 단위이며 1~3주 단위로 진행된다.
  • 반복(teration) 진행 중 새로운 스토리가 추가 될 때 진행 중 반복(teration)이나 다음 반복에 추가될 수 있다.
• Acceptance Test
  • 릴리즈 단위의 개발이 구현되었을 때 진행 하는 테스트로 사용자 스토리에 작성된 요구사항을 확인하여 고객이 직접 테스트한다.
  • 오류가 발견되면 다음 반복(teration)에 추 가한다. 테스트 후 고객의 요구사항이 변경 되거나 추가되면 중요도에 따라 우선순위가 변경될 수 있다.
  • 완료 후 다음 반복(teration)을 진행한다.
• Small Release
  • 릴리즈 단위를 기능별로 세분화하면 고객 의 반응을 기능별로 확인할 수 있다.
  • 최종 완제품일 때 고객에 의한 최종 테스트 진행 후 고객에 제공한다.
• 스토리/스파이크 → 릴리즈계획 → 주기 → 인수테스트 → 릴리즈
• 주기 중 스토리 업데이트되면 릴리즈 계획 단계로, 인수테스트 중 오류나면 주기 단계로 반복
• 릴리즈계획, 주기, 인스테스트를 거의 동시에 진행하면서 왔다갔다 한다. (3주정도)

예시: 애자일 기법에 대한 설명으로 맞지 않는 것은?

① 절차와 도구보다 개인과 소통을 중요하게 생각한다.
② 계획에 중점을 두어 변경 대응이 난해하다. - 무조건 고객이 원하는 것만 개발하기 때문에
③ 소프트웨어가 잘 실행되는데 가치를 둔다.
④ 고객과의 피드백을 중요하게 생각한다.

예시: 애자일 개발 방법론이 아닌 것은?

① 스크럼(Scrum)
② 익스트림+ 프로그래밍(XP : eXtremeProgramming)
③ 기능 주도 개발(FDD : Feature Driven Development)
④ 하둡(Hadoop) - 빅데이터 분석 기법

예시: XP(extremeProgramming)의 핵심 가치 중 부가적 기능 또는 미사용 구조와 알고리즘은 배제하는 가치를 쓰시오.

단순성(Simplicity)

예시: 소프트웨어 프로젝트 관리를 효과적으로 수행 하는데 필요한 3P에 해당하지 않는 것은?

① People
② Problem
③ Process
④ Possibility

예시: XP(extreme Programming)의 기본 원리로 볼 수 없는 것은?

① Linear Sequential Method - Linear는 선형적인 순서대로(워터폴) 뜻임.
② Pair Programming
③ Collective Ownership
④ Continuous Integration

예시: XP(extreme Programming)의 5가지 가치로 거리가 먼 것은?

① 용기
② 의사소통
③ 정형 분석 - 애자일은 뭐다? 소통, 쉽게 개발 이다. 분석같은 건 어울리지 않음.
④ 피드백

스크럼(SCRUM)

얘도 애자일(쉽게 개발, 고객 소통 용이)에 연장선이다. 빠른 소통으로 고객이 원하는 기능을 얼른 개발하도록 하는 방식이다. 작은 업무를 쪼갠 뒤 스프린트라는 단위를 사용한다.
하나의 스프린트에 2~4주 정도 걸린다.

SCRUM팀의 역할

• 제품 책임자(Product Owner) : 우선순위 결정 등
• 스크럼 마스터: 업무 배분, 스크럼 원칙 감시 등
• 스크럼 팀: 나머지

현행 시스템 분석

• 그냥 한 기업 안에 SW 시스템이 어떻게 돼있는지, 개발 시스템의 개발 범위를 확인하고 어떻게 할 지 이행 방향성을 설정하는 분석임.
• 시스템의 전체 구조, 행위, 그리고 행위 원리를 나타내며 시스템이 어떻게 작동하는지 설명하는 틀인 시스템 아키텍쳐를 분석함.

현행 시스템 파악 절차 21.3

• 1단계(어떻게 운영) : 시스템 구성 파악 - 시스템 기능 파악 - 시스템 인터페이스 현황 파악
• 2단계(어떻게 설계) : 아키텍처 파악 - 소프트웨어 구성 파악
• 3단계(하드웨어) : 시스템 하드웨어 현황 파악(OS, 본체 등) - 네트워크 구성 파악(와이파이, LAN 등)

플랫폼

• 현행 시스템의 사용자가 요구사항을 통하여 시스템 성능상의 문제를 요구할 경우 플랫폼 성능 분석을 통하여 사용자가 느끼는 속도를 파악하고 개선 방 향을 제시할 수 있다.
• 특성 분석 항목 : 응답 시간(Response Time), 가용성(Availability), 사용률(Utilization)