일학습병행제 개념 퀴즈

단위 업무 정보시스템들의 명칭, 주요기능 명시

구성 현황

 

조직의 주요 업무를 처리

기간업무

 

기간업무를 지원

지원업무

 

 

단위 업무 시스템에서 제공하는 기능들을 주요기능과 하부기능으로 구분하여 계층형으로 표시

기능 현황

 

주고받는 데이터의 종류, 데이터 형식, 프로토콜, 연계유형, 주기 명시 주고받는 형식, 통신규약, 연계유형이 무엇인지가 중요

인터페이스 현황

 

기간업무를 수행하기 위하여 계층별로 어떠한 기술 요소들을 사용하고 있는지 최상위 수준에서 그림으로 표현한 것. 아키텍처가 다른 경우 가장 핵심이 되는 기간 업무 처리 시스템을 기준으로 함.

현행 시스템 아키텍처 구성도

 

제품명, 용도, 라이선스 적용방식, 라이선스 수 명시 라이선스 적용 방식의 기준 h가 보유한 라이선스 수량 파악이 중요

소프트웨어 구성도

 

1) 단위 업무 시스템들이 어디에 위치하고 있는 서버에서 운용되는지

2) 서버의 주요사양과 수량 이중화(= 백업)가 적용되어 있는지.

이중화는 기간 업무의 서비스기간, 장애대응 정책에 따라 필요성 여부 결정

하드웨어 구성도

 

1) 작성을 통해 파악 내용

- 서버의 위치

- 서버 간 네트워크 연결 방식

 

2)용도

- 서버들의 물리적인 위치 관계파악

- 조직 내 보안 취약성 분석 및 대응

- 네트워크 장애 발생 추적 및 대응

네트워크 구성도

 

-하드웨어와 소프트웨어 리소스를 관리

-컴퓨터 프로그램을 위한 공통 서비스를 제공하는 소프트웨어

운영체제

 

-마이크로소프트윈도즈:

중소규모 서버, 개인PC, 태블릿PC, 임베디드 시스템 유지 및 관리 비용 강점인 운영체제

 

-유닉스:

대용량처리/안정성이 요구 되는 서버

 

 

-리눅스:

중대 규모 서버, 일반적으로 소유 비용이 가장 적게 소요

 

-IOS:

스마트폰, 태블릿, MP

 

-안드로이드:

스마트폰, 태블릿

 

자바 가상 머신(JVM)

- 다양한 하드웨어 및 운영체제에서 자바 언어로 작성된 어플을 수행하기 위한 사양 의 구현체

-오라클이 자바 상표를 소유

-핫스파 구현체와 클래스 라이브러리 구현체를 배포

-운영체제 관련 요구사항을 식별할 때 고려해야 할 사항

 

-

*DBMS

-Oracle :

대량데이터

 

-IBM DB2

:대량데이터

 

-마이크로소프트 SQL:

중소 규모 데이터

 

-MySQL:

오픈 소스 RDBMS

 

-SQLite:

스마트폰, 태블릿 pc등의 임베디드 시스템

 

-MongoDB:

오픈 소스 NoSQL 데이터베이스

 

-Redis:

오픈소스, 메모리에 저장, 키-값으로 저장하는 데이터베이스

 

 

*미들웨어

-운영체제와 소프트웨어 어플리케이션 사이 위치

-어플에게 운영체제가 제공하는 서비스를 추가 및 확장하여 제공하는 컴퓨터 SW

 

 

 

미들웨어의 예시인 WAS=웹 어플리케이션 서버

-동적인 웹 사이트

-웹서비스의 개발을 지원하기 위하여 설계된 소프트웨어

-데이터 접근, 세션 관리, 트랜잭션 관리 등을 위한 라이브러리 제공

 

GlassFish:

NetBeans 개발 툴과 연동하여 사용. WAS중 하나

 

JBoss:

JBoss 기반 오픈 소스 제품들을 이용하는 경우 . WAS중 하나

 

Jetty:

빠른 처리 속도가 요구되는 경우 . WAS중 하나

 

JEUS:

대량의 안정적인 거래 처리가 요구되며, 적시의 기술 지원이 필요한 경우 . WAS중 하나

 

Resin:

빠른 처리 속도가 요구되는 경우 . WAS중 하나

 

WebLogic:

대량의 안정적인 거래 처리가 요구되는 경우 . WAS중 하나

 

WebSphere:

대량의 안정적인 거래 처리가 요구되는 경우 . WAS중 하나

 

*요구공학

요구사항을 정의, 문서화, 관리하는 프로세스

 

(1) 요구사항 도출

-이해관계자가 식별됨

-개발 팀과 고객사이의 관계가 만들어짐

-효율적인 의사소통 중요

 

(2) 요구사항 분석

-소프트웨어의 범위를 파악

-소프트웨어와 환경의 상호작용 이해

 

(3) 요구사항 명세 :

-체계적으로 검토, 평가, 승인될 수 있는 문서를 작성

-시스템 정의, 시스템 요구사항, 소프트웨어 요구사항 작성

 

(4) 요구사항 확인

-분석가가 요구사항을 이해했는지 확인

-요구사항문서가 회사 표준에 적합하고 이해가능하며 일관성 있고 완전한지 검증

-요구사항 관리 툴로 형상 관리

-리소스가 요구사항에 할당되기 전에 문제를 파악하기 위하여 검증을 수행

 

*분석기법

1.요구사항 분류

-기능인지 비기능인지

-하나 이상의 고수준 요구사항으로부터 유도된 것인지 또는 이해관계자나 다른 원천으로부터 직접 발생한 것인지

-제품에 관한 것인지 프로세스에 관한 것인지

-우선순위가 더 높은 것인지 여부

-요구사항의 범위(요구사항이 소프트웨어에 미치는 영향의 범위)

-소프트웨어 생명 주기 동안에 변경이 발생하는지 여부

 

2.개념 모델링

-실세계 문제에 대한 모델링

-엔티티(데이터의 독립적인 단위)들과 그들의 관계 및 종속성(의존)을 반영

 

 

*UML

대부분의 개념 모델링에서 모델링 표기법

 

유스케이스 다이어그램(사용 시나리오를 나타냄)

UML에서 사용하는 다이어그램은

 

-구조 다이어그램:

-시스템의 정적구조

-다양한 추상화 및 구현수준에서 시스템의 구성 요소,

-구성요소들 간의 관계를 보여준다

 

-행위 다이어그램: 

-시스템의 동적인 행위

-시간의 변화에 따른 시스템의 연속된 변경을 설명

 

3.요구사항 할당

-아키텍처 구성 요소를 식별하는 것

-다른 구성 요소와 어떻게 상호작용하는지 분석을 통하여 추가적인 요구사항을 발견

 

 

4.요구사항 협상

 

5.정형분석

-형식적으로 정의된 시맨틱을 지닌 언어로 요구사항을 표현

- 요구사항 분석의 마지막 단계

 

*요구사항 확인 기법

(1) 요구사항 검토

-여러 검토자들이 에러, 잘못된 가정, 불명확성, 표준과의 차이 등을 찾아내는 작업

-검토자 그룹 구성이 중요

-시스템정의서, 시스템사양서, 소프트웨어 요구사항 명세서를 완성한 시점에 함

 

(2) 프로토타이핑

-장점:

-잘못된 경우 유용한 피드백을 제공

-사용자 인터페이스의 동적인 행위가 이해하기 쉬움

-요구사항의 가변성이 급격히 감소

- 잘못된 요구사항을 만족시키기 위하여 자원을 낭비하는 것을 방지

-단점:

-핵심기능에서 관심이 멀어질수도

- 수행 비용

 

(3) 모델 검증

-품질 검증

 

(4) 인수 테스트

-최종 제품이 요구사항을 만족시키는지 확인

-각각의 요구사항을 어떻게 확인할것인지 계획

 

Q.유스케이스 모델 검증의 세가지 요소

액터, 유스케이스, 유스케이스 명세서

액터
기능구현 관련 엑터 모두 도출?
엑터명이 역할 중심으로 명명?
요구사항 정의서, 요구사항 기술서에 외부/내부 엑터가 모두 도출?
엑터 목록과 엑터 명세서에 기록된 엑터가 타당?

유스케이스(= 시스템이 사용자 또는 외부시스템과 상호작용하여 수행해야 할 기능을 정의한  시나리오 )
유스케이스가 모두 도출?
도출된 유스케이스를 논리적으로 연결하여 누락된 기능 파악
도출된 유스케이스가 유스케이스 목록과 유스케이스 명세서에 반영되었는지
도출된 유스케이스의 논리적인 합이 과업 범위와 일치하는지
=프로젝트 목표를 완전하고 정확하게 반영하고 있는지 확인
도출된 유스케이스들이 논리적으로 그룹화 되었는지
(그룹화는 엑터, 연관관계, 동시성 기준)

기능의 범위가 다른 유스케이스와 중복되지 않는지

유스케이스 명세서(유스케이스를 구체적으로 기술한 문서)
유스케이스 명세서 형식에 중요 항목이 누락되지 않았는지
(사전 및 사후 조건, 주요흐름, 서브흐름, 예외흐름 등)
주요이벤트 흐름이 모두 도출되고 논리적으로 타당한지
유스케이스를 구현하기 위하여 필요한 입출력 항목이 모두 도출 되었는지

 

 

시스템과 외부 엑터와의 상호작용을 담당하는 클래스

경계

 

시스템이 유지해야 하는 정보를 관리하는 기능을 전담하는 클래스

엔터티

 

시스템이 제공하는 기능의 로직 및 제어를 담당

제어