[정보처리기사] 2. 소프트웨어 개발 방법론 - 1과목 소프트웨어 구축

[정보처리기사] 2. 소프트웨어 개발 방법론 - 1과목 소프트웨어 구축

 

소프트웨어 개발 방법론은 정처기 실기에서 큰 비중을 차지 하지는 않지만 그냥 지나치기에는 마음이 쓰이는 파트입니다.

 

전체적으로 계획-> 분석-> 설계 -> 구현 -> 테스트 -> 유지보수 순으로 이뤄짐을 기억하시고 보시면 좋습니다.

 

목차

소프트웨어 개발 방법론

구조적 방법론

구조적 방법론은 소프트웨어를 개발하기 위한 체계적이고 구조화된 방법론으로, 소프트웨어 개발 과정을 분석, 설계, 구현, 테스트 등의 단계로 분할하여 각각의 단계를 순차적으로 진행합니다. 이 방법론은 대규모 소프트웨어 프로젝트에 적합하며, 명세화된 요구사항을 기반으로 각 단계를 수행하여 최종적으로 완성된 제품을 얻습니다

• 절차지향적인 소트웨어 개발 방법론
• 제한된 구조 안에서 코드를 생성하고 순차적으로 실행
• 하향식 (에자일은 상향식)
• 절차지향언어
• 개발과정

요구사항 분석 -> 구조적 분석 -> 구조적 설계 -> 구조적 프로그래밍

구성요소

• 데이터흐름도(DFD): 데이터 흐름도는 시스템의 데이터 흐름을 도식화하여 시스템의 입력, 처리, 출력을 나타내는 다이어그램입니다.
  • 주로 데이터 흐름, 처리 과정, 데이터 저장소 등을 표현하여 시스템의 구조와 기능을 이해하고 설계하는 데 사용됩니다.
• 자료사전(DD): 자료사전은 시스템에서 사용되는 데이터의 구체적인 사항을 문서화한 것입니다.
  • 각 데이터의 이름, 형식, 크기, 의미, 출처, 사용 방법 등을 기술하여 데이터의 정의와 사용에 대한 명확한 이해를 돕습니다.
• 상태전이도(STD): 상태전이도는 시스템의 상태와 상태 간의 전이를 시각적으로 도식화한 것입니다.
  • 일반적으로 상태를 동그라미로, 전이를 화살표로 표현하여 시스템이 어떻게 동작하는지를 이해하고 설계하는 데 사용됩니다.
• 소단위 명세서(Minispec): 소단위 명세서는 개별 모듈이나 기능을 명세화한 문서입니다.
  • 각 모듈이나 기능의 목적, 입력, 출력, 동작, 제약 사항 등을 기술하여 모듈 간의 상호 작용과 기능을 명확히 정의합니다.
  • 소프트웨어 개발 과정에서 모듈의 구현 및 테스트를 위해 사용됩니다.

 

정보공학 방법론

정보공학 방법론은 정보 시스템을 개발하기 위한 체계적인 방법론으로, 비즈니스 프로세스를 분석하고 정보 요구 사항을 파악하여 정보 시스템을 개발합니다. 이 방법론은 비즈니스의 목표를 중심으로 정보 시스템을 구축하며, 데이터 모델링, 프로세스 모델링, 인터페이스 설계 등의 단계를 포함합니다.

• 기업 내에 많은 데이터를 전산화한 것, 데이터 중심의 접근 방법

개발과정

정보전략 계획 수립단계 -> 업무영역 분석 단계 -> 시스템 설계 단계 -> 시스템 구축 단계

• 정보전략 계획 수립 단계
  • 비즈니스의 전략과 목표를 고려하여 정보 시스템을 개발하기 위한 전략을 수립합니다.
  • 비즈니스 요구 사항을 이해하고, 정보 시스템이 어떻게 비즈니스 목표를 달성할지를 계획합니다.
• 업무영역 분석 단계
  • 비즈니스 프로세스와 업무 영역을 분석하여 정보 요구 사항을 도출합니다.
  • 비즈니스 프로세스의 흐름을 이해하고, 각 업무가 어떻게 데이터를 생성하고 사용하는지를 파악합니다.
• 시스템 설계 단계
  • 도출된 정보 요구 사항을 기반으로 시스템의 구조와 기능을 설계합니다.
  • 데이터 모델링, 프로세스 모델링, 인터페이스 설계 등을 포함하여 시스템의 구조를 정의하고 시스템이 요구하는 기능을 명세화합니다.
• 시스템 구축 단계
  • 설계된 시스템을 구현하고 테스트하여 완성시킵니다.
  • 프로그래밍, 데이터베이스 구축, 시스템 통합, 품질 보증 등의 활동이 이루어집니다.
  • 최종적으로 구축된 시스템은 사용자에게 전달되어 운영됩니다.

객체지향 개발 방법론

객체지향 개발 방법론은 객체지향 프로그래밍 개념을 기반으로 소프트웨어를 개발하는 방법론으로, 현실 세계의 객체들을 소프트웨어 객체로 모델링하여 개발합니다. 이 방법론은 상속, 캡슐화, 다형성 등의 개념을 활용하여 소프트웨어의 재사용성, 유지보수성, 확장성을 향상시킵니다.

• 상향식(구조적 방법론은 하향식)
• 현실 세계의 개체를 속성과 메서드 형태로 표현

객체지향 개발 방법론 특징

• 캡슐화 : 객체의 세부 구현을 숨기고 인터페이스만을 제공 (private)
• 정보은닉 : 객체 내부의 세부 사항을 외부로부터 숨김
• 상속 : 재사용과 확정성을 위해 상위클랙의 속성과 메서드를 하위 클래스가 상속받는 것
• 다형성
  • 오버로딩 : 메서드는 동일한데, 인자(파라미터)가 여러개인 것
  • 오버라이딩 : 메서드를 재정의하는 것
• 추상화 : 공통 성질을 하나로 묶는 것. 추상화란 보다 상위개념이 된다는 것으로 이해하면 좋음

CBD(Component Based Development)

CBD(Component Based Development)는 소프트웨어 개발 방법론 중 하나로, 소프트웨어를 구성 요소로 분리하고 이러한 구성 요소를 조합하여 시스템을 개발하는 방법을 강조합니다.

 

재사용가능한 컴포넌트를 조합해 애플리케이션 개발

새로운 기능을 개발하는 것이 아니라 기존의 기능들을 배치시키는 방법

CBD 특징

• 재사용성
  • 구성 요소를 재사용 가능한 단위로 분리함으로써 개발 생산성을 높이고 소프트웨어의 재사용성을 극대화합니다.
  • 개발자들은 이미 개발된 구성 요소를 활용하여 새로운 시스템을 구축할 수 있으므로 개발 시간과 비용을 절약할 수 있습니다.
• 모듈화
  • 소프트웨어를 독립적인 모듈 또는 구성 요소로 분해합니다.
  • 각각의 구성 요소는 특정한 기능을 수행하고, 각 모듈은 서로 관련된 기능을 갖습니다.
  • 모듈화된 구성 요소들은 개별적으로 테스트, 유지보수 및 업데이트가 가능합니다.
• 확장성
  • CBD는 시스템의 확장성을 용이하게 합니다.
  • 새로운 요구 사항이나 기능이 추가되면 해당 기능을 수행하는 새로운 구성 요소를 개발하고 기존의 구성 요소와 조합하여 시스템을 확장할 수 있습니다.
• 유지보수 용이성
  • 각 구성 요소는 독립적으로 테스트되고 관리될 수 있으므로 유지보수가 용이합니다.
  • 시스템의 특정 부분을 수정하거나 업그레이드할 때 전체 시스템에 영향을 미치지 않고 해당 부분만 수정할 수 있습니다.
• 표준화
  • CBD는 표준화된 인터페이스와 프로토콜을 사용하여 구성 요소 간의 상호 작용을 정의합니다.
  • 이를 통해 구성 요소들 간의 통합이 용이해지며, 다양한 플랫폼 및 환경에서의 상호 운용성을 보장할 수 있습니다.

에자일 방법론

에자일 방법론은 소프트웨어 개발 프로세스를 반복적이고 적응적으로 진행하는 방법론으로, 초기에 모든 요구사항을 상세히 정의하지 않고 반복적인 개발과정을 통해 요구사항을 점진적으로 발전시킵니다. 이 방법론은 고객의 피드백을 적극적으로 수용하여 빠르게 변화하는 비즈니스 환경에 적합하며, 개발자와 고객 간의 협력과 커뮤니케이션을 강조합니다.

 

* 방법론과 모델에서 모두 등장함, 하단에서 한번 더 설명됨

• 기본 원칙 : 변화에 빠르게 대응할 수 있어야함.
• 소프트웨어 개발의 민첩성과 효율성 강조 (문서보다 개발 자체가 핵심)

애자일 방법론의 종류

자세한 내용은 아래 소프트웨어 개발 모델 파트에서 이어집니다.

1. 익스트림 프로그래밍 (Extreme Programming, XP): 개발 과정에서 반복적인 작업과 테스트를 강조하며, 고객의 요구 사항 변화에 유연하게 대처할 수 있도록 합니다. 쌍프로그래밍, 테스트 주도 개발, 지속적인 통합 등의 방법을 사용하여 소프트웨어의 품질을 향상시킵니다.
2. 스크럼 (Scrum): 작은 팀이 일정한 시간 간격으로 일하는 스프린트를 통해 소프트웨어를 개발하는 방법론입니다. 스크럼 팀은 매일 짧은 회의를 통해 작업의 진행 상황을 공유하고 문제를 해결합니다. 제품 백로그, 스프린트 백로그, 스크럼 마스터 등의 개념을 중심으로 진행됩니다.
3. 칸반 (Kanban): 작업을 시각적으로 관리하는 방법으로, 작업을 칸반 보드의 칸에 할당하여 작업의 진행 상황을 추적하고, 작업량을 제어합니다. 칸반은 지속적인 흐름을 강조하며, 우선순위에 따라 작업을 처리합니다.

소프트웨어 개발 모델

앞에서 설명한 개발 방법론에 각각 적용될만한 모델들이 있습니다. 둘을 별도로 생각하셔도 좋고, 같이 묶어서 생각하셔도 좋습니다.

 

이 번 시간에는 보다 구체적인 소프트웨어 생명주기에 대한 모델들을 설명하고자 합니다. 폭포수, 프로토타이핑, 나선형, 에자일은 자주 출제됩니다. 에자일 기법에 대한 내용은 흟더라도 보고 지나가시길 바랍니다.

 

폭포수 모델

한 때 자주 나온 문제, 정처기 필기에서는 자주 출제되었지만 이제는 잘 안나옴.

계획->분석->설계 ->구현 ->테스트 ->운영 전과정을 순차적으로 접근하는 개발 모델

• 선형적으로 진행됨
• 단계별 정의가 분명함.
• 아주 오래된 개발 방법론
• 역방향 진행 불가

프로토타이핑 모델

주요 기능을 프로토타입(원형)으로 구현하여 클라이언트가 한번 확인해보고 수정사항이 있으면 수정하여 다시 만들어보는 과정.

프로토타입이 컨펌되면 실제 개발로 구현한다.

 

계획->프로토타입개발-> 사용자 평가 -> 구현 -> 인수

1. 프로토타이핑 모델 계획 (Planning the Prototype Model)
   • 이 단계에서는 프로젝트의 목표와 요구 사항을 정의하고, 프로토타입 모델을 만들기 위한 전략을 수립합니다.
   • 필요한 리소스(인력, 장비, 도구 등)를 결정하고 일정을 계획합니다.
   • 프로젝트의 범위와 기대되는 결과물을 명확하게 이해해야 합니다.
2. 프로토타입 개발 (Prototype Development)
   • 이 단계에서는 프로토타입 모델을 만듭니다. 보통 이 모델은 실제 제품 또는 서비스의 기본 기능을 시연하는 데 사용됩니다.
   • 프로토타입은 고객이나 이해관계자와 소통하고 피드백을 받기 위한 목적으로 사용될 수 있습니다.
   • 프로토타입은 보통 최소한의 기능만을 구현하여 빠르게 개발되며, 주로 시각적인 프로토타입 또는 기능적인 프로토타입으로 나뉩니다.
3. 사용자 평가 (User Evaluation)
   • 프로토타입을 대상으로 사용자 테스트 또는 사용자 평가를 수행합니다.
   • 이 단계에서는 사용자들의 피드백을 수집하고, 프로토타입의 장단점을 확인하여 개선점을 찾습니다.
   • 사용자 평가를 통해 실제 사용자들의 요구 사항과 의견을 반영하여 프로토타입을 보다 완성도 있게 만들 수 있습니다.
4. 구현 (Implementation)
   • 사용자 평가를 토대로 프로토타입을 개선하고, 최종 제품 또는 서비스를 구현합니다.
   • 이 과정에서는 프로토타입의 기능을 확장하거나 보완하여 완성된 제품을 만듭니다.
5. 인수 (Acceptance):
   • 프로젝트가 완료되면, 최종 제품 또는 서비스를 고객 또는 이해관계자에게 전달하고 인수합니다.
   • 이 단계에서는 제품이나 서비스가 목표를 달성하고 요구 사항을 충족하는지 확인합니다.

장점

1. 요구사항 변경 용이성: 프로토타이핑은 초기 단계에서 요구 사항을 시험하고 수정하는 데 용이합니다. 이는 제품이나 서비스의 요구 사항이 변경되는 상황에서 유용하며, 새로운 아이디어를 쉽게 테스트할 수 있도록 합니다.
2. 사용자 피드백 수용: 프로토타입을 사용하여 사용자의 의견과 피드백을 빠르게 수용할 수 있습니다. 이를 통해 제품이나 서비스를 개선하고 사용자 경험을 향상시킬 수 있습니다.
3. 시간과 비용 절감: 초기에 프로토타입을 개발하고 테스트함으로써 제품이나 서비스에 대한 불필요한 변경을 줄일 수 있습니다. 이는 프로젝트 전반적인 시간과 비용을 절감할 수 있도록 도와줍니다.

단점

1. 문서화 과정 소홀: 프로토타이핑은 보다 빠르게 개발하고 피드백을 받기 위해 주로 시간을 줄이는 경향이 있습니다. 이로 인해 프로세스 및 요구 사항 문서화가 소홀해질 수 있으며, 나중에 프로젝트 관리 및 유지보수를 어렵게 만들 수 있습니다.
2. 프로토타입의 한계: 프로토타입은 보통 제한된 기능과 성능을 가지고 있기 때문에 최종 제품 또는 서비스의 모든 측면을 반영하지 못할 수 있습니다. 이는 프로토타입을 실제 제품이나 서비스로 확장할 때 추가적인 개발이 필요하다는 것을 의미합니다.

나선형 모델

위험을 관리하고 최소화하는 것이 목적인 나선형 모델은 대규모의 소프트웨어 개발 프로젝트에 유용합니다. 이 모델은 전통적인 선형적인 접근 방식보다 유연성이 높으며, 초기에 위험을 식별하고 관리함으로써 프로젝트의 성공 확률을 향상시킵니다.

• 위험을 관리하고 최소하하는 것
• 큰 규모의 개발에 유리함
• 점진적 개발

계획 및 요구분석 -> 위험분석 -> 개발 -> 평가

RAD(Rapid Application Development)

매우 빠른 개발 주기를 통해 소프트웨어를 신속하게 제공

CASE 도구를 활용하여 효유성을 높인다.

상위 CASE :  분석과 설계 단계를 포함합니다. 요구 사항을 수집하고 분석하며, 이를 바탕으로 소프트웨어의 설계를 수행합니다. - 드라이버

하위 CASE : 구현, 테스트, 문서화 단계를 포함합니다. 설계된 소프트웨어를 실제로 구현하고, 테스트하여 품질을 보증하며, 관련 문서를 작성합니다. - 스텁

통합 : 위 상향, 하향을 다 쓰는 것

• 프로토타이핑을 중요시함
• 매우 큰 규모에는 적합하지 않음

V모형

개발의 각 단계에서 검증과 테스트를 중점적으로 진행한다.

높은 신뢰성을 요구하는 시스템 개발에 유용

반응형

• 단위 테스트 (모듈, 단정동)
  • 정적 테스트: 소프트웨어를 실행하지 않고 코드를 검토하고 분석하여 오류를 찾는 테스트입니다.
    • 소스코드 내부
  • 동적 테스트: 코드를 실행하여 기능적인 오류를 찾고, 예상된 결과와 실제 결과를 비교하여 확인하는 테스트입니다.
    • 소프트웨어 기능
• 통합(아키텍처, 통상하빅)
  • 상향식 통합 테스트
    • 밑에서부터 클러스트 단위로 말아 올리는 방법
    • 작은 모듈을 결합하여 시스템으로 테스트하는 방법으로, 드라이버를 사용하여 테스트를 진행합니다.
  • 하향식 통합 테스트
    • 위에서 아래로 메인부터 확인하는 것
    • 큰 모듈을 작은 모듈로부터 테스트하는 방법으로, 스텁을 사용하여 테스트를 진행합니다.
  • 빅뱅데스트
    • 이 방법은 모든 모듈을 개발한 후에 한 번에 모든 모듈을 통합하여 전체 시스템을 테스트하는 방식
    • 개발이 완료된 모든 모듈을 한꺼번에 통합하기 때문에, 통합 테스트의 과정이 단축
    • 하지만 모든 모듈을 동시에 테스트하기 때문에 문제가 발생했을 때 디버깅이 어려움
• 시스템(요구분석, 시기비)
  • 기능 테스트: 소프트웨어의 기능이 요구 사항을 충족하는지 검증하는 테스트로, 품질과 보안 등을 평가합니다.
  • 비기능 테스트: 소프트웨어의 성능, 안정성, 효율성 등의 비기능적인 측면을 평가하는 테스트입니다.
• 인수
  • 알파 테스트: 개발자와 사용자가 함께하는 테스트로, 사용자의 피드백을 받아 소프트웨어를 개선합니다.
  • 베타 테스트: 실제 사용자가 소프트웨어를 테스트하는 테스트로, 사용자가 혼자 테스트를 진행합니다. 

4세대 기법

4GL와 같은 고급 프로그래밍 언어와 도구 사용

예를 들면 chatGPT한테 기능을 말하고 생성하게 해서 개발하는 것

애자일 방법론

• 애자일 개발 방법론이란 어느 특정 개발 방법론을 가르키는 말이 아니며, 애자일 개발을 가능하게 해주는 다양한 방법론을 다양한 방법론의 전체를 말함.
• 신속하고 반복적인 작업을 통해 지속적으로 작동 간으한 소프트웨어를 개발하는 방식
• 작은 구성요소를 빠르게 제공하고, 애자일 개잘을 가능하게 하는 다양한 방법론의 집합
• 경량(Lightweight) 프로세스라고도 불림

애자일 방법론의 종류

XP

5가지  핵심가치

암기 방법 : 의사선생님 약은 피존 용기에 담아주세요

반복적이고 점진적인 개발을 강조

1. 의사소통 (Communication): 팀 내부 및 외부의 의사소통을 강조합니다. 팀원 간의 원활한 소통은 문제 해결과 협업을 향상시키는 데 중요합니다.
2. 피드백 (Feedback): 빠른 피드백을 통해 개선과 조정을 촉진합니다. 피드백은 소프트웨어의 품질을 향상시키고 사용자 요구 사항을 충족시키는 데 도움이 됩니다.
3. 존중 (Respect): 모든 팀원과 이해관계자를 존중하고 존중받는 환경을 조성합니다. 이는 팀의 동료애와 협력을 증진시키며 팀의 성과를 향상시킵니다.
4. 용기 (Courage): 변경에 대한 용기를 갖고 실패를 받아들이고 개선을 위한 도전을 두려워하지 않습니다. 용기를 갖고 새로운 아이디어를 제시하고 실험함으로써 혁신을 이끌어냅니다.
5. 단순성 (Simplicity): 최대한 단순하고 직관적인 솔루션을 추구합니다. 복잡성을 최소화하여 개발과 유지보수를 용이하게 만듭니다.

12가지 실천사항(짝게테고, 지코작코, 공간시작)

1. 짝프로그래밍(pair Programing) : 두 동료가 같이 개발
2. 계획세우기(Planning Game) : 요구사항 우선순위 중심
3. 테스트기반 개발(Test Driven Development) : 선 다위 테스트 후 실제 코드 통합
4. 고객상주(Whole Team) : 고객하고 같이 이야기하면서 개발
5. 지속적인통합(Continuous Interation) : 매일 여러번 형상관리
6. 코드 개선(Design Improvement) : 코드를 개선하면서 기능을 변경하지 않고 코드를 정리
   1. 동료 검토  : 동료가 검토해주는 것
   2. 워크쓰루 : 팀단위 회의
   3. 인스펜셕 : 공식 회의
7. 작은 릴리즈(Small Release) : 짧은 주기로 소프트웨어 출시
8. 코딩표준(Coding Standard) : 표준화된 코드 사용 
9. 공동소유코드(Collective Code Ownership) : 코드베이스를 팀 구성원 모두 공유
10. 간단한 디자인(Simple Design) : 아키텍처를 간단하게
11. 시스템 메타포어(System Metaphor) : 최종적으로 개발할 프로그래밍을 목표로 개발 진행.
12. 작업시간 준수(Sustainable Pace) : 주 40시간 금지

SCRUM

서프트웨어에 포함될 기능, 개선점에 대한 우선순위를 부여

개발 주기는 30일 정도로 조절하고 개발 주기마다 실제 동작할 수 있는 결과를 제공

개발 주기마다 적용할 기능이나 개선에 대한 목록 작성

항상 팀 단위로 생각하고, 매일 15분 정도의 회의

스크럼 주요 개념

개념명	영문	설명
제품백로그	Product Backlog	제품의 요구사항, 기능, 작업 항목들을 우선순위에 따라 정리한 목록
스프린트(기간)	Sprint	고객 요구사항을 만족시키기 위해 고객 요구사항의 일부를 개발하는 기간
스프린트 계획 회의	Sprint Planning Meeting	스프린트 동안 수행될 작업을 선택하고 계획을 수립하는 회의
스프린트 백로그	Sprint Backlog	스프린트에서 수행될 작업 목록, 제품백로그에서 우선순위에 따라 선정
일일 스크럼 회의	Daily Scrum Meeting	팀원들이 하루의 작업을 검토하고 스스로를 조율하는 짧은 회의
제품 책임자	Product Owner	제품의 비즈니스 가치와 우선순위를 정의하고 제품의 진행을 감독
스크럼 마스터	Scrum Master	스크럼 프로세스를 이해하고 팀이 잘 동작하도록 돕는 역할을 수행

 

FDD(Freature-Driven Development)

Feature 중심 개발: FDD는 각각의 기능(feature)을 중심으로 개발을 진행합니다. 각 기능은 완전히 개발되고 테스트된 상태로 제공됩니다.

2주 주기의 반복 개발: 일반적으로 각 기능을 개발하는데 약 2주 정도의 시간을 할당하고, 이후 다음 기능으로 넘어가는 형태의 짧은 개발 주기를 갖습니다

Crystal

Crystal은 애자일 방법론 중 하나로, 프로젝트의 규모와 영향의 크기에 따라 여러 가지 종류의 방법론을 제공

Crystal 방법론은 프로젝트의 특성과 요구 사항에 따라 조정될 수 있으며, 여러 가지 크기와 복잡성의 프로젝트를 지원하기 위한 다양한 방법론이 제공됩니다. 이를 통해 팀은 프로젝트에 가장 적합한 방법론을 선택하고 적용할 수 있습니다.

ASD(Adaptive Software Development)

합동 애플리케이션 개발을 사용하는 방법론

소프트웨어 개발을 혼란 자체로 규정하고, 혼란을 전제로 그에 적응할 수 있는 소프트웨어 방법을 제시하기 위해 만들어진 방법론

Lean

Lean은 기업에서 낭비를 최소화하고 가치를 극대화하기 위한 철학이자 방법론입니다.

소프트웨어 개발 분야에서는 Lean의 핵심 원칙을 도입하여 소프트웨어 개발 프로세스를 최적화하고 품질을 향상시키는 데 활용할 수 있습니다.

• 도요타 린 시스템 품질기법을 소프트웨어 개발 프로세스에 적용해서 낭비 요소를 제거하여 품질을 향상시킴

IT 서비스 관리

문서 - 관리방법이 짝을 이룹니다. SLM-SLM / ITIL-ITSM

SLM(Service Level Management)

SLM(Service Level Management)은 서비스 수준을 정량적으로 측정하고 평가하여, 서비스의 미흡한 부분을 식별하고 개선하는 관리 활동을 의미합니다. 이는 실질적인 관리 활동으로, 서비스 제공자가 고객에게 제공하는 서비스의 품질과 성능을 보장하기 위해 중요한 역할을 합니다.

• 서비스 수준 정량적으로 측정하고, 실적을 평가하여 미흡한 부분을 개선하는 관리 활동
• 실질적인 관리 활동

SLA(Service Level Agreement)

소프트웨어 수요자와 공급자간의 서비스 수준에 대한 문서

이 문서로  SLM을 진행

• 업무 목표/범위: 서비스의 목표와 범위를 명확히 정의합니다.
• 성과지표: 서비스 수준을 측정하기 위한 지표를 정의합니다. 이는 예를 들어 가용성, 응답 시간 등과 같은 지표를 포함할 수 있습니다.
• 조정절차: 서비스 수준이 준수되지 않을 때의 조치 및 조정 절차를 명시합니다.

ITSM(Information Technology Service Management)

최종 사용자를 위한 IT 서비스를 구현, 전달, 관리하는 일련의 정책과 관행을 나타냅니다. 이는 IT 서비스 제공자가 고객에게 최상의 서비스를 제공하기 위해 필요한 프로세스와 절차를 포함합니다.

ITIL(IT Infrastructure Libary)

IT 서비스를 쉽게 제공하고 관리할 수 있는 가이드 또는 프레임워크입니다. 이는 모범 사례와 표준 절차를 제공하여 ITSM을 효율적으로 관리하고 운영할 수 있도록 도와줍니다.

ITIL은 서비스 전반에 걸쳐 SLA 및 SLM을 포함한 다양한 측면을 다루며, 효과적인 IT 서비스 관리를 지원합니다.

• IT서비스를 쉽게 제공하고 관리할 수 있는 가이드 또는 프레임워크
• 모범사례를 포함하여 IT 서비스 제공 지원