소프트웨어 개발 방법론

구조적 방법론 - 1970년대
• 구조적 방법론의 절차
• 구조적 방법론의 특징

정보공학 방법론 - 1980년대
• 정보공학 방법론의 절차
• 정보공학 방법론의 특징

객체지향 방법론 - 1990년대
• 객체지향 방법론의 절차
• 객체지향 방법론의 특징

컴포넌트 기반 방법론 - 2000년대
• 컴포넌트 기반 방법론의 절차
• 컴포넌트 기반 방법론의 특징
• 소프트웨어의 위기(문제점)

애자일(Agile) 방법론 - 2000년 이후
• 애자일 방법론의 등장 배경
• 애자일 방법론의 정의
• 애자일 방법론의 특징
• 애자일 방법론의 선언문
• 애자일 방법론의 원칙
• 애자일 방법론의 5가지 가치
• XP (eXtreme Programming, 익스트림 프로그래밍)
• 스크럼 (SCRUM)
• 린 (Lean)
• DSDM (Dynamic Systems Development Method)
• FDD(기능 중심 개발) 방법

제품 계열 방법론 - 2010년대

테일러링(Tailoring) 개발 방법론
• 테일러링 개발 방법론의 특징
• 테일러링 개발 방법론의 필요성

보안 개발 방법론
• MS-SDL (Microsoft Secure Development Life Cycle)
• Seven Touchpoints
• CLASP (Comprehensive Lightweight Application Security Process)
• CWE (Common Weakness Enumeration)

1) 구조적 방법론 - 1970년대

① 구조적 방법론의 절차

방법론의 등장

1960년대까지는 특별한 방법론이 존재하지 않았으며, 1968년에 소프트웨어 위기론이 대두되면서 폭포수 개발 방법론이 등장하게 되었다

② 구조적 방법론의 특징

• 1970년대까지 가장 많이 적용되었던 소프트웨어 개발 방법론
• 구조화 프로그래밍 또는 *구조적인 프로그램 작성이라고도 한다
• 정형화된 분석 절차에 따라 사용자 요구사항을 파악하여 문서화하는 체계적 분석 방법
• 쉽게 이해할 수 있고 검증할 수 있는 프로그램의 코드를 생성하는 것이 목적
• 모듈(부품) 중심으로 개발한다
• 분할과 정복 방법으로, 하향식으로 기능을 분해한다
• 프로세스 중심 방식의 개발에 유용하다
• 재사용성, 유지보수성이 낮다

구조적 프로그래밍

전체 프로그램을 여러 개의 부품처럼 구분하여 개발하고, 이 부품들을 조립하듯이 개발하는 프로그래밍 기법

2) 정보공학 방법론 - 1980년대

① 정보공학 방법론의 절차

② 정보공학 방법론의 특징

• 정보 시스템 개발에 필요한 관리 절차와 작업 기법을 체계화한 방법론
• 소프트웨어 공학의 기술 발전에 따라 활용하기 위한 개발 방법론
• 생명주기를 이용해 대형 프로젝트를 수행하는 체계적인 방법론
• 기업 정보 시스템에 공학적 기법을 적용하여 시스템의 계획, 분석, 설계 및 구축을 하는 데이터 중심의 방법론
• *자료 구조 중심의 방법론으로 비교적 안정적
• 데이터와 *프로세스가 균형적
• 기능적 설계를 벗어나지는 못했다
• 기능별로 유지보수를 해야 하며, 재사용성이 낮다

자료 구조

- 프로그램에서 쉽게 사용될 수 있도록 구성된 데이터(자료)들간의 논리적인 관계
- 자료를 효율적으로 사용할 수 있도록 컴퓨터에 저장하는 방법

프로세스

- 현재 실행 중인 프로그램. 디스크에 있는 프로그램 파일이 실행 클릭을 통해서 메모리에 적재되어 시행될 때 프로세스라고 한다
- 프로세서(Processor)는 중앙 처리 장치(CPU)이다

3) 객체지향 방법론 - 1990년대

① 객체지향 방법론의 절차

② 객체지향 방법론의 특징

• 데이터와 그 데이터에 관련되는 동작을 모두 포함하는 방법론
• 데이터는 실체이고, 동작은 절차, 방법, 기능을 의미
• 정보 시스템과 데이터베이스를 설계하는 방법론
• 분석과 설계 및 개발에 있어서 객체지향 기법을 활용하여 시스템을 구축하고자 하는 방법론
• 객체 중심으로 *캡슐화, *추상화 기술이 필요하다
• 분석 초점이 명확하다
• 자연스럽고 유연하며 재사용이 용이하다
• 개발 전문가가 부족하다

캡슐화(Encapsulation)

- 프로그램을 개발할 때, 자료 구조(속성)와 기능(메소드, 함수)을 묶어서 외부에서는 알 수 없도록 캡슐처럼 사용하는 기술
- 객체를 정의할 때 연관된 자료구조(속성)와 기능(메소드, 함수)을 한 테두리로 묶는 것을 말한다

추상화(Abstraction)

- 추상화는 복잡한 문제의 본질을 이해하기 위해 세부 사항은 배제하고 중요한 부분을 중심으로 간략화하는 기법이다
- 사람, 새, 말, 사자, 호랑이 등을 대표할 수 있는 객체는 존재하지 않지만 동물이라는 대표성을 가진 추상적인 데이터를 만들어 사용할 수 있다

4) 컴포넌트 기반 방법론 - 2000년대

① 컴포넌트 기반 방법론의 절차

② 컴포넌트 기반 방법론의 특징

• 소프트웨어를 구성하는 컴포넌트를 조립해서 하나의 새로운 애플리케이션을 작성하는 방법
• 모듈은 기능을 구현하기 위한 최소의 단위
• 공공 행정 정보 시스템의 개발에 많이 활용되고 있는 표준 프로세스이다
• 재사용이 가능한 컴포넌트의 개발 또는 상용 컴포넌트들을 조합하여 개발하는 방법론이다
• 생산성과 품질을 높이고, *유지보수의 비용을 최소화할 수 있는 개발 방법이다
• 반복적, 점진적으로 개발한다
• 재사용성, 생산성, 품질이 높은 방법론이다
• 비용이 저렴하고, 위험을 개선할 수 있다
• 소프트웨어 위기를 극복하기 위한 방법론이다
• 컴포넌트 유통의 환경을 개선해야 한다
• 테스트 환경이 부족하고, 컴포넌트 평가, 인증 환경이 미흡하다

③ 소프트웨어의 위기(문제점)

• 소프트웨어의 개발 이용이 계속적으로 증대된다
• 소프트웨어를 개발한 후에 발생하는 유지보수 비용이 증대된다
• 과거에는 소프트웨어를 개발하는 기술적인 측면이 강조되었지만, 현재에는 소프트웨어의 관리적인 면이 강조되고 있다
• 사용자의 요구 변화가 많아 개발 기간이 연장된다
• 하드웨어의 기술은 높지만, 소프트웨어 기술은 너무 낮다
• 업무의 전문성이 높아지면서 개발자와 사용자 간의 의견 차이가 크다
• 개발된 소프트웨어의 기능적 오류가 많아져 성능 및 신뢰성이 부족하다
• 소프트웨어의 품질을 평가하는 기준이 없다
• 시장은 넓지만, 소프트웨어의 개발 인력은 부족하다

유지보수의 비용

- 이미 개발되어 사용 중인 프로그램을 관리하는 활동을 유지보수라고 한다
- 시간이 지날수록 사용자의 요구가 많아지며 다양해진다
- 이러한 요구를 받아들이는 작업은 매우 힘들고 시간과 비용이 많이 소모된다
- 따라서 개발자는 개발을 의뢰한 측에 유지보수를 하지 않는 조건이나 유지보수할 때마다 비용이 발생하도록 해야 한다

5) 애자일(Agile) 방법론 - 2000년 이후

애자일(Agile)

'기민한, 민첩한, 재빠르다'라는 의미

① 애자일 방법론의 등장 배경

• 사용자의 요구사항이 빈번하게 변경됨에 따라 새로운 방법론이 필요하게 되었다
• 계획이 없는 개발 방법의 경우, 선행 작업을 예측하기 힘들고 효율적이지 못하다는 점에서 취약점을 가지고 있었다
• 계획이 지나치게 많은 개발 방법론의 경우, 형식적인 절차를 따르는 비용과 전체적인 개발의 흐름 자체를 느리게 하는 단점을 가지고 있었다
• 애자일은 개발 과정의 어려움을 극복하기 위해 적극적으로 모색한 방법론이다

② 애자일 방법론의 정의

• 요구사항, 설계, 구현, 시험의 단계를 통해 개발하는 방법론이다
• 소프트웨어 개발 방법에 있어서 계획이 없거나 계획이 지나치게 많은 개발 방법들 사이에 타협점을 찾은 방법론이다
• 소프트웨어 개발 단계의 변화에 신속하게 대응하기 위하여 요구사항을 지속적으로 분석하고 반영하여 시간 지연을 최소화하는 방법론이다

③ 애자일 방법론의 특징

• 프로세스와 도구 중심이 아닌 개발 과정의 소통을 중요하게 생각하는 소프트웨어 개발 방법론으로 반복적인 개발을 통한 잦은 출시를 목표로 한다
• 기존 모형(*폭포수 모형, *프로토타입 모형, *나선형 모형)의 문제점을 보완한 모형이다
• 소프트웨어를 점증적으로 개발한다
• 출시 주기를 짧게 하여 다양한 요구 변화에 대응한다
• 고객과 개발팀과의 소통, 개발팀원 간의 소통, 협력을 극대화한다
• 인간의 수행 능력을 높이기 위한 현실적인 방법을 제시한다
• 가볍고 실용적인 소프트웨어 개발 방법론이다
• 애자일 방법론을 소프트웨어 개발 방법론의 방법론이라고 한다

폭포수 모형 (Waterfall Model)

폭포수의 물흐름처럼 한번 지나가면 다시는 되돌릴 수 없듯이 각 단계를 명확히 하고 다음 단계로 넘어가는 모형이다

프로토타입 모형 (Prototyping Model)

시스템 개발 초기에 사용자의 요구 기능을 시제품으로 만들어 사용자로 하여금 기능과 사용성 등에 대해 검증시켜 가면서 시스템을 개발하는 기법이다

나선형 모형 (Spiral Model)

폭포수 모형과 프로토타입 모형의 장점을 살린 모형으로 사용자 요구 확인에 의한 시스템 개발이 가능하다.
나선형 모형은 위험 분석을 해나가면서 시스템을 개발한다

④ 애자일 방법론의 선언문

• 대형화, 복잡한 개발 방법론보다는 현식적이고 가벼운 소프트웨어 개발을 지지하는 애자일 방법론 지지자들이 모여 2001년에 4가지 애자일 선언문을 발표하였다
  - 개인과 상호 작용을 프로세스와 도구보다 중시한다
  - 동작하는 소프트웨어를 포괄적인 문서보다 중시한다
  - 고객과의 협력을 계약의 협상보다 중시한다
  - 변화의 대응을 계획의 수행보다 중시한다


• 애자일 모형의 도입으로 프로세스와 도구 문서 작업, 계약의 협상, 계획의 수행을 무시하는 것이 아님을 주의한다

⑤ 애자일 방법론의 원칙 6가지

1. 소통한다 -> 알기 쉬운 차트, 정보 공유, 회의
2. 협력한다 -> 개발팀 협조, 고객과의 대화로 문제 해결
3. 적응한다 -> 변화 수용, 융통성 발휘
4. 지속한다 -> 검증을 반복, 점증 개발
5. 가치를 전달한다 -> 위험도 높은 작업 우선, 비용 감소
6. 피드백 한다 -> 자주 출시, 고객 평가

⑥ 애자일 방법론의 5가지 가치

1. 의사소통: 개발팀이 발전적인 방향으로 존속하는 데 있어서 가장 중요한 가치이다
2. 용기: 모르는 것을 모른다고 말하는 용기, 먼저 도움을 주거나 요청할 수 있는 용기로 소프트웨어 개발 시 커다란 미지의 두려움에 마주할 때 필요한 가치이다
3. 피드백: 소프트웨어 개발 및 의사소통의 핵심으로 지속적이고 빠른 피드백을 통해 의사소통과 좋은 분위기를 이어갈 수 있다
4. 단순함: 복잡한 방식으로 개발하는 것이 아닌 간결하고 단순하게 개발하여 어려움을 해소하고자 하는 것이다
5. 존경: 위의 모든 가치를 추구하는 과정에서 유지되어야 하는 가치이다

애자일 방법론의 종류

익스트림 프로그래밍, 스크럼, 린, DSDM, FDD(기능 개발 중심) 등

DSDM(Dynamic System Development Method)

동적 소프트웨어 방법론으로 사용자가 적극적으로 참여하여 개발팀에 영향을 주는 방법

FDD(Feature-Driven Development)

기능 개발 중심으로 설계 및 구축 기능에 중점을 두는 방식.
기능별로 개별적으로 수행해야 하는 매우 구체적이고 짧은 단계의 작업을 수행한다

⑦ XP (eXtreme Programming, 익스트림 프로그래밍)

• 소프트웨어 개발 방식을 애자일 모형으로 개발하는 대표적인 방법
• 전통적인 소프트웨어 개발 방법론과는 달리 문서화를 강조하지 않고 변경을 추구하며, 개발 초기부터 소프트웨어 검사를 병행할 것을 강력히 권고하는 새로운 방법론이다
• 의사소통의 개선과 즉각적인 피드백에 의한 단순한 코딩으로 소프트웨어 품질을 높이는 방법이다
• 12개의 실천 항목을 적용한다
• 애자일 방법론의 5가지(의사소통, 용기, 피드백, 단순함, 존경) 가치를 실현한 방법론이다

XP의 12개 실현 항목

1. Pair Programming: 하나의 작업을 2명의 개발자가 공동 수행
2. Planning Game: 게이머럼 목표를 두고 기획 수행
3. Text Driven Development: 단위 테스트 후 실제 코드 작성
4. Whole Team: 고객을 프로젝트팀원으로 상주
5. Continuous Integration: 살시 빌드 및 배포가 가능한 상태로 유지
6. Design Improvement: 불필요한 기능 제거 및 리팩토링
7. Small Releases: 필요한 기능들만 갖춘 간단한 시스템을 빠르게 배포
8. Coding Standards: 표준화 된 코드 작성
9. Collective Ownership: 소스코드는 모든 개발자가 언제라도 수정 가능
10. Simple Design: 가장 간결한 디자인 상태 유지
11. System Metaphor: 최종 개발되어야 할 시스템 구조를 조망
12. Sustainable Pace: 오버타임 지향

⑧ 스크럼 (SCRUM)

• 애자일 방법론 중의 하나로 프로젝트 관리를 위한 상호 점진적 개발 방법론
• 매일 정해진 시간, 정해진 장소에서 단기간에 개발하는 개발팀을 위한 프로젝트 관리 중심의 방법론이다
• 소프트웨어 유지보수팀이나 일반적인 프로젝트 관리에서도 적용될 수 있다
• 추정 및 조정 기반의 경험적 관리 기법이다

스크럼의 5가지 가치

• 활약: 약속을 확실히 실현한다
• 전념: 확약을 위해 실현에 전념한다
• 정직: 모든 사실을 숨기지 않는다
• 존중: 다른 사람에게 경의를 표한다
• 용기: 옮은 일을 할 수 있도록 갈등과 도전을 극복한다

스크럼의 요소

• 백로그(Backlog): 제품 기능 목록으로 사용자가 요구한 기능에 우선순위를 부여하여 나열한 목록이다
• 스프린트(Sprint): 단거리 선수가 전력 질주한다는 의미로 작업량이 많지 않고, 짧은 개발 단위를 단기간 내에 전력으로 개발하는 것을 말한다
• 스크럼 미팅: 5분 정도의 팀 미팅으로 작업의 계획을 수립한다
• 스크럼 마스터: 팀 리더로 효율적인 개발과 문제 해결을 위해 노력한다

⑨ 린 (Lean)

• 린 시스템의 품질 기법을 적용하여 개발 프로세스의 낭비적인 부분을 제거한 방법론이다
• 낭비적 요소를 제거하고, 개발 결과를 측정, 성과를 분석하여 품질을 향상시킨다

린 방법론의 7가지 원칙

• 낭비적인 요소를 제거한다
• 품질을 내재화한다
• 지식을 창출한다
• 가능한 늦게 결정한다
• 가능한 빠르게 인도한다
• 사람을 존중한다
• 전체 공정을 최적화한다

①⓪ DSDM (Dynamic Systems Development Method)

• 동적 시스템 개발 방법이다
• *RAD 방식으로 개발하여 소프트웨어의 개발 여부를 판단하는 방식이다
• DSDM 은 애자일 프로젝트 프레임워크로 개정되면서 소프트웨어 개발과 코드 작성보다는 프로젝트 관리, 솔루션 전달의 일반적인 접근 방식으로 발전되었다

RAD (Rapid Application Development)

- 초고속 응용 프로그램 개발 모형으로 사용자 요구사항의 일부분이나 제품의 일부분을 반복적으로 개발하여 최종 제품을 완성하는 방법이다
- 2~3개월 정도의 짧은 기간으로 기술적으로 위험이 적고 빠른 개발이 요구될 때 적합하다
- 빠른 개발을 위해 CASE 도구 및 Visual Tool, Code Generation Tool 등을 사용한다
- 프로토타입 사용, 개발 주기 동안 사용자의 적극적인 참여가 필요하다
- 통합 단계가 필요한 대규모 프로젝트에는 부적합하다

DSDM의 5단계

1. 타당성 조사: RAD 방식으로 개발하여 소프트웨어 개발 여부를 판단한다
2. 비지니스 연구: 사용자의 요구사항을 분석한다
3. 기능 모델 반복: 프로토타입을 개발하여 사용자의 요구사항을 받아들인다
4. 설계: 반복된 모델로 최종 설계를 한다
5. 구현: 설계 자료를 구현하며 테스트 단계를 통하여 최종 결과물을 만들어낸다

DSDM의 원칙

• 적극적인 사용자 참여는 필수적이다
• 개발팀이 의사 결정을 할 수 있도록 힘을 실어주어야 한다
• 수시로 제품을 인도해야 한다
• 비즈니스 목적에 부합하는 지가 필수 기준이 되어야 한다
• 반복적이고 점증적인 개발로 정확한 비지니스 솔루션으로 수렴하게 한다
• 개발하는 동안 발생되는 변경 사항은 원래 상태로 되돌릴 수 있어야 한다
• 요구사항은 상위 수준에서 기준선이 만들어진다
• 테스팅은 소프트웨어 생명주기 동안에 통합된다
• 모든 이해관계자 간의 협업과 협조가 필수적이다

①① FDD(기능 중심 개발) 방법

• 사용자가 원하는 기능의 시나리오에 필요한 만큼만 개발하는 방법이다
• 모듈이나 서비스 단위로 개발하는 것이 아니라 기능 중심 단위로 개발하는 방법이다
• 설계와 구축 기능을 중점으로 개발된다
• 모듈화와 구조화의 원칙을 지키면서 한 모듈이 개발되기 전에 테스팅할 수 있을 정도로만 개발하는 방법이다
• 개발 초기부터 기능을 테스트할 수 있기 때문에 *모듈 중심 개발보다 테스트가 빠르다
• 기능 중심 개발은 깊이 우선 통합이며, 모듈 중심 개발은 넓이 우선 통합이다
• 기능을 매우 구체적이고 짧은 작업으로 분할한다
• 작업을 시작하여 2주의 반복 주기로 기능을 개발한다
• 스크럼(SCRUM) 방법은 소프트웨어 개발보다는 프로젝트 관리를 위한 개발팀을 운영하는 효율적인 운영 방침이다
• 스크럼은 상품이나 서비스 단위로 개발되지만 FDD 방법은 기능 단위로 개발된다
• FDD 방법은 *5가지 기본 활동으로 구성된 단기 반복 프로세스이다
• 기능에 의한 설계롸 구현에 많은 시간(전체의 75% 이상)을 할당한다

모듈 중심 개발 방법의 단점

- 모듈(부품화된 프로그램)들을 모두 개발한 후 차후에 통합 과정과 테스트를 한다
- 통합 시점이 늦어지므로 기능을 테스트하는 시기도 늦어진다
- 당장 필요 없는 모듈이 개발될 수 있기 때문에 시간이 낭비될 수 있다

FDD 방법의 5가지 기본 활동

1. 전체 설계 작성
2. 기능 목록 작성
3. 기능에 의한 계획
4. 기능에 의한 설계
5. 기능에 의한 구현

6) 제품 계열 방법론 - 2010년대

• 제품 계열 방법론은 특정 제품에 적용하고 싶은 공통된 기능을 정의하여 개발하는 방법론이다
• 임베디드 소프트웨어를 작성하는 데 유용한 방법론이다
• *영역 공학과 *응용 공학을 연계시키기 위한 제품의 요구사항, 제품의 아키텍처, 제품의 조립 생산이 필요하다

영역 공학

영역 분석, 영역 설계, 핵심 자산을 구현하는 영역이다

응용 공학

제품 요구분석, 제품 설계, 제품을 구현하는 영역이다

7) 테일러링(Tailoring) 개발 방법론

테일러링(Tailoring)

- 양복을 고객의 몸에 맞게 재단한다는 뜻으로 주어진 대상에 맞게 줄이거나 늘리는 것을 말한다
- 시스템 개발에서는 표준 방법론이나 산출물을 활용하여 목적에 맞도록 조정하는 것이다

① 테일러링 개발 방법론의 특징

• 서로 다른 개발 환경하에서 개발되는 다양한 종류의 프로젝트를 하나의 일관된 개발 방법론으로 적용하기 어렵기 때문에 등장한 방법론이다
• 개발하려는 소프트웨어 특성에 맞게 융통성 있게 적용하는 방법론이다
• 표준 프레임워크를 기반으로 실제 업무 분야별로 여건에 맞게 수정 보완하는 방법이다
• 방법론에는 표준이 없다. 테일러링 방법론 또한 절차에 대한 구체적인 표준이 존재하지 않는다. 다만, 일반적으로 따르는 절차들과 개별 방법론에서 제시하는 테일러링 안내서들이 존재한 뿐이다
• 테일러링은 *커스터마이징의 작업이 반복될 뿐이다
• 테일러링 방법론에서 가장 중요한 부분은 프로젝트 분석이다
• 최적화된 방법론이 되기 위해서는 프로젝트의 다양한 특성들을 분석하여 쉽게 해결하고 진행이 용이하도록 테일러링 되어야 한다
• 테일러링을 위한 소프트웨어 개발 프레임워크에는 ISO/IEO 12207, CMMI 모델, SPICE 등이 있다

커스터마이즈 (Customize)

- 맞춤이라는 뜻으로 통상적으로 웹 사이트를 커스터마이징하라는 뜻은 원하는 요구조건으로 웹 사이트를 구죽하다라는 의미이다
- 고객이 기호에 따라 제품을 요구하면 생산자가 요구에 따라 제품을 만들어주는 일종의 맞춤 제작 서비스를 말하는 것으로, '주문 제작하다'는 뜻이다

옵치마이즈 (Optimize)

최적화, 최대한 좋게 만든다

마이그레이션 (Migration)

업그레이드, 새로운 환경으로 옮긴다

② 테일러링 개발 방법론의 필요성

• 내부 기준
  - 목표 환경: 개발 환경과 유형이 다른 경우 테일러링이 필요하다
  - 요구사항: 요구사항이 다른 경우 테일러링이 필요하다
  - 프로젝트 규모: 납기일(일정), 비용, 범위 등이 다른 경우 테일러링이 필요하다
  - 기술 환경: 방법론, 보유 기술, 구성원의 능력 등이 다를 경우 테일러링이 필요하다


• 외부 기준 - 법적 제약 사항: *IT 컴플라이언스 등이 다른 경우 테일러링이 필요하다
  - 표준 품질 기준: 표준 품질 기준이 다른 경우 테일러링이 필요하다

IT 컴플라이언스 (IT Compliance)

정부 기관이나 기업에서 IT 관련 업무에서 반드시 준수되어야 하는 엄격한 규칙과 지침 등을 말한다

8) 보안 개발 방법론

① MS-SDL (Microsoft Secure Development Life Cycle)

• 보안 수준이 높은 안전한 소프트웨어를 개발하기 위해 MS사가 자체적으로 수립한 SDLC(Software Development Life Cycle)이다

② Seven Touchpoints

• 실무적으로 검증된 개발 보안 방법론 중 하나로써 소프트웨어 보안의 모범 사례를 SDLC에 통합한 소프트웨어 개발 보안 생명주기 방법론이다

③ CLASP (Comprehensive Lightweight Application Security Process)

• 소프트웨어 개발 생명주기 초기 단계에서 보안을 강화하기 위한 정형화된 프로세스로써, 활동 중심 역할 기반의 프로세스로 구성된 집합체이다
• 이미 운영 중인 시스템에 적용하기에 적합한 방법론이다
• 개념, 역할 기반, 활동 평가, 활동 구현, 취약성의 5가지 관점에 따라 개발 보안 프로세스를 수행할 것을 제안하였다

④ CWE (Common Weakness Enumeration)

• 소프트웨어의 보안 취약점을 유발하는 원인을 7가지로 정리한 방법론이다
• 7가지 원인
  - 입력 데이터 검증 표현, 보안 기능, 시간 및 상태, 오류 처리, 코드 품질, 캡슐화, API 악용

Seven Touchpoints

코드 검토(Code Review)
아키텍처 위험 분석(Architecture risk analysis)
침투 테스트(Penetration testing)
위험 기반 보안 테스트(Risk base security test)
악용 사례(Abuse case)
보안 요구(Security Requirement)
보안 운영(Security Operation)