[정보처리기사: 필기] 1. 소프트웨어 설계 (1)

1. 소프트웨어 공학의 개념

소프트웨어의 특징

- 상품성

- 복잡성: 개발하는 과정이 복잡하고 관리가 어려움

- 변경 가능성: 업데이트 및 오류 수정

- 복제성: 유통을 위한 복제

시스템의 개요와 기본 요소

시스템: 하나의 조직

기본 요소: 입력 -> 처리 -> 출력 -> 제어 -> 피드백

소프트웨어 위기

개발 비용의 증가, 개발 기간의 지연, 개발 인력 부족 및 인건비 상승, 성능 및 신뢰성 부족, 유지보수의 어려움 등

소프트웨어 공학

현대적인 프로그래밍 기술 적용

높은 신뢰성

높은 편리성과 유지보수성

지속적인 검증 시행 등등

---

2. 재공학

재공학(Reengineering)

장점: 개발 시간 및 비용 감소, 품질 향상, 프로젝트 실패 위험 감소(한 번 검증됨) 등

목표: 유지보수 향상, 수월한 재사용으로 소프트웨어 수명 연장, 유실된 정보의 복구 및 제거 등

과정: 분석 -> 구성 -> 역공학 -> 이식

S/W 재공학 관점에서 가장 연관 깊은 유지보수 유형: Preventive Maintenance

역공학(Reverse Engineering)

소프트웨어를 분석, 재발견하거나 다시 만들어내는 작업

역공학의 가장 오래되고 간단한 형태는 재문서화

CASE(Computer Aided Software Engineering)

소프트웨어를 만드는데 도움을 주는 도구

개발을 신속 정확하게, 생명주기의 전체 단계를 연결/자동화, 문서화 및 명세화를 위한 그래픽 기능

개발 단계의 표준화와 모순 검사 기능 제공 => 생산성 및 품질, 모듈 재사용성 향상

 

상위 CASE: 요구분석 및 설계 단계 지원

하위 CASE: 소스 코드 작성, 테스트, 문서화 과정

통합 CASE: 소프트웨어 개발 주기 전체 과정 지원

 

SADT(Structured Analysis and Design Technique): 블록 다이어그램 지원

REM, PSL/PSA, TAGS 등

---

3. 소프트웨어 개발 방법론

소프트웨어 생명 주기

소프트웨어 제품의 개념 형성에서 시작, 운용 및 유지보수까지 가는 단계

타당성 검토 -> 개발 계획 -> 요구사항 분석 -> 설계 -> 구현 -> 테스트 -> 운용 -> 유지보수

 

폭포수 모형(Waterfall Model)

선형 순차적 모델. 고전적 생명주기 모형. 각 단계가 순차적

소규모에 적합, 중간에 변형 힘듦

나선형 모형(Spiral Model)

 

반복적인 작업을 수행하는 점증적 생명주기 모형

점증적 모형, 집중적 모형으로 유지보수 과정 X

개발 중 발생할 수 있는 위험 분석 및 관리, 최소화하는 것이 목적

나선을 따라 돌아가면서 각 순서를 반복, 누락된 요구사항을 추가할 수 있음

하향식/상향식 설계

하향식 설계: 제일 상위의 기능에서 시작 -> 하위 기능으로 나눠 설계

상향식 설계: 가장 기본적인 컴포넌트를 먼저 설계 -> 상위 수준의 컴포넌트를 설계

프로토타입 모형의 개요

실제 개발될 시스템의 견본, 시제품을 미리 만들어 최종 결과물을 예측

개발이 완료되고 나서 사용할 때 문제점을 알 수 있는 폭포수 모형의 단점을 개선, 보완

HIPO(Hierarchy Input Process Output)

계층적 입력, 처리, 추력으로 구성되는 시스템 분석 및 설계와 시스템 문서화용 기법

가시적 도표(전체적인 기능과 흐름을 보여주는 구조), 총체적 다이어그램, 세부적 다이어그램으로 구성됨

하향식 소프트웨어 개발을 위한 문서화 도구

가독성, 유지보수 용이

V-모델

 

폭포수 모형에 시스템 검증과 테스트 작업을 강조한 모델

생명주기 초반부터 테스트 작업을 지원하며 코드, 요구사항, 설계 결과도 테스트 가능

폭포수 모형보다 반복, 재처리 작업이 명확하며 단계별로 작업을 나눠 책임이 명확함

(기능에 따라 어떤 작업을 하는지 확인)

애자일 개발 방법론

특정 방법론이 아니며 소프트웨어가 잘 실행되는 것에 가치를 둠

따라서 절차, 도구보다 소통, 피드백을 중요하게 생각함

짧은 릴리즈와 반복, 점증적 설계, 문서 최소화 

익스트림프로그래밍(XP), 스크럼, 린, DSDM, FDD, ASD 등이 있음

XP

양질의 소프트웨어를 신속하게 제공하는 것이 목표

핵심 가치: 소통, 단순성, 피드백, 용기, 존중

 

User Story: 고객에 의해 작성되는 요구사항

Release Planning: 몇 개의 스토리가 적용돼 부분적으로 기능이 완료된 제품을 제공하는 것

Iteration(반복): 하나의 릴리즈를 세분화한 단위. 1~3주 단위로 진행. 반복 중 새로운 스토리를 추가 반복할 수 있음

Acceptance Test: 테스트를 통해 오류 발견 시 다음 반복에 추가

Small Release: 릴리즈 단위를 기능별로 세분화해 고객 반응 확인. 최종 완제품도 최종 테스트 진행 후 제공

 

12개의 실천 사항

짝 프로그래밍

Planning Game

TDD

Whole Team(고객을 팀원으로)

Continuous Integration(CI, 지속적 통합)

Design Improvement(기능 변경 없이 중복성/복잡성 제거)

Small Release(짧은 주기로 잦은 릴리즈)

Coding Standards(표준화 준수)

Collective Code Ownership

Simple Design

System Metaphor(최종 개발될 시스템의 구조 기술)

Sustainable Pace(개발자 학대 금지...)

 

효과적인 프로젝트 관리를 위한 3대 요소 (3P)

사람, 문제, 프로세스

---

4. SCRUM

애자일 방법론 중 하나

빠르고 신속하게 개발하는 개발 방법론

 

기능 협업을 기준으로, 스프린트 단위로 소프트웨어 개발

스프린트(고정된 30일의 반복, 2~4주) 시 행하는 작업은 고정됨 => 소멸 차트로 작업 현황 확인

요구사항, 아키텍처, 설계가 잘 드러나야 하며 정해진 시간 준수

완료된 모든 작업은 제품 백로그(제품 개발에 필요한 요구사항을 우선순위에 따라 나열한 목록)에 기록됨

가장 기본적인 정보 교환 수단은 일일 스탠드업 또는 일일 스크럼

 

제품 개발자(PO, 스프린트 시작 시 팀 운영에 관여 X)

스크럼 마스터(업무 배분. 개발 과정의 장애 요소 제거)

스크럼 팀(실제로 작업하는 팀원)

---

5. 현행 시스템 분석

개발 시스템의 개발 범위 확인 및 이행 방향성 설정

어떤 하위 시스템으로 구성되어 있는지, 소프트웨어와 하드웨어 등 정보를 파악함

1단계 조직 및 운영 단위 (시스템 구성, 기능 파악 -> 시스템 인터페이스 현황 파악)

시스템 아키텍처

시스템 내 상위/하위 시스템의 동작 원리와 구성을 표현

단위 업무 시스템별로 아키텍처가 다른 경우 핵심 기간 업무 처리 시스템을 기준으로 함

시스템의 전체 구조, 행위, 행위 원리와 시스템의 작동 원리를 설명하는 틀

목적 달성을 위해 시스템의 각 컴포넌트를 식별, 상호작용을 통해 어떻게 정보가 교환되는지 설명

 

시스템 구성 파악

조직 내 주요 업무를 기간 업무/지원 업무로 구분해 기술 (문서화, CASE)

 

시스템 기능 파악 

단위 업무 시스템이 현재 제공하는 기능을 주요 기능/하부 기능으로 구분해 계층형으로 표시

 

인터페이스 현황 파악

현행 시스템의 단위 업무 시스템이 타 단위 업무 시스템과 주고받는 데이터의 연계 유형 등을 명시

 

EAI(Enterprise Application Integration - 기업 애플리케이션  통합)

기업 내 애플리케이션들을 현대화, 통합, 조정하는 것을 목표로 하는 것

 

FEP(Front-End Processor - 전위 처리기)

입력 데이터를 프로세서가 처리하기 전 미리 처리해 프로세서가 처리하는 시간을 줄여주는 프로그램/하드웨어

여러 통신 라인을 중앙 PC에 연결, 터미널의 메세지가 보낼 상태로 있는지 받을 상태로 있는지 검색 및 통신 라인의 에러 검출

2단계 아키텍쳐 단위 (아키텍쳐 파악)

소프트웨어 구성 파악

시스템 내 단위 업무 시스템의 소프트웨어, 라이선스 등을 명시

라이선스 적용 방식과 보유한 라이선스 수량 파악이 중요 (예산 비중)

라이선스 적용 방식 단위: 사이트, 서버, 프로세서, 코어, 사용자 수

3단계 하드웨어 단위 (하드웨어 및 네트워크 파악)

하드웨어 구성 파악

각 단위 업무 시스템의 서버 위치 및 주요 사양, 수량, 이중화 여부 파악 (OS, DBMS, Middle Ware 등)

서버 사양: CPU 처리 속도, 메모리 크기, 하드 디스크 용량 

네트워크 구성 파악 및 개발 기술 환경 분석도 필요함

플랫폼

기반 시설

응용 소프트웨어 + (하드웨어 + 시스템 소프트웨어)

다양한 애플리케이션이 작동되는 기본 운영 체제 소프트웨어를 의미

JAVA 플랫폼, .NET 플랫폼, IOS, Android 등

 

플랫폼 성능 분석 항목

1. 응답 시간

2. 가용성

3. 사용률

 

플랫폼 성능 분석 방법

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

사용자 인터뷰

문서 점검

 

현행 시스템의 OS 분석

OS 종류와 버전, 패치 일자, 백업 주기 분석

고려사항: 가용성, 성능, 기술 지원, 주변기기, 구축 비용(TCO, Total Cost of Ownership: 일정 기간 자산 획득에 필요한 직간접적 총 비용)

메모리 누수(실행 소프트웨어가 정상 종료되지 않고 남아 있는 증상)

 

오픈소스 라이선스 종류

대표적인 오픈소스 라이선스: Linux

GNU: 컴퓨터 프로그램은 물론 모든 관련 정보를 구매하는 것을 반대하는 게 기본 이념

GNU GPLv1: 비공개 소스코드면서 바이너리만 배포하는 것을 금지. 사용할 수 있는 쉬운 코드를 같이 배포

BSD: 아무나 개작 가능, 수정한 것을 제한 없이 배포 가능. (수정본의 재배포는 의무적이지 않음)

Apache 2.0: 아파치 재단 소유의 SW 적용을 위해 제공하는 라이선스. 소스 코드 수정 배포 시 아파치 2.0을 포함해야 함

(Hadoop: 다수의 저렴한 컴퓨터를 하나처럼 묶어 대량 데이터를 처리하는 기술)

 

현행 시스템 DBMS 분석(DataBase Management System)

종속성과 중복성의 문제를 해결하기 위해 제안된 시스템

응용 프로그램과 데이터의 중재자. 모든 응용 프로그램이 데이터베이스를 공유할 수 있도록 관리함

종류: Oracle, IBM DB2, MySQL, SQ Lite, MongoDB, Redis

 

DBSM 분석 시 고려사항

가용성, 성능, 기술 지원, 상호 호환성, 구축 비용

---

6. 요구사항 개발

요구공학

SW 개발 시 유저의 니즈가 정확히 반영된 시스템 개발을 위해 니즈를 추출, 분석, 명세, 검증 및 관리하는 활동

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

자료 흐름도, 자료 사전 등이 사용될 수 있고, 소단위 명세서가 활용될 수 있음

이를 통해 요구사항 누락 방지, 상호 이해 오류 등을 제거해 경제성을 제공, 개발 비용 및 시간 절약

 

요구사항 베이스라인(BaseLine, 기준선)

이해 당사자 간 명시적 합의 내용, 프로젝트 목표 달성 여부를 확인하는 기준

 

요구공학 프로세스

정리된 명세서를 마지막으로 확인, 검증하는 일련의 단계

경제성, 기술성, 적법성, 대안성 등 타당성 조사가 선행되어야 함

 

SWEBOK(Software Engineering Body of Knowledge, 소프트웨어 공학 지식 체계)에 따른 요구사항 개발 프로세스

요구사항 도출 -> 분석 -> 요구사항 명세 -> 요구사항 검증 및 확인

 

요구사항 도출

- 해결해야 할 문제 이해 및 정의, 이해관계자가 식별됨

- 요구사항 도출 기법: 고객의 발표, 문서 조사, 설문, 업무 절차 및 양식 조사, 브레인스토밍, Use Case, BPR, RFP 등

 

요구사항 분석

- 요구사항 정의를 문서화하는 과정

- 요구분석을 위한 기법: 유저 의견 청취, 인터뷰, 설문조사 등

 

요구사항 분석 수행

- 문제 인식 -> 전개 -> 평가와 종합 -> 검토 -> 문서화

 

요구사항 분류

기술 내용에 따른 분류(기능 요구사항/비기능 요구사항), 기술 관점 및 대상에 따른 분류

 

요구사항 분류 기준

- 기능 요구사항/비기능 요구사항을 구분, 우선순위 여부 확인

- 요구사항이 하나 이상의 고수준 요구사항으로부터 유도된 것인지 확인

- 이해관계자나 다른 원천으로부터 직접 발생한 것인지 확인

- 소프트웨어 생명주기 동안에 변경이 있는 것인지 확인

 

기능적 요구사항: 시스템이 실제로 어떻게 동작하는지에 관점을 둔 요구사항

비기능적 요구사항: 시스템 구축에 대한 성능, 보안, 품질 등으로 실제 수행에 보조적인 요구사항

 

요구사항 명세

시스템 정의, 시스템 요구사항, SW 요구사항 작성 등등

 

요구사항 명세 속성

정확성, 명확성, 완전성, 일관성, 수정 용이성, 추적성

 

요구사항 확인

- 명세를 확인하고 검증하는 단계

- 요구사항 관리 도구의 필요성: 요구사항 변경으로 인한 비용 편익 분성, 변경의 추적 등

 

1. 형상 관리(개발 단계에서 도출되는 모든 자료의 변경을 관리, 버전 관리 등을 함)

2. 요구사항 할당(아키텍처 구성 요소를 식별, 추가 요구사항을 발견)

3. 정형 분석(구문과 시멘틱을 지닌 언어로 요구사항을 표현, 요구사항 분석의 마지막 단계에서 이뤄짐)

 

요구사항 분석 도구

- 프로토타이핑: 시제품을 제작, 개발 중 요구사항을 지속적으로 재작성함 (자원 낭비 방지)

- 모델 검증: 분석 단계에서 개발된 모델의 품질 검증 (정적 분석: 명세 분석 / 동적 분석: 직접 실행)

- 요구사항 검토

- 인수 테스트(계약 인수 테스트, 규정 인수 테스트, 알파 검사, 베타검사, 사용자 인수 테스트, 운영 인수 테스트)

---

7. UML

1) 개념 모델링

요구사항을 이해하기 쉽도록 단순화, 개념적으로 표현한 모델로 이를 만들어나가는 과정을 개념 모델링이라고 함

모델은 문제가 발생하는 상황에 대한 이해를 증진, 해결책을 설명하므로 SW 요구사항 분석의 핵심임

개발 대상 도메인의 엔티티와 그들의 관계 및 종속성을 반영함

요구사항별로 관점이 다르므로 개념 모델도 다양하게 표현됨

UML(Unified Modeling Language)를 사용함

종류: Use Case Diagram, Data Flow Model, Sate Model, Goal-Based Model 등

2) UML

객체지향 SW 개발 과정에서 사용하는 모델링 기술과 방법론을 통합한 범용 모델링 언어

OMT, Booch, OOSE 방법론을 통합해 만든 공통 집합으로 표준 지정을 목표로 제안된 모델링 언어

 

럼바우 객체지향 분석 기법

SW 구성 요소를 그래픽으로 모형화함. 객체 모델링 기법이라고도 함

객체 모델링: 정보 모델링. 객체 간의 관계를 규정해(정적) 객체를 다이어그램으로 표시

동적 모델링: 제어 흐름, 상호작용 등 상태를 시간 흐름에 따라 상태 다이어그램을 표시

기능 모델링: 여러 프로세스 간의 자료 흐름을 표시. 어떤 데이터로 어떤 결과를 가져올지 표현.

 

UML 특성

비주얼화: SW 구성 요소 간의 관계 및 상호작용을 시각화

문서화

명세화

구축

 

기능적 관점: 사용자 측면에서 본 SW 기능을 나타내며 사용 사례 모델링이라고 함.

(요구분석 단계서 사용. UML에서는 Use Case Diagram 사용)

 

정적 관점: SW 내부의 구성 요소 사이의 구조적 관게를 나타냄.

(객체, 속성 등 시스템 구조를 나타내며 UML에서는 Class Diagram을 사용)

 

동적 관점: 시스템의 내부 동작

(UML에서는 Sequence Diagram, State Diagram, Activity Diagram 사용)

 

 

스테레오 타입

UML에서 제공하는 기본 요소 외에 추가적인 확장 요소를 표현할 때 사용

UML 확장 모델에서 스테레오 타입 객체를 표현할 때 <<>> (길러멧) 안에 확장 요소를 적음

 

UML 접근 제어자

Public(+): 어떤 클래스의 객체에서든 접근 가능

Private(-): 해당 클래스로 생성된 객체만 접근 가능

Protected(#): 해당 클래스와 동일 패키지에 있거나 상속 관계의 하위 클래스 객체들만 접근 가능

Package(~): 동일 패키지에 있는 클래스의 객체들만 접근 가능

 

 

3) UML 다이어그램의 분류

1. 구조적 다이어그램 (정적, 구조 표현을 위함)

클래스 다이어그램: 시스탬 내 클래스의 정적 구조 표현, 관계 표현

객체 다이어그램: 객체 정보 보여줌

복합체 구조 다이어그램: 복합 구조의 클래스와 컴포넌트의 내부 구조 표현

배치 다이어그램: 실행 시스탬의 물리 구조 표현

컴포넌트 다이어그램: 컴포넌트 구조 사이의 관계 표현

패키지 다이어그램: 여러 모델 요소들을 그룹화, 패키지를 구성해 패키지의 관계 표현

 

2. 행위 다이어그램 (동적, 순차적인 표현을 위함)

유스케이스 다이어그램: 사용자 관점

활동 다이어그램: 업무 처리 과정, 연산이 수행되는 과정

상태 머신 다이어그램: 객체의 생명주기 표현

콜라보레이션 다이어그램: 시퀀스 다이어그램과 같음. 모델링 공간에 제약이 없어 구조적인 면 중시

상호작용 다이어그램

- 순차 다이어그램(시간에 따른 메세지 발생 순서 강조. 요소: 생명선, 통로, 상호작용, 발생, 실행, 메세지 등...)

- 상호작용 개요 다이어그램

- 통신 다이어그램

- 타이밍 다이어그램

 

4) 클래스 다이어그램 관계 표현

 

집합 관계: A 객체가 B 객체에 포함된 관계로 부분을 나타내는 객체를 다른 객체와 공유할 수 있음

전체 클래스 방향에 빈 마름모 표시, or 관계에 놓이면 선 사이를 점선으로 잇고 {or}로 표시

부분 객체는 다른 객체와 공유 불가

 

UML 연관 관계

- 한 사물의 객체가 다룬 사물의 객체와 연결된 것을 표현

- 두 클래스가 서로 연관있다면 A, B 객체를 서로 참조할 수 있음을 표현

- 이름: 관계의 의미를 표현

- 역할: 수행하는 역할

 

 

Use Case Diagram의 요소

시스템 경계

액터

유스 케이스

접속 관계

사용 관계

확장 관계

 

Use Case Diagram의 작성 단계

1. 액터 식별

2. Use Case 식별

3. 관계 정의

4. Use Case 구조화

---

8. 소프트웨어 아키텍쳐

1) 소프트웨어 아키텍처

ISO/IEC 9126 모델

- SW 품질 특성과 평가를 위한 국제 표준

내외부 품질: 기능성, 신뢰성, 사용성, 효율성, 유지보수성, 이식성

사용 품질: 효과성, 생산성, 안전성, 만족도

외부지표: 실행 가능한 SW, 시스템을 시험/운영/관찰

내부지표: 설계, 코딩 도중 실행할 수 없는 SW 제품에 대해 적용

 

 

ISO/IEC 25010

- 개정되어 특성 기준이 8개로 증가함

2) UI 표준을 위한 환경 분석

1. 사용자 경향 분석

2. 기능 및 설계 분석(사용자 편의를 위한 조작에 관한 분석 확인. 스크롤바나 마우스 조작 등)

- 기능 조작성 분석, 오류방지 분석, 최소한의 조작으로 업무 처리 가능한 형태 분석, UI 정보 전달력 확인

 

요구사항의 요소

데이터 요구, 기능 요구, 제품/서비스 품질, 제약사항

 

정황 시나리오

개발하는 서비스의 초기 모양을 상상하는 단계

가장 기초적인 시나리오로 간단명료, 정확, 육하원칙에 의거

---

9. UI 표준 및 지침

1) UI

UI 분야

- 표현에 관한 분야, 정보 제공과 전달 분야, 기능 분야

 

UI 특징

- 실 사용자의 만족도에 직접 영향을 주며 적절한 UI 구성으로 여러 장점이 있다.

 

UI 개발 시스템이 가져야 할 기능

- 유저 입력의 검증, 에러 처리와 에러 메세지 처리, 도움과 프롬프트(입력창) 제공

2) UI 설계 원칙

UI 설계 원칙

- 직관성, 유효성, 학습성, 유연성

 

UI 설계 지침

- 사용자 중심

- 일관성

- 단순성

- 가시성

- 표준화

- 접근성

- 결과 예측 가능

- 명확성

- 오류 발생 해결

3) UI 표준

한국형 웹 콘텐츠 접근성 지침 2.1 4가지 원칙

- 인식의 용이성

- 운용의 용이성

- 이해의 용이성

- 견고성

4) UX

유저가 제품을 사용하며 겪는 경험

(기본적인 상식으로 생각해보면 됨)

---

10. UI 설계

1) UI 설계 단계

1. 문제 정의

2. 사용자 모델 정의

3. 작업 분석

4. 컴퓨터 오브젝트 및 기능 정의

5. UI 정의

6. 디자인 평가(평가 방법론: GOMS, Heuristics - 짐작을 통함)

 

UI 상세 설계 단계

1. UI 메뉴 구조 설계

2. 내/외부 화면과 폼 설계

3. UI 검토 수행

 

시나리오 작성 원칙

트리 구조나 플로우차트 표기법을 이용

공통 UI 요소와 상호작용을 일반적인 규칙으로 정의

작성 요건: 완전성, 일관성, 이해성, 가독성, 수정 용이성, 추적 용이성

2) UI 설계 도구

와이어 프레임(핸드라이팅, PPT, 키노트, 카카오 오븐 등등)

목업(카카오 오븐, 발사믹 목업, 파워 목업)

프로토타입

스토리보드

3) UI 프로토타입

UI 설계 도구 중 도출된 요구사항을 토대로 와이어 프레임, 스토리보드에 상호작용을 적용한 것

프로토타입의 장단점

4) 감성 공학

1류, 2류, 3류...

HCI(Human Computer Interaction or Interface): 인간과 컴퓨터의 상호작용 연구

기초 기술, 구현 기술, 응용 기술로 응용됨

---

출처: https://www.youtube.com/watch?v=JhKOsZuMDWs&list=PL6i7rGeEmTvqEjTJF3PJR4a1N9KTPpfw0