Dev Diary.

크리스마스에도 집에서 공부~~~~~~~~~~~~~~~~~~!!!!!

메리 크리스마스.....

1.소프트웨어 설계

 1.2 화면 설계

  2.1.1 화면 설계 능력 단위 정의

  2.1.2 UI 요구사항 확인

- 화면 설계 능력 단위 정의

화면 설계란 요구사항분석 단계에서 파악된 화면에 대한 요구사항을 소프트웨어 아키텍처 단계에서 정의된 구현 지침 및 UI/UX 엔지니어가 제시한 UI표준과 지침에 따라 화면을 설계하는 능력이다.

- UI 요구사항 확인

1. UI 표준

1.1 UI의 이해

UI의 개념 

사람과 사물 또는 시스템, 특히 기계, 컴퓨터 프로그램 등 사이에서 의사소통을 할 수 있도록 일시적 또는 영구적인 접근을 목적으로 만들어진 물리적, 가상적 매개체를 뜻한다.

컴퓨터 사용자 인터페이스는 컴퓨터 과학과 인간과 컴퓨터 상호작용(HGI)에서 프로그램이 사용자에게 보여 주는 화상, 문자, 소리 정보와 프로그램을 조작하기 위한 수단(컴퓨터 자판 글쇠 입력, 마우스의 움직임)을 의미한다.

사용자 인터페이스는 크게 다음과 같은 수단을 사용한다.

입력 : 사용자가 시스템을 조작할 수 있게 한다.

출력 : 시스템이 사용자가 이용한 것에 대한 결과를 표시한다.

UI의 종류

그래픽 사용자 인터페이스 (GUI): 그래픽과 텍스트로 이루어져 있으며 객쳊향 인터페이스와 응용 프로그램지향 인터페이스가 공존한다.

웹 기반 인터페이스(WUI) : 인터넷과 웹 브라우저를 통해 웹페이지를 열람하고 조작하는 인터페이스이다.

명령 줄 인터페이스(CLI) : 사용자가 컴퓨터 자판 등을 이용해 명령 문자열을 입력하여 체계를 조작하는 인터페이스이다.

텍스트 사용자 인터페이스(TUI) : 문자열 기반 사용자 인터페이스와 구분하기 위해 그래픽 사용자 인터페이스가 발명된 뒤에 만들어진 용어이다.

터치 사용자 인터페이스

UI의 세 분야

정보 제공과 기능 전달을 위한 물리적 제어 분야

콘텐츠의 상세적 표현과 전체적 구성에 관한 분야

사용자의 편의성에 맞춰 쉽고 간편하게 사용 가능하게 하는 기능적 분야

UI의 설계 원칙

직관성 : 누구나 쉽게 이해하고 사용할 수 있어야 한다.

유효성 : 사용자의 목적을 정확하게 달성하여야 한다.

학습성 : 누구나 쉽게 배우고 익힐 수 있어야 한다.

유연성 : 사용자의 요구사항을 최대한 수용하며, 오류를 최소화하여야 한다.

2. UI 표준

조직의 브랜드나 정체성과 일치되는 디자인 철학과 원칙이 기술되어 UI표준이 정리되고 공통으로 사용하는 UI/GUI 요소 및 배치규칙 등이 정의된다.

3. UI 지침

웹/모바일 서비스의 구축 시 효율적인 정보 전달이 가능하기 하기 위하여 사용자 인터페이스 설계에서 지켜야 할 세부 사항을 규정하는 것을 의미한다.

3.1 사용자 경험(UX)의 고려사항

1. 사용 대상, 사용 환경, 사용 목적, 사용 빈도

2. 직관적으로 서비스 이용 방법을 파악할 수 있는 쉬운 사용 방법

3. 모바일 서비스 특성에 적합한 디자인

4. 사용자 입력을 최소화하고, 자동 완성 기능 제공

5. 사용자의 입력 실수를 되돌릴 수 있는 기능 등 

3.2 핵심기능의 고려사항

1. 모바일 기기의 화면 크기를 고려하여 메뉴 구조를 단순화하고 간결한 정보 제공

2. 모바일 환경에서 활용성 높은 기능 중심으로 서비스 제공

3. 서비스 목적에 부합하는 기능 중심의 서비스를 제공

3.3 호환성과 확장성의 고려사항

1. 모바일 웹의 경우 기술적 제약이 없는 한 3개 이상의 브라우저에서 동등한 서비스를 제공하도록 설계

2. 모바일 기기의 화면 해상도에 따라 호환성을 고려하여 사용자 인터페이스 설계

3. 특정 모바일 운영체계에서만 동작하는 기능 지양

3.4 정보소외계층의 접급성

모바일 서비스 구축 시 장애인 고령자 등이 모바일 서비스에 쉽게 접근하고 이용할 수 있도록 "장애인 , 고령자 등의 정보 접근 및 이용 편의 증진을 위한 지침" 을 준수하여야 한다.

3.5 일관성 

모바일 서비스 구축 시 색상, 글자체, 용어 사용 등에 있어서 일관성을 유지하여야 한다.

3.6 이미지

1. 모바일 서비스 구축 시 전송 속도, 전송량 등을 고려하여 경량화된 이미지를 제공하여야 한다.

2. 성적 표현, 특정 종교나 인종, 여성의 비하 등 사회적 갈등을 유발할 수 있는 이미지를 사용하여서는 안된다.

3. 단순히 색상과 그래픽에 의존한 서비스 제공을 지양하여야 한다.

4. 모바일 서비스 구축 시 사용되는 모든 이미지의 저작권을 확보하여야 한다.

3.7 기타 설계 지침

1. 사용자 중심

사용자가 이해하기 편하고 쉽게 사용할 수 있는 환경을 제공하며 실사용자에 대한 이해가 바탕이 되어야 한다.

2. 단순성

조작 방법은 가장 간단하게 작동이 가능하도록 하여 인지적 부담을 감소시켜야 한다.

3. 결과 예측 가능

작동시킬 기능만 보고도 결과 예측이 가능하여야 한다.

4. 가시성

주요 기능을 메인 화면에 노출하여 조작이 쉽도록 하여야 한다.

5. 표준화

디자인을 표준화하여 기능 구조의 선행 학습 이후 쉽게 사용할 수 잇어야 한다.

6. 접근성

사용자의 직무, 연령, 성별 등 다양한 계층을 수용하여야 한다.

7. 명확성

사용자가 개념적으로 쉽게 인지하여야 한다.

8. 오류 발생 해결

사용자가 오류에 대한 상황을 정확히 인지할 수 있어야 한다.

3. 스토리 보드

3.1 스토리보드의 개념

스토리보드는 디자이너와 개발자가 최종적으로 참고하는 설계 산출 문서로 정책, 프로세스 및 콘텐츠의 구성, 와이어프레임(UI/UX), 기능 정의, 데이터 베이스의 연동 등 서비스 구축을 위한 대부분의 정보가 수록되어 있다.

3.2 스토리보드 작성 절차

1.메뉴 구성도 만들기(1단계)

전체적인 메뉴 구성도이며, 어떤 것을 보여주고 결정된 사항을 표현하기 위한 메뉴의 순서와 구성 단계, 용어를 정의한다.

2.스타일 확정(2단계)

레이아웃이나 글자 모양, 크기, 색상, 그래픽에서의 일관성을 유지해야 한다.

3.설계하기(3단계)

화면에 보여지는 시각적인 디자인 콘셉트를 잡는다.

오답풀이

9문제 모두 정답~~~~~~~ 즐거운 크리스마스 보내세용ㅎㅎ

1.소프트웨어 설계

 1.1 요구사항 확인

  1.1.4 분석모델 확인

- 분석모델 확인

1. 모델링 기법

1.1 모델링의 개념

모델링의 정의 : 실세계의 물리현상을 특정한 목적에 맞추어 이용하기 쉬운 형식으로 표현하는 일을 의미

개념모델링 의 역할

실세계 문제에 대한 모델링이 소프트웨어 요구사항 분석의 핵심이며, 모델은 문제가 발생하는 상황에 대한 이해를 증진시키고 해결책을 설명한다.

따라서 개념모델은 문제 도메인의 엔티티들과 그들의 관계 및 종속성을 반영한다.

1.2 개념 모델의 종류와 표기법

유스케이스 다이어그램, 데이터 흐름 모델, 상태 모델, 목표기반 모델, 사용자 인터액션, 객체 모델, 데이터 모델 등 과 같은 다양한 모델을 작성할 수 있다. 

대부분의 모델린 표기법은 UML을 사용한다.

1.3 UML 다이어그램의 사용

사용 시나리오를 나타내기 위하여 유스케이스 다이어그램이 많이 사용되고 있다.

구조 다이어그램은 시스템의 정적구조와 다양한 추상화 및 구현 수준에서 시스템의 구성요소, 구성 요소들 같의 관계를 보여준다.

행위 다이어그램은 시스템 내의 객체들의 동적인 행위를 보여주며, 시간의 변화에 따른 시스템의 연속된 변경을 설명해준다.

2. 분석자동화 도구

2.1 유스케이스 모델 검증

한국정보화진흥원의 정보 시스템 감리지침에서는 시스템 기능에 대한 유스케이스 모형 상세화 수준 및 적정성에 대하여 다음과 같은 사항을 점검하도록 하고 있다고 한다.

2.2 개념 수준의 분석 클래스 검증

시스템의 주요 도메인 개념을 분석 클래스로 도출하여 유스케이스 분석에 활용하므로, 개념수준의 주요 분석 클래스를 적절히 도출하였는지, 관련 정보가 명확한지 점검해야한다.

주요 점검 항목

• 개별 유스케이스 단위로 작성하지 않고 시스템 전체를 대상으로 작성하였는가?
• 중요도가 높은 요구사항 도는 유스케이스에 필요한 엔티티 클래스가 도출 되었는가?
• 도출된 클래스 이름과 설명이 이해관계자 간에 이견이 발생하지 않도록 명확한가?
• 클래스의 속성은 도출하였는가? 도출된 속성의 이름과 설명이 명확한가?
• 클래스들 간에 순환적 관계과 불필요하게 정의되어 있는가?
• 클래스 간의 관계에서 다중성이 정의되었는가?

2.3 분석 클래스 검증

유스케이스마다 분석 클래스가 적절히 도출되었고, 제어 클래스의 도출 등이 충분하고 상세하게 도출되어 클래스의 역할, 클래스 간의 관계, 메시지 흐름 등을 확인할 수 있는지 검토한다.

1.유스케이스 실현에 필요한 분석 클래스 도출 확인

하나의 유스케이스를 실현하기 위하여 3개 이상의 클래스가 역할 기준으로 도출되어야 하며, 유스케이스 별로 실현에 필요한 클래스가 추적 가능해야 클래스 누락 여부를 확인할 수 있다.

유스케이스 별로 도출된 분석 클래스 들이 역할 기준으로 경계, 엔티티, 제어 클래스가 도출되어 스테레오 타입으로 표시되었는지 확인한다.

2.경계와 제어 클래스의 도출 여부 빛 상세화 정도 확인

유스케이스 실현에 필요한 분석 클래스들이 도출되었는지 확인하기 위하여, 유스케이스 단위로 분석 클래스를 확인한다.

3.클래스 간의 관계, 클래스 정보의 상세화 정도 확인

3.요구사항 관리 도구

3.1 요구사항 관리 도구의 개념

요구사항을 기반으로 프로젝트 관리, 설계, 개발, 테스트 등을 수행할 수 있는 역할을 지원하는 도구이다.

히스토리, 베이스라인, 교환과 같은 요구사항 관리 기능, 요구사항 간의 혹은 요구사항과 다른 산출물 간의 추적성, 다양한 CASE도구와의 통합, 자체 언어와 API를 통한 확장성을 지원한다.

3.2 요구공학의 요구사항 관리

요구공학에서는 요구사항 관리를 요구사항 협상, 요구사항 기준선, 요구사항 변경관리, 요구사항 확인 및 검증 등으로 정의하고 있다.

3.3 요구사항 관리 도구의 주요기능

요구사항 관리 도구는 제품에 따라 기능과 특성의 차이가 있을 수 있으나, 보편적인 요구사항 관리 도구의 기능 사례는 

아래와 같다.

1.프로젝트 생성

프로젝트 타입 및 기본 모듈 템플릿, 속성, 역할별 뷰를 설정하여 프로젝트 생성을 도와주며 이를 저장하여 재사용 할 수 있도록 할 수 있다.

2.요구사항 작성

모든 요구사항에 고유의 ID가 생성, 부여되고 이 ID는 사용자에 의한 임의 변경이 될 수 없도록 한다.

3.요구사항 Import/Export

요구사항의 일괄 등록 및 추출을 위해 Plain Text,Rich Text,Spread sheet, Word, Excel, Outlook, HTML 등 다양한 형식의 파일 Import 와 Export 기능을 제공한다.

4.요구사항 이력관리

요구사항 별로 히스토리 관리 기능을 제공하여 변경 이력을 관리할 수 있다.

5.요구사항 베이스라인

요구사항이 확정되고 관리의 시작점이 되는 요구사항 베이스라인 기능을 제공한다.

5.요구사항 추적성

어느 요구사항이 베이스인지를 구분하기 위한 기능으로 현재 요구사항을 기반으로 작성된 요구사항인지, 타 요구사항을 기반으로 하여 현재 요구사항이 작성되었는지를 알려준다.

7.협업 환경

하나의 요구사항 문서를 여러 명이 작성할 수 있도록 하는 협업 기능이다. 일반적으로 공유 모드를 제공하고 선점 사용자외에는 수정 및 삭제 권한이 제한된다.

8.외부 연동 환경

요구사항대로 설계되었는지를 파악하기 위해 설계도구와 연동을 지원하며, 요구사항대로 구현되었는지를 확인하기 위해 형상 관리도구와의 연동을 지원한다.

9.확장성

API 등을 통해 타 시스템과의 연동 기능을 제공한다.

오답풀이

시스템의 기능을 여러 개의 고유 모듈들로 분할하여 이들 간의 인터페이스를 계층구조로 표현한 도형 또는 도면을 무엇이라 하는가?

1.Flow chart(나의 오답)

2.HIPO Chart(정답) 

3.Control Specification

4.Box Diagram

HIPO는 하향식 소프트웨어 개발을 위한 문서화 도구이다. 기능과 자료의 의존관계를 동시에 표현할 수 있어서 보기 쉽고 이해하기 쉽다.

3.Control Specification

4.Box Diagram 이것들은 뭘까..?

Control Specification

요구되는 완전성의 수준을 보증하기 위하여 데이터 처리 시스템 중에 적용되어야 할 규칙의 기술들.

Box diagram

NS(Nassi-Schneiderman) Chart

- 논리 기술에 중점을 둔 도형을 이용한 표현 방법(Box Diagram, Chapin Chart) 

- 순차, 반복, 선택, 다중 선택 구조등 표현 

- GOTO나 화살표 사용하지 않음, 선택과 반복 구조를 시각화 

- 조건이 복합되어 있는 곳의 처리를 시각적으로 명확히 식별 

출처: https://yeolco.tistory.com/6 [열코의 프로그래밍 일기]

소프트웨어 재사용에 가장 많이 이용되는 것은?

1.HIPO chart

2.Test Case

3.Source Code(정답) 이게 정답이었다니..

4.Project Plan

소스코드는 프로그래머가 작성한 프로그램이다. 소스코드를 통해 재사용, 수정, 세부처리 내용을 파악할 수 있다.

1.소프트웨어 설계

 1.1 요구사항 확인

  1.1.3 요구사항 확인

- 요구사항 확인

1. 요구분석기법

1.1 요구분석의 개념

도출된 요구사항들 간의 상충을 해결하고 소프트웨어의 범위를 파악하며 소프트웨어가 환경과 어떻게 상호작용하는지를 분석하는 과정을 말한다.

외부사용자와의 인터페이스 및 내부시스템 구성요소간의 인터페이스를 정확히 분석하여 시스템을 계층적이고 구조적으로 표현한다.

1.2 요구분석 기법

1.사용자그룹 인터뷰

요구사항을 도출한 사용자를 대상으로 인터뷰를 수행한다.

많은 사용자로부터 인터뷰를 하는 것이 좋고 회의록 작성은 필수이다.

필요시 인터뷰 내용을 녹음하여 반복 청취하는 것이 좋다.

2.이해관계자 설문조사

사용자와 대면 조사가 어려울 때에 설문 형식으로 조사한다.

현행 시스템의 개선 의견을 끌어낸다.

3.문헌 조사

유사 프로젝트 및 업무 문서나 양식을 조사하여 현재 시스템 정보에 대한 이해를 도출한다.

산업 및 기업표준, 정부 정책, 규제 및 법규도 조사한다.

개발팀은 업무 도메인 교육이나 튜토리얼에 참가한다.

4.프로토타이핑

요구사항에 대한 이해를 하기 위하여 기본적인 기능만 빠르게 구현하여 사용자로부터 피드백을 받는 기법이다.

개발자의 아이디어를 사용자로부터 조기에 피드백 받고자 할 때 사용한다.

프로토타이핑 전용언어로 모의 사용자 인터페이스를 사용한다.

5.사용자 스토리텔링

사용자의 요구사항을 이야기 형식으로 기술하여 자연스럽게 개발자가 요구사항에 대한이해가 가도록 구성하는 기법이다.

주로 애자일 방법에서 사용하는데 개발자와 사용자가 서로 긴밀히 대화하면서 요구사항을 함께 만들어간다.

2. UML

2.1 UML의 개념

객체지향 소포트웨어 개발과정에서 산출물을 명세화, 시각화, 문서화할 때 사용되는 모델링 기술과 방법론을 통합하여 만든 표준화된 범용 모델링 언어이다.

특징으로는 

가시성 : 반복적/점진적으로 구체화하여 소프트웨어의 가시성을 제공한다.

문서화 : 개발규모, 개발 프로세스 및 언어와 무관하게 개발자간 의사소통 도구를 제공한다.

명세화 : 단순 표기법이 아닌 구현에 필요한 개발적 요소 및 기능에 대한 명세를 제공한다.

구성요소

View : 모델화된 시스템의서로 다른 모형 제공

Diagram : View의 내용을 나타내기 위한 9가지 다이어그램 제공

모델요소 : 객체지향 개념을 표현하기 위해 사용되는 요소 ( 클래스, 속성, 오퍼레이션으로 구성 )

General Mechanism : 모델 요소에 대하여 주석 정보와 의미 제공

2.2 UML 다이어그램 종류

3. 애자일

3.1 애자일 방법론의 개념

1.애자일 방법론 정의

전체 개발 단계에서 변화에 대한 신속한 대응으로 요구사항을 지속적으로 분석,반영하여 배포 시간차를 최소화하는 개발방법론이다.

2.애자일 방법론의 등장배경

애자일 방법론은 소프트웨어 개발 방법에 있어서 아무런 계획이 없는 개발 방법과 계획이 지나치게 많은 개발 방법들 사이에서 타협점을 찾고자하는 방법론이다.

계획이 없는 방법론의 경우, 앞으로의 일을 예측하기 힘들고 비효율적인 점에서 취약점을 가짐 계획에 의존하는 경우는 그 형식적인 절차를 따르는데 필요한 시간, 비용을 무시할 수 없고 전체적인 개발 흐름을 느리게하는 단점보유

계획을 통해서 주도해 나갔던 과거의 방법론과는 다르게 앞을 예측하여 개발하지 않고 일정한 주기를 가지고 끊임없이 프로토타입을 만들어내며 그때 그때 필요한 요구를 더하고 수정하여 하나의 커다란 소프트웨어를 개발해나가는 방식

3.애자일 선언문

소프트웨어를 개발하고 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있으며 이를 통해 다음을 가치있게 여기게 되었다.

공정과 도구보다 개인과 상호작용

포괄적인 문서보다 작동하는 소프트웨어를

계약 협상보다 고객과의 협력을

계획을 따르기보다 변화에 대응하기를 가치있게 여긴다.

3.2 애자일 개발 프로세스

어느 특정 개발 방법론을 가리키는 말은 아니며 "애자일 : 기민한 ,좋은것을 빠르고 낭비없게 만드는것 " 개발을 가능하게 해 주는 다양한 방법론 전체를 일컫는 말이다. 과거에는 애자일 개발 프로세스는 "경량 프로세스" 로 불림

익스트림 프로그래밍이 애자일 개발 프로세스의 대표적인 방법이라 볼 수 있음!

3.3 애자일 방법론의 종류

3.4 애자일 방법론과 전통 방법론 비교

오답풀이

설계 기법 중 하향식 설계 방법과 상향식 설계 방법에 대한 비교설명으로 가장 옳지 않은 것은?

1.하향식 설계에서는 통합 검사 시 인터페이스가 이미 정의 되어 있어서 통합이 간단하다.

2.하향식 설계에서 레벨이 낮은 데이터 구조의 세부 사항은 설계 초기 단계에서 필요하다.

3.상향식 설계는 최하위 수준에서 각각의 모듈들을 설계하고 이러한 모듈이 완성되면 이들을 결합하여 검사한다.

4.상향식 설계에서는 인터페이스가 이미 성립되어있지 않더라도 기능 추가가 쉽다.( 정답 )

상향식 설계와 하향식 설계에 대한 개념이 잡혀있지 않은 상황이라 구글링을 통해 공부를 하였다!

- 상향식 설계(Bottom-up Design)

1. 세부 기능의 구현을 초기에 강조

2. 결과 프로그램 = 세부 기능들의 조합

3. 단점: 주어진 문제의 고유 특성을 고려하지 않는 설계가 될 위험이 있음.

※ 최하위 단계에 있는 작은 단위를 먼저 결정하고 이를 이용하여 좀 더 큰 단위인 상위 단계의 문제를 해결하는 방법이다. 최하위 단위의 문제들에 대해 기존에 개발되어 있는 문제해결 도구(알고리즘)를 재사용할 수 있는 경우에는 개발기간과 비용을 단축하고 신뢰성을 확보할 수 있다.

- 하향식 설계(Top-down Design)

1. 프로그램을 관리 가능한 세그먼트들로 분할

2. 단점: "도미노 효과"가 발생 가능

※ 도미노 효과: 한가지를 수정할 때 연관되어 있는 다른 것들도 다 같이 수정해야 될 수 있음

※ 무엇을 수행할 것인지 정의하는 단계에서 시작하여 다음 단계에서 어떻게 수행할 것인지를 구체적으로 정의하고, 그 다음 단계에서 더 세분화하여 정의하는 방식으로서 하위 단계로 갈수록 좀 더 구체적으로 세부 문제를 정의한다. 마지막으로 최하위 단게로 분할된 작은 단위의 문제들을 각각 처리함으로써 전체 문제를 해결한다. 이러한 방식은 분할 정복이라고도 한다. 출처: https://berapp.tistory.com/entry/기본-개념 [Bera의 개발 이야기]

상향식 설계에서는 세부 기능의 구현을 초기에 강조하기 때문에 4번이 정답이 아닐까 .... 하는 생각이다 

효과적인 모듈화 설계 방법으로 가장 거리가 먼 것은?

1.Coupling은 강하게 Cohesion는 약하게 설계한다.(정답)

2.Complexity와 Redundancy를 최대한 줄일 수 있도록 설계한다.

3.Maintenance가 용이하도록 설계한다.

4.Module 크기는 시스템의 전반적인 기능과 구조를 이해하기 쉬운 크기로 설계한다.

이문제는 원어를 잘 몰라서 어려웠다.. 내가아는 것이라곤 Maintenance와 Module 뿐..

Coupling : 결합도

Cohesion : 응집도

Complexity : 복잡성

Redundancy : 불필요한 중복

2번은 무조건 맞는말이고... 결합도와 응집도에 대해서 공부해보았다!

결합도와 응집도는 모듈의 독립성을 판단하는 두 가지 지표이다.

결합도(또는 의존도)는 어떤 모듈이 다른 모듈에 의존 정도를 말한다.

응집도는 모듈 내부의 기능적인 집중 정도라고 할 수 있다.

이상적인 모듈화는 결합도는 낮을 수록, 응집도는 높을 수록 "유지보수성이 높다"라고 할 수 있다.

결합도가 높은 클래스의 문제점

• 연관된 다른 클래스가 변경되면 더불어 변경이 필요하다
• 수정하려는 클래스를 이해하기 위해 연관된 클래스를 함께 이해해야한다.
• 다른 프로그램에서의 클래스를 재사용하기 힘들다.

 응집도가 낮은 클래스의 문제점

• 이해하기 어려움
• 재사용하기 힘듦
• 유지보수가 어려움
• 다른 클래스의 변화에 민감함

출처 1000hg.tistory.com/32

1.소프트웨어 설계

 1.1 요구사항 확인

  1.1.1 요구사항 확인 능력단위 정의

  1.1.2 현행 시스템 분석

-요구사항 확인 능력 단위 정의

요구사항 확인이란 업무 분석가가 수집/분석/정의한 요구사항과 이에 따른 분석모델에 대해서 확인과 현행 시스템

에 대해 분석하는 능력이다.

-현행 시스템 분석

능력단위요소 : 현행 시스템 분석하기

수행 준거 

1.1 개발하고자 하는 응용소프트웨어에 대한 이해를 높이기 위해, 현행 시스템의 적용현황을 파악함으로써 개발범위와      향후 개발될 시스템으로의 이행 방향성을 분석할 수 있다.

1.2 개발하고자 하는 응용소포트웨어와 관련된 운영체제, 데이터베이스 관리시스템, 미들웨어등의 요구사항을 식별 할        수 있다.

1.3 현행시스템을 분석하여 개발하고자 하는 응용소프트웨어가 이후 적용될 목표시스템을 명확하고 구체적으로 기술할      수 있다.

1. 플랫폼 기능 분석 

1.1 플랫폼의 개념

일반적으로 플랫폼이란 응용 소프트웨어 프로그램을 구동시키는데 쓰이는 하드웨어와 소프트웨어의 결합을 말한다. 플랫폼은 소프트웨어 개발과 운영을 쉽게하고 한번 만들어진 소프트웨어는 동일한 플랫폼에서는 언제, 어디서 실행시키더라도 손쉽게 구동이 될 수 있도록 만들어진 결합체를 의미한다. 

예를들면 자바 플랫폼, 닷넷 플랫폼을 들 수있고, 모바일 플랫폼은 iOS와 안드로이드 플랫폼을 들 수 있다.

요구사항을 확인하기 위하여 현행 시스템을 분석하기 위해서는 현재 시스템의 구성요소인 소프트웨어 및 하드웨어 플랫폼을 상세하게 분석해야 한다.

1.2 플랫폼의 기능

소프트웨어 개발 및 운영 비용을 감소한다.

동일한 플랫폼간 커뮤니티를 형성하여 네트워크 효과를 유발한다.

소프트웨어 개발의 생산성을 향상시킨다.

1.3 플랫폼의 기능 특성 확인방법

기능테스트 : 현재 시스템의 플랫폼을 평가할 수 있는 기능테스트를 수행한다.

사용자 인터뷰 : 현재 시스템 사용자를 대상으로 플랫폼 기능의 불편함을 인터뷰 한다.

문서 점검 : 현재 시스템의 플랫폼과 유사나 플랫폼의 기능 자료를 분석한다.

2. 플랫폼 성능 특성 분석

2.1 현행 시스템 분석하기에서 플랫폼의 성능 특성을 알아야하는이유

현재의 시스템에 구성된 플랫폼의 성능을 분석해야 사용자가 사용하기에 속도가 느린지 빠른지 알 수있기 때문

사용자 요구사항 중에 성능에 대한 요구사항이 있는데 이느 현재 시스템의 플랫폼 성능이 느려서 제기되는 요구사항일 가능성이 높기 때문

2.2 플랫폼 성능 특성 확인 방법

성능테스트 : 현재 시스템의 플랫폼을 대상으로 성능/부하 테스트를 수행한다.

문서 점검 : 현재 시스템의 플랫폼과 유사한 플랫폼의 성능 자료를 분석한다.

사용자 인터뷰 : 현재시스템 사용자와의 인터뷰를 통하여 성능을 확인한다.

3. 운영체제 분석

3.1 운영체제의 개념

운영체제는 하드웨어와 소프트웨어 자원을 관리하고 컴퓨터 프로그램을 위한 공통 서비스를 제공하느 소프트웨어를 의미한다.

3.2 현재 시스템의 운영체제를 분석한다.

현재 운영체제의 종류, 버전, 패치일자, 백업주기 등을 분석한다.

운영체제의 종류에는 윈도우, 리눅스, 유닉스 등 매우 다양하다.

3.3 운영체제의 종류 및 특징

윈도우 : 중소규모서버, 개인용 pc,임베디드 시스템

유닉스 : 대용량 처리, 안정성이 요구되는 서버, NAS

리눅스 : 중/대규모 서버

iOS : 스마트폰, 태블릿pc, 음악 플레이어 등

Andoid : 스마트폰, 태블릿pc

4. 네트워크 분석

4.1 네트워크의 개념

컴퓨터 네트워크 또는 컴퓨터망은 노드들이 자원을 공유할 수 있게 하는 디지털 전기통신망의 하나이다.

즉 분산되어 있는 컴퓨트를 통신망으로 연결한 것을 말한다. 컴퓨터 네트워크에서 컴퓨팅 장치들은 노드 간 연결을 사용하여 서로에게 데이터를 교환한다. 이 데이터 링크들은 유선, 광케이블과 같은 케이블 매체, 또는 와이파이와 같은 무선매체를 통해 확립된다.

OSI 7 계층의 정의

네트워크 통신에서 생기는 여러가지 충돌 문제를 완화하기 위해 국제표준기구에서 제시한 기본 모델이다.

4.2 현재 시스템의 네트워크를 분석한다.

현재 시스템이 구성된 네트워크 구조를 분석한다.

사내 인터넷 센터, 백본망, 라우터, 스위치, 방화벽 등을 분석한다.

4.3 현재 시스템의 네트워크 구성도를 작성한다.

현재 시스템의 서버의 위치, 서버 간의 네트워크 연결방식, 논리 및 물리 네트워크 구성도를 작성한다.

5. DBMS 분석

5.1 데이터베이스의 개념

사용자와 다른 애플리케이션, 데이터베이스 등과 상호작용하여 데이터를 저장하고 분석하기위한 컴퓨터 소프트웨어로 데이터베이스 생성, 조회, 변경등의 관리가 주요 기능이다.

5.2 데이터베이스의 기능

데이터 저장과 개발 및 유지보수 측면에서 중복성 통제

다중 사용자간의 데이터 공유 

권한없는 사용자의 데이터접근 통제

다양한 사용자에게 다양한 형태의 인터페이스 제공

데이터 사이에 존재하는 복잡한 관련성 표현

데이터베이스의 무결성 보장

백업과 복구기능 제공

5.3 현재 시스템의 데이터베이스 시스템을 분석한다.

DBMS의 종류, 버전, 구성방식, 스토리지 크기, 백업 주기 등을 분석한다.

테이블 수량, 데이터 증가 추이, 백업 방식 등을 분석한다.

5.4 논리/물리 테이블의 구조 파악

각 테이블의 정규화 정도, 조인의 난이도를 파악한다.

조인이란 여러개의 테이블을 결합하여 데이터를 검색하는 것을 의미한다.

각종 프로시저, JOB 트리거 등을 분석하낟.

6. 비즈니스 융합분석

6.1 비즈니스 융합의 개념

-비즈니스

재화나 서비스 등 유무형의 가치를 제공하고 그에 상응하는 대가를 보상받는 등 영리를 목적으로 행하는 모든 활동을 말한다. 

재화나 서비스의 개발 및 제공을 통해 영리를 추구하는 기업활동 또는 경영활동이다.

-비즈니스 모델

고객의 가치를 창출하고 시장에서 성공적인 경쟁을 하기 위해 고안된 조직 목표, 전략, 프로세스, 기술, 구조 등을 포함하는 요소들의 구성체이다.

-비즈니스 융합

산업 또는 시장 간의 경계를 허물고 ICT등을 통한 새로운 전달방식을 도입함으로써 비즈니스 모델의 적용범위를 확대시키는 것을 의미한다.

6.2 비즈니스 융합 분석

-고객분석

비즈니스 모델 상에서 사업자에게 수익을 제공하는 참여자를 식별하고 분석한다.

-제품 및 서비스 분석

비즈니스 모델 상에서 자사가 제공하는 상품 또는 서비르를 식별하고 분석한다.

비즈니스 융합 참여자간 제공하는 서비스와 제공받는 서비스를 식별하고 문석한다.

-사업구조 분석

상품 및 서비스의 제공자, 소비자 등 참여자간의 관계와 구조를 식별하고 분석한다.

오답 풀이

다음 프로그래밍 시스템에서 발생하는 교착상태의 4가지 필요조건에 해당하는 조건으로 옳지 않은 것은?

1.점유와 대기 

2.비선점 - 나의 오답 (4개의 보기가 전부 맞는것 같았고 선점이라고 생각했음.. 제대로 다시 공부하자..)

3.환형 점유 ( 환형 점유가 아닌 환형 대기!!!!!!)

4.상호배제

다음 중 외부 인터럽트의 설명으로 옳지 않은 것은?

1.프로그램과 비동기적으로 발생 - 나의 오답 ( 내부 인터럽트가 동기적으로 발생함!! ....)

2.정전이나 전원 이상으로 발생

3.입출력 데이터의 오류나 이상현상으로 발생

4.프로그램 처리 중 명령의 요청에 의해 발생 ( 명령의 요청에 의해 발생되는것은 소프트웨어 인터럽트임 !!! )