정보처리기사 필기 문제 유형 분석 (9)

안녕하세요. 소복냥 입니다.
9번째 시간 달려가 보겠습니다.

* CASE (Computer Aided Software Engineering)

• 소프트웨어 공학의 여러 작업들을 자동화하는 도구
• 소프트웨어 부품의 재사용성을 향상해줍니다.
• 소프트웨어 품질과 일관성을 효율적으로 관리할 수 있습니다.
• 소프트웨어 생명 주기의 모든 단계를 연결시켜 주고 자동화시켜 줍니다.
• 소프트웨어의 유지보수를 용이하게 수행할 수 있도록 해줍니다.
• 소프트웨어 공학의 여러 작업들을 자동화하는 도구입니다.
• 소프트웨어 시스템의 문서화 및 명세화를 위한 그래픽 기능을 제공합니다.
• 자료 흐름, 비즈니스 프로세스 등의 다이어그램을 쉽게 작성하게 해주는 소프트웨어도 CASE 도구입니다.

* UML (Unified Modeling Language)

소프트웨어 시스템을 개발하는 과정에서 산출물의 명세화, 시각화, 문서화할 때 사용하는 모델링 언어입니다.
하나의 시스템을 표현하기 위한 표준적인 방법을 제공하기 위해서 만들어졌습니다.

* UML Diagram 종류 ( 구조 / 행위 다이어그램)

* 구조 다이어그램

Class Diagram (클래스 다이어그램)

• 클래스의 속성, 함수, 변수 타입들로 구성된 다이어그램입니다.

Object Diagram (객체 다이어그램)

• 클래스의 인스턴스, 값이 매겨진 행동을 가지고 있는 독립된 객체 정보를 표현하는 다이어그램입니다.

Package Diagram (패키지 다이어그램)

• UML의 다양한 모델 요소를 그룹화한 다이어그램입니다.

Component Diagram (컴포넌트 다이어그램)

• 컴포넌트끼리의 구조 관계를 표현한 다이어그램입니다.

Deployment Diagram (배치 다이어그램)

• 소프트웨어, 하드웨어 등을 포함한 시스템의 물리적인 구조를 나타내는 다이어그램입니다.

* 행위 다이어그램

Use Case Diagram (쓰임새 다이어그램)

• 사용자 관점에서 바라본 시스템을 표현한 다이어그램입니다.

Acticity Diagram (활동 다이어그램)

• 여러 활동들이 순차, 병행 방식 등을 수행하는 상황을 표현한 다이어그램. 시스템 내부에 존재하는 여러 가지 행위들과 각 행위의 분기, 분기가 생기기 위한 이벤트들을 포함합니다. 상태 다이어그램과의 차이는 활동 다이어그램은 시스템 전체의 흐름을 표현한다면, 상태 다이어그램은 하나의 객체의 흐름을 나타내는데에서 차이가 있습니다.

State Diagram (상태 다이어그램)

• 하나의 객체가 다른 객체와의 상호 작용에 따라 어떻게 변화하는지 표현하는 다이어그램. 다시 말해 하나의 객체에서 발생하는 활동 변화를 그림으로 나타낸 다이어그램입니다.

Sequence Diagram (순서 다이어그램)

• 여러 대상 간의 상호작용을 시간 순서에 따라 표현한 다이어그램입니다.

Communication Diagram (커뮤니케이션 다이어그램)

• 동작에 참여하는 객체들이 주고받는 메시지를 표현하고, 메시지뿐만 아니라 객체 간의 관계까지 표현하는 다이어그램입니다.

* 객체지향 분석 (OOA; Object Oriented Analysis)

• 사용자의 요구사항을 분석하여 요구된 문제와 관련된 모든 클래스 (객체), 이와 연고나 된 속성과 연산, 그들 간의 관계 등을 정의하여 모델링하는 작업을 의미합니다. 객체는 클래스로부터 인스턴스화 되고, 이 클래스를 식별하는 것이 객체지향 분석의 주요한 목적입니다.
• 소프트웨어를 개발하기 위한 비즈니스 (업무)를 객체와 속성, 클래스와 멤버, 전체와 부분 등으로 나누어서 분석해 내는 기법입니다.

* 소프트웨어 생명주기

* 폭포수 모형

• 이전 단계로 돌아갈 수 없습니다. 각 단계를 확실히 매듭짓고 그 결과를 철저히 검토하여 승인 과정을 거친 후 다음 단계로 진행하는 개발 방법론입니다.
• 소프트웨어공학에서 가장 오래되었고, 가장 폭넓게, 전통적인 SW생명주기, 고전적 생명 모형 주기입니다.
• 개발의 한 과정이 끝나야 다음 단계로 진행 가능한 개발 방법론입니다.
• 제품 일부가 될 매뉴얼 작성해야 합니다.
• 2개 이상의 과정이 병행하여 수행되지 않습니다.
• 각 단계가 끝난 후에는 다음 단계로 수행하기 위한 결과물이 명확하게 산출되어야 합니다. (단계적 정의, 산출물 명확합니다)
• 순차적 접근방법입니다.
• 모형 적용 경험과 성공사례가 많습니다.

* 프로토타입 모형, 원형 모형

• 사용자의 요구사항을 정확하게 하기 위해 실제 개발될 소프트웨어에 대한 견본품을 만들어 최종 결과물을 예측하는 모형입니다.
• 시제품(프로토타입)은 사용자와 시스템 사이의 인터페이스 중점을 두어 개발합니다.
• 시스템 일부 or 모형을 만드는 과정으로서 요구된 소프트웨어를 구현하는데, 이는 추후 구현 단계에서 사용될 골격 코드가 됩니다.
• SW의 개발이 완료된 시점에서 오류가 발견되는 폭포수 모형의 단점을 보완하기 위한 모형입니다.

* 나선형 모형, 점진적 모형, Sprial Model

• 보헴이 제안했습니다.
• 폭포수 모형과 프로토타입 모형 장점에 위험 분석 기능 추가한 모형입니다.
• 대규모입니다.
• 여러 번의 SW 개발 과정을 거쳐 점진적으로 완벽한 최종 SW를 개발합니다.
• SW를 개발하면서 발생할 수 있는 위험 관리 및 최소화가 목적입니다.
• 점진적으로 개발 과정이 반복되므로 누락되거나 추가된 요구사항을 첨가할 수 있고, 유지보수 과정이 필요 없습니다.
• 계획 및 정의 > 위험 분석 > 공학적 개발 > 고객 평가

* 애자일 모형 Agile Model

• 고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하면서 개발 과정을 진행합니다.
• 좋은 것을 빠르게, 낭비 없이 만들기 위해 고객과의 소통에 초점을 맞춘 방법론입니다.
• 스프린트 (Sprint), 이터레이션 (Iteration)과 같은 짧은 개발 주기 반복, 반복되는 주기마다 만들어지는 결과물에 대한 고객의 평가와 요구를 적극 수용합니다.
• 각 개발 주기에서는 고객의 요구사항에 우선순위를 부여하여 개발 작업을 진행합니다.
• 소규모 프로젝트, 고도로 숙달된 개발자, 급변하는 요구사항에 적합합니다.
• 스크럼 (Scrum), XP (eXtreme Programming), 칸반 (Kanban), Lean, 크리스털 (Crystal) ASD, FDD, DSDM, DAD

* XP (eXtreme Programming)의 5가지 핵심 원칙

• 의사소통 (Communication)
• 단순성 (Simplicity)
• 용기 (Courage)
• 존중 (Respect)
• 피드백 (Feedback)

끝까지 읽어주셔서 감사합니다!

정보처리기사 필기 문제 유형 분석 (8)