Section 1. 개발 환경 구축
1. 서버 환경 구축
1. 웹 서버(WEB)
- 정적 파일(HTML, CSS, JS, 이미지)을 제공하는 웹서버 애플리케이션이 설치된 하드웨어
- Apache Web Server, IIS, Nginx, GWS 등
2. 웹 어플리케이션 서버(WAS)
- 동적인 웹 서비스를 제공하기 위한 미들웨어가 설치된 하드웨어
- 요청에 맞는 동적인 콘텐츠를 생성
- DB조회나 다양한 로직 처리
- Web Logic, Web Sphere, Jeus, Tomact등
3. 데이터베이스 서버(DBMS)
- 데이터의 저장과 관리를 위한 데이터베이스 소프트웨어가 설치된 하드웨어
- ORacle, MySQL, MS-SQL 등
4. 파일 서버
- 사용자의 파일을 저장하고, 파일을 공유할 목적으로 구성된 하드웨어
5. Load Balancer
- 여러 대의 서버가 존재할 경우 요청을 분배해주는 역할
- 분배 방식
- Random
- Least Loaded
- Round Robin: 순서를 정하여 돌아가며 작업 분배
6. CDN(Content Delievery Network)
- 용량이 큰 컨텐츠 데이터(이미지, 비디오 등)를 빠른 속도로 제공하기 위해 사용자와 가까운 곳에 분산되어 있는 데이터 저장 서버
- 클라이언트는 용량이 큰 콘텐츠 데이터를 가까운 CDN에 요청해 멀리 있는 웹서버에서 직접 받는것보다 빠르게 받을 수 있다
투명성: 난 몰라도 된다~ 사용자가 알 필요없다
7. 시스템 아키텍처 고려사항
- 확장성: 클라이언트 수가 늘어났을 때 무리없이 요청을 처리할 수 있는 확장성을 고려
- 성능: 요청한 내용을 정확하고 빠르게 제공
- 응답 시간: 빠른 시간안에 요청
- 처리량
- 접근성
- 일관성: 일정한 결과를 돌려주어야 한다
2. 개발 소프트웨어 환경
1. 시스템 소프트웨어
- 운영체제(OS, Operating System)
- JVM(Java Virtual Machine)
- Web Server
- 정적 웹 서비스를 수행함
- WAS(Web Application Server)
- DMBS(Database Management System)
- 데이터 저장과 관리를 위한 데이터베이스 소프트웨어
2. 개발 소프트웨어
- 요구사항 관리 도구
- JFeature, JRequisite, OSRMT, Trello 등
- 설계/모델링 도구
- ArgoUML, StarUML, DB Designer등
- 구현 도구(IDE)
- Eclipse,IntelliJ, Visual Studio 등
- 테스트 도구
- 개발된 도뮬들에 대하여 요구사항에 적합하게 구현되어 있는지 테스트를 지원하는 도구
- JUnit, CppUnit, JMeter, Spring Test등
- 형상관리 도구
- 산출물 및 소스코드의 변경사항을 버전별로 관리하여, 목표 시스템의 품질 향상을 지원하는 도구
- Git, CSV, SVN 등
3. IDE(Integrated Development Environment) 도구
IDE 도구의 개념
- Text, Compiler, Debugger, Test, DB등의 도구, 작업들을 한 환경에서 처리하게 제공되는 소프트웨어
IDE 도구의 기능
- 소스코드를 작성하기 위한 에디터
- 컴파일
- 디버거
- 배포
- 플러그인
IDE 도구 선정 시 고려사항
- 적정성
- 효율성
- 이식성
- 친밀성
- 범용성
4. 협업 도구
협업 도구의 개념
- 여러 사용자가 각기 별개의 작업 환경에서 통합된 하나의 프로젝트를 동시에 수행할 수 있도록 도와주는 소프트웨어
- 개발자, 디자이너, 기획자, 현업 관리자 등의 커뮤니케이션을 하나의 채널에서 가능하게끔 만들어준다
Iaas: 장비 빌리는 것(Cloud) Paas: 환경 빌리는 것 Saas: 소프트웨어를 빌리는 것 Baas: 블록체인 Secaas: 보안
협업 도구의 기능
- 전사 관리: 전자 결제, 조직도 등
- 프로젝트 관리
- 자체 드라이브 공간
- 문서 공유 지원
- 커뮤니케이션
- 다국어 지원
- 타 협업툴 간 연동 지원
5. 형상 관리 도구
- 소프트웨어 생명주기 동안 발생하는 변경사하응ㄹ 통제하기 위한 관리 방법
- 변경 관리/버전 관리/형상 관리
형상 관리 절차
- 형상 식별
- 형상 통제: 소프트웨어 형상 변경 요청을 검토하고 승인하여 현재의 베이스라인에 반영될 수 있도록 통제
- 형상 감사
- 형상 기록/보고
6. 버전 관리 도구
- 동일한 소스코드에 대한 여러 버전을 관리하는 것
소프트웨어 버전 관리 도구 유형
- 공유 폴더 방식(RCS, SCCS)
- 클라이언트 / 서버방식(CVS, SVN)
- 분산 저장소 방식(Git, Betkeeper)
버전 관리 도구
1) CVS - 커밋중 오류가 발생하면 롤백되지 않는다 - 느리다 - 등록된 파일이나 디렉토리 변동이 어렵다 2) SVN - CVS의 단점을 보완하기 위해 만들어짐 3) Git - 리누스 토발즈가 리눅스 커널의 개발을 위해 만듬 - 로컬 우선 작업을 통해 성능이 우수 4) Clear Case 5) BitKeeper 6) RCS
7. 빌드 도구
빌드의 개념
- 소스코드 파일들으 컴퓨터에서 실행할 수 있는 소프트웨어로 변환하는 일련의 과정
- 컴파일이 포함
- 지속적인 통합(Continuous Integration)을 수행할 수 있도록 도와준다
빌드 자동화 도구 특징
- 빌드, 테스트, 배포를 자동으로 수행하는 도구
- 소스코드를 컴파일, 테스트, 정적분석 등을 실시하여 실행 가능한 애플리케이션으로 자동으로 생성
- 계속해서 늘어나는 라이브러리 자동 추가 및 관리
빌드 자동화 프로세스
- 빌드
- 테스트
- 배포
빌드 자동화 도구 종류
- Make: Unix에서 운영
- Ant: Java 기반의 빌드 도구. XML 기반의 빌드 스크립트로 개발
- Maven
- 프로젝트에 필요한 모든 의존성을 리스트 형태로 Maven에게 알려 관리할 수 있도록 돕는 방식
- Jenkins: Java기반의 오픈소스. Servlet 기반
- Gradle
- Groovy를 기반으로 한 오픈 소스 형태의 자동화 도구로 안드로이드 앱 개발 환경에서 사용
- 플러그인을 설정하면 Java, C/C++, Python등의 언어도 가능
- Groovy를 사용해서 만든 DSL을 스크립트 언어로 사용
Section 2. 개발 프레임워크
1. 프레임워크의 개념
- 반제품 형태의 소프트웨어
- 개발에 공통적으로 사용되는 구성 요소와 아케틱처를 일반화하여 제공
- 템플릿과 비슷한 역할을 하는 클래스들과 인터페이스의 집합
2. 프레임워크의 특징
- 모듈화(modularity)
- 캡슐화를 통해서 모듈화를 강화
- 설계와 구현의 변경에 따르는 영향을 최소화시킴으로써 쉽게 소프트웨어의 품질을 향상시킴
- 재사용성(resuability)
- 확장성(extensibility)
- 제어의 역흐름(inversion of control)
3. 프레임워크의 구분
- Java framework:
- 전자정부 표준 프레임워크
- 스트럿츠
- 스프링
- ORM 프레임워크
- 아이바티스(iBatis)
- 마이바티스(myBatis)
- 하이버네이트(Hibernate)
- 자바스크립트 프레임워크
- Angular JS
- REactJS
- ExtJS
- 프론트엔드 프레임워크
- Bootstrap
- Foundation
- MDL
4. 라이브러리(Library)
- 컴퓨터 프로그램에서 빈번하게 사용되는 루틴 또는 리소스를 모아둔 것
5. API(Application Programming Interface)
- 일종의 소프트웨어 인터페이스이며 다른 종류의 소프트웨어에 서비스를 제공 특징
- 비용 감축
- 반복 작업 줄임
- 유지관리가 쉬움
- 새로운 수익 채널의 확대
- 비즈니스 파이의 확장
Section 3. 모듈 구현
1. 단위 모듈 구현
모듈 구현의 장점:
- 효율적인 관리 및 성능 향상
- 소프트웨어 복잡성 감소, 이해성 증대
- 테스트, 모듈 통합, 변경 용이성 쉬움
- 인터페이스가 단순해짐 -> 기능 분기 가능
- 오류의 파급효과 최소화
- 모듈의 재사용으로 개발과 유지보수가 용이
효과적인 모듈화
- 결합도를 낮추고 응집도를 높여 모듈의 독립성을 높힘
- FAN-OUT 최소화, FAN-IN 증가
단위 모듈 설계의 원리
- 단계적 분해
- 추상화
- 독립성
- 정보은닉
- 분할과 정복
단위 모듈 작성 원칙
- 정확성
- 명확성
- 완전성
- 일관성
- 추적성
2. 결합도
1) 결합도(Coupling)의 개념
- 어떤 모듈이 다른 모듈에 의존하는 정도
- 두 모듈 사이의 연관 관계
- 결합도가 낮을수록 잘 설계된 모듈이다
#정처기중요
2) 결합도 유형(데스형쟤왜저래공유랑내가닮았대)
- 자료 결합도: 모듈 간의 인터페이스로 값이 전달되는 경우. Call by value
- 스탬프 결합도: 모듈간의 인터페이스로 배열이나 오브젝트, 스트럭처 등이 전달되는 경우. Call by reference
- 제어 결합도: 값 + 어떻게 처리를 해야 한다는 제어요소가 전달되는 경우
- 외부 결합도: 어떤 모듈에서 선언한 데이터를 외부의 다른 모듈에서 참조하는 경우
- 공통 결합도: 전역변수를 참조하고 전역변수를 갱신
- 내용 결합도: 스파게티 코드, 다른 모듈 내부에 있는 변수가 기능을 다른 모듈에서 사용하는 경우
#정처기중요
3. 응집도
응집도 유형(우리놀던시절에통통한순대기억해)
- 기능적 응집도: 모든 기능이 단일한 목적을 위해 수행되는 경우
- 순차적 응집도: 한 활동으로부터 나온 출력값을 다른 활동이 사용할 경우
- 통신적 응집도: 동일한 입력과 출력 사용
- 절차적 응집도: 모듈이 다수의 관련 기능을 가질때 모듈 안의 구성 요소들이 그 기능을 순차적으로 수행할 경우
- 시간적 응집도: 동시에 일어나는 일들을 모아놓은 경우
- 논리적 응집도: 유사한 성격을 갖거나 특정 형태로 분류되는 경우
- 우연적 응집도: 모듈 내부의 구성이 연관이 없는 경우
4. 팬인(Fan-in), 팬아웃(Fan-out)
팬인: 모듈로 들어오는 수 팬아웃: 호출하는 하위 모듈 수
5. 공통 모듈 구현요소
DTO
- 프로세스 사이에서 데이터를 전송하는 객체
- Getter, Setter 메서드만 포함
VO
- 도메인에서 속성들을 묶어서 특정 값을 나타내는 객체
- DTO와 동일한 개념이나 차이점은 Read-Only속성 객체이다
Section 4. 서버프로그램 구현
이후로는 시간없어서 추가 노트
배치 프로그램
- 크론탭(crontab): 분 시 일 월 요일 명령어
- Spring Batch
- Quartz Job Scheduler: 초 분 시 일 월 요일 년(생랴가능) 명령어
송수신 데이터 구성(송신, 중계, 수신 중)
- 전문 공통부: 인터페이스 표준 항목을 포함
- 전문 개별부: 업무처리에 필요한 데이터
- 전문 종료부: 전송 데이터의 끝을 표시는 문자 포함
인터페이스 설계서
- 인터페이스 목록(리스트 형태)
- 인터페이스 ID
- 인터페이스 명
- 송신 시스템
- 수신 시스템
- 대내외 구분
- 연계 방식
- 통신 유형
- 처리 유형
- 주기
- 데이터 형식
- 관련 요구 사항 ID
- 인터페이스 정의서 -> 이후 인터페이스 설계서
- 인터페이스 아이디
- 최대 처리 횟수
- 데이터 크기
- 시스템 정보
- 데이터 정보
인터페이스 기능 구현
내외부 모듈 연계 방식
EAI(Enterprise Application Integration)
- EAI의 개념
- 기업에서 운영되는 서로 다른 플랫폼 및 애플리케이션들 간의 정보 전달, 연계, 통합을 가능하게 해주는 솔루션
- EAI의 구축유형
- Point-to-Point: 중간에 미들웨어를 두지 않고 어플간 point to point 형태로 연결
- Hub & Spoke: 단일 접점이 있는 허브 시스템을 중간에 두고 이용
- Message Bus(ESB 방식): 어플 사이 미들웨어를 두어 처리
- Hybrid: 그룹 내에는 Hub&Splie방식을, 그룹간에는 메세지 버스 방식을 사용
ESB(Enterprise Service Bus)
- 다양한 시스템과 연동하기 위한 멀티 프로토콜 지원
- 버스를 통해 이기종 애플리케이션을 유연하게 통합하는 핵심 플랫폼
- EAI와 유사하지만, 애플리케이션보다는 서비스 중심으로 통합을 지향하는 아키텍처 혹은 기술이다
인터페이스 구현
SOAP
WSDL(설명서): 웹 서비스 기술언어 또는 기술된 정의 파일의 총칭으로 XML로 기술 UDDL(저장소)): 인터넷에서 비즈니스 업체 목록에 자신의 목록을 등록하기 위한 XML 기반의 규격 SOAP(메시지 프로토콜): HTTP, HTTPS, SMTP등을 사용하여 XML 기반의 메시지를 네트워크상에서 교환하는 형태의 프로토콜
REST
- HTTP Method(POST, GET, PUT, DELETE)를 통해 자원에 대한 CRUD를 진행
- 자원 기반의 구조(ROA)로 이루어짐
- 표현: JSON, XML, TEXT, RSS등 여러 형태로 나타낼 수 있다
특징
- 유니폼 인터페이스: 어떤 언어나 플랫폼에서나 사용 가능
- Stateless: 상태 정보를 유지하지 않는다
- Cacheable: HTTP가 가진 캐싱 기능이 적용 가능
인터페이스 구현 검증 도구
- xUnit: 다양한 언어를 지원하는 단위 테스트
- STAF: 서비스 호출 및 컴포넌트 재사용
- FitNesse: 웹 기반 테스트케이스 설계, 실행, 결과 확인을 지원
- NTAF: FitNesse의 장점과 STAF의 장점을 합침(Naver에서 만듬)
- Selenium: 다양한 브라우저 및 개발언어를 지원하는 웹 애플리케이션 테스트 프레임워크
- watir: Ruby 사용 애플리케이션
객체지향 설계
객체지향 구성요소
- 클래스(Class): 틀
- 객체(Object): 클래스의 인스턴스
- 속성(Attribute)
- 메서드(Method)
- 메시지(Message): 객체에게 어떤 행위를 하도록 지시
객제지향언어의 특징
- 캡슐화(Encapsulation)
- 속성과 메서드를 하나로 묶은 것
- 정보은닉되어 오류의 파급 효과 줄임
- 재사용이 용이
- 정보은닉(Information Hiding)
- 상속(Inheritance)
- 다형성(Polymorphism)
- 오버로딩
- 오버라이딩
- 추상화(Abstraction)
#정처기중요
객체지향 설계원칙(SOLID)(중요!)
- 단일 책임 원칙(SRP, Single Responsibility Principle)
- 한 클래스는 하나의 책임만을 가져야 한다
- 개방 폐쇄 원칙(OCP, Open-Close Principle)
- 확장에는 열려있고, 수정에는 닫혀 있어야 한다
- 기존 코드를 변경하지 않으면서(Closed) 기능을 추가할 수 있도록(Open) 설계
- 리스코프 치환 원칙(LSP, Liskov Subsitution Principle)
- 자식 클래스는 언제나 자신의 부모 클래스를 대체할 수 있어야 한다
- 인터페이스 분리 원칙(ISP, Interface Segregation Principle)
- 자신이 사용하지 않는 인터페이스는 구현하지 말아야 한다
- 의존성 역전 원칙(DIP, Dependency Inversion Principle)
- 자주 변화하는 것보다, 변화가 거의 없는 것에 의존해야 한다
- 구체적인 클래스보다 인터페이스나 추상 클래스와 의존 관계를 맺어야 한다
디자인 패턴
GoF(Gang of Four)
- 23가지의 디자인 패턴을 정리
- 분류
- 생성(Creatoinal)
- 구조(Structural)
- 행위(Behavioral)
생성 패턴:
- Abstract Factory
- 구체적인 클래스에 의존하지 않고 서로 연관되거나 의존적인 객체들의 조합을 만드는 인터페이스를 제공하는 패턴
- Builder
- 복합 객체의 생성과 표현을 분리하여 동일한 생성절차에서도 다른 표현 결과를 만들어낼 수 있음
- Factory Method(Virtual-Constructor 패턴)
- 객체 생성을 서브클래스로 위임하여 캡슐화 함
- Prototype
- 원본 객체를 복사함으로써 객체를 생성함
- Singleton
- 어떤 클래스의 인스턴스는 하나임을 보장하고 어디서든 참조할 수 있도록 함
구조 패턴: 클래스나 객체들을 조합해 더 큰 구조로 만들 수 있게 해주는 패턴
- Adapter
- 클래스의 인터페이스를 다른 인터페이스로 변환하여 다른 클래스가 이용할 수 있게 함
- Bridge
- 추상층을 분리하여 각자 독립적으로 확장가능하게 함
- Composite
- 객체들의 관계를 트리 구조로 구성하여 복합 객체와 단일 객체를 구분없이 다룸
- 하나 이상의 유사한 객체를 구성으로 설계된 객체로 모두 유사한 기능을 나타냄
- Decorator
- 주어진 상황 및 용도에 따라 어떤 객체에 다른 객체를 덧붙이는 방식
- Facade
- 하나의 통합된 인터페이스(Wrapper)제공
- 앞쪽에 위치하면서 객체들을 사용할 수 있도록 인터페이스 역할을 함
- Flyweight
- 크기가 작은 여러 객체들을 가능한 공유할 수 있도록 하여 메모리 절약
- Proxy
- 접근이 어려운 객체로의 접근을 제어하기 위해 객체의 대리나 대체글을 제공
행위 패턴: 클래스나 객체들이 상호 작용하는 방법을 정의한 패턴
- Chain of Responsibility
- 요청 받는 객체를 연쇄적으로 묶어 요청처리하는 객체를 만날때까지 전달
- Command
- 요청을 객체의 행태로 캡슐화하여 재사용하거나 취소할 수 있도록 저장함
- Interpreter
- 특정 언어의 문법 표현을 정의
- Iterator
- 내부 노출 x, 원소를 순차적으로 접근할 수 있는 동일한 인터페이스 제공
- Mediator
- 한 집합에 속해있는 객체들의 상호작용을 캡슐화하여 새로운 객체로 정의
- Memento
- 다시 되돌아올 수 있도록 함
- Observer
- 변화를 통지받고 자동으로 갱신될 수 있게 함
- State
- 객체의 상태에 따라 동일한 동작을 다르게 처리해야 할 때 사용
- Strategy
- 알고리즘군을 정의하고 캡슐화하여 상호교환이 가능하도록 함
- Template Method
- 상위클래스는 알로리즘의 골격만 작성, 서브클래스가 구체적인 처리를 함
- Visitor
- 객체의 원소에 대해 수행할 연산을 분리하여 별도의 클래스로 구성
- SOLID중 OCP를 적용하는 방법
어플리케이션 테스트 케이스
결함 집중(Defect Clustering)의 법칙(파레토 법칙)
- 전체 결과의 80%가 전체 원인의 20%에서 일어나는 현상
살충제 패터독스(Preticide Paradox)
- 동일한 테스트 케이스로 반복 실행하면 결함을 발견할 수 없으므로 주기적으로 테스트 케이스를 리뷰하고 개선해야 한다
테스팅은 정황(Context)에 의존한다
- 정황과 비즈니스 도메인에 따라 테스트를 다르게 수행하여야 한다
오류-부재의 궤변(Absence of Errors Fallacy)
- 사용자의 요구사항을 만족하지 못하는 오류를 발견하고 그 오류를 제거하였다 해도, 해당 어플리케이션의 품질이 높다고 말할 수 없다
테스트 케이스
- 입력 값, 테스트 조건, 기대 결과로 구성
테스트 오라클
테스트의 결과가 참인지 거짓인지를 판단하기 위해서 사전에 정의된 참 값을 입력하여 테스트
테스트 오라클의 유형
- 참 오라클(True)
- 모든 테스트 케이스 입력값의 기대 결과를 확인
- 샘플링 오라클(Sampling)
- 특정한 몇 개의 입력 값에 대해서만 기대되는 결과를 제공해 주는 오라클
- 휴리스틱 오라클(Heuristic)
- 샘플링 오라클을 개선
- 특정 입력 값에 대해 올바른 결과를 제공, 나머지 값들에 대해서는 휴리스틱(추정)으로 처리하는 오라클
- 일관성 검사 오라클(Consistent)
- 애플리케이션 변경이 있을때, 수행 전ㄴ과 후의 결과 값이 동일한지 확인하는 오라클
테스트 레벨
구현 - 단위 테스트 - 통합 테스트 - 시스템 테스트 - 인수 테스트
블랙박스 테스트 기법
동등 분할 기법(Equivalence Partitioning Testing)
- 입력 자료에 초점을 맞춰 테스트 케이스를 만들어 검사하는 방법
경계값 분석(Boundary Value Analysis)
- 경계값에서 오류가 발생할 확률이 높으니 경계값 위주로 검사하는 방법
원인-효과 그래프 검사(Cause-Effect Graphing Testing)
- 입력 간의 관계와 출력에 영향을 미치는 상황을 체계적으로 분석 한 다음 효용성이 높은 테스트 케이스를 선정하여 검사하는 기법
오류 예측 검사(Error Guessing)
- 경험이 많은 테스터가 감각으로 테스트하는 기법
비교검사(Comparison Testing)
- 여러 버전의 프로그램에 동일한 테스트 자료를 제공하여 동일한 결과가 출력되는지 테스트하는 기법
애플리케이션 성능 개선
애플리케이션 성능 저하 원인
데이터베이스 관련 성능 저하
- 데이터베이스 락(DB Lock)
- 불필요한 패치(DB Fetch)
- 연결 누수(Connection Leak)
어플리케이션 성능 분석 지표
- 처리량(Throughput)
- 응답 시간(Response Time)
정형 기술 검토회의(FTR, Formal Technical Review)
- 소프트웨어 엔지니어가 수행하는 소프트웨어 품질보증 활동
- 공식적인 회의/활동
소스코드 품질 분석
- 동료 검토(Peer Review)
- 워크스루(Walk through)
- 인스펙션(Inspection)
- 계획-사전교육-준비-인스펙션 회의-수정-후속조치
정적 분석 도구
- PMD
- checkstyle
- SonarQube
- cppcheck
- ccm
- cobertura
동적 분석 도구
- Avalanche
- Valgrind
코드 스멜(Code Smell)
- 스파게티 코드(spaghetti code)
- 외계인 코드
리펙토링
- 외부동작을 바꾸지 않으면서 내부 구조를 개선하는 방법
- 이미 작성한 소스코드에서 기능의 변경없이, 가독성과 유지보수성을 높이기 위해 내부 구조를 변경하는 것
- 메서드 정리, 객체 간 기능 이동, 이름 변경, 추측성 일반화
9. 소프트웨어 유지보수
유지보수 관련 용어
- 레거시 시스템(Legacy System)
- 외계인 코드(Alien Code)
- 스파게티 코드(Spaghetti Code)
10. 제품 소프트웨어 패키징
국제 표준 제품 품질 특성
제품 품질 국제 표준
소프트웨어 품질 관련 국제 표준
- ISO/IEC 9126
- 기능성
- 신뢰성
- 사용성
- 효율성
- 유지보수성
- 이식성
- ISO/IEC 14598
- 반복성
- 재현성
- 동정성
- 객관성
- ISO/IEC 12119
- 제품 설명서
- 사용자 문서
- 실행 프로그램
- ISO/IEC 25000
국제 프로세스 품질 표준
- ISO/IEC 122207: 소프트웨어 개발 관련 생명주기
- 기본 생명주기 프로세스
- 지원 생명주기 프로세스
- 조직 생명주기 프로세스
- ISO/IEC 15504(SPICE): 소프트웨어 개발 관련해 선정된 프로세스 평가 모델
- SPICE 프로세스 능력 수준
- 0: 불안정 단계
- 1: 수행 단계
- 2: 관리 단계
- 3: 확립 단계
- 4: 예측 단계
- 5: 최적화 단계
- SPICE 프로세스 능력 수준
- CMM(Capability Maturity Model)
- 조직의 소프트웨어 개발 관련
- 미국 국방부의 의뢰를 받아 카네기멜론 대학이 만든 평가 모델
- 성숙도 5단계
- 초기 단계(Initial)
- 반복 단계(Repeatable)
- 정의 단계(Defined)
- 관리 단계(Managed)
- 최적화 단계(Optimizing)
- CMMI(Capability Maturity Model Integration)
- CMM을 개선시킨 모델
- 성숙도 5단계
- 초기 단계(Initial)
- 관리 단계(Managed)
- 정의 단계(Defined)
- 정량적 관리 단계(Quantatively Managed)
- 최적화 단계(Optimizing)
서비스 국제 표준
ISO/IEC 20000
- 고객에게 제공하는 IT서비스의 수준을 객관적으로 평가