정보처리기사 필기-소프트웨어 설계1

Hyor·2022년 2월 1일

정보처리기사

1. 요구사항 확인

소프트웨어 생명 주기

소프트웨어 생명주기란 소프트웨어 개발방법론의 기초가 되는것으로서 개발을 위한 분석, 운용, 유지보수 등의 과정을 각각 단계별로 나누는 것이다.

소프트웨어 공학의 기본원칙
- 현대적인 프로그래밍 기술을 계속적으로 적용해야한다.
- 개발된 소프트웨어의 품질이 유지되도록 지속적으로 검증해야 한다.
- 소프트웨어 개발 관련 사항 및 결과에 대한 명확한 기록을 유지해야합니다.

소프트웨어 생명주기모형으로는 아래에 4가지가 대표적이다.

폭포수 모형
- 개발과정에서 이전 단계로 돌아갈 수 없다는 전제하에 각 단계를 확실히 매듭짓고 그 결과를 철저하게 검토하여 승인 과정을 거친 후에 다음 단계를 진행하는 개발방법론이다.
- 가장오래되고 폭넓게 사용된 전통적인 소프트웨어 생명 주기모형이다.
- 선형 순차적모형이다.
- 모형을 적용한 경험과 성공사례가 많다.
- 각 단계가 끝난 후에는 다음단계를 수행하기위해서 결과물이 명확하게 산출되어야한다.
- 타당성 검토 -> 계획 -> 요구 분석 -> 설계 -> 구현(코딩) -> 시행(검사) -> 유지보수
프토토타입 모형
- 사용자의 요구사항을 정확히 파악하기 위해서 실제 개발된 소프트웨어에 대한 프로토타입을 만들어 최종 결과물을 예측하는 모형이다.
- 사용자 요구사항이 불명확할때 용이하다.
- 요구 수집 -> 빠른 설계 -> 프로토타입 구축 -> 고객평가 -> 프로토타입 조정 -> 구현
나선형 모형
- 보헴이 제안한것으로 폭포수 모형과 프로토타입 모형의 장점에 위험분석 기능을 추가한 모형이다.
- 계획 수립 -> 위험 분석 -> 개발 및 검증 -> 고객 평가
에자일 모형
- 고객의 요구사항 변화에 유연하게 대응할수 있도록 일정한 주기를 반복하면서 개발과정을 진행한다.
- 고객과의 소통에 초점을 맞춘 개발방법론이다.
- 에자일 모형을 기반으로 하는 소프트웨어 개발 모형에는 스크럼(Scrum),XP(eXtreme Programming), 기능중심개발(FDD) 등이 있다.

에자일 개발 4가지 핵심가치
1. 프로세스와 도구보다 개인과 상호작용에 더 가치를 둔다.
2. 방대한 문서보다는 실행되는 SW에 더 가치를 둔다.
3. 계약협상보다는 고객과 협업에 더 가치를 둔다.
4. 계획을 따르기보다는 변화에 반응하는 것에 더 가치를 둔다.

스크럼

팀이 중심이 되어서 개발의 효율성을 높인다. 팀원 스스로가 스크럼 팀을 구성해야하며, 개발 작업에 관한 모든 것을 스스로 해결할 수 있어야한다.
스크럼팁은 제품책임자, 스크럼마스터, 개발팀으로 구성된다.

제품책임자 (PO: Product Owner)
이해관계자들 중 개발된 제품에 대한 이해도가 높고, 요구사항을 책임지고 의시 결정할 사람으로 선정한다.
요구사항이 담긴 백로그를 작성하고 벡로그에 대한 우선수위를 지정한다.
스크럼 마스터 (SM: Scrum Master)
스크럼 팀이 스크럼을 잘 수행하도록 객관적인 시각에서 조언을 해주는 가이드 역할
개발팀 (DT: Develpment Team)
제품책임자와 스크럼 마스털르 제외한 모든 팀원

스크럼 프로세스는
제품 백로그 -> 스프린트 계획 회의 -> 스프린트 -> 일일 스크럼 회의 -> 스프린트 검토 회의 -> 스프린트 회고

제품백로그
제품 개발에 필요한 모든 요구사항을 우선순위에 따라 나열한 것이다.
스프린트 계획 회의
스프린트에서 처리할 요구사항(User Story)을 개발자들이 나워서 작업할 수 있도록 테스크라는 작업단위로 분할, 개발자별로 수행할 작업 목록인 스프린트 백로그를 작성
스프린트
실제 개발 작업을 진행하는 과정, 2~4주 정도 기간 내에서 진행한다.
일일 스크럼 회의
모든 팀원이 약속된 시간에 15분 정도 짧은 시간동안 진행상황을 점검한다.
스프린트 검토 회의
부분 또는 전체 완성제품이 요구사항에 부합하는지 사용자가 포함된 참석자 앞에서 테스팅을 수행한다.
스프린트 회고
스프린트 주기를 되돌아보며 정해높은 규칙을 잘 준수했는지, 개선할 점은 없는지 등을 확인하고 기록한다.

XP(eXtreme Programming)

짧고 반복적인 개발 주기, 단순한 설계, 고객의 적극적인 참여를 통해 소프트웨어 를 빠르게 개발하는것을 목적으로한다.

XP의 5가지 핵심가치
- 의사소통
- 단순성
- 용기
- 존중
- 피드백
XP의 주요 실천 방법
- Pair Programming
- Collective Ownership
- Test-Driven Development
- Whole Team
- Continuous Integration
- Design Imporvement
  * Small Releases

현행시스템 파악

새로 개발하는 시스템의 개발 범위를 명확히 설정하기 위해 현행 시스템의 구성과 제공기능, 시스템 간의 전달정보, 사용되는 기술 요소, 소프트웨어, 하드웨어 그리고 네트워크의 구성 등을 파악해야한다.

시스템 구성 파악
시스템 기능 파악
시스템 인터페이스 파악
시스템 간에 주고받는 테이터의 종류, 형식, 프로토콜, 연계유형, 주기 등을 명시한다.
아키텍처 구성 파악
기간 업무 수행에 어떠한 기술 요소들이 사용되는지 최상위 수준에서 계층별로 표현한 아키텍처 구성도 작성한다.
소프트웨어 구성 파악
하드웨어 구성 파악
네트워크 구성 파악

개발 기술 환경 파악

개발하고자 하는 소프트웨어와 관련된 운영체제, DBMS, 미들웨어, 등을 선정할 떄 고려해야 할 사항을 기술하고, 오픈 소스 사용 시 주의해야 할 내용을 제시한다.

운영체제 관련 요구사항 식별 시 고려사항
- 가용성
  - 시스템의 장시간 운영으로 발생할 수 있는 운영체제 고유의 장애발생 가능성
  - 메모리 누수로 인한 성능 저하
  - 보안상 발견된 허점을 보완하기 위한 지속적인 패치 설치로 인한 재기동
  - 운영체저의 결함 등으로 인한 패치 설치를 위한 재기동
- 성능
- 기술 지원
- 주변 기기
- 구축 비용
DBMS
- Oracle, MySQL, MongoDB, Redis, IBM DB2, Microsoft SQL, Server, SQLite 등이 있다.
DBMS 고나련 요구사항 식별 시 고려사항
- 가용성
- 성능
- 기술 지원
- 상호 호환성
- 구축 비용
웹 애플리케이션 서버(WAS: Web Application Server)
- Tomcat, GlassFish, JBoss, Jetty, JEUS, Resin, WebLogic, WebSphere 등이 있다.
웹 애플리케이션 서버 관련 요구사항 식별 시 고려사항
- 가용성
  - 시스템의 장시간 운영으로 발생할 수 있는 운영체제 고유의 장애발생 가능성
  - WAS 결함 등으로 인한 패치 설치를 위한 재기동
  - 안정적인 트랜잭션 처리
  - WAS 이중화 지원
- 성능
- 기술 지원
- 구축 비용
  - 라이센스 정책 및 비용

요구사항 정의

소프트웨어가 어떤 문제를 해결하기 위해 제공하는 서비스에 대한 설명과 정상적으로 운영되는데 필요한 제약조건 등을 보여준다.

요구사항 유형
- 기능 요구사항
  - 어떤 기능을 하는지에 대한 사항
    - 입력이나 출력으로 무엇이 포함되어야하는지, 어떤 데이터를 저장하거나 연산을 수행해야하는지에 대한 사항
    - 시스템이 반드시 수행해야하는 기능
    - 사용가 시스템을 통해 받고자하는 기능
- 비기능 요구사항
  - 시스템 장비 구성 요구사항 : 하드웨어, 소프트웨어, 네트워크 등의 시스템 장비구성에 대한 요구사항
    - 성능 요구사항
    - 인터페이스 요구사항
    - 데이터 요구사항
    - 테스트 요구사항
    - 보안 요구사항
    - 품질 요구사항
    - 제약사항
    - 프로젝트 관리 요구사항
    - 프로젝트 지원 요구사항
- 사용자 요구사항
- 시스템 요구사항
요구사항 개발 프로세스
- 개발대상에 대한 요구사항을 체계적으로 도출하고 이를 분석한 후 분석결과를 명세서에 정리한 다음 마직막으로 이를 확인 및 검증하는 일련의 구조화된 활동이다.
- 도출 -> 분석 -> 명세 -> 확인

요구사항 분석

요구사항을 이해하고 문서화하는 활동을 의미하며, 개발 대상에 대한 사용자의 요구사항 중 명확하지 않거나 모호하여 이해되지 않는 부분을 발견하고 이를 걸러내기 위한 과정이다.

구조적 분석 기법
- 시스템 개발의 모든 단계에서 필요한 멍세서 작성이 가능하다.
- 구조적 분석 기법
  - 자유 흐름도(DFD)
    자료의 흐름 및 변환 과정과 기능을 도형 중심으로 기술하는 방법으로 자료흐름 그래프, 버블차트라고한다.
    자료흐름과 기능은 프로세스, 자료흐름, 자료 저장소, 단말 4가지 기본 기호로 표시한다.
  - 자료 사전(DD)
    자료흐름도에 있는 자료를 더 자세히 정의하고 기록한 것이며, 이처럼 데이터를 설명하는 데이터를 데이터의 데이터 또는 메타데이터라고한다.
    '=' : 자료의 정의
    '+' 자료의 연결
    '()' 자료의 생략
    '[|]' 자료의 선택
    '{}' 자료의 반복
    '* *' 자료의 설명
  - 소단위 명세서(Mini-Spec)
  - 개체 관계도(ERD)
  - 상태 전이도(STD)
  - 제어 명서세

HIPO(Hierarchy Input Process Output)

시스템의 분석 및 설계나 문서화할 떄 사용되는 기법으로, 시스템 실행 과정인 입력, 처리, 출력의 기능을 나타낸다.

기본 시스템모델은 입력, 처리, 출력으로 구성되며, 하향식 소프트웨어 개발을 위한 문서화 도구이다.
처계적인 문서 관리가 가능하다.
기호, 도표 등을 사용, 이해하기도 쉽다.
기능과 자료의 의존 관계를 동시에 표현할 수 있다.
변경, 유지보수가 용이하다.
HIPO Chart

시스템의 기능을 여러 개의 고유 모듈들로 분할, 이들 간의 인터페이스를 계층구조로 표현한 것이다.
종류
- 가시적 도표
  전체적인 기능과 흐름을 보여주는 계층
- 총체적 도표
  기능을 기술한 것으로 입력, 처리, 출력에 대한 전반적인 정보제공
- 세부적 도표
  총체적 도표에 표시된 기능을 구성하는 기본 요소들을 상세히 기술하는 도표

UML(Unified Modeling Language)

시스템 분석, 설계, 구현 등 시스템 개발 과정에서 시스템 개발자와 고객 또는 개발자 상호간의 의사소통이 원할하게 이루어지도록 표준화한 대표적인 객체지향모델링언어이다.

UML 구성요소
사물(모델을 구성하는 가장 중요한 기본요소, 다이어그램 안에서 관계가 형성될 수 있는 대상)

관계(사물과 사물 사이의 연관성)

연관관계
집합관계
포함관계
일반화관계
하나의 사물이 다른 사물에 비해 더 일반적인지 구체적인지를 표현한다.
ex) 사람은 여자와 남자보다 일반적인 개념, 여자와 남자는 사람보다 구체적인 개념
의존관계
연관관계와 같이 사물사이에 서로 연관은 있으나 필요에 의해 서로에게 영향을 주는 짦은 시간 동안만 연관을 유지하는 관계를 표현
하나의 사물과 다른 사물이 소유관계는 아니지만 사물의 변화가 다른 사물에도 영향을 미치는 관계이다.
실체화관계
사물이 할 수 있거나 해야하는 기능(오페레이션, 인터페이스)으로 서로를 그룹화 할 수 있는 단계
한 사물이 다른 사물에게 오퍼레이션을 수행하도록 지정하는 의미적단계이다.

다이어그램

구조적 다이어그램종류
- 클래스 다이어그램
  시스템을 구성하는 클래스, 클래스의 특성인 속성과 오퍼레이션(클래스가 수행할 수 있는 동작으로 함수(Method 라고도함), 속성과 오퍼레이션에 대한 제약조건, 클래스 사이의 관계를 표현한것이다.
- 객체 다이어그램
- 컴포넌트 다이어그램
- 배치 다이어그램
- 복합체 구조 다이어그램
- 패키지 다이어그램
행위 다이어그램종류
- 유스케이스 다이어그램
  개발될 시스템을 이용해 수행할 수 있는 기능을 사용자의 관점에서 표현
  - 외부요소와 시스템간의 상호 작용을 확인할 수 있다.
    - 사용자의 요구사항을 분석하기 위한 도구로 사용된다.
    - 시스템의 범위를 파악할 수 있다
- 시퀀스 다이어그램
  시스템이나 객체들이 메시지를 주고받으며 시간의 흐름에 따라 상호작용하는 과정을 액터 ,객체, 메시지 등의 요소를 사용하여 그림으로 표현한것이다.
  구성요소
  - 액터 - 서비스를 요청하는 외부 요소, 사람이나 외부 시스템을 의미
    - 객체 - 메시지를 주고받는 주체
    - 생명선 - 메모리에 존재하는 기간, 객체 아래쪽에 점선을 그어 표현
    - 실행 상자 - 메시지를 주고 받으며 구동되고 있음을 표현
    - 메시지 - 상호작용을 위해 주고받는 메시지
- 커뮤니케이션 다이어그램
- 상태 다이어그램
  하나의 객체가 자신이 속한 클래스의 상태 변화 혹은 다른 객체외의 상호 작용데 따라 상태가 어떻게 변화하는지를 표현한다.
  럼바우 객체지향 분석기법에서 동적 모델링에 활용한다.
- 활동 다이어그램
- 상호작용 다이어그램
- 타이밍 다이어그램

스테레오 타입

UML 에서 표현하는 기본 기능 외에 추가적인 기능을 표현하기 위해사용
길러멧이라는 겹화살괄호<<>> 를 사용한다.

<<include>> 연결된 다른 UML요소에 대해 포함관계

<<exclude>> 연결된 다른 UML요소에 대해 확장관계

<<interface>> 인터페이스 정의

<<exception>> 예외를 정의

<<constructor>> 생성자 역할