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

[SW]
특징
-상품성, 복잡성, 변경 가능성, 복제성

시스템의 기본요소
-입력, 처리, 출력, 제어, 피드백

소프트웨어 위기의 원인
-HW 비용을 초과하는 개발 비용의 증가
-개발 기간의 지연
-개발 인력 부족 및 인건비 상승
-성능 및 신뢰성 부족
-유지보수의 어려움에 따른 엄청난 비용

[SW 공학]
기본 원칙
-현대적인 프로그래밍 기술을 적용
-신뢰성이 높아야함.(정확해야 함.)
-사용의 편리성과 유지보수성 높아야 함.
-지속적인 검증 시행.


[재공학]
: 소프트웨어 위기를 개발의 생산성이 아닌 유지보수의 생산성으로 해결하려는 방법
; 유지보수성 향상이 최우선 목표
-분석analysis>구성restructing>역공학reverse engineering>이식migration

[역공학]
: 소프트웨어를 분석하여 개발 과정과 데이터 처리 과정을 설명하는 분석 및 설계 정보를 재발견하거나 다시 만들어냄.
; 재문서화

[CASE]
: 소프트웨어개발 과정에서사용되는 도구를 사용하여 자동화하는 작업

제공 기능
-개발을 신속하게. 오류 수정이 쉬움.->소프트웨어 품질 향상
-소프트웨어 생명주기의 전체 단계 연결
-소프트웨어 시스템의 문서화 및 명세화를 위한 그래픽 기능을 제공
-개발 단계의 표준화를 기할 수 있음. 자료 흐름도 작성 기능 제공.
-모델들 사이의 모순 검사 기능 제공.

원천 기술
-구조적 기법, 프로토타이핑 기술, 정보 저장소 기술

장점
-기간 단축, 비용 절약->생산성 향상
-자동화된 검사->품질 향상

분류
(상위 CASE): 요구분석 및 설계 단계 지원
(하위 CASE): 소스 코드 작성, 테스트, 문서화 과정 지원
(통합 CASE): 소프트웨어 개발 주기 전체 과정 지원

*SADT: softtech사에서 개발한 시스템 정의, 소프트웨어 요구사항 분석, 시스템/소프트웨어 설계를 위해 널리 이용되어 온 구조적 분석 및 설계도구. 블록 다이어그램을 채택.


[소프트웨어 설계 방법론]
소프트웨어 생명주기
-타당성 검토 > 개발 계획> 요구사항 분석> 설계 > 구현> 테스트> 운용> 유지보수

폭포수 모형: 선형 순차적 모델
나선형 모형: 반복적인 작업을 수행하는 점증적 생명주기 모형./계획 수립, “위험 분석”, 개발, 고객평가, *반복(과정에서 프로토타임(시제품) 개발)

하향식 설계
: 제일 상위에 있는 main user function에서 시작하여 기능을 하위 기능들로 나눠가면서.
상향식 설계
: 가장 기본적인 컴포넌트를 먼저 설계한 다음 이걱을 사용하는 상위 수준의 컴포넌트를 설계

프로토타입 모형
; 실제 개발될 시스템의 견본을 미리 만들어 최종 결과물을 예측.

HIPO
: 계층적 입력, 처리, 출력으로 구성되는 시스템 분석 및 설계와 시스템 문서화용 기법(하향식)
-가시적 도표, 총체적 다이어그램, 세부적 다이어그램

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

[애자일 개발 방법론]
; 날렵한, 재빠른
-절차와 도구보다 개인과 소통을 중요시하고 고객과의 피드백을 중요하게
-XP, SCRUM, 린, DSDM, FDD(기능 중심 개발)

[XP]
핵심 가치
-소통, 단순성, 피드백, 용기, 존중
-user story, release planning, iteration, acceptance test(적응 테스트), small release

12가지 실천사항
1. Pair Programming(짝 프로그래밍): 한사람 코딩, 한사람 검사
2. Planning Game: 선수와 규칙, 목표를 두고 기획에 임함.
3. Test Driven Development: 코딩 전 단위 테스트부터 작성 및 수행.
4. Whole Team: 개발 효율을 위해 고객을 프로젝트 팀원으로 상주시킴.

5. Continuous Integration: 상시 빌드 및 배포 가능한 상태 유지
6. Design Improvement: 기능 변경 없이 중복성/복잡성 제거, 커뮤니케이션 향상, 단순화, 유연성 등을 위한 재구성 수행
7. Small Releases: 짧은 주기로 잦은 릴리즈. 고객이 변경사항 볼 수 있도록.

8. Coding Standards: 소스 코드 작성 포맷과 규칙들을 표준화된 관례에 따라 작성.
9. Collective Code Ownership: 시스템에 있는 소스 코드는 팀원 누구든지 언제라도 수정 가능.
10. Simple Design: 가능한 가장 간결한 디자인
11. System Metaphor: 최종적으로 개발되어야 할 시스템의 구조를 기술

12. Sustainable Pace: 일주일에 40시간 이상 작업 금지. 2주 연속 오버타임 금지.

효과적인 프로젝트 관리를 위한 3대 요소
-3P: People(인적 자원), Problem(문제 인식), Process(작업 계획)


[SCRUM]
팀의 역할
#제품 책임자
-개발 목표에 이해도가 높은 개발 의뢰자, 사용자가 담당
-제품 테스트 수행 및 요구사항 우선순위를 갱신
-업무 관점에서 우선순위와 중요도를 표시하고 신규 항목을 추가
-스프린트 계획 수립까지만 임무를 수행.
#스크럼 마스터
-업무를 배분만 하고 일은 강요하지 않음. 개발 과정 장애 요소를 찾아 제거.
#스크럼 팀
-제품책임자, 스크럼 마스터, 개발자, 디자이너 총 5~9명 내외로 구성
-일정, 속도를 추정한 뒤 제품 책임자에게 전달
-스프린트 결과물을 제품 책임자에게 시연

과정
소멸 차트: 한 일을 소거해 나감.
sprint: 2~4주간 daily scrum meeting을 진행하면서 개발 진행.

scrum의 작업 흐름도에서 제품 개발에 필요한 모든 요구사항을 우선순위에 따라 나열한 목록=>product back log


[현행 시스템 분석]
현행 시스템 파악 절차
1. 시스템(부서) 구성 파악 - 시스템 기능 파악 - 시스템 인터페이스 현황 파악
2. 아키텍처 파악 - 소프트웨어 구성 파악
3. 시스템 하드웨어 현황 파악 - 네트워크 구성 파악

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

[시스템 및 인터페이스 현황 파악]
!! 문서화
시스템 구성 파악-기간 업무, 지원 업무 부서들 정리
시스템 기능 파악-a단위 업무 시스템-기능1, 기능 1-1, 기능 1-1-1 등.
인터페이스 현황 파악- 타 단위 업무 시스템과 서로 주고받는 데이터의 연계 유형(송신 시스템, 수신 시스템, 연동 데이터, 연동 형식, 통신 규약, 연계 유형, 주기)

EAI(기업 어플리케이션 통합) Enterprise Application Integration
-기업 내의 컴퓨터 어플을 현대화하고 통합, 조정.
FEP(전위 처리기) Front-End Processor
-입력 데이터를 프로세서가 처리하기 전에 미리 처리하여 프로세서가 처리하는 시간을 줄여주느 프로그램이나 하드웨어

[소프트웨어, 하드웨어, 네트워크 현황 파악]
소프트웨어 구성 파악-품명, 용도, 라이선스 적용 방식, 수
하드웨어 구성 파악-서버 이중화
네트워크 구성 파악- 서버의 위치, 서버간 연결 방식

개발 기술 환경 분석-개발 대상 시스템의 플랫폼, OS, DBMS, MIddle Ware등을 분석.

[플랫폼]
; 응용 소프트웨어 + (하드웨어 + 시스템 소프트웨어)
: 다양한 애플리케이션이 작동하는 기본이 되는 운영체제 소프트웨어.
-java, net, ios, android, windows 등

특성 분석
-응답 시간, 기용성, 사용률
특성 분석 방법
-기능 테스트, 사용자 인터뷰, 문서 점검

[현행 시스템의 OS 분석]
분석 항복
-OS 종류와 버전, 패치 일자, 백업 주기 분석
고려사항
-가용성, 성능, 기술 지원, 주변기기, 구축비용(TCO; Total Cost of Ownership)
메모리 누수
-실행 SW가 정상 종료되지 않고 남아있는 증상

#오픈소스 라이언스 종류
-GNU(GNU’s Not Unix); Linux
*GNU GPLv1(General Public License): 소스 코드 없이 바이너리만 배포하는 것을 금지.
*BSD(Berkeley Software Distribution): 아무나 개작, 수정한 것을 제한 없이 배포. 수정본의 재배포는 의무적인 사항이 아님. 공개하지 않아도 되는 상용 SW에서도 사용가능.
-Apache 2.0: 아파치 재단 소유의 SW 적용을 위해 제공하는 라이선스. ; Android, HADOOP(빅데이터 처리 기술)

[현행 시스템 DBMS 분석]
; DBMS 종류, 버전, 구성 방식, 저장 용량, 백업 주기, 벤더의 유지보수 여부 가능성을 분석.
테이블 수량, 데이터 증가 추이, 백업 방식 등을 분석,

고려사항
-가용성, 성능, 기술 지원, 상호 호환성, 구축 비용


[요구사항 개발]
[요구공학]
; 자료 흐름도, 자료 사전 등이 효과적으로 이용될 수 있으며, 더 구체적인 명세를 위해 소단위 명세서가 활용될 수 있다.

목적
-요구사항 누락 방지, 상호 이해 오류 등의 제거->경제성을 제공
-요구사항 변경 이력 관리를 통해 개발 비용 및 시간 절약
-비용과 일정에 대한 제약 설정과 타당성 조사, 요구사항 정의 문서화

요구사항 베이스라인(기준선)
-이해 당사자 간의 명시적 합의 내용

프로세스
-개발 대상에 대한 요구사항을 체계적으로 도출>분석 결과를 명세서에 정리>정리된 명세서를 마지막으로 확인, 검증.
-경제성, 기술성, 적법성, 대안성 등 타당성 조사(Feasibility Study)가 선행되어야 함.

SWEBOK에 따른 요구사항 개발 프로세스
-요구사항 추출(도출), 분석, 명세, 검증

요구사항 도출 기법
-고객의 발표, 문서 조사, 설문, 업무 절차 및 양식 조사, 브레인스토밍, 워크숍, 인터뷰, 관찰 및 모델의 프로토타이핑, use case, 벤치마킹, BPR(업무 재설계), RFP(제안 요청서)

요구사항 분석 기법
- 사용자 의견 청취, 사용자 인터뷰, 현재 사용중인 각종 문서 분석과 중재, 관찰 및 모델 작성 기술, 설문조사를 통한 의견 수렴
수행 단계
- 문제 인식 > 전개 > 평가와 종합 > 검토 > 문서화

요구사항 분류
; 기술 내용에 따른 분류-기능 요구사항, 비기능 요구사항
; 기술 관점 및 대상에 따른 분류-시스템 요구사항, 사용자 요구사항

요구사항 분류 기준
-기능/비기능 구분 후 우선순위 여부 확인.
-하나 이상의 고수준 요구사항으로부터 유도된 것인지 확인.
-이해관계자나 다른 원천으로부터 직접 발생한 것인지 확인.
-제품에 관한 것인지/프로세스에 관한 것인지 확인 후 소프트웨어에 미치는 영향의 범위를 확인.
-요구사항이 소프트웨어 생명주기 동안에 변경이 있는지 확인.

정형 명세
; 수학적 기반, 모델링 기반…낮은 이해도
비정형 명세
; 자연어 기반 …모호성
>State Chart(SADT), UseCase, 사용자 기반 모델링

요구사항 명세 속성
-정확성, 명확성, 완전성, 일관성, 수정 용이성, 추적성

요구사항 관리 도구의 필요성
-요구사항 변경으로 인한 비용 편익 분석, 요구사항 변경의 추적, 요구사항 변경에 따른 영향 평가

형상 관리
: 개발 단계에서 도출되는 프로그램, 문서, 데이터 등의 모든 자료를 형상 단위라고 함. 이러한 자료의 변경을 관리함으로써 버전 관리 등을 하는 활동.

요구사항 할당
: 아키텍처 구성 요소를 식별하는 활동.

정형 분석
: 구문과 형식적으로 정의된 의미를 지닌 언어로 요구사항을 표현

[요구사항 확인 기법]
-프로토타이핑, 모델 검증, 요구사항 검토, 인수 테스트

[프로토타이핑]
;지속해서 재작성 함.
-새로운 요구사항을 도출하기 위한 수단.

절차
-요구사항 분석 > 프로토타입 설계 > 개발 > 고객의 평가 > 정제 > 완제품 생산

[모델 검증]
: 분석 단계에서 개발된 모델의 품질 검증
-정적 분석: 객체들 사이에 존재하는 Communication Path를 검증하기 위해 사용. 명세의 일관성과 정확성을 확인 분석
-동적 분석: 직접 실행을 통해 모델 검증

[인수 테스트]
: 요구사항을 만족하는지 확인. 고객에게 전달.
-계약 인수 테스트, 규정 인수 테스트, 알파 검사, 베타검사, 사용자 인수 테스트, 운영 인수 테스트