정처기 #3 소프트 웨어 개발 방법론

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

1. 절차

타당성 검토 단 -> 계획 단계 -> 요구 사항 단계 -> 설계 단계 

-> 구현 단계 -> 시험 단계 -> 운용/유지 보수 단계

 

2. 특징 * 틀린 설명 문제

 

1970년까지 가장 많이 적용된 소프트 웨어 개발 방법론

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

 

2 ) 정보공학 방법론 - 1980년대 * 틀린 설명 문제

1. 절차

수직적 구조 방법론 

정보 전략 계획 -> 업무 영역 분석 => 업무 시스템 설계 -> 기술 설계 -> 업무 시스템 구축 -> 업무 시스템 실행

 

수평적 구조 방법론

데이터 -> 업무 활동 -> 상호 작용

 

2. 특징

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

3 ) 객체지향 방법론 - 1990년대 * 틀린 설명 문제

1. 절차

요구분석 -> 설계 -> 구현 -> 시험 -> 인수

 

2. 특징

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

4 ) 컴포넌트 기반 방법론 - 2000년대 * 틀린 설명 문제

1. 절차

개발 준비 -> 분석 -> 설계 -> 구현 -> 시험 -> 전개 -> 인도

 

2. 특징

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

3. 위기(문제점)

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

5 ) 애자일 방법론 - 2000년 이후 * 틀린 설명 문제

1. 등장 배경

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

 

2. 정의

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

3. 특징

 

• 개발 과정의 소통을 중요하게 생각하는 소프트웨어 개발 방법론으로 반복적인 개발을 통한 잦은 출시를 목표
• 기존 모형(폭포수 모형, 프로 토타 팁 모형, 나선형 모형)의 문제점을 보완한 모형

• 폭포수 모형(Waterfall Model): 폭포수의 물 흐름처럼 한번 지나가면 다시는 되돌릴 수 없듯이 각 단계를 명확히 하고 다음 단계로 넘어감 
•  프로토 타입 모형(Prototyping Model) : 시스템 개발 초기에 사용자의 요구 기능을 시제품으로 만들어 사용자로 하여금 기능과 사용성 등에 대해 검증시켜 가면서 시스템을 개발하는 기법
• 나선형 모형(Spiral Model) : 폭포수 모형과 프로토타입 모형의 장점을 사린 모형으로 사용자 요구 확인에 의한 개발 시스템 개발 가능, 위험분석을 하면서 시스템 개발

• 소프트웨어를 집중적으로 개발
• 출시 주기를 짧게 해 다양한 요구 변화에 대응
• 고객과 개발팀과의 소통, 개발팀원 간의 소통, 협력을 극대화
• 인간의 수행 능력을 높이기 위한 현실적인 방법을 제시
• 가볍고 실용적인 소프트웨어 개발 방법론
• 애자일 방법론은 소프트웨어의 개발 방법론의 방법론

4. 선언문 * 선언문이 아닌 것 찾기

2001년에 4가지 애자일 선언문 발표

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

• 개인과 상호작용을 프로세스와 도구보다 중시
• 동작하는 소프트웨어를 포괄적인 문서보다 중시
• 고객과의 협력을 계약의 협상보다 중시
• 변화의 대응을 계획의 수행보다 중시

5. 원칙 * 원칙이 아닌 것

1. 소통한다
2. 협력한다.
3. 적응한다.
4. 지속한다.
5. 가치를 전달한다.
6. 피드백한다.

 

6. 5가지 가치 * 가치가 아닌 것

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

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

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

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

8. 스크럼(SCRUM)

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

 

스크럼의 5가지 가치

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

 

스크럼의 요소

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

 

9. 린(Lean)

시스템의 품질 기법을 적용해 개발 프로세스의 낭비적인 부분을 제거한 방법론

낭비적 요소를 제거하고, 개발 결과를 측정, 성과를 분석해 품질을 향상

 

7가지 원칙 * 스크럼 5가지와 연동 문제 나옴

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

10. DSDM(Dynamic Systems Development Method)

동적 시스템 개발 방법

RAD방식(초고속 응용프로그램 개발 모형)으로 개발해 소프트웨어의 개발 여부를 판단하는 방식

프로젝트 관리, 설루션 전달의 일반적인 접근 방식으로 발전

 

DSDM의 5단계

1. 타당성 조사: RAD방식으로 개발하여 소프트웨어의 개발 여부를 판단

2. 비즈니스 연구: 사용자의 요구사항을 분석

3. 기능 모델 반복: 프로토 타입을 개발하여 사용자의 요구사항을 받아들임

4. 설계 : 반복된 모델로 최종 설계를 한다.

5. 구현 : 설계 자료를 구현하며 테스트 단계를 통하여 최종 결과물을 만듦

 

DSDM의 원칙

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

11. FDD(기능 중심 개발) 방법

사용가 원하는 기능의 시나리오에 필요한 만큼만 개발하는 방법 

모듈이나 서비스 단위로 개발하는 것이 아니라 기능 중심의 단위로 개발하는 방법

설계와 구축 기능을 중점으로 개발

모듈화와 구조화의 원칙을 지키면서 한 모듈이 개발되기 전에 테스트를 할 수 있을 정도로만 개발

개발 초기부터 기능을 테스트 가능 해 모듈 중심 개발보다 테스트가 빠름

FDD는 깊이 우선 통합이며, 모듈 중심 개발은 넓이 우선 통합

기능을 매우 구체적이고 짧은 작업으로 분할

작업을 시작해 2주의 반복 주기로 기능을 개발

스크럼 방법은 소프트 웨어 개발보다는 프로젝트 관리를 위한 개발되지만, FDD는 기능 단위로 개발

기능에 의한 설과 구현에 많은 시간을 할당

5가지 기본 활동으로 구성된 단기 반복 프로세스

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

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

특정 제품에 적용하고 싶은 공통된 기능을 정의하여 개발하는 방법론

임베디드 소프트웨어를 작성하는 데 유용한 방법론

영역 공학과 응용공학을 연계시키기 위한 제품의 요구사항, 제품의 아키텍처, 제품의 조립 생산이 필요

 

7 ) 테일러링 방법론 -  틀린 설명 문제

1. 특징

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

2. 필요성

내부 기준

• 목표 환경
• 요구사항
• 프로젝트 규모
• 기술 환경

외부 기준

• 법적 제약 사항
• 표준 품질 기준

8 ) 보안 개발 방법론 

1. MS-SDL(Microsoft Secure Development Life Cycle) :  MS사가 자체적으로 수립한 SDLC(Software Development Life Cycle)
2. Seven Touchpoints: 소프트웨어의 보안의 모범 사례를 SDLC에 통합한 소프트웨어 개발 보안 생명주기 방법론
3. CLASP(Comprehensive Lightweight Application Security Process)

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

 4. CEW(Common Weakness Enumeration)

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

 

출처 이기적 정보처리기사