정보처리기사 실기 1

요구사항 확인 1

• 소프트웨어 생명 주기

  • 소프트웨어를 개발하기 위한 설계, 운용, 유지보수 등의 과정을 각 단계 별로 나눈 것

• 나선형 모형

  • 여러 번의 소프트웨어 개발 과정을 거쳐 점진적으로 완벽한 최종 소프트웨어를 개발하는 모형
  • 4가지 주요 활동 계획 수립 -> 위험 분석 -> 개발 및 검증 -> 고객 평가

• 폭포수 모형

  • 각 단계를 확실히 매듭짓고 그 결과를 철저하게 검토하여 승인 과정을 거친 후에 다음 단계를 진행하는 개발 방법론
  • 고전적 생명 주기 모형

• 프로토타입 모형

  • 실제 개발될 소프트웨어에 대한 견본품을 만들어 최종 결과물을 예측하는 모형

• 애자일 모형

  • 고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하면서 개발하는 모형
  • 대표적인 개발 모형
  • 스크럼, XP, 칸반, Lean, 기능 중심 개발(FDD)

• 애자일 개발 4가지 핵심 가치

  • 개인과 상호작용, 실행되는 SW, 고객과 협업, 변화에 반응하는 것

• 소프트웨어 공학

  • 소프트웨어의 위기를 극복하게 위한 방안으로 연구된 학문
  • 소프트웨어 공학의 기본 원칙
  • 현대적 프로그래밍 기술 계속적 적용,
  • 개발된 소프트웨어 품질 유지를 위한 지속적인 검증,
  • 개발 관련 사항 및 결과에 대한명확한 기록 유지

• 스크럼

  • 팀이 중심이 되어 개발의 효율성을 높이는 기법
  • 스크럼 팀의 구성원 및 역할
  • 재품 책임자(PO) - 요구사항이 담긴 제품 백로그를 작성함
  • 스크럼 마스터(SM) - 스크럼 팀의 가이드 역할을 수행함
  • 개발팀(DT) - 제품 책임자 및 스크럼 마스터를 제외한 팀원, 제품 개발을 수행함

• 스크럼 개발 프로세스

  • 스프린트 계획 회의 -> 스프린트 -> 일일 스크럼 회의 -> 스프린트 검토 회의 -> 스프린트 회고

• XP

  • 고객의 요구사항에 유연하게 대응하기 위해 고객의 참여와 개발 과정의 반복을 극대화하여 개발 생산성을 향상시키는 방법
  • XP의 5가지 핵심 가치
  • 의사소통 - 단순성 - 용기 - 존중 - 피드백

• XP의 주요 실천 방법

  • 짝 프로그래밍 - 다른 사람과 함께 프로그래밍을 수행, 개발 책임을 공동으로 나눠 갖음
  • 공동 코드 소유 - 개발 코드에 대한 권한과 책임을 공동으로 소유
  • 테스트 주도 개발 - 실제 코드 작성전 테스트 케이스를 먼저 작성
  • 전체 팀 - 개발에 참여하는 모든 구성원들이 각자 자신의 역할과 책임을 가짐
  • 계속적인 통합 - 모듈 단위로 나눠서 개발된 코드들을 지속적으로 통합
  • 리팩토링 - 프로그램 기능의 변경 없이 시스템을 재구성
  • 소규모 릴리즈 - 릴리즈 기간을 짧게 반복함

• 데이터베이스 관리 시스템

  • 사용자와 데이터베이스 사이에서 사용자의 요구에 따라 정보를 생성해 주고, 데이터베이스를 관리해 주는 소프트웨어
  • DBMS 관련 요구사항 식별 시 고려사항
  • 가용성, 성능, 기술 지원, 상호 호환성, 구축 비용

• 웹 애플리케이션 서버

  • 사용자의 요구에 따라 변하는 동적인 콘텐츠를 처리하기 위해 사용되는 미들웨어
  • 웹 애플리케이션 서버 관련 요구사항 식별 시 고려사항
  • 가용성, 성능, 기술 지원, 구축 비용

• 오픈 소스

  • 제한 없이 사용할 수 있도록 소스 코드를 공개한 소프트웨어
  • 오픈 소스 관련 요구사항 식별 시 고려사항
  • 라이선스의 종류, 사용자 수, 기술의 지속 가능성

• 요구사항

  • 소프트웨어가 어떤 문제를 해결하기 위해 제공하는

• 기능 요구사항

  • 시스템이 무엇을 하는지, 어떤 기능을 하는지 등의 기능이나 수행과 관련된 요구사항

• 비기능 요구사항

  • 품질이나 제약사항과 관련된 요구사항
  • 품질 요구사항
  • 가용성, 정합성, 상호 호환성, 대응성, 이식성, 확장성, 보안성 등

• 요구사항 개발 프로세스

  • 개발 대상에 대한 요구사항을 체계적으로 도출하고 분석한 후 명세서에 정리한 다음 확인 및 검증하는 일련의 구조화된 활동
  • 도출 -> 분석 -> 명세 -> 확인

• 요구사항 명세

  • 분석된 요구사항을 바탕으로 모델을 작성하고 문서화하는 것

• 요구사항 명세 기법

  • 정형 명세 기법
  • 기법 - 수학적 원리 기반, 모델 기반
  • 작성 방법 - 수학적 기호, 정형화된 표기법
  • 특징 - 요구사항을 정확하고 간결하게 표현, 표기법이 어려워 사용자가 이해하기 어려움
  • 종류 - VDM, Z, Petri-net, CSP 등
  • 비정형 명세 기법
  • 기법 - 상태/기능/객체 중심
  • 작성 방법 - 일반 명사, 동사 등의 자연어를 기반으로 서술 또는 다이어그램 작성
  • 특징 - 내용의 이해가 쉬워 의사소통이 용이함
  • 종류 - FSM, Decision Table, ER모델링, State Chart(SADT) 등

• 자료 흐름도

  • 요구사항 분석에서 자료의 흐름 및 변환 과정과 기능을 도형 중심으로 기술하는 방법
  • 자료 흐름 그래프, 버블 차트

• 자료 흐름도의 구성 요소

  • 프로세스 - 자료를 변환 시키는 시스템의 한 부분
  • 자료 흐름 - 자료의 이동이나 연관 관계를 나타냄
  • 자료 저장소 - 시스템에서의 자료 저장소를 나타냄
  • 단말 - 시스템과 교신하는 외부 개체, 입력데이터가 만들어지고 출력데이터를 받음

• 자료 사전

  • 자료 흐름도에 있는 자료를 더 자세히 정의하고 기록한 것
  • = 자료의 정의, + 자료의 연결, () 자료의 생략, [] 자료의 선택, {} 자료의 반복, * * 자료의 설명

• 요구사항 분석용 CASE

  • 요구사항을 자동으로 분석하고, 요구사항 분석 명세서를 기술하도록 개발된 도구
  • 대표적인 요구사항 분석용 CASE
  • SADT, SREM(=RSL/REVS), PSL/PSA, TAGS

• SADT

  • 시스템 정의, 소프트웨어 요구사항 분석, 시스템/소프트웨어 설계를 위한 도구

• HIPO

  • 시스템의 분석 및 설계, 또는 문서화에 사용되는 기법, 시스템 실행 과정인 입력 . 처리 . 출력의 기능을 표현한 것

• UML

  • 시스템 개발 과정에서 의사소통이 원활하게 이루어지도록 표준화한 대표적인 객체지향 모델링 언어
  • UML의 구성 요소
  • 사물, 관계, 다이어그램

• 관계

  • 사물과 사물 사이의 연관성을 표현하는 것
  • 관계의 종류
  • 연관 관계, 집합 관계, 포함 관계, 일반화 관계, 의존 관계, 실체화 관계

• 연관 관계

  • 2개 이상의 사물이 서로 관련되어 있는 관계
  • 실선 화살표

• 집합 관계

  • 하나의 사물이 다른 사물에 포함되어 있는 관계
  • 실선 속이 빈 마름모

• 포함 관계

  • 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계
  • 실선 속이 채워진 마름모

• 일반화 관계

  • 하나의 사물이 다른 사물에 비해 더 일반적이거나 구체적인 관계
  • 실선 속이 빈 화살표, 하위 여러개에서 상위 한개 쪽으로

• 의존 관계

  • 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계
  • 점선 화살표

• 실체화 관계

  • 사물이 할 수 있거나 해야하는 기능으로, 서로를 그룹화 할 수 있는 관계
  • 점선 속이 빈 화살표, 하위 여러개에서 상위 한개 쪽으로

• 다이어그램

  • 사물과 관계를 도형으로 표현한 것
  • 정적 모델링 - 구조적 다이어그램
  • 동적 모델링 - 행위 다이어그램

• 구조적 다이어그램의 종류

  • 클래스 다이어그램 - 클래스와 클래스가 가지는 속성, 클래스 사이의 관계를 표현
  • 객체 다이어그램 - 클래스에 속한 사물들, 즉 인스턴스를 특정 시점의 객체와 객체 사이의 관계로 표현
  • 컴포넌트 다이어그램 - 실제 구현 모듈인 컴포넌트 간의 관계나 컴포넌트 간의 인터페이스를 표현
  • 배치 다이어그램 - 결과물, 프로세스, 컴포넌트 등 물리적 요소들의 위치를 표현
  • 복합체 구조 다이어그램 - 클래스나 컴포넌트가 복합 구조를 갖는 경우 그 내부 구조를 표현
  • 패키지 다이어그램 - 유스케이스나 클래스 등의 모델 요소들을 그룹화한 패키지들의 관계를 표현

• 행위 다이어그램의 종류

  • 유스케이스 다이어그램 - 사용자의 요구를 분석하는 것, 기능 모델링 작업에 사용
  • 시퀀스 다이어그램 - 상호작용 시스템이나 객체들이 주고받는 메시지를 표현
  • 커뮤니케이션 다이어그램 - 동작에 참여하는 객체들이 주고받는 메시지와 객체들 간의 연관 관계를 표현
  • 상태 다이어그램 - 하나의 객체가 자신이 속한 클래스의 상태 변화 혹은 다른 객체와의 상호작용에 따라 상태가 어떻게 변화하는지를 표현
  • 활동 다이어그램 - 시스템이 어떤 기능을 수행하는지 객체의 처리 로직이나 조건에 따른 처리의 흐름을 순서에 따라 표현
  • 상호작용 개요 다이어그램 - 상호작용 다이어그램 간의 제어 흐름을 표현
  • 타이밍 다이어그램 - 객체 상태 변화와 시간 제약을 명시적으로 표현

• 스테레오 타입

  • UML에서 표현하는 기본 기능 외에 추가적인 기능을 표현하는 것 겹화살괄호 « »

요구사항 확인 2

• 유스케이스 다이어그램

  • 사용자와 다른 외부 시스템들이 개발될 시스템을 이용해 수행할 수 있는 기능을 사용자의 관점에서 표현한 것
  • 유스케이스 다이어그램의 구성요소
  • 시스템 / 시스템 범위 - 시스템 내부의 유스케이스들을 사각형으로 묶어 시스템의 범위를 표현한 것
  • 액터 - 시스템과 상호작용을 하는 모든 외부 요소
  • 주액터 - 시스템을 사용함으로써 이득을 얻는 대상, 주로 사람
  • 부액터 - 주액터의 목적 달성을 위해 시스템에 서비스를 제공하는 외부 시스템, 조직이나 기관 등
  • 유스케이스 - 사용자가 보는 관점에서 시스템이 액터에게 제공하는 서비스나 기능을 표현한 것
  • 관계 - 유스케이스에서 나타날 수 있는 관계 - 포함 관계, 확장 관계, 일반화 관계

• 유스케이스에서 나타날 수 있는 관계

  • 포함 관계 - 두 개 이상의 유스케이스에 공통적으로 적용되는 기능을 별도로 분리하여 새로운 유스케이스로 만든 경우, 원래의 유스케이스와 새롭게 분리된 유스케이스와의 관계
  • 점선 화살표, «include»
  • 확장 관계 - 유스케이스가 특정 조건에 부합되어 유스케이스의 기능이 확장될 때 원래의 유스케이스와 확장된 유스케이스와의 관계
  • 점선 화살표, «extends»

• 활동 다이어그램

  • 사용자의 관점에서 시스템이 수행하는 기능을 처리 흐름에 따라 순서대로 표현한 것
  • 활동 다이어그램의 구성 요소
  • 액션 / 액티비티 - 액션 - 더이상 분해할 수 없는 단일 작업, 액티비티 - 몇 개의 액션으로 분리될 수 있는 작업
  • 시작 노드 - 액션이나 액티비티가 시작됨을 표현한 것
  • 종료 노드 - 액티비티 안의 모든 흐름이 종료됨을 표현한 것
  • 조건 노드 - 조건에 따라 제어의 흐름이 분리됨을 표현한 것
  • 병합 노드 - 여러 경로의 흐름이 하나로 합쳐짐을 표현한 것
  • 포크 노드 - 액티비티의 흐름이 분리되어 수행됨을 표현한 것
  • 조인 노드 - 분리되어 수행되던 액티비티의 흐름이 다시 합쳐짐을 표현한 것
  • 스윔레인 - 액티비티 수행을 담당하는 주체를 구분하는 선

• 클래스 다이어그램

  • 클래스와 클래스가 가지는 속성, 클래스 사이의 관계를 표현한 것
  • 클래스 다이어그램의 구성 요소
  • 클래스 - 각각의 객체들이 갖는 속성과 오퍼레이션을 표현한 것
    • 속성 - 클래스의 상태나 정보를 표현
    • 오퍼레이션 - 클래스가 수행할 수 있는 동작, 함수(메소드)라고도 함
  • 제약조건 - 속성에 입력될 값에 대한 제약조건, 오퍼레이션 수행 전후에 지정해야할 조건 기술
  • 관계 - 클래스와 클래스 사이의 연관성을 표현
  • 연관 관계, 집합 관계, 포함 관계, 일반화 관계, 의존 관계

• 연관 클래스

  • 연관 관계에 있는 두 클래스에 추가적으로 표현해야 할 속성이나 오퍼레이션이 있는 경우 생성하는 클래스

• 시퀀스 다이어그램

  • 시스템이나 객체들이 메시지를 주고받으며 상호작용하는 과정을 그림으로 표현한 것
  • 시퀀스 다이어그램의 구성 요소
  • 액터 - 시스템으로 부터 서비스를 요청하는 외부 요소, 사람이나 외부 시스템을 의미
  • 객체 - 메시지를 주고받는 주체
  • 생명선 - 객체가 메모리에 존재하는 기간
  • 실행 상자 - 객체가 메시지를 주고받으며 구동되고 있음을 표현
  • 메시지 - 객체가 상호 작용을 위해 주고받는 메시지
  • 객체 소멸 - 해당 객체가 더 이상 메모리에 존재하지 않음을 표현한 것
  • 프레임 - 다이어그램의 전체 또는 일부를 묶어 표현한 것

• 커뮤니케이션 다이어그램

  • 시스템이나 객체들이 메시지를 주고 받으며 상호작용하는 과정과 객체들 간의 연관을 그림으로 표현한 것
  • 커뮤니케이션 다이어그램의 구성 요소
  • 액터 - 시스템으로부터 서비스를 요청하는 외부 요소로, 사람이나 외부 시스템을 의미함
  • 객체 - 메시지를 주고받는 주체
  • 링크 - 객체들 간의 관계를 표현한 것
  • 메시지 - 객체가 상호 작용을 위해 주고받는 내용

• 상태 다이어그램

  • 객체들 사이에 발생하는 이벤트에 의한 객체들의 상태 변화를 그림으로 표현한 것
  • 상태 - 객체의 상태를 표현한 것
  • 시작 상태 - 상태의 시작을 표현한 것
  • 종료 상태 - 상태의 종료를 표현한 것
  • 상태 전환 - 상태 사이의 흐름, 변화를 화살표로 표현한 것
  • 이벤트 - 상태에 변화를 주는 현상
  • 프레임 - 상태 다이어그램의 범위를 표현한 것

• 패키지 다이어그램

  • 유스케이스나 클래스 등의 요소들을 그룹화한 패키지 간의 의존 관계를 표현한 것
  • 패키지 다이어그램 구성 요소
  • 패키지 - 객체들을 그룹화한 것
    • 단순 표기법 - 패키지 안에 패키지 이름만 표현
    • 확장 표기법 - 패키지 안에 요소까지 표현
  • 객체 - 유스케이스 클래스, 인터페이스, 테이블 등 패키지에 포함될 수 있는 다양한 요소들
  • 의존 관계 - 점선 화살표
    • «import» - 패키지에 포함된 객체들을 직접 가져와서 이용하는 관계
    • «access» - 인터페이스를 통해 패키지 내의 객체에 접근하여 이용하는 관계

• 구조적 방법론

  • 정형화된 분석 절차에 따라 사용자 요구사항을 파악하여 문서화하는 처리 중심의 방법론
  • 구조적 방법론의 개발 절차
  • 타당성 검토 단계 -> 계획 단계 -> 요구사항 단계 -> 설계 단계 -> 구현 단계 -> 시험 단계 -> 운용/유지보수 단계

• 객체지향 방법론

  • 객체들을 조립해서 필요한 소프트웨어를 구현하는 방법론
  • 객체지향 방법론의 개발 절차
  • 요구 분석 단계 -> 설계 단계 -> 구현 단계 -> 테스트 및 검증 단계 -> 인도 단계

• 컴포넌트 기반 방법론

  • 기존의 시스템이나 소프트웨어를 구성하는 컴포넌트를 조합하여 하나의 새로운 애플리케이션을 만드는 방법론
  • 컴포넌트 기반 방법론의 개발 절차
  • 개발 준비 단계 -> 분석 단계 -> 설계 단계 -> 구현 단계 -> 테스트 단계 -> 전개 단계 -> 인도 단계

• 소프트웨어 재사용

  • 이미 개발되어 인정받은 소프트웨어를 다른 소프트웨어 개발이나 유지에 사용하는 것
  • 소프트웨어 재사용 방법
  • 합성 중심 - 전자 칩과 같은 소프트웨어 부품, 즉 블록을 만들어서 끼워 맞춰 소프트웨어를 완성시키는 방법, 블록 구성 방법
  • 생성 중심 - 추상화 형태로 써진 명세를 구체화하여 프로그램을 만드는 방법, 패턴 구성 방법

• 소프트웨어 재공학

  • 기존 시스템을 이용하여 보다 나은 시스템을 구축하고, 새로운 기능을 추가하여 소프트웨어 성능을 향상시키는 것

• CASE

  • 소프트웨어 개발 과정에서 사용되는 요구 분석, 설계, 구현, 검사 및 디버깅 과정 전체 또는 일부를 컴퓨터와 전용 소프트웨어 도구를 사용하여 자동화 하는 것
  • CASE의 주요 기능
    • 소프트웨어 생명 주기 전 단계의 연결
    • 다양한 소프트웨어 개발 모형 지원
    • 그래픽 지원

• 하향식 비용 산정 기법

  • 과거의 유사한 경험을 바탕으로 전문 지식이 많은 개발자들이 참여한 회의를 통해 비용을 산정하는 방법
  • 하향식 비용 산정 기법
    • 전문가 감정 기법 - 조직 내에 있는 경험이 많은 두 명 이상의 전문가에게 비용 산정을 의뢰하는 기법
    • 델파이 기법 - 전문가 감정 기법의 주관적인 편견을 보완하기 위해 많은 전문가의 의견을 종합하여 산정하는 기법

• 상향식 비용 산정 기법

  • 프로젝트의 세부적인 작업 단위 별로 비용을 산정한 후 집계하여 전체 비용을 산정하는 방법
  • 주요 상향식 비용 산정 기법
    • LOC(원시 코드 라인 수) 기법
    • 개발 단계 인월수 기법
    • 수학적 산정 기법

• LOC 기법

  • 소프트웨어 각 기능의 원시 코드 라인 수의 비관치, 낙관치, 기대치를 측정하여 예측치를 구하고 이를 이용하여 비용을 산정하는 기법
  • 산정 공식
    • 노력(인월) = 개발 기간 X 투입 인원 = LOC / 1인당 월 평균 생산 코드 라인 수
    • 개발 비용 = 노력(인월) X 단위 비용(1인당 월평균 인건비)
    • 생산성 = LOC / 노력(인월)

• 수학적 산정 기법

  • 경험적 추정 모형, 실험적 추정 모형
  • 주요 수학적 산정 기법
    • COCOMO 모형
    • Putnam 모형
    • 기능 점수(FP) 모형

• COCOMO 모형

  • 원시 프로그램의 규모인 LOC(원시 코드 라인 수)에 의한 비용 산정 기법, 보헴이 제한

• COCOMO의 소프트웨어 개발 유형

  • 조직형 - 중 . 소 규모 소프트웨어, 5만 라인 이하의 소프트웨어를 개발하는 유형
    • 사무 처리용, 업무용, 과학용 응용 소프트웨어 개발에 적합
  • 반분리형 - 조직형과 내장형의 중간형 소프트웨어, 30만 라인 이하의 소프트웨어를 개발하는 유형
    • 컴파일러, 인터프리터와 같은 유틸리티 개발에 적합
  • 내장형 - 초대형 규모 소프트웨어, 30만 라인 이하의 소프트웨어를 개발하는 유형
    • 신호기 제어 시스템, 미사일 유도 시스템, 실시간 처리 시스템 등의 시스템 프로그램 개발에 적합

• Putnam 모형

  • 소프트웨어 생명 주기의 전 과정 동안에 사용될 노력의 분포를 예상하는 모형
  • Rayleigh-Norden 곡선의 노력 분포도를 기초로 함

• 기능 점수 모형

  • 소프트웨어의 기능을 증대시키는 요인별로 가중치를 부여, 요인별 가중치를 합산하여 총 기능 점수 산출, 총 기능 점수와 영향도를 이용하여 기능 점수(FP)를 구한 후 이를 이용해서 비용을 산정하는 기법
  • 소프트웨어 기능 증대 요인
    • 자료 입력(입력 양식)
    • 정보 출력(출력 보고서)
    • 명령어(사용자 질의수)
    • 데이터 파일
    • 필요한 외부 루틴과의 인터페이스

• 비용 산정 자동화 추정 도구

  • SLIM - Reyleigh-Norden 곡선과 Putnam 예측 모델을 기초로 하여 개발된 자동화 추정 도구
  • ESTIMACS - 다양한 프로젝트와 개인별 요소를 수용하도록 FP 모형을 기초로 하여 개발된 자동화 추정 도구

• PERT

  • 프로젝트에 필요한 전체 작업의 상호 관계를 표시하는 네트워크
  • 각 작업별로 낙관적인 경우, 가능성이 있는 경우, 비관적인 경우를 나누어 종료 시기를 결정

• CPM

  • 프로젝트 완성에 필요한 작업을 나열하고 작업에 필요한 소요 기간을 예측하는데 사용하는 기법

• 간트 차트

  • 프로젝트의 작업 일정을 막대 도표를 이용하여 표시하는 프로젝트 일정표
  • 시간선 차트

• ISO/IEC 12207

  • ISO(국제표준화기구)에서 만든 표준 소프트웨어 생명 주기 프로세스
  • ISO/IEC 12207 구분
    • 기본 생명 주기 프로세스 - 획득, 공급, 개발, 운영, 유지보수 프로세스
    • 지원 생명 주기 프로세스 - 품질 보증, 검증, 확인, 활동, 검토, 감사, 문서화, 형상관리, 문제 해결 프로세스
    • 조직 생명 주기 프로세스 - 관리, 기반 구조, 훈련, 개선 프로세스

• CMMI

  • 소프트웨어 개발 조직의 업무 능력 및 조직의 성숙도를 평가하는 모델
  • CMMI의 소프트웨어 프로세스 성숙도
    • 초기 - 작업자 능력에 따라 성공 여부 결정
    • 관리 - 특정한 프로젝트 내의 프로세스 정의 및 수행
    • 정의 - 조직의 표준 프로세스를 활용하여 업무 수행
    • 정량적 관리 - 프로젝트를 정략적으로 관리 및 통제
    • 최적화 - 프로세스 역량 향상을 위해 지속적인 프로세스 개선

• SPICE

  • 정보 시스템 분야에서 소프트웨어의 품질 및 생산성 향상을 위해 소프트웨어 프로세스를 평가 및 개선하는 국제 표준
  • ISO/IEC 15504

• SPICE의 프로세스 수행 능력 단계

  • 0 불완전 - 프로세스가 구현되지 않았거나 목적을 달성하지 못한 단계
  • 1 수행 - 프로세스가 수행되고 목적이 달성된 단계
  • 2 관리 - 정의된 자원의 한도 내에서 그 프로세스가 작업 산출물을 인도하는 단계
  • 3 확립 - 소프트웨어 공학 원칙에 기반하여 정의된 프로세스가 수행되는 단계
  • 4 예측 - 프로세스가 목적 달성을 위해 통제되고, 양적인 측정을 통해서 일관되게 수행되는 단계
  • 5 최적화 - 프로세스 수행을 최적화하고, 지속적인 개선을 통해 업무 목적을 만족시키는 단계

• 소프트웨어 개발 방법론 테일러링

  • 프로젝트의 상황 및 특성에 맞도록 정의된 소프트웨어 개발 방법론의 절차, 사용기법 등을 수정 및 보완하는 작업
  • 소프트웨어 개발 방법론 테일러링 고려사항
    • 내부적 기준 - 목표 환경, 요구사항, 프로젝트 규모, 보유 기술
    • 외부적 기준 - 법적 제약사항, 표준 품질 기준

• 소프트웨어 개발 프레임워크

  • 소프트웨어 개발에 공통적으로 사용되는 구성 요소와 아키텍처를 일반화하여 손쉽게 구현할 수 있도록 여러가지 기능들을 제공해주는 반제품 형태의 소프트웨어 시스템

• 스프링 프레임워크

  • 자바 플랫폼을 위한 오픈 소스 경량형 애플리케이션 프레임워크

• 소프트웨어 개발 프레임워크의 특성

  • 모듈화 - 캡슐화를 통해 모듈화를 강화, 설계 및 구현에 따른 영향을 최소화 함으로 소프트웨어 품질 향상
  • 재사용성 - 재사용 가능한 모듈들을 제공함으로 예산 절감, 생산성 향상, 품질 보증 가능
  • 확장성 - 다형성을 통한 인터페이스 확장이 가능하여 다양한 형태와 기능을 가진 애플리케이션 개발 가능
  • 제어의 역흐름 - 개발자가 관리하고 통제해야 하는 객체들의 제어를 프레임워크에 넘김으로써 생산성을 향상시킴