1단계(구성/기능/인터페이스 파악)
2단계(소프트웨어/아키텍처 구성 파악)
3단계(하드웨어/네트워크 구성 파악)
목적을 달성하기 위하여 구성요소들이 상호유기적으로 구성된 집합체
입력, 처리, 출력, 피드백, 제어
개발 단계에서 점차 변화하면서 나오는 소프트웨어 형상(Configuration)을 가시화.
소프트웨어 형상 : 개발과정에서 생산되는 산출물인 문서.
계획 : 타당성 분석, 예측, 팀구성 (실행정의서, 프로젝트계획서)
분석 : 사용자 요구사항 분석. 기능요구, 비기능요구(요구명세서)
설계 : 기본설계 상세설계(설계사양서)
구현 : 프로그래밍
시험 : 요구목록, 수정목록
운용 및 유지보수
분석 - 신속한 설계 - 프로토타입 작성 - 사용자 평가 - 프로토타입 정제 - 공학적 제품화
위험분석을 추가. 비교적 대규모시스템에 적합.
계획 - 위험분석 - 개발 - 사용자평가 의 반복.
폭포수 모형에 시스템 검증과 테스트 작업을 강조.
높은 신뢰성이 요구되는 분야에 적합
요구 분석 - 시스템 설계 - 상세 설계 - 코딩(꼭지점) - 단위테스트 - 통합테스트 - 시스템테스트 - 인수/설치
짧은 개발주기를 강조하는 점진적 소프트웨어 개발 방식.
재사용이 가능한 프로그램 컴포넌트의 개발을 강조
RAD 접근법
비즈니스 모델링 - 데이터모델링 - 프로세스모델링 - 애플리케이션 생성 - 시험 및 인도
애자일의 특성
프로세스 중심이 아닌 사람중심
전반적인 문서화보다는 제대로 작동하는 소프트웨어
계약협상보다는 고객과의 협력
계획을 따르기보다는 변화에 대응
중소형, 아키텍처설계, 프로토타이핑에 적합
애자일 종류
- XP(eXtreme Programming)
고객과 함께 2주 정도의 반복개발을 하고, 테스트와 우선 개발을 특징으로 함.- 스크럼
30일마다 동작가능한 제품을 제공하는 스프린트를 중심으로 함.- 크리스탈 패밀리
- 기능주도개발(FDD)
- ASD
XP의 5가지 핵심가치
- 존중(Respect)
- 단순성(Simplicity)
- 의사소통(Communication)
- 피드백(Feedback)
- 용기(Courage)
XP의 실천사항
- 소규모 릴리즈
- 테스트 기반 개발
- 리팩토링
- 짝프로그래밍
- 공동코드소유
- 고객상주
- 시험우선
하향식산정방법
- 전문가의 감정
경험과 지식을 갖춘 2명 이상의 전문가에게 의뢰하는 기법- 델파이식 산정
조정자를 통해 여러 전문가의 의견 일치를 얻어내는 기법- WBS(Work Break-down Structure, 업무 분류 구조) : 세분화
상향식산정방법
- LOC(Line Of Code, 원시코드 라인 수 기법)
WBS상에서 분해된 각각의 시스템 기능들에 필요한 원시 코드 라인수를 산정함에 있어 PERT의 예측공식을 사용
예측치 = (낙관치 + (4 x 기대치) + 비관치)/2- 개발단계별인월수기법(M/M)
각 기능을 구현시키는 데 필요한 노력을 생명주기 각 단계별로 산정.- PERT의 예측 공식 적용.
수학적산정방법
수학적산정방법
- COCOMO : 원시코드라인수에 의한 비용 예측 모형(보헴)
- COCOMO 계층.
- Basic(기본) COCOMO
- Intermediate(중간) COCOMO.
- Detailed(고급) COCOMO
- COCOMO의 프로젝트 모드
- 유기적모델(Organic Model) : 5만라인이하
- 준분리형모델(Semi-Detached Model) : 30만라인 이하
- 내장형모델(Embeded Model) : 30만라인 이상
- Putnam의 생명주기예측모형
- Rayleigh-Norden곡선에 기초
- FP모형
소프트웨어 각 기능에 대하여 가중치를 부여하여, 요인별 가중치를 합산해서 소프트웨어 규모,복잡도,난이도 산출하는 모형
내부논리파일(내부논리파일)
외부연계파일(외부인터페이스)
외부입력(사용자입력수)
외부출력(사용자출력수)
외부조회(사용자 질의)
요구분석기법
기능요구 : 사용자가 필요로하는 정보처리능력에 대한 것으로 절차나 입축력에 대한 요구이다.
비기능요구
성능, 신뢰도, 보안성, 개발계획, 개발비용, 환경
JAD : 개발자와 사용자가 만나서 요구사항 도출을 위한 공동 작업을 수행.
요구공학
요구사항을 정의하고 문서화하는데 필요한 제반 공정에 대한 체계적 접근방법.
요구공학 프로세스
요구사항 도출 - 분석 - 명세 - 검증 - 유지보수.
요구사항 명세 속성
정확성, 명확성, 완전성, 일관성, 수정용이성, 추적성.
구조적분석과 객체지향 분석(모델링 기법. 요구사항 가시화)
구조적분석
자료흐름도(DFD, Data Flow Diagram) 기능 중심.
시스템의 기능적 측면을 고려하여, 데이터가 시스템을 통해 이동하면서 어떻게 변형되는지를 표시.
단말(Terminal, 네모), 프로세스(Process, 원), 자료흐름(Data Flow), 자료저장소(Data Store)
자료사전(DD, Data Dictionary)
=(정의), +(연결), ()(생략), {}(반복), [](선택), **(주석)
프로세스명세서(Mini-Spec, 소단위명세서)
자료흐름도의 계층상에서 최하위단계, 즉 더이상 분해할 수 없는 단계의 버블.
종류 : 구조화 영어, 의사결정테이블, 의사결정도.
객체지향분석
데이터와 행위를 하나로 묶어 객체를 정의내리고, 추상화시키는 작업.
객체지향분석 도구 : UML
객체지향분석 기법 -
럼바우OMT기법
소프트웨어 구성 요소들을 그래픽 표기법을 이용하여 객체들을 모델링하는 기법
객체모델링(Object Modeling) : 객체(Object)다이어그램으로 표시. 객체식별 및 관계 규정
동적모델링(Dynamic Modeling) : 시스템이 시간 흐름에 따라 변화하는 것을 보여주는 상태(State)다이어그램을 작성
기능모델링(Function Modeling) : 시스템 내에서 데이터가 변하는 과정을 나타내며 자료흐름도(DFD)를 이용
Booch의 OOAD
여러가지 다른 방법론을 통합. 분석보다는 설계쪽에 더 많은 중점.
구현언어(Ada)에 제한됌
Coad/Yourdon 방법
E-R다이어그램을 사용하여 객체의 행위를 모델링
UML(Unified Modeling Language)
기본 구성 요소
사물(Things) : 다이어그램 안에서 관계가 형성될 수 있는 대상들
관계(Relationships) : 사물과 사물 사이의 연관성을 표현
다이어그램(Diagram) : 사물과 관계를 도형으로 표현.
UML다이어그램의 종류
구조 다이어그램 : Objec(Diagram), Class, Component, Composite, Package, Deployment
행위 다이어그램 : Use Case, Sequence, State, Activity, Timing, Communication
특성별 다이어그램
정적인측면 : Class Diagram
동적인측면 : Sequence Diagram, State Diagram
기능적 측면 : Use Case Diagram
Use Case Diagram
외부에서 보는 시스템의 동작으로, 외부 객체들이 어떻게 시스템과 상호작용하는지 모델링한 것.
유스케이스 다이어그램 구성 요소 : 액터, 시나리오, 유스케이스
액터파악 -> 시나리오작성 -> 유스케이스
유스케이스의 관계 : 통신관계, 포함관계, 확장관계, 일반화관계
Class Diagram
객체, 클래스, 속성, 오퍼레이션 및 연관관계를 이용하여 시스템을 나타냄.
오퍼레이션 : 클래스의 동작. 클래스에 속하는 객체에 대하여 적용될 메소드
클래스 표기
|클래스명
|속성
|연산(메소드)
클래스다이어그램 구성요소
클래스, 관계, 제약조건
클래스카이어그램 유형
일반화관계(Generalization) : 상속관계, 속이 빈 화살표
연관관계(Association) : 선
부분 전체 관계
집합관계(Aggregation) : 구성 요소가 없어도 전체 개념이 존재할 수 있다. 속이 빈 마름모
복합관계(Composition) : 부분은 한 순간에 하나의 전체에만 포함된다. 속이 찬 마름모
Sequence Diagram
객체 간의 메시지 통신을 분석
Collaboration Diagram
관련 객체와의 연관성 분석
State Diagram
객체 내의 동적 행위를 모형화하기 위한 것.
Activity Diagram
시스템의 흐름 전체를 파악.
Component Diagram
소프트웨어 컴포넌트 간의 구성 체계를 기술.
Package Diagram
모듈로 그룹화하는 도구로 사용가능
하나의 패키지는 여러 개의 서브 패키지나 클래스를 가질 수 있다. 이들은 나중에 하나의 모듈 혹은 컴포넌트가 된다.
논리 데이터 모델링
사용자들의 요구사항을 분석하여 DB에 저장될 정보를 파악하고, 필요한 정보들 간의 연관관계를 모형화하는 과정
데이터 모델링 절차
요구 조건 분석 : 사용자가 원하는 데이터베이스의 용도를 파악하는 것
개념적모델링 (개념적 데이터 모델)
사용자들의 요구사항을 이해하기 쉬운 형식으로 간단히 기술하는 단계
개념스키마모델링(데이터 중심), 트랜잭션 모델링(처리중심), ERD(개체-관계를 표현)
논리적모델링 (논리적 데이터 모델 - 관계 데이터 모델-표, 네트워크 데이터 모델-그래프, 계층 데이터 모델-트리)
개념적 설계에서 만든 구조를 구현 가능한 데이터 모델로 변환하는 단계.
해당 DBMS가 지원하는 데이터 모델에 적합하게 변환.(DBMS에 종속적)
트랜잭션 인터페이스 설계, 정규화
물리적모델링
논리적 데이터베이스 구조를 내부 저장 장치 구조와 접근 경로 등을 설계.
DBMS/HW 종속적, 트랜잭션 세부설계
데이터베이스의 논리적 구성
개체(Entity) : 표현하려는 유형, 무형 정보의 대상으로 존재하면서 서로 구별되는 것.
속성(Attribute) : 개체의 특성이나 상태를 기술하는 것
관계(Relationship) : 개체 간 또는 속성 간의 상호작용
DBMS(DataBase Management System)
물리적으로 저장된 데이터를 관리하고 접근하도록 지원하는 소프트웨어.
데이터모델
현실 세계의 데이터구조를 컴퓨터 세계의 데이터구조로 기술하는 논리적 구조.
구성요소 : D = SOC
구조(Structure) : 정적성질로서 개체타입과 이들간의 관계를 명세
연산(Operation) : 동적성질로서 개체 인스턴스에 적용가능한 연산에 대해 명세.
제약조건(Constraint) : 데이터에 대한 논리적 제약으로 개체 인스턴스의 허용조건을 의미.
개체-관계모델(E-R, Entity-Relationship Model)
개체타입과 관계타입을 기본 개념으로 현실 세계를 개념적으로 표현.
E-R다이어그램 표기법
개체(사각), 속성(원), 관계(마름모), 키 속성(밑 줄), 이중원(다중 속성), 복합속성(서브속성이 붙음)
약한개체타입
자기 자신의 속성만으로는 키를 명세할 수 없는 개체.(전체 참여)
단순속성과 복합속성(독립적인 의미를 가질 수 있는 여러 기본 속성으로 구성된 속성 ex)이름(성,명), 주소(~시~동~리))
단일값속성(ex)나이, 학년)과 다중값속성(특정속성은 여러 개의 값을 가질 수 있다.ex)취미,과목)
저장속성(기본 속성값만 저장)과 유도속성(다른 관련된 속성이나 개체의 값으로부터 유도된 속성)
관계 데이터 모델
관계 데이터 구조
릴레이션(Relation) : 정보 저장의 기본 형태가 2차원 구조의 테이블로 표현되는 모델
속성(Attribute) : 테이블의 각 열을 의미.
도메인(Domain) : 속성이 취할 수 있는 값들의 집합
튜플(Tuple) : 테이블이 한 행을 구성하는 속성들의 집합.
차수(Degree) : 속성의 개수
기수(Cadinality) : 튜플의 개수
릴레이션의 특성
1.튜플의 유일성
2.튜플의 무순서
3.애트리뷰트의 무순서
4.애트리뷰트의 원자성.
키의 종류
슈퍼키 : 유일성은 만족시키지만 최소성은 만족시키지 못하는키
후보키 : 튜플을 유일하게 식별할 수 있는 속성이나 속성의 조합들. 유일성과 최소성 만족
기본키 : 튜플을 유일하게 식별할 수 있는 속성집합.
대체키 : 기본키를 제외한 후보키들.
외래키 : 다른 릴레이션을 참조하는 데 사용되는 속성.
ORM(Object-Relational Mapping)
객체와 관계형데이터베이스의 데이터를 자동으로 매핑해 주는 것을 말한다.
장점
객체지향적인 코드로 인해 더 직관적이고, 비즈니스 로직에 더 집중할 수 있게 도와줌.
재사용 및 유지보수의 편리성이 증가.
DBMS에 대한 종속성이 줄어듬
단점
완벽한 ORM으로만은 완벽한 서비스를 구현하기가 어렵다
프로시저가 많은 시스템에선 ORM의 객체지향적인 장점을 활용하기 어렵다.
3단계 스키마
스키마 : 데이터베이스의 구조에 대한 정의와 이에 대한 제약 조건등을 기술한 것
외부스키마 : 가장 바깥쪽 스키마로 전체 데이터 중 사용자가 사용하는 한 부분에서 본 구조.(서브스키마, 뷰)
개념스키마 : 범 기관적 입장에서 데이터베이스를 정의
내부스키마 : 물리적 저장장치 관점에서 전체 데이터베이스가 저장되는 방법을 명세.
논리적 데이터 독립성(개념스키마에 대한 변경에 대해 응용 인터페이스만 변경해 준다면 외부스키마에 아무 영향을 미치지 않음)
물리적 데이터 독립성(내부 스키마에 대한 변경에 대해 저장 인터페이스만 변경해 준다면 내부 스키마에는 아무 영향을 미치지 않음)
응용 인터페이스 : 외부스키마와 개념스키마 간의 대응 관계
저장 인터페이스 : 개념스키마와 내부스키마 간의 대응 관계.