요구사항 확인

애자일 방법론

• 절차보다 사람이 중심이 되어 변화에 유연하고 신속하게 적응하면서 효율적으로 시스템을 개발할 수 있는 신속 적응적 경량 개발방법론

소프트웨어 생명주기(SDLC) 모델

• 시스템의 요구분석부터 유지보수까지 전 공정을 체계화한 절차

요구사항분석

• 다양한 이해관계자의 상충할 수도 있는 요구사항을 고려하여 새로운 제품이나 변경된 제품에 부합하는 요구와 조건을 결정하는 단계

설계

• 시스템 명세 단계에서 정의한 기능을 실제 수행할 수 있도록 수행 방법을 논리적으로 결정하는 단계

구현

• 설계 단계에서 논리적으로 결정한 문제 해결 방법을 특정 프로그래밍 언어를 사용하여 실제 프로그램을 작성하는 단계

테스트

• 시스템이 정해진 요구를 만족하는지, 예상과 실제 결과가 어떤 차이를 보이는지 검사하고 평가하는 단계

유지보수

• 시스템이 인수되고 설치된 후 일어나는 모든 활동

폭포수 모델

• 소프트웨어 개발 시 각 단계를 확실히 마무리 지은 후에 다음 단계로 넘어가는 단계

프로토타이핑 모델

• 고객이 요구한 주요 기능을 프로토타입으로 구현하여, 고객의 피드백을 반영하여 소프트웨어를 만들어가는 모델

나선형 모델

• 시스템 개발 시 위험을 최소화 하기 위해 점진적으로 완벽한 시스템으로 개발해나가는 모델

반복적 모델

• 구축대상을 나누어 병렬적으로 개발 후 통합하거나, 반복적으로 개발하여 점증 완성시키는 모델

구조적 방법론

• 전체 시스템을 기능에 따라 나누어 개발하고, 이를 통합하는 분할과 정복 접근 방식의 방법론

정보공학 방법론

• 정보시스템의 개발에 필요한 관리 절차와 작업을 체계화한 방법론
• 개발주기를 이용해 대형 프로젝트를 수행하는 체계적인 방법론

객체지향 방법론

• ‘객체’라는 기본 단위로 시스템을 분석 및 설계하는 방법론
• 복잡한 현실 세계를 사람이 이해하는 방식으로 시스템에 적용하는 방법론

컴포넌트 기반 방법론

• 소프트웨어를 구성하는 컴포넌트를 조립해서 하나의 새로운 응용 프로그램을 작성하는 방법론

애자일 방법론

• 절차보다는 사람이 중심이 되어 변화에 유연하고 신속하게 적응하면서 효율적으로 시스템을 개발할 수 있는 신속 적응적 경량 개발방법론
• 개발 과정의 어려움을 극복하기 위해 적극적으로 모색한 방법론

제품 계열 방법론

• 특정 제품에 적용하고 싶은 공통된 기능을 정의하여 개발하는 방법론
• 임베디드 소프트웨어를 작성하는 데 유용한 방법론

짝 프로그래밍

• 개발자 둘이서 짝으로 코딩하는 원리

지속적인 통합(CI)

• 매일 여러 번씩 소프트웨어를 통합하고 빌드해야 한다는 원리

메타포어

• 공통적인 이름 체계와 시스템 서술서를 통해 고객과 개발자 간의 의사소통을 원활하게 한다는 원리

테스트 기반 개발(TDD)

• 작성해야하는 프로그램에 대한 테스트를 먼저 수행하고, 이 테스트를 통과할 수 있도록 실제 프로그램의 코드를 작성 한다는 원리

리팩토링

• 프로그램의 기능을 바꾸지 않으면서 중복제거, 단순화 등을 위해 시스템 재구성한다는 원리

XP

• 의사소통 개선과 즉각적 피드백으로 소프트웨어 품질을 높이기 위한 방법론

스크럼

• 매일 정해진 시간, 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심 방법론

린

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

델파이 기법(Delphi Method)

• 전문가의 경험적 지식을 통한 문제 해결 및 미래예측을 위한 기법

LoC

• 소프트웨어 각 기능의 원시 코드 라인 수의 낙관치, 중간치, 비관치를 측정하여 예측치를 구하고 이를 이용하여 비용을 산정하는 방식

Man Month

• 한 사람이 1개월 동안 할 수 있는 일의 양을 기준으로 프로젝트 비용을 산정하는 방식

COCOMO

• 보헴이 제안한 모형으로 프로그램 규모에따라 비용을 산정하는 방식

푸트남

• 소프트웨어 개발주기의 단계별로 요구할 인력의 분포를 가정하는 방식

기능점수(FP)

• 요구 기능을 증가시키는 인자별로 가중치를 부여하고, 요인별 가중치를 합산하여 총 기능의 점수를 계산하여 비용을 산정하는 방식

주 정공법(CPM)

• 여러 작업들의 수행 순서가 얽혀 있는 프로젝트의 일정을 계산하는 기법

PERT

• 일의 순서를 계획적으로 정리하기 위한 수렴 기법으로 비관치, 중간치, 낙관치의 3점 추정방식을 통해 일정을 관리하는 시법

중요 연쇄 프로젝트 관리(CCPM)

• 주 공정 연소법으로 자원제약사항을 고려하여 일정을 작성하는 기법

임계 경로

• 가장 오랜 기간이 걸리는 경로

Template Method

• 어떤 작업을 처리하는 일부분을 서브 클래스로 캡슐화해 전체 일을 수행하는 구조는 바꾸지 않으면서 특정 단계에서 수행하는 내역을 바꾸는 패턴으로 일반적으로 상위 클래스(추상 클래스)에는 추상 메서드를 통해 기능의 골격을 제공하고, 하위 클래스(구체 클래스)의 메서드에는 세부처리를 구체화 하는 방식으로 사용하며 코드양을 줄이고, 유지보수를 용이하게 만드는 특징을 갖는 디자인 패턴

Command

• 실행될 기능을 캡슐화함으로써 주어진 여러 기능을 실행할 수 있는 재사용성이 높은 클래스를 설계하는 패턴으로 하나의 추상 클래스에 메서드를 만들어 각 명령이 들어오면 그에 맞는 서브 클래스가 선택되어 실행되는 특징을 갖는 패턴

Observer

• 한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체들한테 연락이 가고 자동으로 내용이 갱신되는 방법으로 일대 다의 의존성을 가지며 상호작용하는 객체 사이에서는 가능하면 느슨하게 결합하는 디자인 패턴

State

• 객체 상태를 캡슐화하여 클래스화함으로써 그것을 참조하게 하는 방식으로 상태에 따라 다르게 처리할 수 있도록 행위 내용을 변경하여, 변경 시 원시 코드의 수정을 최소화할 수 있고, 유지 보수의 편의성도 갖는 디자인 패턴

Stategy

• 알고리즘 군을 정의하고(추상 클래스) 같은 알고리즘을 각각 하나의 클래스로 캡슐화한 다음, 필요할 때 서로 교환해서 사용할 수 있게 하는 패턴으로, 행위를 클래스로 캡슐화해 동적으로 행위를 자유롭게 바꿀 수 있게 해주는 디자인 패턴

소프트웨어 아키텍처

• 여러 가지 소프트웨어 구성요소와 그 구성요소가 가진 특성 중에서 외부에 드러나는 특성, 그리고 구성요소 간의 관계를 표현하는 시스템의 구조나 구조체이다.

유케이스뷰

• 유스케이스 또는 아키텍처를 도출하고 설계하며 다른 뷰를 검증하는 데 사용되는 뷰
• 사용자, 설계자, 개발자, 테스트 관점

논리 뷰

• 시스템의 기능적인 요구사항이 어떻게 제공되는지 설명해주는 뷰
• 설계자, 개발자 관점

프로세스 뷰

• 시스템의 비기능적인 속성으로서 자원의 효율적인 사용, 병행 실행, 비동기, 이벤트 처리 등을 표현한 뷰
• 개발자, 시스템 통합자 관점

구현 뷰

• 개발 환경 안에서 정적인 소프트웨어 모듈의 구성을 보여주는 뷰
• 컴포넌트 구조와 의존성을 보여주고 컴포넌트에 관한 부가적인 정보 정의

배포 뷰

• 컴포넌트가 물리적인 아키텍처에 어떻게 배치되는가를 매핑해서 보여주는 뷰

계층화 패턴

• 시스템을 계층으로 구분하여 구성하는 패턴

클라이언트-서버 패턴

• 하나의 서버와 다수의 클라이언트로 구성된 패턴

파이프-필터 패턴

• 데이터 스트림을 생성하고 처리하는 시스템에서 사용 가능한 패턴

브로커 패턴

• 분리된 컴포넌트들로 이루어진 분산시스템에서 사용되고, 이 컴포넌트들은 원격 서비스 실행을 통해 상호 작용이 가능한 패턴

모델-뷰-컨트롤러패턴(MVC패턴)

• 대화형 어플리케이션을 모델, 뷰, 컨트롤러 3개의 서브 시스템으로 구조화 하는 패턴

디자인 패턴

• 소프트웨어 공학의 소프트웨어 설계에서 공통으로 발생하는 문제에 대해 자주 쓰이는 설계 방법을 정리한 패턴

Builder

• 복잡한 인스턴스를 조립하여 만드는 구조로, 복합 객체를 생성할 때 객체를 생성하는 방법(과정)과 객체를 구현(표현) 하는 방법을 분리함으로써 동일한 생성 절차에서 서로 다른 표현 결과를 만들 수 있는 디자인 패턴

Prototype

• 처음부터 일반적인 원형을 만들어 놓고, 그것을 복사한 후 필요한 부분만 수정하여 사용하는 패턴으로, 생성할 객체의 원형을 제공하는 인스턴스에서 생성할 객체들의 타입이 결정되도록 설계하며 객체를 생성할 때 갖추어야 할 기본 형태가 있을 때 사용되는 디자인 패턴

Factory Method

• 상위 클래스에서 객체를 생성하는 인터페이스를 정의하고, 하위 클래스에서 인스턴스를 생성하도록 하는 방식으로, 상위 클래스에서 인스턴스를 만드는 방법만 결정하고, 하위 클래스에서 그 데이터의 생성을 책임지고 조작하는 함수들을 오버라이딩하여 인터페이스와 실제객체를 생성하는 클래스를 분리할 수 있는 특성을 가진 디자인패턴

Abstract Factory

• 구체적인 클래스에 의존하지 않고 서로 연관되거나 의존적인 객체들의 조합을 만드는 인터페이스를 제공하는 패턴으로 이 패턴을 통해 생성된 클래스에서 사용자에게 인터페이스(API)를 제공하고, 구체적인 구현은 Concrete Product클래스에서 이루어지는 특징을 갖는 디자인 패턴

Singleton

• 전역 변수를 사용하지 않고 객체를 하나만 생성하도록 하며, 생성된 객체를 어디에서든지 참조할 수 있도록 하는 디자인 패턴

요구공학

• 사용자의 요구가 반영된 시스템을 개발하기 위하여 사용자 요구사항에 대한 도출, 분석, 명세, 확인 및 검증하는 구조화된 활동

요구사항 도출

• 소프트웨어가 해결해야할 문제를 이해하고, 고객으로부터 제시되는 추상적인 요구에 대해 관련 정보를 식별하고 수집 방법 결정, 수집된 요구사항을 구체적으로 표현하는 단계

요구사항 분석

• 도출된 요구사항에 대해 충돌, 중복, 누락등의 분석을 통해 완전성과 일관성을 확보하는 단계

요구사항 명세

• 체계적으로 검토, 평가, 승인될 수 있는 문서를 작성하는 단계

요구사항 확인 및 검증

• 분석가가 요구사항을 이해했는지 확인하고, 요구사항 문서가 회사의 표준에 적합하고 이해 가능하며, 일관성이 있고, 완전한지 검증하는 단계

인터뷰

• 이해관계자와 직접 대화를 통해 정보를 구하는 공식적, 비공식적 정보 수집방법

브레인스토밍

• 말을 꺼내기 쉬운 분위기로 만들어, 회의 참석자들이 내놓은 아이디어들을 비판 없이 수용할 수 있도록 하는 회의

델파이 기법

• 전문가의 경험적 지식을 통한 문제 해결 및 미래예측을 위한 방법

롤 플레잉

• 현실에 일어나는 장면을 설정하고 여러 사람이 각자가 맡은 역을 연기함으로써 요구사항을 분석하고 수집하는 방법

워크숍

• 단기간의 집중적인 노력을 통해 다양하고 전문적인 정보를 획득하고 공유하는 방법

설문 조사

• 설문지 또는 여론조사 등을 이용해 간접적으로 정보를 수집하는 방법

비정형 명세 기법

• 사용자의 요구를 표현할 때 자연어를 기반으로 서술하는 기법

정형 명세 기법

• 사용자의 요구를 표현할 때 수학적인 원리와 표기법으로 서술하는 기법

요구사항 명세서

• 소프트웨어 개발 프로세서의 시작인 소프트웨어의 요구사항을 분석하고 정의하는 단계에서 작성되는 최종 산출물

인스펙션

• 소프트웨어 요구, 설계, 원시 코드 등의 저작자 외의 다른 전문가 또는 팀이 검사하여 문제를 식별하고 문제에 대한 올바른 해결을 찾아내는 형식적인 검토 기법

관리 리뷰

• 프로젝트 진행 상황에 대한 전반적인 검토를 바탕으로 범위, 일정, 인력 등에 대한 통제 및 의사결정을 지원하는 리뷰

기술 리뷰

• 정의된 계획 및 명세를 준수하고 있는지에 대한 검토를 수행하는 리뷰

워크스루

• 검토 자료를 회의 전에 배포해서 사전 검토한 후 짧은 시간 동안 회의를 진행하는 형태로 리뷰를 통해 문제 식별, 대안 조사, 개선 활동, 학습 기회를 제공하는 가장 비형식적인 검토 기법

감사

• 소프트웨어 제품 빛 프로세스가 규제, 표준, 가이드라인, 계획, 절차를 준수하고 있는지를 독립적으로 평가하는 기법

형상통제 위원회

• 형상 관리에 대해 주요 방침을 정하고 산출물을 검토하여, 단계별 의사결정을 수행하는 조직

Man Month

• 한 사람이 1개월 동안 할 수 있는 일의 양을 기준으로 프로젝트 비용을 산정하는 방식

소프트웨어 아키텍처 패턴

• 소프트웨어를 설계할 때 참조할 수 잇는 전형적인 해결 방식

SAAM

• 변경 용이성과 기능성에 집중, 평가가 용이하여 경험이 없는 조직에서도 활용 가능한 비용 평가 모델

ATAM

• 아키텍처 품질 속성을 만족시키는지 판단 및 품질 속성들의 이해 상충관계까지 평가하는 모델

CBAM

• ATAM 바탕의 시스템 아키텍처 분석 중심으로 경제적 의사결정에 대한 요구를 충족하는 비용 평가 모델

ADR

• 소프트웨어 아키텍처 구성요소 간 응집도를 평가하는 모델

ARID

• 전체 아키텍처가 아닌 특정 부분에 대한 품질 요소에 집중하는 비용 평가 모델

Bridge

• 기능의 클래스 계층과 구현의 클래스 계층을 연결하고, 구현부에서 추상 계층을 분리하여 추상화된 부분과 실제 구현 부분을 독립적으로 확장할 수 있는 디자인 패턴
• 구현뿐만 아니라, 추상화된 부분까지 변경해야하는 경우 활용

Facade

• 복잡한 시스템에 대하여 단순한 인터페이스를 제공함으로써 사용자와 시스템 간, 또는 여타 시스템과의 결합도를 낮추어 시스템 구조에 대한 파악을 쉽게 하는 패턴으로 오류에 대해서 단위별로 확일할 수 있게 하며, 사용자의 측면에서 단순한 인터페이스 제공을 통해 접근성을 높일 수 있는 디자인 패턴
• 통합된 인터페이스 제공

Adapter

• 기존 생성된 클래스를 재사용할 수 있도록 중간에 맞춰주는 역할을 하는 인터페이스를 만드는 패턴으로, 상속을 이용하는 클래스 패턴과 위임을 이용하는 인스턴스 패턴의 두 가지 형태로 사용되는 디자인 패턴
• 인터페이스가 호환되지 않는 클래스들을 함께 이용할 수 있도록, 타 클래스의 인터페이스를 기존 인터페이스에 덧씌움