소프트웨어 생명 주기
- 소프트웨어를 개발하기 위한 과정을 단계별로 나눈 것
- 소프트웨어 개발 단계와 각 단계별 주요 활동 그리고 활동의 결과에 대한 산출물로 표현
나선형 모형 (Spiral Model , 점진적 모형)
- 여러번의 소프트웨어 개발 과정을 거쳐 점진적으로 개발하는 모형
- 계획 수립 -> 위험 분석 -> 개발 및 검증 -> 고객 평가
폭포수 모형 (Waterfall Model)
- 각 단계를 확실히 매듭짓고 그 결과를 검토하여 승인 과정을 거친 후 다음 단계를 진행하는 개발 방법
- 가장 오래되고 전통적 , 고전적
프로토타입 모형 (Prototype Model, 원형 모형)
- 실제 개발될 소프트웨어에 대한 견본품을 만들어 최종 결과물을 예측하는 모형
애자일 모형 (Agile)
- 요구사항 변화에 유연하게 대응할 수 있도록 일정 주기를 반복하면서 개발하는 모형
- 고객과 소통에 초점
- ex) 스크럼(Scrum) , XP(eXtreme Programming), 칸반(Kanban), Lean, 기능 중심 개발 (FDD)
애자일 개발 4가지 핵심 가치
- 프로세스 & 도구 < 개인과 상호작용
- 방대한 문서 < 실행되는 SW
- 계약 협상 < 고객과 협업
- 계획 < 변화에 반응
소프트웨어 공학
- 소프트웨어 위기를 극복하기 위한 방안으로 연구된 학문
스크럼
- 팀이 중심이 되어 개발의 효율성을 높이는 방법
| 구성원 | 역할 |
| 제품 책임자 (PO: product Owner) | 요구 사항 담긴 백로그 작성 이해도 높고, 의사 결정 |
| 스크럼 마스터(SM: Scrum Master) | 스크럼 수행의 가이드 |
| 개발팀(DT;Development Team) | 제품 개발 수행 |
스크럼 개발 프로세스
| 프로세스 | 내용 |
| 스프린트 계획 회의 | 백로그 중 수행할 작업 대상 일정 수립 회의 |
| 스프린트 | 2~4주 기간 개발 |
| 일일 스크럼 회의 | 15분 정도의 점검회의 남은 작업 시간 소멸 차트에 표시 |
| 스프린트 검토 회의 | 요구사항 부합 테스트 |
| 스프린트 회고 | 개선할 점 확인 및 기록 |
XP (eXtreme Programming)
- 요구사항에 유연하게 대응하기 위해 고객 참여, 개발 과정의 반복을 극대화하여 개발 생산성을 향상 시키는 방법
- 5가지 핵심 가치 ( 피드백 , 존중, 의사소통, 용기, 단순성 --> 피존의 용단)
XP의 주요 실천 방법
| 방법 | 설명 |
| Pair Programming (짝 프로그래밍) | 다른 사람과 함께 프로그래밍 수행 |
| Collective Ownership (공동 코드 소유) | 개발 코드에 대한 권한 , 책임을 공동으로 소유 |
| Test-Driven Development (테스트 주도 개발) | 개발 전테스트 케이스 먼저 작성 --> 무엇을 해야할 지 정확히 파악 |
| Whole Team (전체 팀) | 개발 참여 모든 구성원 본인 역할에 책임 |
| Continuous Integration (지속적인 통합) | 모듈 단위로 나눠 지속적으로 통합 |
| Refactoring (리팩토링) | 프로그램 기능 변경 없이 시스템 구성 목적 : 프로그램 쉽게 이해, 빠르게 개발 |
| Small Releases (소규모 릴리즈) | 릴리즈 기간 짧게 --> 요구 변화에 신속 대응 |
데이터베이스 관리 시스템 (DBMS)
- 사용자와 데이터베이스 사이에서 정보 생성, 데이터 베이스 관리 소프트웨어
- 요구사항 식별 시 고려 사항 ( 성능 , 기술 지원, 상호 호환성 , 구축 비용, 가용성 --> 성기상구가)
웹 애플리케이션 서버 (WAS)
- 사용자 요구에 따라 변하는 동적 콘텐츠 처리 미들웨어
- 요구사항 식별 시 고려 사항 ( 성능, 기술 지원, 주변 기기, 구축 비용, 가용성 --> 성기주구가)
오픈 소스
- 제한없이 사용할 수 있도록 소스 코드를 공개한 소프트웨어
- 요구사항 식별 시 고려사항 (라이선스 종류, 사용자 수, 기술의 지속 가능성 --> 라사기)
요구 사항
- 소프트웨어가 어떤 문제를 해결하기 위해 제공하는 서비스에 대한 설명과 제약조건
- 의사소통 원활하게 하는데 도움
- 개발, 유지 보수 과정에서 필요한 기준과 근거 제공
기능 요구사항
- 시스템이 무엇을 하는지, 어떤 기능을 하는지 기능이나 수행과 관련된 요구사항
- ex) 입출력 , 연산 등
비기능 요구사항
- 품질이나 제약사항과 관련된 요구사항
- ex) 성능, 장비, 보안, 품질 등
요구사항 개발 프로세스
- 도출 -> 분석 -> 명세 -> 확인 (도분명확)
요구사항 명세
- 분석된 요구사항을 바탕으로 모델을 작성하고 문서화하는 것
- 기능 요구사항은 빠짐없이, 비기능은 필요한 것만
요구사항 명세 기법
| 구분 | 정형 명세 | 비정형 명세 |
| 기법 | 수학적 원리 기반 | 상태/기능/객체 중심 |
| 작성 방법 | 수학적 기호, 정형화된 표기법 | 일반 명사, 동사, 자연어 서술 , 다이어그램 |
| 특징 | 정확,간결, 어려움 | 일관성 떨어짐, 이해가 쉬움 |
| 종류 | VDM,Z, Petri-net, CSP | FSM, Decision Table, ER 모델링, SADT |
요구사항 분석
- 개발 대상에 대한 사용자의 요구사항을 이해하고 문서화하는 활동
- 비용과 일정에 대한 제약 설정
- 타당성 조사
- 요구사항 정의 문서화
- 목표 설정
자료 흐름도 (DFD)
- 자료 흐름 및 변환 과정 기능을 도형 중심으로 기술하는 방법
- 자료 흐름 그래프, 버블 차트, 구조적 분석 기법
- 구성 요소 : 프로세스(Process), 자료 흐름(Data flow), 자료 저장소(Data Store), 단말(Terminator)
자료 사전 (DD)
- 자료 흐름도에 있는 자료를 더 자세히 정의하고 기록한 것 (= 메타 데이터)
| 기호 | 의미 |
| = | 자료 정의 |
| + | 자료 연결 |
| () | 자료 생략 |
| [ ] | 자료 선택 |
| { } | 자료 반복 |
| * * | 자료 설명 |
요구사항 분석용 CASE
- 요구사항을 자동으로 분석, 요구사항 분석 명세서를 기술하도록 개발된 도구
- ex) SADT, SREM , RSL/REVS , PSL/PSA, TAGS
SADT
- 시스템 정의, 소프트웨어 요구사항 분석, 시스템/소프트웨어 설계 도구
- SoftTech사에서 개발
HIPO
- 시스템 실행 과정인 입력 , 처리 , 출력의 기능을 표현한 것
- 하향식 소프트웨어 개발
- 가시적 , 총체적 , 세부적 도표
UML
- 시스템 개발 과정에서 의사소통이 원활하게 이루어지도록 표준화한 대표적 객체지향 모델링 언어
- 구성요소 (사물 , 관계, 다이어그램)
관계
- 사물과 사물 사이의 연관성을 표현하는 것
- 종류 : 연관, 포함, 의존, 집합, 일반화, 실체화 (연포의 집일실)
연관 관계
- 2개 이상 사물이 서로 관련있는 관계
- 실선 표현 , 방향성 (화살표로 표현)
- ex) 사람 -> 집
집합 관계
- 하나의 사물이 다른 사물에 포함되어 있는 관계
- 포함되는 쪽에서 포함하는 쪽으로 속이 빈 마름모로 연결
- ex) 컴퓨터 <빈 마름모>-- 프린터
포함 관계
- 포함하는 사물의 변화가 포함되는 사물에 영향을 미치는 관계
- 속이 채워진 마름모 연결
- ex) 문 <채워진 마름모>-- 키
일반화 관계
- 하나의 사물이 다른 사물에 비해 더 일반적이거나 구체적인 관계
- 상위 (부모), 하위(자식)
- ex) 커피 <- (아메리카노, 에스프레소)
의존 관계
- 서로에게 영향 주는 짧은 시간 동안만 연관 유지 관계
- 점선 표현
- ex) 등급 ----> 할인율
실체화 관계
- 사물이 할 수 있거나 해야하는 기능으로 서로 그룹화할 수 있는 관계
- 속이 빈 점선
- ex) 날 수 있다 <| --- (비행기, 새)
다이어그램
- 사물과 관계를 도형으로 표현한 것
- 정적 모델링 : 구조적 다이어그램
- 동적 모델링 : 행위 다이어그램
구조적 다이어그램
| 종류 | 기능 |
| 클래스 다이어그램 | 클래스와 클래스가 가지는 속성, 클래스 사이 관계를 표현 |
| 객체 다이어그램 | 객체와 객체 사이 관계료 표현, 럼바우 기법에서 객체 모델링에 활용 |
| 컴포넌트 다이어그램 | 컴포넌트 간의 관계나 컴포넌트 간의 인터페이스 |
| 배치 다이어그램 | 요소들의 위치 표현 |
| 복합체 구조 다이어 그램 | 복합 구조를 갖는 경우 그 내부 구조를 표현 |
| 패키지 다이어그램 | 그룹화한 패키지들의 관계 표현 |
--> 클객컴배복패
행위 다이어그램
| 종류 | 기능 |
| 유스케이스 다이어그램 | - 사용자 요구 분석하는 것, 기능 모델링 작업에 사용 - 사용자(Actor)와 사용사례(Use Case)로 구성 |
| 시퀀스 다이어그램 | 객체들이 주고받는 메시지를 표현 |
| 커뮤니케이션 다이어그램 | 메시지와 객체들 간의 연관 관계 표현 |
| 상태 다이어그램 | 럼바우 객체지향 분석 기법에서 동적 모델링에 활용 |
| 활동 다이어그램 | 객체의 처리 로직이나 조건에 따른 처리 흐름을 순서에 따라 표현 |
| 상호작용 개요 다이어그램 | 상호작용 다이어그램 간의 제어 흐름을 표현 |
| 타이밍 다이어그램 | 객체 상태 변화와 시간 제약을 명시적으로 표현 |
--> 상상활순타커유
스테레오 타입
- UML에서 표현하는 기본 기능 외 추가적인 기능을 표현하는 것
- <<>>
유스케이스 다이어그램
- 개발될 시스템을 이용해 수행할 수 있는 기능을 사용자 관점에서 표현한 것
| 구성 요소 | 내용 |
| 시스템 / 시스템 범위 | 시스템 내부 유스케이스들을 사각형으로 묶어 싯트템 범위 표현한 것 |
| 액터 | - 시스템과 상호작용하는 모든 외부 요소 - 주로 사람이나 외부 시스템을 의미 - 주액터 : 시스템을 사용함으로 써 이득을 얻는 대상 - 부액터 : 주액터 목적 달성을 위해 제공하는 시스템 등 |
| 유스케이스 | 사용자가 보는 관점에서 시스템이 액터에게 제공하는 서비스나 기능을 표현한 것 |
| 관계 | 포함 관계, 확장 관계, 일반화 관계가 있음 |
유스케이스 관계
- 포함 관계 : 두 개 이상의 유스케이스에 공통적으로 적용되는 기능을 별도 분리하여 새로운 유스케이스를 만든 경우
- 확장 관계 : 특정 조건을 만족할 때 기능이 확장 되는 것
활동 다이어그램
- 사용자 관점에서 시스템이 수행하는 기능을 처리 흐름에 따라 순서대로 표현한 것
| 구성 요소 | 내용 |
| 액션/액티비티 | - 액션 : 더 이상 분해할 수 없는 단일 작업 - 액티비티 : 몇 개의 액션으로 분리될 수 있는 작업 |
| 시작 노드 | - 액션이나 액티비티가 시작됨을 표현한 것 |
| 종료 노드 | - 액티비티 안의 모든 흐름이 종료됨을 표현한 것 |
| 조건(판단) 노드 | - 조건에 따라 제어 흐름이 분리됨을 표현한 것 - 들어오는 제어 흐름 1개, 나가는 제어 흐름 여러개 |
| 병합 노드 | - 여러 경로의 흐름이 하나로 합쳐짐을 표현 - 들어오는 제어 흐름 여러개, 나가는 제어 흐름 1개 |
| 포크 노드 | - 액티비티 흐름이 분리되어 수행됨을 표현한 것 - 들어오는 액티비티 흐름 1개, 나가는 액티비티 흐름 여러개 |
| 조인 노드 | - 분리되어 수행되던 액티비티 흐름 다시 합쳐짐을 표현 - 들어오는 액티비티 여러개, 나가는 액티비티 흐름 1개 |
| 스윔레인 | - 액티비티 수행을 담당하는 주체 구분선 - 가로 또는 세로 실선을 그어 구분 |
클래스 다이어그램
- 클래스와 클래스가 가지는 속성, 클래스 사이의 관계를 표현한 것
| 구성 요소 | 내용 |
| 클래스 (Class) | 각각 객체들이 갖는 속성과 오퍼레이션을 표현한 것 - 속성 : 클래스 상태나 정보 표현 - 오퍼레이션 : 클래스가 수행할 수 있는 동작 |
| 제약 조건 | - 속성에 입력될 값에 대한 제약조건이나 오퍼레이션 수행 전 후에 지정해야할 조건이 있다면 이를 적음 - 제약 조건 기술 시 { } 중괄호 이용 |
| 관계 | - 클래스 사이 연관성 표현 - 연관, 집합, 포함,일반화, 의존 관계가 있음 |
연관 클래스
- 연관 관계에 있는 두 클래스에 추가적으로 표현해야 할 속성이나 오퍼레이션이 있는 경우 생성하는 클래스
시퀀스 다이어그램
- 시스템이나 객체들이 메시지를 주고 받으며 상호작용하는 과정을 그림으로 표현한 것
| 구성 요소 | 의미 |
| 액터 | 시스템으로부터 서비스 요청하는 외부 요소 |
| 객체 | 메시지 주고받는 객체 |
| 생명선 | - 객체가 메모리에 존재하는 기간, 점선을 그어 표현 - 객체 소멸(X)이 표시된 기간까지 존재 |
| 실행 상자 | 객체가 메시지를 주고 받으며 구동되고 있음을 표현 |
| 메시지 | 객체가 상호 작용을 위해 주고받는 메시지 |
| 객체 소멸 | 해당 객체가 더 이상 메모리에 존재하지 않음을 표현 |
| 프레임 | 다이어그램 전체 또는 일부를 묶어 표현한 것 |
커뮤니케이션 다이어그램
- 시스템이나 객체들이 메시지 주고 받으며 상호작용하는 과정과 객체들 간 연관을 그림으로 표현
| 구성 요소 | 의미 |
| 액터 | 위와 동일 |
| 객체 | 위와 동일 |
| 링크 | - 객체들 간 관계 표현 - 액터와 객체, 객체와 객체 간 실선으로 표현 |
| 메시지 | - 객체가 상호 작용을 위해 주고받는 내용 - 화살표 방향은 받는 쪽으로 향하게 - 일정한 순서에 의해 처리되는 메시지의 경우 숫자로 순서 표현 |
상태 다이어그램
- 객체들 사이에서 발생하는 이벤트에 의한 객체들의 상태 변화를 그림으로 표현한 것
| 구성 요소 | 의미 |
| 상태 | 객체 상태 표현한 것 |
| 시작 상태 | 상태 시작 표현한 것 |
| 종료 상태 | 상태 종료 표현한 것 |
| 상태 전환 | 상태 사이 흐름, 변화를 화살표로 표현한 것 |
| 이벤트 | - 상태에 변화를 주는 현상 - 이벤트에는 조건, 외부 신호, 시간의 흐름 등이 있음 |
| 프레임 | 상태 다이어그램의 범위를 표현한 것 |
패키지 다이어그램
- 요소들을 그룹화한 패키지 간의 의존 관계를 표현한 것
| 구성 요소 | 의미 |
| 패키지 | - 객체들을 그룹화한 것 - 단순 표기법 : 패키지 안에 패키지 이름만 표현 - 확장 표기법 : 패키지 안에 요소까지 표현 |
| 객체 | 유스케이스, 클래스, 인터페이스, 테이블 등 패키지에 포함될 수 있는 다양한 요소들 |
| 의존 관계 | - 패키지와 패키지, 패키지 객체간 점선 화살표로 연결하여 표현 - 스테레오 타입을 이용해 의존 관계를 구체적으로 표현 가능 - <<import>> , <<access>> |
구조적 방법론
- 사용자 요구사항을 파악하여 문서화하는 처리 중심의 방법론
- 타당성 검토 -> 계획 -> 요구사항 -> 설계 -> 구현 -> 시험 -> 운용/유지보수 단계
객체지향 방법론
- 객체들을 조립해서 소프트웨어를 구현하는 방법론
- 요구 분석 -> 설계 -> 구현 -> 테스트 및 검증 -> 인도 단계
컴포넌트 기반 방법론 (CBD)
- 기존 컴포넌트를 조합하여 하나의 새로운 애플리케이션을 만드는 방법론
- 시간과 노력 절감 (재사용으로)
- 개발 준비 -> 분석 -> 설계 -> 구현 -> 테스트 -> 전개 -> 인도 단계
소프트웨어 재사용
- 이미 개발되어 인정받은 소프트웨어를 다른 소프트웨어 개발이나 유지에 사용하는 것
- 합성 중심 : 블록을 만들어 끼워 맞춰 완성 시키는 방법 ( 블록 구성 방법 )
- 생성 중심 : 추상화 명세를 구체화하여 완성 시키는 방법 ( 패턴 구성 방법)
소프트웨어 재공학
- 기존 시스템을 이용해 보다 나은 시스템 구축, 새로운 기능 추가하여 소프트웨어 성능 향상
CASE
- 소프트웨어 개발 과정에서 사용되는 과정 전체 또는 일부를 소프트웨어 도구를 이용해 자동화하는 것
- 주요 기능 (소프트웨어 생명 주기 전 단계 연결, 다양한 개발 모형 지원 , 그래픽 지원)
하향식 비용 산정 기법
- 전문 지식이 많은 개발자들이 참여한 회의를 통해 비용 산정하는 방법
- 전문가 감정 기법 : 경험 많은 두 명 이상의 전문가에게 비용 산정 의뢰
- 델파이 기법 : 많은 전문가 의견 종합하는 방법
상향식 비용 산정 기법
- 세부적인 작업 단위별로 비용을 산정한 후 집계하여 전체 비용을 산정하는 방법
- ex) LOC기법 , 개발 단계별 인월수 기법 , 수학적 산정 기법
LOC 기법
- 원시 코드 라인 수의 비관치, 낙관치, 기대치를 측정해 예측치를 구하고 비용을 산정하는 기법
- 공식
- 노력(인월) = 개발 기간 X 투입 인원 = LOC/ 1인당 월평균 생상 코드 라인 수
- 개발 비용 = 노력 (인월) X 단위 비용 (인당 월평균 인건비)
- 개발 기간 = 노력 (인월) / 투입 인원
- 생산성 = LOC / 노력 (인월)
수학적 산정 기법
- 비용 산정의 자동화를 목표로 ( = 경험적 추정 모형, 실험적 추정 모형)
- ex) COCOMO , Putnam , FP(기능 점수) 모형
COCOMO 모형
- LOC(원시 코드 라인 수)에 의한 비용 산정 기법
- 조직형(Organic Mode) : 5만(50KDSI) 라인 이하 소프트웨어 개발
- 반분리형(Semi-Detached Mode) : 30만(300KDSI) 라인 이하 소프트웨어 개발
- 내장형(Embedded Mode) : 30만(300KDSI) 라인 이상 소프트웨어 개발
Putnam 모형
- 소프트웨어 생명주기의 전 과정 동안에 사용될 노력의 분포를 예상하는 모형
- Rayleigh-Norden 곡선의 노력 분포도를 기초로 함
기능 점수 (FP) 모형
- 소프트웨어의 기능을 증대시키는 요인별로 가중치 부여, 점수를 구해 비용 산정
- 증대 요인
- 자료 입력 (입력 양식)
- 정보 출력 (출력 보고서)
- 명령어 (사용자 질의수)
- 데이터 파일
- 필요한 외부 루틴과의 인터페이스
비용 산정 자동화 추정 도구
- SLIM : Rayleigh-Norden 곡선과 Putnam 예측 모델을 기초로 한 자동화 추정 도구
- ESTIMACS : FP 모형을 기초로 하여 개발된 자동화 추정 도구
PERT
- 전체 작업의 상호 관계를 표시하는 네트워크
- 종료 시기 결정 단계 (낙관적인 경우, 가능성 있는 경우, 비관적인 경우 --> 낙가비)
CPM (임계 경로 기법)
- 작업을 나열하고 작업에 필요한 소요 기간을 예측하는데 사용하는 기법
- 최장 경로 기법
간트 차트
- 작업 일정을 막대 도표를 이용해 표시하는 프로젝트 일정표
- 시간선 차트라고도 함
ISO/IEC 12207
- ISO에서 만든 표준 소프트웨어 생명 주기 프로세스
| 기본 생명 주기 프로세스 | 획득, 공급, 개발, 운영, 유지보수 |
| 지원 생명 주기 프로세스 | 품질 보증, 검증, 확인, 활동 검토, 감사, 문서화, 형상 관리, 문제 해결 |
| 조직 생명 주기 프로세스 | 관리, 기반 구조, 훈련, 개선 |
CMMI
- 개발 조직의 업무 능력, 성숙도를 평가하는 모델
- 성숙도 (초관정정최)
| 단계 | 특징 |
| 초기 | 작업자 능력에 따라 성공 여부 결정 |
| 관리 | 특정 프로젝트 내 프로세스 정의 및 수행 |
| 정의 | 조직 표준 프로세스를 활용해 업무 수행 |
| 정량적 관리 | 프로젝트를 정량적으로 관리 및 통제 |
| 최적화 | 프로세스 역량 향상을 위해 지속적인 프로세스 개선 |
SPICE
- 소프트웨어 프로세스를 평가 및 개선하는 국제 표준
- 공식 명칭 : ISO/IEC 15504
SPICE 프로세스 수행 능력 단계
- 0수준 : 불완전
- 1수준 : 수행
- 2수준 : 관리
- 3수준 : 확립
- 4수준 : 예측
- 5수준 : 최적화
--> 불수관 확예최
소프트웨어 개발 방법론 테일러링
- 소프트웨어 개발 방법론의 절차, 사용기법 등을 수정 및 보완하는 작업
| 기준 | 내용 |
| 내부적 기준 | - 목표 환경 - 요구 사항 - 프로젝트 규모 - 보유 기술 |
| 외부적 기준 | - 법적 제약사항 - 표준 품질 기준 |
프레임워크
- 개발에 공통적으로 사용되는 구성 요소와 아키텍처를 일반화하여 제공해주는 반제품 형태의 소프트웨어 시스템
스프링 프레임워크
- 자바 플랫폼을 위한 오픈 소스 경량형 애플리케이션 프레임워크
- 동적인 웹 사이트 개발에 사용 , 전자정부 표준 프레임워크 기반 기술로 사용
소프트웨어 개발 프레임워크의 특성
| 특성 | 내용 |
| 모듈화 | 캡슐화를 통해 모듈화를 강화하고 변경에 따른 영향을 최소화 |
| 재사용성 | 재사용 가능한 모듈을 제공함으로써 예산 절감, 생산성 향상 |
| 확장성 | 다형성을 통한 확장이 가능 |
| 제어의 역흐름 (IoC) | 객체들의 제어를 프레임워크에 넘김으로써 생산성 향상 |
