잡다한 배똥월드

1. 정의

• 현실 세계의 개체(Entity)를 기계의 부품처럼 하나의 객체(Object)로 만들어, 기계적인 부품들을 조립하여 제품을 만들 듯이 소프트웨어를 개발할 때에도 객체들을 조립해서 작성할 수 있는 기법을 말함
• 구조적 기법의 문제점으로 인한 소프트웨어 위기의 해결책으로 채택되어 사용되고 있음
• 소프트웨어의 재사용 및 확장이 용이 => 고품질의 소프트웨어를 빠르게 개발 가능, 유지보수 쉬움
• 복잡한 구조를 단계적 · 계층적으로 표현하고, 멀티미디어 데이터 및 병렬 처리를 지원함
• 현실 세계를 모형화함 => 사용자와 개발자가 쉽게 이해 가능
• 주요 구성 요소와 개념 : 객체, 클래스, 캡슐, 상속, 다형성, 연관성

2. 객체(Object)

• 데이터와 데이터를 처리하는 함수를 묶어 놓은 캡슐화한 하나의 소프트웨어 모듈
• 데이터(= 속성, 상태, 변수, 상수, 자료구조) : 객체가 가지고 있는 정보로 속성이나 상태, 분류 등을 나타냄
• 함수(= 메소드, 행위, 서비스, 동적, 연산) : 객체가 수행하는 기능. 객체가 갖는 데이터를 처리하는 알고리즘, 객체의 상태를 참조하거나 변경하는 수단이 되는 것
• 독립적으로 식별 가능한 이름을 가지고 있음
• 상태(State) : 객체가 가질 수 있는 조건 => 시간에 따라 변함
• 객체와 객체는 상호 연관성에 의한 관계가 형성됨
• 객체가 반응할 수 있는 메시지(Message)의 집합을 행위라고 하며, 객체는 행위의 특징을 나타낼 수 있음
• 객체는 일정한 기억장소를 가지고 있음
• 객체의 메소드는 다른 객체로부터 메시지를 받았을 때 정해진 기능을 수행함

3. 클래스(Class)

• 공통된 속성과 연산(행위)을 갖는 객체의 집합으로 객체의 일반적인 타입(Type)을 의미
• 각각의 객체들이 갖는 속성과 연산을 정의하고 있는 틀
• 객체지향 프로그램에서 데이터를 추상화하는 단위
• 인스턴스(Instance) : 클래스에 속한 각각의 객체들
• 인스턴스화(Instantiation) : 클래스로부터 새로운 객체를 생성하는 것
• 동일 클래스에 속한 각각의 객체들은 공통된 속성과 행위를 가지고 있으면서 그 속성에 대한 정보가 서로 달라서 동일 기능을 하는 여러 가지 객체를 나타내게 됨
• 슈퍼 클래스(Super Class) = 특정 클래스의 상위(부모) 클래스
• 서브 클래스(Sub Class) = 특정 클래스의 하위(자식) 클래스

4. 캡슐화(Encapsulation)

• 데이터(속성)와 데이터를 처리하는 함수를 하나로 묶은 것을 의미
• 캡슐화된 객체는 인터페이스를 제외한 세부 내용이 은폐(정보 은닉)되어 외부에서의 접근이 제한적이기 때문에 외부 모듈의 변경으로 인한 파급 효과가 적음
• 캡슐화된 객체들은 재사용이 용이
• 인터페이스가 단순해지고, 객체 간의 결합도가 낮아짐

5. 상속(Inheritance)

• 이미 정의된 상위 클래스의 모든 속성과 연산을 하위 클래스가 물려받는 것
• 상속을 이용하면 상위 클래스의 모든 속성과 연산을 다시 정의하지 않고서도 즉시 자신의 속성으로 사용 가능
• 상속받은 속성과 연산 외에 새로운 속성과 연산을 첨가하여 사용 가능
• 객체와 클래스의 재사용, 즉 소프트웨어의 재사용(Reuse)을 높이는 중요한 개념
• 다중 상속(Multiple Inheritance) : 한 개의 클래스가 두 개 이상의 상위 클래스로부터 속성과 연산을 상속 받는 것

6. 다형성(Polymorphism)

• 메시지에 의해 객체(클래스)가 연산을 수행하게 될 때 하나의 메시지에 대해 각각의 객체(클래스)가 가지고 있는 고유한 방법(특성)으로 응답할 수 있는 능력을 의미
• 객체들은 동일한 메소드명을 사용하며 같은 의미의 응답을 함
• 하나의 함수나 연산자가 두 개 이상의 서로 다른 클래스의 인스턴스들을 같은 클래스에 속한 인스턴스처럼 수행할 수 있도록 하는 것

7. 연관성(Relationship)

• 두 개 이상의 객체(클래스)들이 상호 참조하는 관계를 말함
• is member of : 연관화(association) : 2개 이상의 객체가 상호 관련되어 있음을 의미
• is instance of : 분류화(Classfication) : 동일한 형의 특성을 갖는 객체들을 모아 구성하는 것
• is part of : 집단화(Aggregation) : 관련 있는 객체들을 묶어 하나의 상위 객체를 구성하는 것
• is a
  1. 일반화(Generalization) : 공통적인 성질들로 추상화한 상위 객체를 구성하는 것
  2. 특수화/상세화(Specialization) : 상위 객체를 구체화하여 하위 객체를 구성하는 것

1. 정의

• 시스템 분석, 설계, 구현 등 시스템 개발 과정에서 시스템 개발자와 고객 또는 개발자 상호간의 의사소통이 원활하게 이루어지도록 표준화한 대표적인 객체지향 모델링 언어
• Rumbaugh(OMT), Booch, Jacobson 등의 객체지향 방법론의 장점을 통합
• 객체 기술에 관한 국제표준화기구인 OMG(Object Management Group)에서 표준으로 지정
• 시스템의 구조를 표현하는 6개의 구조 다이어그램과 시스템의 동작을 표현하는 7개의 행위 다이어그램을 작성할 수 있음
• 구성요소 : 사물(Things), 관계(Relationships), 다이어그램(Diagram) 등

2. 사물(Things) = 객체(Object)

• 모델을 구성하는 가장 중요한 기본 요소
• 다이어그램 안에서 관계가 형성될 수 있는 대상들을 말함
• 구조 사물(Structural Things) : 시스템의 개념적, 물리적 요소를 표현
• 행동 사물(Behavioral Things) : 시간과 공간에 따른 요소들의 행위를 표현
• 그룹 사물(Grouping Things) : 요소들을 그룹으로 묶어서 표현
• 주해 사물(Annotation Things) : 부가적인 설명이나 제약조건 등을 표현

3. 관계(Relationships)

• 사물과 사물 사이의 연관성을 표현하는 것
• 종류 : 연관 관계, 집합 관계, 포함 관계, 일반화 관계, 의존 관계, 실체화 관계 등

4. 연관(Association) 관계

• 2개 이상의 사물이 서로 관련되어 있음을 표현
• 사물 사이를 실선으로 연결하여 표현하며, 방향성은 화살표로 표현
• 양방향의 관계일 경우 화살표 생략
• 연관에 참여하는 객체의 개수를 의미하는 다중도(Multiplicity)를 선 위에 표기

5. 집합(Aggregtion) 관계

• 하나의 사물이 다른 사물에 포함되어 있는 관계를 표현
• 포함하는 쪽(전체, Whole)과 포함되는 쪽(부분, Part)은 서로 독립적
• 부분에서 전체 방향으로 속이 빈 마름모를 연결하여 표현 (부분 ―◇ 전체)

6. 포함(Composition) 관계

• 집합 관계의 특수한 형태
• 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계를 표현
• 포함하는 쪽(전체, Whole)과 포함되는 쪽(부분, Part)은 서로 독립될 수 없고 생명주기를 함께함
• 부분에서 전체 방향으로 속이 채워진 마름모를 연결하여 표현 (부분 ―◆ 전체)

7. 일반화(Generalization) 관계

• 하나의 사물이 다른 사물에 비해 더 일반적인지 구체적인지를 표현
• 보다 일반적인 개념을 상위(부모), 보다 구체적인 개념을 하위(자식)라고 부름
• 구체적인 사물에서 일반적인 사물 방향으로 속이 빈 화살표를 연결하여 표현 (하위 ―▷ 상위)

8. 의존(Dependency) 관계

• 연관 관계와 같이 사물 사이에 서로 연관은 있으나 필요에 의해 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계를 표현
• 하나의 사물과 다른 사물이 소유 관계는 아니지만 사물의 변화가 다른 사물에도 영향을 미치는 관계
• 일반적으로 한 클래스가 다른 클래스를 오퍼레이션의 매개 변수로 사용하는 경우에 나타나는 관계
• 영향을 주는 사물(이용자)이 영향을 받는 사물(제공자) 쪽으로 점선 화살표를 연결하여 표현 (이용자 ····> 제공자)

9. 실체화(Realization) 관계

• 사물이 할 수 있거나 해야 하는 기능(오퍼레이션, 인터페이스)으로 서로를 그룹화 할 수 있는 관계를 표현
• 한 사물이 다른 사물에게 오퍼레이션을 수행하도록 지정하는 의미적 관계
• 사물에서 기능 쪽으로 속이 빈 점선 화살표를 연결하여 표현 (사물 ····▷ 기능)

10. 다이어그램(Diagram)

• 사물과 관계를 도형으로 표현한 것
• 의사소통에 도움을 줌
• 정적 모델링에서는 주로 구조적 다이어그램을 사용하고 동적 모델링에서는 주로 행위 다이어그램을 사용함

10. 구조적(Structural) 다이어그램의 종류

• 클래스(Class) 다이어그램 : 클래스와 클래스가 가지는 속성, 클래스 사이의 관계를 표현
• 객체(Object) 다이어그램 : 인스턴스(Instance)를 특정 시점의 객체와 객체 사이의 관계로 표현 (럼바우 객체지향 분석 기법에서 객체 모델링에 활용)
• 컴포넌트(Component) 다이어그램 : 컴포넌트 간의 관계나 인터페이스를 표현 (구현 단계에서 사용)
• 배치(Deployment) 다이어그램 : 물리적 요소들의 위치를 표현하며 노드와 의사소통(통신) 경로로 표현 (구현 단계에서 사용)
• 복합체 구조(Composie Structure) 다이어그램 : 클래스나 컴포넌트가 복합 구조를 갖는 경우 그 내부 구조를 표현함
• 패키지(Package) 다이어그램 : 유스케이스나 클래스 등의 모델 요소들을 그룹화한 패키지들의 관계를 표현

11. 행위(Behavioral) 다이어그램의 종류

• 유스케이스(Use Case) 다이어그램 : 사용자의 요구를 분석하는 것으로 기능 모델링 작업에 사용
• 시퀸스(Sequence) 다이어그램 : 상호 작용하는 시스템이나 객체들이 주고받는 메세지를 표현
• 커뮤니케이션(Communication) 다이어그램 : 시퀸스 다이어그램의 메시지뿐만 아니라 객체들 간의 연관까지 표현
• 상태(State) 다이어그램 : 자신이 속한 클래스의 상태 변화 혹은 다른 객체와의 상호 작용에 따라 상태가 어떻게 변화하는지를 표현 (럼바우 객체지향 분석 기법에서 동적 모델링에 활용)
• 활동(Activity) 다이어그램 : 시스템이 어떤 기능을 수행하는지 객체의 처리 로직이나 조건에 따른 처리의 흐름을 순서에 따라 표현
• 상호작용 개요(Interaction Overview) 다이어그램 : 상호작용 다이어그램 간의 제어 흐름을 표현
• 타이밍(Timing) 다이어그램 : 객체 상태 변화와 시간 제약을 명시적으로 표현

※ 유스케이스 다이어그램의 구성요소 : 시스템(System) / 시스템 범위(System Scope), 액터(Actor), 유스케이스(Use Case), 관계(Relationship)

※ 클래스 다이어그램의 구성요소 : 클래스(Class), 제약조건, 관계(Relationship)

※ 시퀸스 다이어그램의 구성요소 : 액터(Actor), 객체(Object), 생명선(Lifeline), 실행 상자(Active Box), 메시지(Message)

12. 스테레오 타입(Stereotype)

• UML에서 표현하는 기본 기능 외에 추가적인 기능을 표현하기 위해 사용
• 길러멧(Guilemet)이라고 부르는 겹화살괄호(《》) 사이에 표현할 형태를 기술
• 《include》 : 연결된 다른 UML 요소에 대해 포함 관계에 있는 경우
• 《extend》 : 연결된 다른 UML 요소에 대해 확장 관계에 있는 경우
• 《interface》 : 인터페이스를 정의하는 경우
• 《exception》 : 예외를 정의하는 경우
• 《constructor》 : 생성자 역할을 수행하는 경우

1. 정의

• 소프트웨어 개발의 실제적인 첫 단계로 개발 대상에 대한 요구사항을 이해하고 문서화(명세화)하는 활동을 의미
• 사용자 요구의 타당성 조사
• 비용과 일정에 대한 제약 설정
• 요구를 정확하게 추출하여 목표를 정하고, 해결 방안 결정
• 분석 결과는 소프트웨어 설계 단계에서 필요한 기본적인 자료가 되므로 요구사항을 정확하고 일관성 있게 분석하여 문서화해야 함

2. 구조적 분석 기법

• 자료의 흐름과 처리를 중심으로 하는 요구사항 분석 방법
• 도형 중심의 분석용 도구와 절차를 이용하여 요구사항을 파악하고 문서화
• 분석가와 사용자 간의 대화가 용이
• 하향식 방법을 사용하여 시스템을 세분화할 수 있고, 분석의 중복을 배제할 수 있음
• 시스템 분석의 질이 향상되고, 시스템 개발의 모든 단계에서 필요한 명세서 작성이 가능함
• 모델링 기법 : 자료 흐름도(DFD), 자료 사전(DD), 소단위 명세서(Mini-Spec.), 개체 관계도(ERD), 상태 전의도(STD) 제어 명세서 등

3. 자료 흐름도(DFD: Data Flow Diagram) = 자료 흐름 그래프, 버블 차트

• 요구사항 분석에서 자료의 흐름 및 변환 과정과 기능을 도형 중심으로 기술하는 방법
• 시스템 안의 프로세스와 자료 저장소 사이에 자료의 흐름을 나타내는 그래프
• 자료 흐름과 처리를 중심으로 하는 구조적 분석 기법에 이용됨
• 자료 흐름과 기능을 자세히 표현하기 위해 단계적으로 세분화됨
• 자료는 처리(Process)를 거쳐 변환될 때마다 새로운 이름이 부여되며, 처리는 입력 자료가 발생하면 기능을 수행한 후 출력 자료를 산출
• 기호 : 프로세스(Process, 원형), 자료 흐름(Data Flow, 실선 화살표), 자료 저장소(Data Store, 이중 직선), 단말(Terminator, 직사각형)

4. 자료 사전(DD: Data Dictionary)

• 자료 흐름도에 있는 자료를 더 자세히 정의하고 기록한 것
• 데이터의 데이터, 메타 데이터(Meta Data) : 데이터를 설명하는 데이터
• 개발자나 사용자가 편리하게 사용 가능
• = : 자료의 정의
• + : 자료의 연결
• ( ) : 자료의 생략
• [ | ] : 자료의 선택
• { } : 자료의 반복
• * * : 자료의 설명(주석)

5. 소단위 명세서(Mini-Specification) = 프로세스 명세서

• 자료 흐름도 상의 최하위 처리 절차를 상세하게 기술하는 데 사용하는 도구
• 자료 흐름도를 지원하기 위하여 작성
• 구조적 언어, 의사 결정표(판단표), 의사 결정도를 이용하여 기술

6. 개체 관계도(ERD, Entity Relationship Diagram)

• 시스템에서 처리되는 개체(자료)와 개체의 구성과 속성, 개체 간의 관계를 표현하여 개체를 모델화하는 도구
• 자료 흐름도의 자료 저장소를 종합적이고, 체계적으로 모델링함
• 개체(Entity, 직사각형 □), 관계(Relationship, 마름모 ◇), 속성(Attribute, 원형 ○) 등으로 구성

7. 상태 전이도(STD: State Transition Diagram)

• 시스템에 어떤 일이 발생할 경우 시스템의 상태와 상태의 변화를 모델링하는 것
• 상태 전이도를 통해 개발자는 시스템의 행위를 정의할 수 있음
• 시스템의 상태 : 시스템이 수행중인 상태를 의미하는 것으로 직사각형으로 나타냄
• 상태의 변화 : 시스템이 어떤 상태에서 다른 상태로 변환되는 과정을 의미하는 것으로 화살표로 나타냄
• 상태의 변화를 일으키는 조건과 그 조건이 상태를 변화시킬 때 시스템이 취하는 행동을 제시해야 함
• 화살표의 시작은 상태 변화를 일으키는 사건을 의미하며, 화살표의 끝은 사건의 결과로 발생하는 내용(행동)임

1. 정의

• 팀이 중심이 되어 개발의 효율성을 높인다는 의미가 내포된 용어
• 스크럼 팀은 제품 책임자, 스크럼 마스터, 개발팀으로 구성

2. 제품 책임자(PO: Product Owner)

• 이해관계자들 중 개발될 제품에 대한 이해도가 높고, 요구사항을 책임지고 의사 결정할 사람으로 선정하는데, 주로 개발 의뢰자나 사용자가 담당
• 이해관계자들의 의견을 종합하여 제품에 대한 요구사항을 작성하는 주체
• 요구사항이 담긴 백로그(Backlog)를 작성하고 백로그에 대한 우선순위를 지정
• 제품에 대한 테스트를 수행하면서 주기적으로 요구사항의 우선순위를 갱신

3. 스크럼 마스크(SM: Scrum Master)

• 팀이 스크럼을 잘 수행할 수 있도록 객관적인 시각에서 조언을 해주는 가이드 역할을 수행
• 일일 스크럼 회의를 주관하여 진행 사항을 점검하고, 개발 과정에서 발생된 장애 요소를 공론화하여 처리

4. 개발팀(DT: Development Team)

• 제품 책임자와 스크럼 마스터를 제외한 모든 팀원으로, 개발자 외에도 디자이너, 테스터 등 제품 개발을 위해 참여하는 모든 사람이 대상이 됨
• 보통 최대 인원은 7~8명이 적당

5. 스크럼 개발 프로세스

• 제품 백로그 → 스프린트 계획 회의 → 스프린트 → 일일 스크럼 회의 → 스프린트 검토 회의 → 스프린트 회고

6. 제품 백로그(Product Backlog)

• 제품 개발에 필요한 모든 요구사항(User Story)을 우선순위에 따라 나열한 목록
• 개발 과정에서 새롭게 도출되는 요구사항으로 인해 지속적으로 업데이트 됨
• 제품 백로그에 작성된 요구사항을 기반으로 전체 일정 계획인 릴리즈 계획(Release Plan)을 수립

7. 스프린트 계획 회의(Sprint Planning Meeting)

• 이번 스프린트에서 수행할 작업을 대상으로 단기 일정을 수립하는 것
• 개발자들이 나눠서 작업할 수 있도록 태스트(Task)로 분할 수 스프린트 백로그(Sprint Backlog)를 작성
• 태스트 : 작업 단위
• 스프린트 백로그 : 개발자별로 수행할 작업 목록

8. 스프린트(Sprint)

• 실제 개발 작업을 진행하는 과정으로 보통 2 ~ 4주 정도의 기간 내에서 진행
• 스프린트 백로그에 작성된 태스크를 대상으로 작업 시간(양)을 추정한 후 개발 담당자에게 할당
• 할당된 태스크는 보통 할 일(To Do), 진행 중(In Progress), 완료(Done)의 상태를 갖음

9. 일일 스크럼 회의(Daily Scrum Meeting)

• 모든 팀원이 매일 15분 정도의 짧은 시간동안 진행 상황을 점검함
• 남은 작업 시간은 소멸 차트에 표시
• 스크럼 마스터는 발견된 장애 요소를 해결할 수 있도록 도와줌

10. 스프린트 검토 회의(Sprint Review)

• 부분 또는 전체 완성 제품이 요구사항에 잘 부합되는지 사용자가 포함된 참석자 앞에서 테스팅을 수행
• 제품 책임자는 개선할 사항에 대한 피드백을 정리한 후 다음 스프린트에 반영할 수 있도록 제품 백로그를 업데이트 해야 함

11. 스프린트 회고(Sprint Retrospective)

• 스프린트 주기를 되돌아보며 정해놓은 규칙을 잘 준수했는지, 개선할 점은 없는지 등을 확인하고 기록함
• 해당 스프린트가 끝난 시점에서 수행하거나 일정 주기로 수행

1. 개요

• 소프트웨어 개발, 유지보수 등에 필요한 여러 가지 일들의 수행 방법과 이러한 일들을 효율적으로 수행하려는 과정에서 필요한 각종 기법 및 도구를 체계적으로 정리하여 표준화한 것
• 목적 : 소프트웨어의 생산성과 품질 향상

2. 구조적 방법론

• 정형화된 분석 절차에 따라 사용자 요구사항을 파악하여 문서화하는 처리(Process) 중심의 방법론
• 1960년대까지 가장 많이 적용되었던 방법론임
• 목적 : 쉬운 이해 및 검증이 가능한 프로그램 코드를 생성하는 것
• 복잡한 문제를 다루기 위해 분할과 정복(Divide and Conquer) 원리를 적용함
• 절차 : 타당성 검토 → 계획 → 요구사항 → 설계 → 구현 → 시험 → 운용/유지보수

3. 정보공학 방법론

• 정보 시스템의 개발을 위해 계획, 분석, 설계, 구축에 정형화된 기법들을 상호 연관성 있게 통합 및 적용하는 자료(Data) 중심의 방법론
• 대규모 정보 시스템을 구축하는데 적합
• 절차 : 정보 전략 계획 수립 → 업무 영역 분석 → 업무 시스템 설계 → 업무 시스템 구축

4. 객체지향 방법론

• 현실 세계의 개체(Entity)를 기계의 부품처럼 하나의 객체(Object)로 만들어, 소프트웨어를 개발할 때 기계의 부품을 조립하듯이 객체들을 조립해서 필요한 소프트웨어를 구현하는 방법론
• 구조적 기법의 문제점으로 인한 소프트웨어 위기의 해결책으로 채택됨
• 구성 요소 : 객체(Object), 클래스(Class), 메시지(Message) 등
• 기본 원칙 : 캡슐화(Encapsulation), 정보 은닉(Information Hiding), 추상화(Abstraction), 상속성(Inheritance), 다형성(Polymorphism) 등
• 절차 : 요구 분석 → 설계 → 구현 → 테스트 및 검증 → 인도

5. 컴포넌트 기반(CBD: Component Based Design) 방법론

• 기존의 시스템이나 소프트웨어를 구성하는 컴포넌트를 조합하여 하나의 새로운 애플리케이션을 만드는 방법론
• 컴포넌트의 재사용(Reusability)이 가능하여 시간과 노력을 절감할 수 있음
• 새로운 기능을 추가하는 것이 간단하여 확장성이 보장됨
• 유지 보수 비용을 최소화하고 생산성 및 품질을 향상시킬 수 있음
• 절차 : 개발 준비 → 분석 → 설계 → 구현 → 테스트 → 전개 → 인도

6. 애자일(Agile) 방법론

• 고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하면서 개발 과정을 진행하는 방법론
• 소규모 프로젝트, 고도로 숙달된 개발자, 급변하는 요구사항에 적합
• 종류 : 익스트림 프로그래밍(XP: eXtreme Programming), 스크럼(Scrum), 칸반(Kanban), 크리스탈(Crystal) 등
• 절차 : 사용자 스토리 → (계획 → 개발 → 승인 테스트)   *괄호는 반복 주기를 뜻함

7. 제품 계열 방법론

• 특정 제품에 적용하고 싶은 공통된 기능을 정의하여 개발하는 방법론
• 임베디드 소프트웨어를 만드는데 적합
• 영역공학과 응용공학으로 구분
  • 영역공학 : 영역 분석, 영역 설계, 핵심 자산을 구현하는 영역
  • 응용공학 : 제품 요구 분석, 제품 설계, 제품을 구현하는 영역
• 영역공학과 응용공학의 연계를 위해 제품의 요구사항, 아키텍처, 조립 생산이 필요함

1. 정의

• 소프트웨어 개발 방법론의 바탕이 되는 것으로, 소프트웨어를 개발하기 위해 정의하고 운용, 유지보수 등의과정을 각 단계별로 나눈 것
• 소프트웨어 수명 주기라고도 함
• 종류 : 폭포수 모형, 프로토타입 모형, 나선형 모형, 애자일 모형

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

• 현대적인 프로그램 기술을 계속적으로 적용해야 함
• 개발된 소프트웨어의 품질이 유지되도록 지속적으로 검증해야 함
• 소프트웨어 개발 관련 사항 및 결과에 대한 명확한 기록을 유지해야 함

3. 소프트웨어 위기의 현상

• 소프트웨어 개발 속도가 하드웨어 개발 속도를 따라가지 못해 사용자들의 요구 사항을 처리할 수 없는 문제가 발생함을 의미
• 개발 인력의 부족과 그로 인한 인건비 상승
• 성능 및 신뢰성의 부족
• 개발 기간의 지연 및 개발 비용의 증가
• 유지보수의 어려움과 이에 따른 비용 증가
• 소프트웨어의 생산성과 품질 저하

4. 폭포수 모형(Waterfall Model, 고전적 생명 주기 모형)

• 이전 단계로 돌아갈 수 없다는 전제하에 각 단계를 확실히 매듭짓고 그 결과를 철저하게 검토하여 승인 과정을 거친 후에 다음 단계를 진행하는 개발 방법론
• 소프트웨어 공학에서 가장 오래되고 가장 폭넓게 사용된 전통적인 소프트웨어 생명 주기 모형
• 개발 과정의 한 단계가 끝나야만 다음 단계로 넘어갈 수 있는 선형 순차적 모형
• 제품의 일부가 될 매뉴얼을 작성해야 함
• 각 단계가 끝난 후에는 다음 단계를 수행하기 위한 결과물이 명확하게 산출되어야 함
• 타당성 검토 → 계획 → 요구 분석 → 설계 → 구현(코딩) → 시험(검사) → 유지보수

5. 프로토타입 모형(Prototype Model, 원형 모형)

• 사용자의 요구사하을 정확히 파악하기 위해 실제 개발된 소픝웨어에 대한 견본(시제)품(Prototype)을 만들어 최종 결과물을 예측하는 모형
• 시제품은 사용자와 시스템 사이의 인터페이스에 중점을 두어 개발
• 시스템의 일부 혹은 시스템의 모형을 만드는 과정으로서 요구된 소프트웨어를 구현하는데, 이는 추구 구현 단계에서 사용될 골격 코드가 됨
• 소픝웨어의 개발이 완료된 시점에서 오류가 발견되는 폭포수 모형의 단점을 보완하기 위한 모형
• 요구 수집 → 빠른 설계 → 프로토타입 구축 → 고객 평가 → 프로토타입 조정(정제) → 구현

6. 나선형 모형(Spiral Model, 점진적 모형)

• 보헴(Boehm)이 제안한 것으로, 폭포수 모형과 프로토타입 모형의 장점에 위험 분석 기능을 추가한 모형
• 여러 번의 소프트웨어 개발 과정을 거쳐 점진적으로 완벽한 최종 소프트웨어를 개발하는 것
• 목적 : 소프트웨어를 개발하면서 발생할 수 있는 위험을 관리하고 최소화하는 것
• 점진적으로 개발 과정이 반복되므로 누락되거나 추가된 요구사항을 첨가할 수 있고, 정밀하며, 유지보수 과정이 필요 없음
• 초기에 위험 요소를 발견하지 못할 경우 위험 요소를 제거하기 위해 많은 비용이 들 수 있음
• 계획 수립 → 위험 분석 → 개발 및 검증 → 고객 평가

7. 애자일 모형(Agile Model)

• 고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하면서 개발과정을 진행
• 좋은 것을 빠르고 낭비 없게 만들기 위해 고객과의 소통에 초점을 맞춘 방법론을 통칭
• 기업 활동 전반에 걸쳐사용됨
• 스프린트(Sprint) 또는 이터레이션(Iteation)이라고 불리는 짧은 개발 주기를 반복하며, 반복된 주기마다 만들어지는 결과물에 대한 고객의 평가와 요구를 적극 수용함
• 소규모 프로젝트, 고도로 숙달된 개발자, 급변하는 요구사항에 적합
• 애자일 모형을 기반으로 하는 개발 모형 : 스크럼(Scrum), XP(eXtreme Programming), 칸반(Kanban), Lean, 크리스탈(Crystal), ASD(Adaptive Software Development), 기능중심 개발(FDD : Feature Driven Development), DSDM(Dynamic System Development Method), DAD(Disciplined Agile Delivery) 등

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

• 프로세스와 도구 < 개인과 상호작용
• 방대한 문서 < 실행되는 SW
• 계약 협상 < 고객과 협업
• 계획 < 변화 반응

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

2. 운영체제

- 사용자와 컴퓨터 시스템 간의 인터페이스 기능을 제공

- CPU, 기억장치, 파일, 입출력장치 등의 자원을 관리

- 사용자가 쉽게 하드웨어에 접근할 수 있도록 함

※ 고급 언어로 작성된 프로그램을 컴파일하여 기계어로 만들어 주는 것은 언어 번역 프로그램임

8. 유닉스에서 프로세스 구성 요소

- 코드 영역(Code Area)

- 자료 영역(Data Area)

- 스택 영역(Stack Area)

- 사용자 영역(User Area)

12. 유닉스 기본 명령어 중 파일과 관련된 명령어

- cat

- chmod

- cp

- create

- find

- rm

- Is

16. MS-DOS / Windows 기본 명령어

- TYPE : 파일의 내용을 표시

- ATTRIB : 파일의 속성을 변경

- PATH : 파일의 타맥 경로를 지정

- SYS : 시스템 파일을 복사

20. OSI 계층 - 인터넷 프로토콜 

- 응용, 표현, 세션 계층 (응용 계층) : FTP, SMTP, TELNET, SNMP, DNS, HTTP, MQTT

- 전송 계층 (전송 계층) : TCP, UDP, RTCCP

- 네트워크 계층 (인터넷 계층) : IP, ICMP, IGMP, ARP, RARP

- 테이터 링크, 물리 계층 (네트워크 액세스 계층) : Ethenet(IEEE 802.3), IEEE 802, HDLC, X.25, RS-232C

※ 괄호( ) 안의 계층은 TCP/IP의 계층

21. OSI 계층 간단 설명

- 물리 계층 : 시스템과 시스템 간의 물리적인 접속을 제어하는 기능을 제공

- 데이터 링크 계층 : 두 개의 인접한 통신 시스템 간에 신뢰성 있고 효율적인 정보를 전송할 수 있도록 하기 위해 데이터의 오류 검출 및 회복과 흐름 제어를 조절하는 것

- 네트워크 계층 : 시스템들 간의 네트워크 연결 관리 기능과 데이터 교환 및 중계 기능을 제공

- 전송 계층 : 논리적 안정과 균일한 테이터 전송 서비스를 제공하여 종단 시스템 간에 투명한 데이터 전송을 가능하게 함 (하위 계층과 상위 계층의 인터페이스를 담당)

- 세션 계층 : 개체들 간의 관령성을 유지하고 대화 제어를 담당

- 표현 계층 : 서로 다른 데이터 표현 형태를 갖는 응용 계층과 세션 계층 사이에서 상호 접속을 위해 각 계층에 맞게 데이터를 변환하는 기능을 제공

- 응용 계층 : 사용자가 OSI 환경에 접근할 수 있도록 서비스를 제공

1. 정의

- 인터넷에 견결된 서로 다른 기종의 컴퓨터들이 데이터를 주고받을 수 있도록 하는 표준 프로토콜

- TCP/IP는 TCP 프로토콜과 IP 프로토콜이 결합된 것을 의미

2. TCP (Transmission Control Potocol)

- OSI 7계층의 전송 계층 (4계층)에 해당

- 신뢰성 있는 연결혀 서비스를 제공

- 패킷의 다중화, 순서 제어, 오류 제어, 흐름 제어 기능을 제공

3. IP (Internet Protocol)

- OSI 계층의 네트워크 계층 (3계층)에 해당

- 비연결형 서비스를 제공

- 패킷의 분해/조립, 주소 지점, 경로 선택 기능을 제공

- 헤더의 길이는 최소 20Byte ~ 60Byte

4. 구조

응용계층

- OSI계층의 응용, 표현, 세션 계층

- 응용 프로그램 간의 데이터 송/수신 제공

- TELNET

- FTP(File Transfer Protocol), SMTP(Simple Mail Transfer Protocol)

- SNMP(Simple Network Management Protocol)

- DNS(Domain Name System), HTTP(HyperText Transfer Protocol)

- MQTT(Message Queuing Telemetry Transport)

전송 계층

- OSI계층의 전송 계층

- 호스트들 간의 신뢰성 있는 통신 제공

- TCP(Transmission Control Protocol)

- UDP(User Datagram Protocol)

- RTCP(Real-Time Control Protocol)

인터넷 계층

- OSI계층의 네트워크 계층

- 데이터 전송을 위한 주소 지정, 경로 설정을 제공

- IP(Interne Protocol)

- ICMP(Internet Control Management Protocol)

- IGMP(Internet Group Management Protocol)

- ARP(Address Resolution Protocol)

- RARP(Reverse Address Resolution Protocol)

네트워크 액세스 계층

- OSI계층의 데이터 링크, 물리 계층

- 실제 데이터(프레임)를 송/수신 하는 역할

- Ethernet(IEEE 802.3), IEEE 802, HDLC, X.25, RS-232C, ARQ