개발방법론 Flashcards
개발방법론
[리드] 소프트웨어 공학원리를 SDLC에 적용
[정의] SW SDLC 단계 별 상세 절차, 산출물, 기법, 도구 정의 등 공학적 기법으로 체계화/표준화한 이론
[출현 배경] 1.소프트웨어 위기에 따른 소프트웨어 공학 발전 2.소프트웨어 이용범위 확대 3.소프트웨어 프로젝트 대형화
[필요성] 1.작업의 표준화/모듈화 가능(개발경험 축적 및 재활용) 2.효과적인 프로젝트 관리 3.정형화된 절차와 표준용어를 통한 의사소통 수단 제공 4.품질 보증(각 단계별 검증과 종결 승인)
[특징]
- 개발단계 정의 : 활동, 제품, 검증절차, 종결기준
- 공학기법 정리 : 계획, 분석, 설계, 구축 단계 시 정형화 방법과 절차, 도구 정리
- 실무적 통합 : 개발 방법 및 절차, 도구를 실무적 관점에서 통합
[유형] (구정객CAS M)
1. 구조적 방법론(OLD) : 업무활동, 분할과 정복, 프로그램 로직, DFD(데이터 흐름도), Structure Chart
2. 정보공학 방법론 : 데이터 중심, Data Model, ISP,BAA,BSD,SD. E-R Diagram, 기능 차트
3. 객체지향 방법론 : 객체, 클래스, 관계 중심, 데이터, 로직 통합, Use Case, Sequence
4. CBD 방법론 : 컴포넌트 중심, 인터페이스, Black Box Reuse, Component Diagram
5. SPL : 자산 중심 재사용, Core Asset, Product, 도메인 기반 재사용, 조합
6. Agile : 사람 중심, 효율성, 반복 중시, XP, SCRUM, KANBAN, Lean
7. AOSE : 에이전트 기반, 유연성, 자율기반 조치, 독립적 뷰로 프로토콜 상호작용
8. MDD : 모델 기반, PIM ↔ PSM, 독립 모델 종속 모델 변환, 메타모델, 매핑
구조적 방법론
[정의] 고전적 폭포수 모델을 기반으로 한 순차적 개발 방법론
[특징] 구조중심 분석/설계/구현(정보와 정보, 기능과 기능 구조), 데이터 흐름 지향(폭포수 모델 기반, 하향식 설계 방식), 분할과 정복(추상화 원칙 기반), 간단(도형중심 분석 도구)
[단계] (요분설프) 1.요구사항 분석 → 2.구조적 분석 → 3.구조적 설계 → 4.구조적 프로그래밍
정보공학 방법론
[정의] 기업의 정보시스템을 구축하기 위해 계획,분석,설계 등 전 과정을 데이터 중심으로 정형화시킨 절차 및 방법론
[특징] 기업 중심, ISP중심, 데이터 중심, 분할과 정복, 공학적 접근, 사용자 참여
[구성요소]
1.ISP(정보전략수립) : 경영 전략 분석, 현 시스템 분석/평가, 아키텍처 개발, 전략 계획
2.BAA(사업영역분석): 데이터 모델, 프로세스 분할, 프로세스 의존 다이어그램, CRUD 매트릭스
3.BSD(업무시스템 설계): ERD, 분할/액션/의존 다이어그램, 데이터 흐름도, 결정트리
4.SD(구축 및 통합) : 데이터 사용 분석, 물리 DB설계, 분산 분석
[절차] ISP → BAA → BSD → 기술설계 → 구축 → 전환 → 운영
[차별화] Agile vs 정보공학 방법론
- 지향점 : 경험기반, 코드지향 / 정형 프로세스, 문서지향
- 산출물 : 백로그, 유저스토리 / STD, DFD(Data Flow Diagram)
객체지향 방법론
[정의] 객체, 클래스간의 높은 응집도, 낮은 결합도 기반의 모델 구축위한 소프트웨어 개발방법론
[모델링 목표] 결합도 감소, 응집도 향상, 재사용성/유지보수성 향상
[기본원리] 캡슐화, 추상화, 다양성, 정보은닉, 상속성
[구성요소] (객클인메메)
1. 객체(속성+메서드)
2. 클래스(공통 속성+메서드(행위) 단위)
3. 인스턴스(메모리 할당된 객체)
4. 메서드(클래스로부터 생성된 객체 행위)
5. 메시지(매개변수 통한 작업 요청)
[프로세스] (분설구)
1. 객체지향 분석 : 객체모델링(객체 Diagram) > 동적 모델링(Use Case Diagram) > 기능 모델링(상태 Diagram)
2. 객체지향 설계 : 시스템 설계(패키지 Diagram) > 객체 설계(상세화된 클래스 Diagram)
3. 객체지향 구현 : 코딩과 테스트
CBD
[리드] Black Box 재사용
[정의] 재사용 가능한 컴포넌트 기반 반복 점진적 개발 프로세스를 통해 고품질, 생산성 확보 및 유지보수 비용을 최소화하는 방법론
[배경] 객체지향 개발방법론 개선(개발생산성, 재사용성, 유지보수성 등)
[특징] 재사용성(컴포넌트 제작 기법통한 재사용성 향상), 확장성(아키텍쳐중심 개발), 유지보수성(대체성, 유용성, 반복개발)
[종류] Catalysis, RUP, XP, 마르미3
[프로세스] 도메인→컴포넌트→CBD
- CD (분설 추설구인): 도메인 분석 → 도메인 설계 → 컴포넌트 추출 → 컴포넌트 설계 → 컴포넌트 구현 → 컴포넌트 인증 → Repository (CMDB)
- CBD (요분 설조구): 요구사항 정의 → 영역 분석 → 컴포넌트기반 설계(Repository) → 컴포넌트 조립(Repository) → 응용 시스템 구축
[산출물]
1. 계획 : 비즈니스 프로세스, 개념모델, 프로젝트 계획서
2. 분석 : 유즈케이스(다이어그램, 명세서), 요구사항 추적표
3. 설계 : 설계서(사용자 I/F, 컴포넌트, DB설계), ERD 기술서
SPL
[정의] Domain Specific하게 재사용할 단위인 Core Asset을 미리 개발하고 이를 활용하여 다양한 Product를 만드는 개발 방법
[특징] SPL(Software Product Line) = 도메인공학 + CBSE(Component Based SW Eng.)
[구성요소]
1. Core Asset 개발 (Domain 공학) : 공통 요소 개발(플랫폼, 컴포넌트, 아키텍처, 각종 산출물 등)
2. Product 개발 (Application 공학) : Core Asset 이용 Product 개발로 신속한 출시
3. Management : Core Asset 개발과 Product개발의 연동/조율, 기술적 관리(형상관리, 프로세스 개선, 기술적 코칭), 조직적 관리(조직 구성 및 자원할당)
SSPL
[정의] SW와 HW 생산성 제고를 위해 단일 제품군 내에서 아키텍처나 컴포넌트, 문서 등 핵심자산은 재사용하고, 가변요소만 선택적으로 집중 개발해 이를 조립하는 SW공학 방법론
[특징] 재사용성, 아키텍처 기반, 리엔지니어링
[구성요소] 도애기관
1. 도메인 공학 : (요설구) 도메인 요구공학, 도메인 설계, 도메인 구현
2. 애플리케이션 공학 : (요설구) 애플리케이션 요구공학, 애플리케이션 설계, 애플리케이션 생성
3. 기획 : SSPL 스코핑(포트폴리오 결정, 도메인/자산 범위 결정), 개발 계획 수립
4. 관리 : 기술관리, 조직관리
[프로세스]
1.제품군 정의 → 2.제품군 플랫폼 개발 → 3.자산 구축 → 4. 개별 제품 생산 → 5. 제품 개량
애자일
[리드] 고객중심 유연한 개발
[정의] 변화에 유연하고 민첩한 대응위해 상호협력하며 반복 점진적 개발위한 코드지향 SW개발 방법론
[배경]
- Biz 변화 대응 : time-to-market, 정보 시스템 수명주기 단축, 요구사항 다양성
- 기존방법론 한계 : 문서/절차중심 방법론의 변화 대응 어려움
[구성요소]
- 애자일 조직 : Cross Functional(목저 달성 후 해체), 팀장 없는 수평적 구조, 적은 인원과 QA조직 불필요 (PO(Product Owner), SM(Scrum Manager), 개발자, 디자이너)
- 애자일 산출물 : Product backlog, Sprint backlog
- 애자일 개발기법 : Scrum, XP, Lean, Kanban
- 애자일 도구 : 애자일 추정, TDD, Product back 로그 기반 Story Point 추정 (플레이닝 포커, 도트 투표)
Agile 방법론의 효율적인 수행방안
[효율적인 수행 저해 요인]
- 기업 문화 수용 한계(사상이 아닌 기술접근, 협업 프로세스 한계), 대규모 프로젝트 적용 한계 (구현 모델 부족, 지속적 변화 관리 어려움)
* Agile 문화 체득화 및 자동화 기반의 지속적 변화 관리 프로세스 구축을 통해 효율적 수행전략 수립
[수행방안]
1. Agile 문화 내재화
- SW 생명주기(SDLC) 정의: 코드 작성, 자산관리, 기술 표준 지침 확림
- Agile 문화 체득 : Functional Team, Sprint 진행, 명확한 목적
- SW Visualization 기반 협력 환경 구축: Jira, Kanban, Git, Burndown Chart
2. 자동화, 지속적 반영 프로세스 구축
- DEVOPS 자동화 프로세스 구축: CI/CD, 코드형 인프라(IaC), 지속적 테스팅
- Agile 프로세스 모델 적용 : Scrum, XP, Lean + 디자인 씽킹
- Cloud Native 개발 환경 구축 : Docker, 컨테이너, MSA
XP
[정의] 짧은 주기의 반복을 통해 요구사항을 신속히 대응, 고품질의 SW를 빠르게 전달하는 Agile개발방법론
[등장배경]
1.RUP의 산출물 부담과 신속한 개발의 어려움
2.Time to Market 실현과 Products의 적시 배포
[핵심가치] (용단의피존)
1. 용기 : 고객 요구 사항 능동 대처
2. 단순성 : 부가기능 불필요한 구조/알고리즘 배제
3. 의사소통 : 개발자, 관리자, 고객간의 원활한 의사 소통
4. 피드백 : 지속적인 테스트, 반복 결함 수정, 빠른 피드백
5. 존경 : 상호 존중
[절차] (구리반승리)
1.구조적 스파이크 2.(유저 스토리)릴리즈 계획( 불확실한 추정 → 스파이크 → 믿음직한 추정) 3.반복 4.승인테스트 5.작은릴리스
[12가지 실천항목] (개관구환 페공지 게작메 심티리 40상)
- 개발 : 페어 프로그래밍, 공동소유/공동책임, CI
- 관리 : Planning Process, Small Release(2주), System Metaphor
- 구현 : Simple Design, TDD, 리팩토링
- 환경 : 40-hour work, 고객의 상주 / 기타 - 코드 표준 준수
SCRUM
[정의] Product backlog, 반복적 Sprint를 통해 신속하게 구현하는 Agile방법론
[구성요소]
1. 구성원 : ① Product Owner(제품관리자)(Product Backlog 작성, 관리 및 우선순위 결정) ② Scrum Master( 일정 추진 최종 결정권자, 팀원에 업무/권한 부여, 문제 상황 해결) ③ Scrum Team(4~7명의 개발자로 Sprint Backlog 기반 개발 진행)
2. 산출물 : ① Product Backlog ② Sprint Backlog ③ Burn Down/Up Chart 프스번
3. Action : ① Sprint Plan(계획) ② Daily Scrum(미팅) ③ Sprint Review (회고) 플스리
[프로세스]
1.Product Backlog 작성 2.스프린트 계획 3.스프린트(1~4주) 4.스프린트 개발 완료 5.스프린트 검토/회고
[스크럼의 3가지 기둥] 투명성, 점검(산출물들과 합의된 목표 꼼꼼히 점검), 조정
[스크럼의 5가지 가치] 확약(Commitment), 집중(Focus), 개방성(Opennes), 존중(Respect), 용기(Courage)
[효과적인 Scrum 적용방안]
1. Burndown Chart : 팀과 이해 관계자가 모두 볼 수 있는 시각적 아티팩트는 강력한 동기를 부여
2. The product owner : product backlog 관리, 명확한 가이드
3. The scrum master : 개발팀의 외부 요인으로부터 보호
4. The scrum team : 가이드 적용에 대한 노하우 축적
5. 사용툴 : JIRA(이슈관리), Bitbucket(소스관리), Confluence(문서관리)
KANBAN
[정의] 개발공정을 시각화하고, 작업 제한, 소요시간 최적화 기법을 통해 적시개발(JIT)를 지원 Agile 방법론
[필요성] 업무 흐름의 시각화, 진행 중 업무 제한, 흐름 측정 및 관리, 명시적 프로세스 정책 수립
* 칸반보드는 기본적으로 백로그, 계획(Todo), 진행중(Doing), 완료(Done)의 형태 사용
[메커니즘]
1.Workflow 가시화 : 작업을 분할(backlog)로하여 작업지시서(카드)에 기록하여 작업보드에 게시
2.WIP(Work in progress)제한 : 워크플로우의 적정 프로세스 관리(Bottle neck 관리통한 품질저하 방지)
3.Workflow 측정 및 최적화 : 평균시간, 사이클 타임을 산정하여 소요시간 최소화를 위한 프로세스 최적화
[실천방법] WIP제한, 흐름관리, 정책 명시화, 피드백루프실행, 시각화, 개선 및 발전
- 칸반보드 구성과 실천방법 기반으로 스크럼을 동시에 활용 가능한 스크럼반 이용
린
[정의] 프로세스 낭비요소 제거 후 결과를 측정,성과를 분석하여 소프트웨어의 품질을 향상시키는 개발 방법론
[린의 7원칙] (낭배결빠위통최)
1.낭비의 제거 2.배움증폭 3.늦은결정 4.빠른 납품 5.팀에권한 위임 6.통합성구축(사람 존중) 7.전체 최적화
[7대 낭비] (미가재이전지결)
1.미완성 작업 2.가외 기능 3.재학습 4.이관 5.작업 전환 6.지연 7.결함
TDD
[정의] 테스트 설계 후 이를 통과위한 프로그램 코드를 반복적인 Refactoring으로 완성해가는 개발방법론
[장점] 1) 품질향상(테스트영역 100%커버) 2) 짧은개발주기 3) 지속적인 테스트(리팩토링)
[절차] 요구사항 → 테스트케이스 추가 → 코드작성 → 테스트수행(Badsmell?) → 리팩토링 → Simple code
[패턴] (빨초테디X)
1. 빨간막대 패턴 : 테스트 작성 후 실행되지 않는 기 개발된 모듈 내부에 대한 검증
2. 테스팅 패턴 : 테스트-모듈 간의 적합성 및 성능, 견고함을 검증
3. 초록막대 패턴 : 코드가 테스트를 통과하도록 신속하게 작동하는 코드 작성
4. xUnit 패턴 : xUnit 계열의 테스트 프레임워크를 활용
5. 디자인 패턴 : Best Practices 모음
[고려사항]
- 빈번한 요구변경 : 요구사항 짧은 주기로 변경발생 =>과도한 테스트케이스변경 소스변경 발생
- 테스트케이스 독립성 확보 : 요구변경으로 인한 변경
- 테스트 자동화필요, 회귀테스트 환경수립 : 반복적테스트, 품질확보필요
[대응방안]
- 요구공학 통한 요구 명확화, 변경 최소화(요구 관리)로 부하 경감
- 테스트 전문가/조직 구성
- 자동화도구(테스트스텁, 드라이버)
- CI/CD프로세스 운용 : 회귀테스트 이후 릴리즈환경
MDD
[정의] 시장변화 적응 및 빠른 적용을 위해 플랫폼 종속적인 SW모델로 변환하고, 코드/산출물을 자동 생산하는 방법론
[특징]
- MDA기반 개발 방식, UML 모델링 언어로 소통, MDD 도구 필수
- 설계 후 구현까지 즉시 검증, 개발시간 단축, 설계=소스코드
- 기술과 업무 분리, 신속한 대응 및 반영, 효과적인 의사소통
[개발절차]
1. MDA 개발 : 타겟플랫폼 식별 → 메타모델식별/정의(CWMs) → 매핑기법 정의 구현(UML Profile)
2. MDD 개발 : PIM모델작성 → PSM모델생성 → Application완성(Code)
* 플랫폼 독립적, 설계수준의 재사용성, 구현 모델 자동화
[구성요소]
- MDA : MDD사상 적용 표준 아키텍처
- CIM : 모델 표준화. 연계시스템반영, SW맵핑 (분석가)
- PIM : 용어/아키 표준화. 언어특징 반영, 산출물 생성 (아키텍트)
- PSM : 코딩 표준화. 소스생성, 테스트전문 생성 (시스템 아키텍트)
- Code : Code Generator를 이용한 코드 자동 생성 (소스코드 산출물)
* SW모델(PIM)으로부터 플랫폼 종속적인 SW모델(PSM)으로 자동 변환하고 소스코드 자동 생성