애자일 방법론(Agile)
ManMonth = LoC/개발자 월간 생산성
프로젝트 개발 기간 = ManMonth/개발자 수
개발 기간 : 20개월
계산식 : (30,000라인 / 300라인)/5명 = 20개월
시스템의 요구분석부터 유지보수까지 전 공정을 체계화한 절차이다.
설계 단계
요구사항 분석 | 설계 | 구현 | 테스트 | 유지보수 |
---|---|---|---|---|
다양한 이해관계자의 상충할 수도 있는 요구사항을 고려하여 새로운 제품이나 변경된 제품에 부합하는 요구와 조건을 결정하는 단계 | 시스템 명세 단계에서 정의한 기능을 실제 수행할 수 있도록 수행 방법을 논리적으로 결정하는 단계 | 설계 단계에서 논리적으로 결정한 문제 해결방법을 특정 프로그래밍 언어를 사용하여 실제 프로그램을 작성하는 단계 | 시스템이 정해진 요구를 만족하는지, 예상과 실제 결과가 어떤 차이를 보이는지 검사하고 평가하는 단계 | 시스템이 인수되고 설치된 후 일어나는 모든 활동 |
폭포수 모델(Waterfall Model)
폭포수 모델 | 프로토타이핑 모델 | 나선형 모델 | 반복적 모델 |
---|---|---|---|
소프트웨어 개발 시 각 단계를 확실히 마무리 지은 후에 다음 단계로 넘어가는 모델 | 고객이 요구한 주요 기능을 프로토 타입으로 구현하여, 고객의 피드백을 반영하여 소프트웨어를 만들어가는 모델 | 시스템 개발 시 위험을 최소화 하기 위해 점진적으로 완벽한 시스템으로 개발해나가는 모델 | 구축대상을 나누어 병렬적으로 개발 후 통합하거나 반복적으로 개발하여 점증 완성시키는 모델 |
구조적 방법론
구조적 방법론 | 정보공학 방법론 | 객체지향 방법론 | 컴포넌트 기반 방법론(CBD) | 애자일 방법론 | 제품 계열 방법론 |
---|---|---|---|---|---|
전체 시스템을 기능에 따라 나누어 개발하고, 이를 통합하는 분할과 정복 접근 방식의 방법론 | 정보 시스템 개발에 필요한 관리 절차와 작업 기법을 체계화한 방법론 개발주기를 이용해 대형 프로젝트를 수행하는 체계적인 방법론 | '객체'라는 기본 단위로 시스템을 분석 및 설계하는 방법론 복잡한 현실 세계를 사람이 이해하는 방식으로 시스템에 적용하는 방법론 | 소프트웨어를 구성하는 컴포넌트를 조립해서 하나의 새로운 응용 프로그램을 작성하는 방법론 | 절차보다는 사람이 중심이 되어 변화에 유연하고 신속하게 적응하면서 효율적으로 시스템을 개발 할 수 있는 신속 적응적 경량 개발방법론 개발 과정의 어려움을 극복하기 위해 적극적으로 모색한 방법론 | 특정 제품에 적용하고 싶은 공통된 기능을 정의하여 개발하는 방법론 임베디드 소프트웨어를 작성하는데 유용한 방법론 |
작성해야 하는 프로그램에 대한 테스트를 먼저 수행하고, 이 테스트를 통과할 수 있도록 실제 프로그램의 코드를 작성한다는 원리이다.
지속적인 통합(CI)
짝 프로그래밍 | 지속적인 통합(CI) | 메타포어 | 테스트 기반 개발(TDD) | 리팩토링 |
---|---|---|---|---|
개발자 둘이서 짝으로 코딩하는 원리 | 매일 여러번씩 소프트웨어를 통합하고 빌드해야된다는 원리 | 공통적인 이름 체계와 시스템 서술서를 통해 고객과 개발자 간의 의사소통을 원활하게 한다는 원리 | 작성해야 하는 프로그램에 대한 테스트를 먼저 수행하고, 이 테스트를 통과할 수 있도록 실제 프로그램의 코드를 작성한다는 원리 | 프로그램의 기능을 바꾸지 않으면서 중복제거, 단순화 등을 위해 시스템 재구성 한다는 원리 |
스크럼
XP | 스크럼 | 린 |
---|---|---|
의사소통 개선과 즉각적 피트백으로 소프트웨어 품질을 높이기 위한 방법론 | 매일 정해진 시간, 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심 방법론 | 도요타의 린 시스템 품질기법을 소프트웨어 개발 프로세스에 적용해서 낭비 요소를 제거하여 품질을 향상시킨 방법론 |
전문가의 경험적 지식을 통한 문제 해결 및 미래예측을 위한 기법이다.
기능점수(FP)
LoC | Man Month | COCOMO | Putnam(푸트남) | FP(기능점수) |
---|---|---|---|---|
소프트웨어 각 기능의 원시 코드 라인 수의 낙관치, 중간치, 비관치를 측정하여 예측치를 구하고 이를 이용하여 비용을 산정하는 방식 | 한 사람이 1개월 동안 할 수 있는 양을 기준으로 프로젝트 비용을 산정하는 방식 | 보헴이 제안한 모형으로 프로그램 규모에 따라 비용을 산정하는 방식 | 소프트웨어 개발주기의 단계별로 요구할 인력의 분포를 가정하는 방식 | 요구 기능을 증가시키는 인자별로 가중치를 부여하고, 요인별 가중치를 합산하여 총 기능의 점수를 계산하여 비용을 산정하는 방식 |
PERT
주 공정법 (CPM) | PERT | 중요 연쇄 프로젝트 관리(CCPM) |
---|---|---|
여러 작업들의 수행순서가 얽혀있는 프로젝트의 일정을 계산하는 기법 | 일의 순서를 계획적으로 정리하기 위한 수렴기법으로 비관치, 중간치, 낙관치의 3점 추첨방식을 통해 일정을 관리하는 기법 | 주 공정 연소법으로 자원제약 사항을 고려하여 일정을 작성하는 기법 |
임계경로는 가장 오랜 기간이 걸리는 경로를 찾는다.
50,000/250 = 200 Man Month
한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체들에 연락이 가고 자동으로 내용이 갱신되는 방법으로 일대다의 의존성을 가지며 상호작용하는 객체 사이에서는 가능하면 느슨하게 결합하는 디자인을 사용해야 한다.
Observer(Pattern)
Template Method | Command | Observer | State | Strategy |
---|---|---|---|---|
어떤 작업을 처리하는 일부분을 서브 클래스로 캡슐화해 전체 일을 수행하는 구조는 바꾸지 않으면서 특정 단계에서 수행하는 내역을 바꾸는 패턴으로 일반적으로 상위클래스(추상클래스)에는 추상 메서드를 통해 기능의 골격을 제공하고, 하위 클래스(구체 클래스)의 메서드에는 세부 처리를 구체화하는 방식으로 사용하며 코드양을 줄이고 유지보수를 용이하게 만드는 특징을 갖는 디자인 패턴 | 실행될 기능을 캡슐화함으로써 주어진 여러 기능을 실행할 수 있는 재사용성이 높은 클래스를 설계하는 패턴으로 하나의 추상 클래스에 메서드를 만들어 각 명령이 들어오면 그에 맞는 서브 클래스가 선택되어 실행되는 특징을 같는 디자인 패턴 | 한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체들한테 연락이 가고 자동으로 내용이 갱신되는 방법으로 일대 다의 의존성을 가지며 상호작용하는 객체 사이에서는 가능하면 느슨하게 결합하는 디자인 패턴 | 객체 상태를 캡슐화 하여 참조하게 하는 방식으로 상태에 따라 다르게 처리할 수 있도록 행위내용을 변경하여, 변경시 원시코드 수정을 최소화할 수 있고 유지보수의 편의성도 갖는 디자인 패턴 | 알고리즘 군을 정의하고 (추상클래스) 같은 알고리즘을 각각 하나의 클래스로 캡슐화한 다음, 필요할 때 서로 교환해서 사용할 수 있게 하는 패턴으로, 행위를 클래스로 캡슐화해 동적으로 행위를 자유롭게 바꿀 수 있게 해주는 디자인 패턴 |
안드로이드(Android)
행위
목적에 따른 디자인 패턴 유형(생구행)
여러가지 소프트웨어 구성요소와 그 구성요소가 가진 특성중에서 외부에 드러나는 특성, 그리고 구성요소 간의 관계를 표현하는 시스템의 구조나 구조체이다.
시스템의 비기능적인 속성으로서 자원의 효율적인 사용, 병행 실행, 비동기, 이벤트 처리등을 표현한 뷰
개발자, 시스템 통합자 관점
프로세스 뷰
유스케이스 뷰 | 논리 뷰 | 프로세스 뷰 | 구현 뷰 | 배포 뷰 |
---|---|---|---|---|
유스케이스 또는 아키텍처를 도출하고 설계하여 다른 뷰를 검증하는데 사용되는 뷰 사용자, 설계자, 개발자, 테스트 관점 | 시스템의 기능적이 요구사항이 어떻게 제공되는지 설명해주는 뷰 설계자, 개발자 관점 | 시스템의 비기능적인 속성으로서 자원의 효율적인 사용, 병행 실행, 비동기, 이벤트 처리등을 표현한 뷰 개발자, 시스템 통합자 관점 | 개발환경 안에서 정적인 소프트웨어 모듈의 구성을 보여주는 뷰 컴포넌트 구조와 의존성을 보여주고 컴포넌트에 관한 부가적인 정보 정의 | 컴포넌트가 물리적이 아키텍처에 어떻게 배치되는 가를 매핑해서 보여주는 뷰 |
계층화 패턴
계층화 패턴 | 클라이언트-서버 패턴 | 파이프-필터 패턴 | 브로커 패턴 | 모델-뷰-컨트롤러(MVC)패턴 |
---|---|---|---|---|
시스템을 계층으로 구분하여 구성하는 패턴 | 하나의 서버와 다수의 클라이언트로 구성된 패턴 | 데이터 스트림을 생성하고 처리하는 시스템에서 사용가능한 패턴 | 분리된 컴포넌트들로 이루어진 분산 시스템에서 사용되고, 이 컴포넌트들은 원격 서비스 실행을 통해 상호 작용이 가능한 패턴 | 대화형 애플리케이션을 모델, 뷰, 컨트롤러 3개의 서브 시스템으로 구조화하는 패턴 |
대화형 애플리케이션을 모델, 뷰, 컨트롤러 3개의 서브시스템으로 구조화하는 패턴이다.
소프트웨어 공학의 소프트웨어 설계에서 공통으로 발생하는 문제에 대해 자주 쓰이는 설계방법을 정리한 패턴이다.
싱글톤 패턴
Builder | Prototype | Factory Method | Abstract Factory | Singleton |
---|---|---|---|---|
복잡한 인스턴스를 조립하여 만드는 구조로, 복합 객체를 생성할 때 객체를 생성하는 방법(과정)과 객체를 구현(표현)하는 방법을 분리함으로써 동일한 생성 절차에서 서로 다른 표현 결과를 만들 수 있는 디자인 패턴 | 처음부터 일반적인 원형을 만들어 놓고, 그것을 복사한 후 필요한 부분만 수정하여 사용하는 패턴으로, 생성할 객체의 원형을 제공하는 인스턴스에서 생성할 객체들의 타입이 결정되도록 설정하여 객체를 생성할 때 갖추어야 할 기본 형태가 있을 때 사용되는 디자인 패턴 | 상위 클래스에서 객체를 생성하는 인터페이스를 정의하고, 하위 클래스에서 인스턴스를 생성하도록 하는 방식으로 상위 클래스에서는 인스턴스를 만드는 방법만 결정하고, 하위 클래스에서 그 데이터의 생성을 책임지고 조작하는 함수들을 오버로딩하여 인터페이스와 실제 객체를 생성하는 클래스를 분리할 수 있는 특성을 가진 디자인 패턴 | 구체적인 클래스에 의존하지 않고 서로 연관괴거나 의존적인 객체들의 조합을 만드는 인터페이스를 제공하는 패턴으로 이 패턴을 통해 생성된 클래스에서는 사용자에게 인터페이스(API)를 제공하고 구체적인 구현은 Concrete Product 클래스에서 이루어지는 특징을 갖는 디자인 패턴 | 전역 변수를 사용하지 않고 객체 하나만 생성하도록 하며, 생성된 객체를 어디에서든지 참조할 수 있도록 하는 디자인 패턴 |
팩토리 메서드 패턴 (Factory Method)
전략(Strategy)패턴
템플릿(Teamplate) 패턴
사용자의 요구가 반영된 시스템을 개발하기 위하여 사용자 요구사항에 대한 도출, 분석, 명세, 확인 및 검증하는 구조화된 활동이다.
- 부서별 담당자가 홈페이지 게시물을 작성할 수 있도록 관리자 페이지가 제공되어야 한다.
- 특정 함수의 호출시간은 5초를 넘지 말아야 한다.
- 콘텐츠 관리자가 예약정보를 입력하고 예약 현황을 파악할 수 있도록 다양한 통계와 관리 메뉴를 제공해야한다.
- 시스템 자원(CPU, 메모리 등)의 평균사용률은 최대 70%를 초과하지 않도록 구현해야 한다.
기능적 요구사항 1,3
비기능적 요구사항 2,4
요구사항 도출
요구사항 도출 | 요구사항 분석 | 요구사항 명세 | 요구사항 확인 및 검증 |
---|---|---|---|
소프트웨어가 해결해야 할 문제를 이해하고, 고객으로부터 제시되는 추상적 요구에 대해 관련 정보를 식별하고 수집 방법 결정, 수집된 요구사항을 구체적으로 표현하는 단계 | 도출된 요구사항에 대해 충돌, 중복, 누락등의 분석을 통해 완전성과 일관성을 확보하는 단계 | 체계적으로 검토, 평가 , 승인될 수 있는 문서를 작성하는 단계 | 분석가가 요구사항을 이해했는지 확인하고, 요구사항 문서가 회사의 표준에 적합하고 이해가능하며 일관성이 있고 완전한지 검증하는 단계 |
브레인스토밍(BrainStorming)
인터뷰 | 브레인스토밍 | 델파이 기법 | 롤 플레잉 | 워크숍 | 설문조사 |
---|---|---|---|---|---|
이해관계자와 직접 대화를 통해 정보를 구하는 공식적, 비공식적 정보 수집 방법 | 말을 꺼내기 쉬운 분위기로 만들어, 회의 참석자들이 내놓은 아이디어들을 비판없이 수용할 수 있도록 하는 회의 | 전문가의 경험적 지식을 통한 문제 해결 및 미래 예측을 위한 벙법 | 현실에 일어나는 장면을 설정하고 여러 사람이 각자가 맡은 역을 연기함으로써 요구사항을 분석하고 수집하는 방법 | 단기간의 집중적인 노력을 통해 다양하고 전문적인 정보를 획득하고 공유하는 방법 | 설문지 또는 여론조사등을 이용해 간접적으로 정보를 수집하는 방법 |
비정형 명세 기법
비정형 명세 기법 | 정형 명세 기법 |
---|---|
사용자의 요구를 표현할 떄 자연어를 기반으로 서술하는 기법 | 사용자의 요구를 표현할 때 수학적인 원리와 표기법으로 서술하는 기법 |
요구사항 명세서
인스펙션
관리 리뷰 | 기술 리뷰 | 인스펙션 | 워크스루 | 감사 |
---|---|---|---|---|
프로젝트 진행상황에 대한 전반적인 검토를 바탕으로 범위, 일정, 인력 등에 대한 통제 및 의사결정을 지원하는 리뷰 | 정의된 계획 및 명세를 준수하고 있는지에 대한 검토를 수행하는 리뷰 | 소프트웨어 요구 ,설계, 원시 코드 등의 저작자 외의 다른 전문가 또는 팀이 검사하여 문제를 식별하고 문제에 대한 올바른 해결을 찾아내는 형식적인 검토 기법 | 검토 자료를 회의 전에 배포해서 사전 검토한 후, 짧은 시간 동안 회의를 진행하는 형태로 리뷰를 통해 문제 식별, 대안 조사, 개선 활동, 확습 기회를 제공하는 가장 비형식적인 검토 기법 | 소프트웨어 제품 및 프로세스가 규제, 표준, 가이드라인, 계획, 절차를 준수하고 있는지를 독립적으로 평가하는 기법 |
형상관리에 대한 주요방침을 정하고 산출물을 검토하며, 단계별 의사결정을 수행하는 조직이다.
유스케이스 모델 검증 방법은 시스템 기능에 대한 유스케이스 모형 상세화 수준 및 적정성 검증을 위해서 액터, 유스케이스, 유스케이스 명세서를 점검하는 기법이다.
요구사항을 만족시키키 위한 분석 모델에 따라 시스템을 구현할 때 요구되는 시스템의 자원 식별
분석 클래스에서 불필요하고 지나치게 많은 속성들이 포함시키게 되면 객체 생성 시 시스템의 메모리 자원이 많이 요구되며, 전체 시스템의 성능 저하 발생
성능 및 용량 산정의 적정성
성능 및 용량 산정의 적정성
시스템 간 상호 운용성
IT 시장 성숙도 및 트렌드 부합성
기술적 위험 분석