해당 post는 개인 공부 목적으로 작성되어, 다시 봐야할 부분만 간단히 정리해놓은 post입니다.
1. 요구사항 확인
1) 현행 시스템 분석
* 분석 순서
고객 요구 -> 요구사항 분석 -> 설계 -> 구현 -> 테스팅 -> 제품
* 현행 시스템에서 파악해야 하는 것
플랫폼 기능 분석
플랫폼 성능 특성 분석
운영체제 분석
네트워크 분석
DBMS 분석
비즈니스 융합 분석
(인적 자원 분석은 들어가지 않는다.)
* 미들웨어 솔루션 유형 6가지
1) DB : 원격 DB와 연결
2) WAS 웹 : Web ~ ; 웹 환경을 구현
3) MOM 메시지 비동기 : Message ~ ; 메시지 기반의 비동기형 메시지를 전달
4) RPC : 원격 프로시저를 로컬 프로시저처럼 호출
5) ORB 객체지향 : Object ~ ; 객체 지향 미들웨어
6) TP-Monitoir 트랜잭션 감시 : Transaction ~ ; 온라인 트랜잭션 업무에서 트랜잭션을 처리 및 감시
2) 요구사항 확인
* 소프트웨어 개발 생명주기 모델
1) 폭포수 모델 : 대기 후 끝나면 다음 단계 , 수정이 어렵다 역순 불가능
2) 원형 모델 : Prototype(원형) 을 가능한 빨리 개발 후 , 고객과 검증, 개발시간 ↑
3) 나선형 모델 : 위험을 최소화! Risk 분석 중요. 고비용의 시스템 개발이나 큰 시스템 구축 시 효과적이다
*소프트웨어 개발 방법론
소프트웨어 개발 과정들을 정리하고 표준화, 일관성을 유지 하고 효과적인 협업이 이루어질 수 있도록!
1) 구조적 개발 방법론 : 기능중심
2) 정보 공학 방법론 : 자료구조 중심
3) 객체 지향 개발 방법론 : 객체 중심
4) CRB 방법론 : 컴포넌트 중심
* 구조적 분석 : 기능중심, 도형 중심의 분석용 도구 활용
: 자료 흐름도 -> 자료사전 -> 소단위 명세서
- 자료 흐름도 (Data Flow Diagram : DFD)
: process, data flow, data store, terminator 포함
- 자료 사전 (Data Dictionary : DD)
= 자료 항목 정리
+ 복합적인 자료 요소 구성
{} 반복
[] 선택
() 생략가능
** 주석
| or ; 나열(대체항목)
- 소단위 명세서 (Mini Specification) : 자료 흐름도에 나타난 모든 최소 단위의 처리에 대해 자료흐름이 변환되는 절차
* 애자일 (Agile) 개발 방법론
- 개인과의 상호작용
- 제대로 동작하는 소프트웨어의 개발에 집중
- 고객과의 협력 / 소통이 중요
- 문서 중요도 보다 실행력이 우선!
* 애자일 (Agile) 방법론의 유형
1) XP (eXtreme Programming) : "고객의 요구사항은 변경된다!" 개발팀과 고객간의 의사소통 중요!
; 용기, 단순성, 의사소통, 피드백 ,존중
2) 스크럼 (SCRUM) : 진행 체제 수립, 역할, 정의에 중점
; 활약, 전념, 정직, 존중, 용기
3) 린 (LEAN) : 전적으로 고객 관점
4) + Crystal, ASD, FDD
* 스크럼에서 사용하는 용어
1) Product Owner(PO) : 제품책임자, 백로그(요구사항 list)를 작성하는 주체
2) Scrum Master(SM) : 개발 x, PM 느낌, 전적으로 관리
3) 스프린트 : 짧은 기간 동안 동작하는 SW를 사용자에게 제공하며, 피드백을 받고 수정
* 객체지향 방법론
Module화! -> 재사용!
표기법이라도 통일 하자 => UML 다이어그램
SOLID 원칙.
관련 개념 : 객체, 클래스 ,캡슐화, 데이터 은닉, 상속, 조합, 다형성의 개념
* SOLID 객체지향 설계
1) SRP ; 단일 책임 원칙 : 한 클래스는 하나의 책임만 가져야 한다.
2) OCP ; 개방-폐쇄 원칙 : 소프트웨어 요소는 확장에는 열려있으나, 폐쇄에는 닫혀 있어야 한다.
3) LSP ; 리스코프 치환 원칙 : 객체는 프로그램의 정확성을 깨뜨리지 않으면서, 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
4) ISP ; 인터페이스 분리 원칙 : 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나 보다 낫다.
5) DIP ; 의존관계 역전 원칙 : 추상화에 의존! 구체화에는 의존하지 말라. (의존성 주입!)
* 객체지향 분석 기법
1) 럼바우(Rumbaugh)의 OMT : 객체 모델링(객체다이어그램) - 동적 모델링(상태다이어그램) - 기능 모델링(자료흐름도)
2) Booch 방법론 : DFD 사용, 클래스다이어그램, 객체다이어그램, 모듈다이어그램, 프로세스다이어그램
3) Coad/Yaurdon 방법론 : ERD (Entity-Relationship Diagram)
3) 분석 모델 확인
* 요구사항 개발 프로세스 순서
도출 -> 분석 -> 명세 -> 확인
* 요구사항 분류
기능 : 기능적인 부분
비기능 : 성능, 신뢰성, 보안, 사용성 등 (동사 앞에 부사로 제한이 되어 있으면 비기능)
* 정형 분석
비정형 명세기법 : 자연어
정형 명세기법 : 수학적 원리와 표기법, Z 정형 명세 언어
* 소프트웨어 개발 방법 중 요구사항 분석과 거리가 먼 것은?
: 비용과 일정에 대한 제약 설정, 타당성 조사, 요구사항 정의 문서화, 설계 명세서 작성
- 비용과 일정 제약도 설정해야 하며, 설계 명세서 작성은 다음 단계이다.
* UML (Unified Modeling language)의 구성요소
사물, 관계, 다이어그램
* UML에서 활용되는 다이어그램
* 유스케이스 다이어그램 - 관계
연관관계, 의존관계, 일반화관계
* (CASE)의 필요성
요구사항 변경으로 인한 비용 편인 분석 ; "비용도 분석!!"
요구사항 변경의 추적
요구사항 변경에 따른 영향 평가
개발 과정의 일부 또는 전체 자동화하기 위한 도구 (code 생성기 능력도 있다!)
- 기존 시스템과 신규 시스템의 성능 비교은 포함되지 않는다. (시스템 nono)
+ 틀린 문제
유스케이스(Use Case)의 구성 요소 간의 관계에 포함되지 않는 것은?
- 연관관계(Association) : 유스케이스와 액터간의 상호작용이 있음을 표현한다.
- 포함 관계(Include): 하나의 유스케이스가 다른 유스케이스의 실행을 전제로 할 때 형성되는 관계이다. => 구체화
- 확장 관계(Extend): 확장 기능 유스케이스와 확장 대상 유스케이스 사이에 형성 되는 관계이다.
2. 화면 설계
1) UI 요구사항 확인
* 8가지 일반적인 소프트웨어 아키텍쳐 패턴
1) 계층화 패턴 레이어드 패턴
2) 클라이언트 - 서버 패턴
3) 마스터-슬레이브 패턴
4) 파이트-필터 패턴 : 서브시스템이 입력데이터를 받아 처리하고, 결과를 다음 서브시스템으로 넘겨주는 과정을 반복
5) 브로커 패턴
6) 피어 투 피어 패턴
7) 이벤트-버스 패턴
8) 모델-뷰-컨트롤러 패턴 : Controller가 모델 - 뷰 사이에서 전달자 역할
* 아키텍쳐 설계과정 순서
설계 목표 설정
-> 시스템 타입 결정
-> 스타일 적용 및 커스터마이즈
-> 서브시스템의 기능, 인터페이스 동작 작성
-> 아키텍쳐 설계 검토
* SW 아키텍쳐 시스템 품질 속성
가용성, 변경용이성, 성능, 보안성, 시험용이성, 사용편의성
* UI 의 종류
CLI, GUI, NUI (오감으로 반응)
* UI 설계 원칙
직관성, 유효성, 학습성, 유연성
