1. ATDD(Acceptance Test Driven Development)의 개요

 1-1. ATDD(Acceptance Test Driven Development)의 정의

   - 테스트로부터 시작해서 구현을 마무리 짓는 TDD의 범위를 소스 코드 수준에서 기능 테스트 수준까지 확장하여 고품질의 소프트웨어를 생산하는 개발 방법론

 

 1-2. ATDD(Acceptance Test Driven Development)의 필요성

   - 테스트 케이스 명확: 개발 착수 전 사용자, 개발자, QA등 제품 관련자들이 인수 테스트 케이스를 작성

   - 커뮤니케이션 도구: 토론하는 과정을 통해 요구사항에 대한 오해가 없고 충분한 의사소통가능

 

2. ATDD(Acceptance Test Driven Development )의 프로세스, 단계별 활동, 관련 기법간 비교

 2-1. ATDD(Acceptance Test Driven Development)의 프로세스

 

 2-2. ATDD(Acceptance Test Driven Development)의 단계별 활동

  1) 요구사항 토론
   활동 : 명확한 인수 기준 항목, 기능별 질문 사항 요구
   연관요소: 이해관계자와 협업, 자연어 기반 기록

 2) 프레임워크 포맷 기반의 케이스 작성
   활동: 테스트 자동화 F/W, 다양한 유형 테스트
   연관요소: FIT, Selenium

 3) TDD 수행
   활동: 테스트 픽스처 작성, setUp, tearDown
   연관요소: Regression Test, SUT

 4) 탐색적 테스팅
   활동: Test Code를 수행하면서 테스트 시나리오 작성
   연관요소: 테스트 차터

 

 2-3. ATDD(Acceptance Test Driven Development)와 관련 기법간 비교

항목 ATDD TDD
관점 인수테스트 단위테스트
용어사용 TDD 기반 언어 비 표준 어휘
핵심 User Story 기반 테스트 케이스
사례 assert(기대값, 실제값) assert(기대값, 실제값)
대표 F/W FIT xUnit
장점 인수 품질 향상 코드 품질 향상
단점 오랜 작성기간 설계관점 취약

- ATDD 시스템 품질(상위 레벨), TDD 소스 품질(하위 레벨)

'1. IT Story > Basic Studies' 카테고리의 다른 글

SCRUM  (0) 2019.06.24
ALM(Application Lifecycle Management)  (0) 2019.06.23
Daily Build  (0) 2019.06.22
CI(Continuous Integration)  (0) 2019.06.21
SEM(Strategic Enterprise Management)  (0) 2019.06.19
TDD (Test Driven Development)  (0) 2019.06.18
XP (extreme Programming)  (0) 2019.06.17
Agile 개발방법론  (0) 2019.06.16
블로그 이미지

운명을바꾸는자

IT와 함께 살아가는 삶

,

1. SEM(Strategic Enterprise Management)의 개요

 1-1. SEM(Strategic Enterprise Management)의 정의

   - 기업의 경영 정보를 보다 정확히 판단하여 최고 경영진 및 임원으로 하여금 가치 중심의 경영을 전사적으로 구현할 수 있게 해주는 일련의 통합 경영 관리 체계.

 

 1-2. SEM(Strategic Enterprise Management)의 특징

   - 경영진이 가치 창출에 경영 활동을 집중하도록 회사의 비전, 목표, 전략을 정렬

   - 전략과 운영을 연계하며, 수익성을 제고하는 전략 경영을 위한 통합된 시스템

 

2. SEM(Strategic Enterprise Management)의 개념도, 구성요소

 2-1. SEM(Strategic Enterprise Management)의 개념도

 

 2-2. SEM(Strategic Enterprise Management)의 구성요소

 1) 가치중심 경영, VBM (Value Based Management)

   - 정의: 경영의사결정의 판단 기준을 손익위주에서 기업의 가치 중심으로 전환하여, 장기적으로 회사의 미래 성장이 유지되도록 계획, 실행, 통제함으로써 회사의 기업가치를 최대화 해나가는 동태적인 경영 사고

 2) 활동중심 원가관리, ABM (Activity Based Management) ABC(Costing)

   - 정의: 의사결정과정에서 경영자를 지원하는 강력한 도구이며, ABC 원가정보를 이용하여 기업에 나타나는 다양한 전략적이고 운영적인 의사결정이 이루어지게 하는 경영활동

 3) 기업성과 관리, BSC (Balanced Scorecard)

   - 정의: 기업의 성과를 재무, 고객, 내부 프로세스, 학습과 성장의 네 가지 관점에서 종합적이고 균형적으로 측정하는 성과 관리 시스템

 4) 실시간 분석 도구 OLAP (OnLine Analytical Processing)

   - 정의 : DW에 저장되어있는 대용량 데이터를 사용자의 의도대로 쉽게 사용(질의, 가공, 보고서작성, 분석)할 수 있도록 하는 데이터 처리 기법

 

3. SEM(Strategic Enterprise Management) 향후 전망

  - 부가가치 우선의 가치경영 도입의 필수적인 환경으로 발전

  - ERPⅡ, SCM, CRM 등의 업무성과 평가 측정을 위한 시스템의 연계

  - 경영 전략과의 연동 및 보상 체계와 연계

  - VBM, BSC, ABM 등의 신 경영지식과 신 정보기술로의 결합

'1. IT Story > Basic Studies' 카테고리의 다른 글

ALM(Application Lifecycle Management)  (0) 2019.06.23
Daily Build  (0) 2019.06.22
CI(Continuous Integration)  (0) 2019.06.21
ATDD(Acceptance Test Driven Development)  (0) 2019.06.20
TDD (Test Driven Development)  (0) 2019.06.18
XP (extreme Programming)  (0) 2019.06.17
Agile 개발방법론  (0) 2019.06.16
CBD(Component Based Development)방법론  (0) 2019.06.14
블로그 이미지

운명을바꾸는자

IT와 함께 살아가는 삶

,

1. TDD (Test Driven Development)의 개요

 1-1. TDD (Test Driven Development)의 정의

  - 프로그램에 대한 Test Case를 먼저 개발하고 이 Test Case를 통과하는 실제코드를 나중에 개발하는 Agile 개발방법

  - 테스트 작성으로 요구사항 검증 및 설계의 고도화, 짧은 주기에 Lifecycle을 반복하는 테스트-설계-피드백 중심의 개발 사고방식/방법론

 

 1-2. TDD (Test Driven Development)의 특징

  - Design for Testability : 소스코드의 의존성이 감소하고 독립적인 테스트가능

  - 테스트 커버리지 확보 : 단위테스트를 통한 테스트 커버리지 유지, 디버깅감소

  - Clean code that works : 작동하는 깔끔한 코드지향

 

2. TDD (Test Driven Development)의 개념도, 구성요소, 패턴

 2-1. TDD (Test Driven Development)의 개념도

  - Needs --> 해결방안모색 TODO List 작성 --> TODO List 세분화 --> Test 로 시작하는 method를 만듦 --> 테스트가 실패할 경우 실제코드를 작성 --> 가장빨리 테스트를 통과 --> 중복을 제거한 리팩토링--> 테스트코드로 밝히는 진실 --> 테스트 통과

 

 2-2. TDD (Test Driven Development)의 구성요소

  1) 사용자 요구사항 : 사용자, BA, 제품 개발자 등이 요구사항 Story작성, 유저스토리

  2) Test Case : 사용자, Tester등 관련자들이 Test Case 작성, Test Case

  3) Code 작성 : 테스트에 대해 실행 가능한 코드 작성. 임시코드

  4) Refactoring : Bad Small을 제거하여 Refactoring 수행, 리펙토링

 

 2-3. TDD (Test Driven Development)의 패턴

  1) 빨강막대 패턴 : 테스트를 언제, 어디에 작성할 것인지, 언제 멈출 것인지 결정

  2) 초록막대 패턴 : 코드가 테스트를 통과하도록 신속하게 작동하는 코드작성

  3) 테스트 패턴 : 상세한 테스트를 작성, 자식/모의객체/Self-Shunt/메시지 호출

  4) xUnit패턴 : 자동화된 단위테스트 지원 프레임 워크, jUnit, CppUnit, PyUnit

  5) 디자인 패턴 : 검증된 해결책 설계, Template/Best Practice

'1. IT Story > Basic Studies' 카테고리의 다른 글

Daily Build  (0) 2019.06.22
CI(Continuous Integration)  (0) 2019.06.21
ATDD(Acceptance Test Driven Development)  (0) 2019.06.20
SEM(Strategic Enterprise Management)  (0) 2019.06.19
XP (extreme Programming)  (0) 2019.06.17
Agile 개발방법론  (0) 2019.06.16
CBD(Component Based Development)방법론  (0) 2019.06.14
객체지향방법론  (0) 2019.06.13
블로그 이미지

운명을바꾸는자

IT와 함께 살아가는 삶

,

1. XP (extreme Programming)의 개요

 1-1. XP (extreme Programming)의 정의

   - 짧은 개발주기 반복(Iteration)을 통해 고객이 원하는 핵심적인 기능을 우선 구현 함으로서 프로젝트의 위험을 줄이는 프로그래밍 중심의 소프트웨어 개발방법론

 1-2. XP (extreme Programming)의 특징

  1) 신속한 피드백 : 개발자가 짧은 단위로 고객의 피드백을 받아서 고객의 요구 반영 확인 

  2) 단순함을 전제 : 현재의 문제에 집중해서 작업하고 미래의 일에 대해 걱정하지 않음

  3) 점진적인 수정 : 문제를 풀 때의 과정은 작은 교정의 연속

  4) 변화의 인정 : 변경 및 변화는 당연히 발생하는 것이라 인정함

  5) 고품질의 작업 : 선 테스트 후 프로그래밍 방법(TDD)으로 테스트의 중요성 강조

 

2. XP (extreme Programming)의 핵심 가치와 실천항목

 2-1. XP (extreme Programming)의 핵심 가치

  1) 용기 : 고객의 요구사항 변화에 능동적인 대처

  2) 단순성 : 부가적 기능, 사용되지 않는 구조와 알고리즘 배제

  3) 커뮤니케이션 : 개발자, 관리자, 고객 간의 원활한 의사소통

  4) 피드백 : 지속적인 테스트와 통합, 반복적 결함 수정, 빠른 피드백

 

 2-2. XP (extreme Programming)의 실천항목

구분 실천항목 설명
계획 Planning Game 유저 스토리 이용, 개발 계획을 빠르게 수립
분석 / 설계 On-Site Customer 개발 효율성을 위해 고객을 프로젝트에 상주시킴
Simple Design 가능한 가장 간략한 디자인 상태 유지
Metaphor 최종적으로 개발되어야 할 시스템의 구조 기술
구현 Refectoring 프로그램 기능은 변경 없이 중복/복잡성 제거
Pair Programming 두 사람이 함께 프로그래밍(driver/partner)
Continuous Integration 한 작업이 끝날 때 마다 지속적으로 통합하고 동시 테스트
테스트 Testing 개발자가 먼저 단위 테스트, 실제 코드를 작성하기 전에 먼저 작성함으로써 자신이 무엇을 해야 하는지 스스로 깨우침
배포  Small Release 필요한 기능만을 갖춘 간단한 시스템을 빠르게 릴리즈
환경 40hour Week

주 40시간 이상을 일하지 말도록 규칙을 정함 (2주를 연속으로 오버타임 하지 않도록 함)

Code Standard 팀원간 협업을 위해 코드가 표준화된 관례에 따라 작성됨
Collective Ownership 팀의 모든 프로그래머가 소스코드에 대한 공동 책임

 

3. XP (extreme Programming)의 개발 프로세스

 

 1) 사용자 스토리
    - 사용자 요구사항/UML의 유즈케이스와 같은 목적

 2) 스파이크
   - 어려운 요구사항 혹은 잠재적인 솔루션들을 고려하기 위해 작성하는 간단한 프로그램

 3) 배포계획
   - 전체 프로젝트에 대한 배포 계획 생성

 4) 반복
   - 하나의 반복을 1~3주 정도로 나누고 반복들을 프로젝트 전반에 균일하게 유지

 5) 인수테스트
- 고객은 제대로 작동하는 시스템을 보면서 진척사항을 확인하고 이 시스템이 자신이 직접 명세한 테스트를 통과했는지 파악

 6) 작업배포
- 소규모로 빈번하게 배포하여 고객에게 이득 조기 제공

'1. IT Story > Basic Studies' 카테고리의 다른 글

CI(Continuous Integration)  (0) 2019.06.21
ATDD(Acceptance Test Driven Development)  (0) 2019.06.20
SEM(Strategic Enterprise Management)  (0) 2019.06.19
TDD (Test Driven Development)  (0) 2019.06.18
Agile 개발방법론  (0) 2019.06.16
CBD(Component Based Development)방법론  (0) 2019.06.14
객체지향방법론  (0) 2019.06.13
정보공학방법론  (0) 2019.06.12
블로그 이미지

운명을바꾸는자

IT와 함께 살아가는 삶

,

1. Agile 개발방법론의 개요

 1-1. Agile 개발방법론의 정의

- 절차보다는 사람이 중심이 되어 변화에 유연하고 신속하게 적응하면서 고객과 상호작용하며 반복적으로 SW개발하는 방법론

 

 1-2. Agile 개발방법론의 등장배경

  1) S/W개발 환경 변화 

    - 정보시스템의 time-to-market과 적시배포가 중요해짐

    - 사용자의 요구가 다양해지고 수명주기가 짧아짐

 

  2) 기존 개발방법론의 한계

   - 문서 및 절차위주의 방법론은 변화에 신속 대응 어려움

   - 변화에 빠르게 적응하고 효율적으로 개발할 수 있는 방법론 필요

 

  1-3. Agile 개발방법론의 4가지 핵심가치

   1) 프로세스나 도구에 앞서, 개인의 상호 협력을 중시

   2) 포괄적인 문서에 앞서, 작동하는 소프트웨어를 중심

   3) 계약 협상에 앞서, 고객과의 협력을 중시

   4) 계획 준수에 앞서, 변화에 대응을 중시

 

2. Agile 개발방법론의 개념도, 특징, 종류

 2-1. Agile 개발방법론의 개념도

 

  2-2. Agile 개발방법론의 특징

   1) 가변적 요구 대응

      - Predictive 하기 보다는 Adaptive한 방식임

   2) 고객만족

     - 개발 후반부라도 요구사항의 변화 적극 수용

     - 고객의 요구 사항 신속 대응: S/W 배포 일정이 짧음

   3) 개발자 동기부여

    - 개발자에게 적합한 개발환경 구성

    - 개발자가 책임을 완수할 것으로 신뢰

   4) PM의 역할변화

    - 프로젝트 관리자에서 촉진자로 변경

    - 프로젝트 계획수립 및 통제의 책임이 팀원에게 이양

   5) Sweet Spots

    - 한 작업실에 5~8명의 작업자

    - Key User 상주: 개발자와 사용자간 중계역할, 신속한 피드백 가능

   6) 적용 범위

    - 중소형, 아키텍처 설계, 프로토타이핑에 적합

 

  2-3.  Agile 개발방법론의 종류

   1) XP
    - extreme programming
    - 의사소통 개선, 즉각적인 피드백에 의해 단순하게 코딩하여 S/W 품질 향상
    - 테스트 강조, 4가지 가치와 12개 실천항목
    - 1~3주 단위의 반복
    - 가장 주목 받음
    - 개발 관점


  2) SCRUM
    - 프로젝트를 스프린트(30일 단위 반복)로 분리, 팀은 매일 스크럼(15분정도) 미팅으로 계획수립
    - 팀 구성원이 어떻게 활동해야 하는가에 초점
    - 통합 및 인수 테스트가 상세하지 않음
    - Iteration 계획과 Tracking에 중점


  3) UP
    - 완전한 S/W 개발 모델 제시
    - 비주얼 모델링 도구 지원
    - Agility 성격 강조


  4) Crystal
    - 프로젝트 상황에 따라 알맞은 방법론을 적용할 수 있도록 다양한 방법론 제시
    - Tailoring 하는 원칙 제공
    - 프로젝트 중요도와 크기에 따른 메소드 방법 제시


  5) FDD
    - Feature Driven Development
    - 기능 모델, 설계와 구현, 수행의 3단계 사이클
    - 짧은 Iteration(2주)과 5단계 프로세스
    - 설계와 구축 프로세스의 반복

'1. IT Story > Basic Studies' 카테고리의 다른 글

ATDD(Acceptance Test Driven Development)  (0) 2019.06.20
SEM(Strategic Enterprise Management)  (0) 2019.06.19
TDD (Test Driven Development)  (0) 2019.06.18
XP (extreme Programming)  (0) 2019.06.17
CBD(Component Based Development)방법론  (0) 2019.06.14
객체지향방법론  (0) 2019.06.13
정보공학방법론  (0) 2019.06.12
구조적방법론  (0) 2019.06.11
블로그 이미지

운명을바꾸는자

IT와 함께 살아가는 삶

,

with recursive t (inhrelid, inhparent, depth) 
as (
        select  inhrelid, inhparent, 1 
        from    pg_inherits pi
        union all
        select  pi.inhrelid, pi.inhparent, depth + 1
        from    t, pg_inherits pi
        where   pi.inhparent = t.inhrelid
)
select pa.rolname,
       (select relname from pg_class where oid = pi.inhparent) as table_name,
       pcs.relname as partition_name,
       pt.spcname as tablespace_name,
       case ppt.partstrat when 'l' then 'list' when 'r' then 'range' else 'not partition' end as partition_type,
       dr.DEGREE,
       pc.reltuples::int as row_nums,
       pg_size_pretty(pg_table_size(pc.oid)) as size,
       pg_get_expr(pc.relpartbound, pc.oid) as partition_value
from    pg_class pcs
join    pg_inherits pi 
        on pc.oid = pi.inhrelid
join    pg_partitioned_table ppt 
        on ppt.partrelid = pi.inhparent
join    pg_authid pa 
        on pc.relowner = pa.oid
join    pg_tablespace pt 
        on pt.oid = case 
                        when pc.reltablespace = 0 
                            then (
                                    select  dattablespace 
                                    from    pg_database 
                                    where   datname=current_database()
                                 )
                        else pc.reltablespace 
                    end
join (
        select inhrelid, inhparent, max(depth) as degree
        from t
        group by inhrelid, inhparent
     ) dr 
     on dr.inhrelid = pc.oid
WHERE   DEGREE='1'
order by degree, table_name, partition_name;
블로그 이미지

운명을바꾸는자

IT와 함께 살아가는 삶

,

1. CBD(Component Based Development)방법론의 개요

 1-1. CBD(Component Based Development)방법론의 정의

    - 재사용 가능한 컴포넌트의 개발 또는 상용 컴포넌트들을 조합하여 어플리케이션의 개발생산성과 품질을 높이고 시스템 유지보수비용을 최소화하는 혁신적 방법

 

 1-2. CBD(Component Based Development)방법론의 등장배경

    - 객체지향 개발 방법론이 해결하지 못한 개발 생산성, 재사용성, 시스템 유지보수성 등을 해결하기 위한 대안으로 등장

    - 업무, 기술, e-Business 조직의 변화

 

2. CBD(Component Based Development)방법론의 개발 프로세스 구조, 프로세스 요소

 2-1. CBD(Component Based Development)방법론의 개발 프로세스 구조

 

 

 2-2. CBD(Component Based Development)방법론의 프로세스 요소

  1) CD
    - CD (Component Development)
    - SW 개발에 필요한 부품을 만드는 과정
    - 재사용 목적상 해당 도메인에 대한 분석이 핵심사항

  2) CBD
   - CBD (Component Based Development)
   - 컴포넌트들을 조립하여 새로운 응용 소프트웨어 제품개발
   - 반복적 개발 프로세스를 적용하여 혁신적인 생산성 향상

 

3. CBD(Component Based Development)방법론의 구축방안

  1) 아키텍처 중심적 : 아키텍처 중심 개발을 통한 가시성 확보, 위험 조기 식별 및 대응

  2) 엔지니어링 도구 : 자동화된 툴을 통해 생산성과 정확성 향상 가능

  3) 프레임워크 기반 : 프레임워크 기반 개발은 개발생산성 향상 및 품질향상의 기반 역할

  4) 수행조직 : 컴포넌트 개발팀, 솔루션 개발팀, 조직지원팀의 역할 분담

  5) 표준 및 방법론 :

    - 실행환경 표준: .NET, J2EE, CCM
    - 개발표준:UML기반 개발표준 및 RUP와 같은 방법론

  6) 개발 역량 강화 : 개발팀원의 기반 기술 습득 정도, 표준 이해 및 준수 정도

  7) 재사용관리체계 : 컴포넌트 재사용 자산 축적 및 품질관리 체계 구축 중요

  8) 경험 축적 : 프로젝트 관리나 아키텍처 정립에 대한 경험과 적용 능력 중요

  9) 정책 : 개발자들이 컴포넌트에 대해 긍정적인 마인드를 갖도록 고취

'1. IT Story > Basic Studies' 카테고리의 다른 글

SEM(Strategic Enterprise Management)  (0) 2019.06.19
TDD (Test Driven Development)  (0) 2019.06.18
XP (extreme Programming)  (0) 2019.06.17
Agile 개발방법론  (0) 2019.06.16
객체지향방법론  (0) 2019.06.13
정보공학방법론  (0) 2019.06.12
구조적방법론  (0) 2019.06.11
SW개발방법론  (0) 2019.06.09
블로그 이미지

운명을바꾸는자

IT와 함께 살아가는 삶

,

1. 객체지향방법론의 개요

 1-1. 객체지향방법론의 정의

- 프로그램을 객체와 객체간의 인터페이스 형태로 구성하기 위하여 문제영역에서 객체와 클래스, 이들간의 관계를 식별하여 설계모델로 변환하는 방법론

 

 1-2. 객체지향방법론의 기본 원칙

 1) 캡슐화 : 메시지만으로 객체와 상호작용, 접근지정자(Public/Private)

 2) 추상화 : 복잡함을 간단히 분석의 초점을 명확히, 자료/기능/제어 추상화

 3) 다형성 동일인터페스 서로 다른 응답하는 특성, Overriding, Overloading  

 4) 정보은닉 : 객체의 내부구조와 실체분리, 멤버변수 접근제한

 5) 상속성 : 수퍼클래스의 성질 서브클래스에 자동부여, 단일/다중/반복/선택

 

 1-3. 객체지향방법론의 특징

 

2. 객체지향방법론의 방법론 절차, 단계별 작업 항목

 2-1. 객체지향방법론의 방법론 절차

 

 2-2. 객체지향방법론의 단계별 작업 항목

  1) 객체지향 분석 (3가지 모델링)

   - 객체모델링-객체다이어그램: 시스템 정적 구조 포착

   - 동적모델링-상태다이어그램: 시간의 흐름에 따라 객체간 변화조사

   - 기능모델링-자료흐름도: 입력에 대한 처리결과에 대한 확인

 

  2) 객체지향 설계 (3가지 모델 통합)

   - 시스템 설계: 시스템 구조설계,성능 최적화 방안, 자원분배

   - 객체 설계: 구체적 자료 구조와 알고리즘 구현

 

  3) 객체지향 구현

   - 객체지향 프로그래밍: 객체지향언어(C++, JAAVA), 객체지향 DBMS

 

'1. IT Story > Basic Studies' 카테고리의 다른 글

TDD (Test Driven Development)  (0) 2019.06.18
XP (extreme Programming)  (0) 2019.06.17
Agile 개발방법론  (0) 2019.06.16
CBD(Component Based Development)방법론  (0) 2019.06.14
정보공학방법론  (0) 2019.06.12
구조적방법론  (0) 2019.06.11
SW개발방법론  (0) 2019.06.09
EAP (Enterprise Architecture Planning)  (0) 2019.06.08
블로그 이미지

운명을바꾸는자

IT와 함께 살아가는 삶

,