Software Development Life Software Development Life
Cycle (SDLC)
Cycle (SDLC)
소프트웨어의 이해 소프트웨어 위기
I II
III 소프트웨어 개발 생명 주기
IV Waterfall Model
V Prototyping Model
VI Evolutionary Model
VII
Component Based Dev. Model
VIII
3 5 7 8 12 13 15 18
Iterative & Incremental Dev. Model
IX 21
Spiral Model
목목 차차
소프트웨어의
소프트웨어의 이해 이해 (1/2) (1/2)
프로그램과 소프트웨어
프로그램 ?Â
정의 논리적, 산술적 그리고 신속하게 처리되어야 할 기능들을 프로그래밍 언어로 구현한 명령어 및 관련 데이터의 집합
소프트웨어?Â
정의 작성된 프로그램을 상품화한 것
Â
소프트웨어의 특성 유형성 : 프로그램 코드를 인쇄시켜 볼 수도 있고 분석/설계 산출물로 가시화시킬 수 있다.
동적행위성 : 프로그램은 정적인 반면 소프트웨어는 동적이다. 프로그램이 하드웨어에 의해 수행되고 사용자와 상호작용할 때 비로소 소프트웨어가 된다.
상품성 : 개발된 프로그램은 제품에 불과하고 포장이 되고 사용자가 사용할 가치가 생김으로 써 상품이 된다.
견고성 : 소프트웨어의 행위는 예측이 어렵고 수정이 용이하지 않다. 따라서 소프트웨어가 한 번 구조성을 잃으면 유지보수는 점점 어려워지므로 ‘소프트’라는 단어처럼 그리 유연하지 못하다는 것이다.
비마모성 : 소프트웨어는 하드웨어와 달리 마모되지 않고 품질이 저하되는 특징이 있다.
소프트웨어의
소프트웨어의 이해 이해 (2/2) (2/2)
소프트웨어의 분류
정보처리 방법에 의한 분류Â
일괄처리, 온라인, 실시간 등
사용자와 하드웨어 사이의 위치에 의한 분류Â
시스템 및 응용 소프트웨어 등
기능 수행방법에 의한 분류Â
계산, 정보처리, 절차, 지식 기반 등
개발 목적에 의한 분류Â
프로토타입, 프로젝트, 패키지 등
획득 방법에 의한 분류Â
패키지, 주문형 등
하드웨어 및 운영체제에 의한 분류Â
메인프레림, 중형, PC, 워크스테이션용 등
규모에 의한 분류Â
라인이나 기능점수 등 규모에 의해 분류
최신 기술에 의한 분류Â
통신용, 프로그래밍 언어, 사용자 인터페이스, 워드프로세서, 거래처리, 분산처리, 인공 지능, 개발지원도구, 멀티미디어 등 다양하게 분류소프트웨어
소프트웨어 위기 위기 (1/2) (1/2)
“ “
하드웨어의하드웨어의 기술기술 발전발전 속도가속도가 소프트웨어의소프트웨어의 기술발전기술발전 속도보다속도보다 빠르다.빠르다. 새로운새로운 소프트웨어를소프트웨어를 요구하는요구하는 시장의시장의 수요를수요를 감당하기감당하기 어렵다. 어렵다.쌓이는쌓이는 기존기존 소프트웨어의소프트웨어의 유지보수가유지보수가 힘들어진다.힘들어진다.
” ”
Software crisis Software crisis
인건비의인건비의 상승효과와상승효과와 우수우수소프트웨어의소프트웨어의 부족부족현상으로현상으로
악화되어악화되어소프트웨어소프트웨어 생산성이라는생산성이라는 새로운새로운 과제를과제를 심각하게심각하게해결해야만해결해야만 하는하는상황상황
소프트웨어
소프트웨어 위기 위기 (2/2) (2/2)
Software Crisis Software Crisis Software Crisis
소프트웨어
소프트웨어 특성에특성에 관한관한 이해의이해의 부족부족
물리적이지 않고 논리적인 소프트웨어만이 가지고 있는 특성을 이해하지 못함.
관리의관리의 부재부재
소프트웨어에 대한 잘못된 의식 구조가 관리의 중요성을 소홀히 만들었고 의사소통 장애와 효과적인 자원의 통제 등이 제대로 이루어지지 못함
프로그래밍에만 치중
과거의 방식대로 소프트웨어의 품질이나 유지보수성 등 은 고려하지 않은 채 프로그래밍만 잘하려는 집착으로는 복잡, 다양해지는 소프트웨어의 요구수준을 맞출 수가 없음
소프트웨어
소프트웨어 개발 개발 생명 생명 주기 주기
정의
Software Development Lift Cycle (SDLC) “정보시스템을 개발하는 절차, 혹은 개발 단계의 반복 현상”
소프트웨어를 하나의 생명체처럼 탄생에서 사망까지의 변환과정으로 취급
소프트웨어를 정보시스템의 일부로만 취급하며 시작과 끝을 중요하게 여김 소프트웨어 프로세스 모델
정의“특정 관점으로부터 프로세스를 표현하는
프로세스에프로세스에 대한대한 추상적인추상적인 표현”표현
종류Â
폭포수 모델(Waterfall Model)Â
프로토타이핑 모델(Prototyping Model)Â
나선형 모델(Spiral Model)Â
반복 및 점증적 개발 모델(Iterative & Incremental Development Model)Â
컴포넌트 기반 개발 모델(Component Based Development Model)Waterfall Model (1/4) Waterfall Model (1/4)
개요
전통적인 생명 주기 모델
단계적 생명 주기(Phased Life-Cycle) 모델이라고도 불림 “A single time”으로 구성됨.
단계
계획단계Â
사용자의 문제를 정의하고 전체 시스템이 갖추어야 할 기본 기능과 성능요건을 파악하 여, 이를 개발하고자 하는 기본요구로 전환시킨다.
분석단계Â
사용자의 문제를 구체적으로 이해하고 소프트웨어가 담당해야 하는 정보영역을 정의한 다. 의사소통 기술이 필수적이다.
설계단계Â
소프트웨어의 구조와 그 성분을 명확하게 밝혀 구현을 준비하는 단계이다. 외부 시스템 및 사용자와의 인터페이스를 중시하는 외부설계와 시스템 내부를 설계하는 내부설계로 분류되기도 하고 전체적인 구조와 데이터 알고리즘을 설계하는 단계를 분리해 기본설 계와 상세설계로 분류하기도 한다.
구현단계Â
프로그래밍을 하는 단계이다. 각 모듈의 코딩과 디버깅이 이루어지고 그 결과를 검증하 는 단위 시험 혹은 모듈 시험을 실시한다.Waterfall Model (2/4) Waterfall Model (2/4)
단계
시험단계Â
개발된 모듈을 통합시키며 시험하는 통합시험, 완성된 시스템으로서의 요구사항을 완 벽히 반영시켰는가를 알아보는 시스템 시험, 그리고 사용자가 직접 자신의 사용 현장에 서 검증해 보는 인수 시험 등이 있다.
운영 및 유지보수 단계Â
소프트웨어를 직접 이용하고 이용상에 나타나는 문제점을 수정하거나 새로운 기능을 추가해 보다 유용한 소프트웨어로 발전시키는 단계이다.Waterfall Model (3/4) Waterfall Model (3/4)
운영운영및및 유지보수유지보수 시험시험
구현구현 설계설계
분석분석 계획계획
문제정의
개발계획 수립
요구분석
기본설계
상세설계
프로그래밍
단위시험
통합 시험
시스템 시험
인수 시험
운영 및 유지보수 시스템
정의서
프로젝트 계획서
요구사양서 임시 사용자지침서
기본설계사양서
상세설계사양서 사용자지침서
시험계획서
모듈별 코드
인수시험계획서 통합 S/W
확인된 S/W
검증된 S/W
검증
Waterfall Model (4/4) Waterfall Model (4/4)
특징
고전적 생명주기 패러다임
요구사항 분석, 설계, 구현(프로그래밍), 시험 및 유지보수의 순서
S/W개발을 단계적으로 정의한 체계이며 순차적 접근방법 사용
가장 오래되고 널리 사용됨
개념 정립에서 구현까지 하향식 접근 방법을 사용하여 높은 추상화 단계에서 낮 은 추상화 단계로 옮겨가는 방식
각 단계 종료 시 검증 후에 다음 단계로 진행
프로젝트 진행과정을 세분화하여 관리 용이
고객의 요구사항을 초기에 명확히 정의하기 어려움
목표 시스템이 과정의 후반부에 가서야 구체화되므로 중요한 문제점이 뒤에 발견 됨Prototyping Model Prototyping Model
개요
사용자의 요구사항을 충분히 분석할 목적으로 시스템의 일부분을 일시적으로 간 략히 구현.
간략히 구현 다음 원래 계획했던 개발 절차로 되돌아가는 방식과 지속적으로 개 선해가며 최종시스템으로 완성시켜가는 방식으로 분류됨. 분류
실험적(Experimental) 프로토타이핑 모델Â
요구분석의 어려움을 해결하기 위해 실제 개발될 소프트웨어의 일부분을 직접 개발함 으로써 의사소통의 도구로 사용.Â
개발의 타당성을 검증하기 위한 목적으로 프로토타입을 개발하기도 함.
진화적(Evolutionary) 프로토타이핑 모델Â
프로토타입을 요구분석의 도구로만 활용하는 것이 아니라 이미 개발된 프로토타입을 지속적을 발전시켜 최종 소프트웨어 완성시키는 모델(예:나선형모델)Evolutionary development (1/3) Evolutionary development (1/3)
Outline description
Outline Outline description description
Specification Specification
Development Development
Validation Validation
Initial version Initial Initial version version
Intermediate Intermediate
versions versions
Final version Final Final version version Concurrent
Concurrent
activities
activities
Evolutionary development (2/3) Evolutionary development (2/3)
- - - - - ▶ Refinements
R: Requirements C/T: Coding & Testing
D: Design I/AS: Installation & Acceptance Support
D C/T I/AS
R
D C/T I/AS
D C/T I/AS
R
R
Build 1
Build 2
Build n
Evolutionary development (3/3) Evolutionary development (3/3)
특징
간단한 시제품을 만드는 개념
폭포수 모델의 단점을 보완하여 점진적으로 시스템을 개발해 나가는 접근방식
시스템의 기능이 사용자에게 일부 모여짐으로써 개발자와 사용자의 오해가 초기 에 규명
생각지 못했던 기능과 서비스가 발견되기도 함
불완전하거나 의문스럽던 요구사항을 시제품을 통하여 발견할 수 있고, 교육효과 및 시험 기간을 줄일 수 있음
완성될 시스템에 대한 오해를 불러일으킬 수 있음
시제품에서 완제품으로 옮겨가는데 많은 변화가 있을 수도 있음
극한 상황, 타 시스템과의 인터페이스 등의 성능 평가가 어려움 Applicability
소규모 혹은 중급 시스템
대규모 엔터프라이즈의 부분 시스템(예 : 사용자 인터페이스)
생명주기가 짧은 시스템Iterative & Incremental Dev. Model (1/4) Iterative & Incremental Dev. Model (1/4)
개요
사용자의 요구사항의 일부분, 또는 제품의 일부분을 반복적을 개발하여 최종제품 을 완성하는 방법으로 폭포수 모델뿐 아니라 프로토타이핑 모델과 나선형 모델 등의 개념이 모두 포함되어 있는 보다 진보된 개발 모델
개발 프로세스 중에서 반복할 부분과 반복 횟수, 각 반복의 완료시에 산출되는 Baseline 등을 사전에 계획하여, 후반부의 반복으로 갈수록 작업량과 성과가 늘 어남
폭포수 모델과는 달이 개발과정의 유연성으로 인해 후속 단계에서 언제든지 선행 작업으로 되돌아갈 수 있음.
객체지향 방법론에 채용이 되면서 최근에 가장 부각되고 있으며 앞으로 많은 발 전이 기대되는 모델Iterative & Incremental Dev. Model (2/4) Iterative & Incremental Dev. Model (2/4)
- - - - - ▶ Feedback
R: Requirements C/T: Coding & Testing
R D C/T I/AS
D C/T I/AS
C/T
D I/AS
Build 1
Build 2
Build n
Iterative & Incremental Dev. Model (3/4)
Iterative & Incremental Dev. Model (3/4)
Iterative & Incremental Dev. Model (4/4) Iterative & Incremental Dev. Model (4/4)
특징
고객의 요구사항이 각 단계에서 적용되어 시스템 기능성이 초기부터 활용이 가능 하다.
초기 반복은 프로토타입이지만 다음 단계 반복의 요구사항 도출에 도움을 줄 수 있다.
전체 프로젝트에 대한 위험도를 낮춤
최우선 시스템 서비스가 대부분의 시험과정을 통해 도출될 수 있다.Waterfall, Incremental, Evolutionary Waterfall, Incremental, Evolutionary
Waterfall, Incremental, Evolutionary
Yes Yes
No Evolutionary
May be Yes
Yes Incremental
No No
Yes Waterfall
Distribute interim software?
Multiple development cycles?
Define all requirements first?
Process Model
Spiral Model (1/3) Spiral Model (1/3)
개요
프로토타입을 지속적을 발전시켜 최종 소프트웨어 개발까지 이르는 개발방법
위험관리가 중심인 생명주기 모델
위험 분석에 대한 해결역량이 없으면 오히려 위험한 모델이 될 수 있음 단계
계획수립Â
목표, 제약조건의 설정
위험분석Â
위험요소들의 분석과 관리기술을 통한 해소
개발Â
다음 단계 프로토타입의 개발
고객평가Â
개발된 프로토타입의 평가Spiral Model (2/3)
Spiral Model (2/3)
Spiral Model (3/3) Spiral Model (3/3)
특징
폭포수 모델과 프로토타이핑 모델의 장점에 위험 분석(Risk Analysis)을 추가하여 만든 모델
나선을 돌면서 점진적으로 완벽한 시스템 개발
각 나선은 계획수립, 위험분석, 개발, 고객평가의 4단계로 구성
나선형 모델은 비용이 많이 들고 시간이 오래 걸리는 큰 시스템을 구축해나가는 데 가장 현실적인 접근방법
성과를 보면서 조금씩 투자하여 위험부담을 줄일 수 있는 방법
프로젝트 관리를 어렵게 만들 가능성 존재
상대적으로 새로운 접근방법이며 많이 사용되지 않아 충분한 검증이 거치지 못하 였다는 단점 보유CBD(Component
CBD(Component - - Based Development) (1/3) Based Development) (1/3)
Objective of CBD
CBD는 컴포넌트들을 새롭게 개발하는 것보다는 기존 개발된 컴포넌트들로부터 새로운 소프트웨어를 조립함으로써 소프트웨어 개발 프로세스를 향상시키는 것 을 목적으로 함. 바람직한 이유
소프트웨어의 유지보수가 어렵고,
어플리케이션 통합 요구가 증가하고,
프리젠테이션이 시대에 따라 변화하고,
기술이 변화함에 따라서
소프트웨어가 재구현 필요성 및 새로운 소프트웨어의 개발이 요구됨.CBD(Component
CBD(Component - - Based Development) (2/3) Based Development) (2/3)
재사용 접근 방법
재사용 접근 방법은 다음 가정을 만든다.Â
모든 경험이 재사용될 수 있다.Â
재사용은 전형적으로 재사용될 객체의 일부 수정을 요구한다.Â
재사용은 특정 소프트웨어 개발에 통합되어야만 한다.Â
분석은 재사용이 적합할 때(when)와 재사용이 적합한지(if)를 결정하기 위해 반드시 필 요하다. 컴포넌트 가이드라인
Well specified
Easy to understand
Sufficiently general
Easy to adapt
Easy to deliver and deploy
Easy to replaceCBD(Component
CBD(Component - - Based Development) (3/3) Based Development) (3/3)
Component-Based Software Lifecycle
Deve lopm
ent Analysis
Design
Implementation
Integration
Test Evalua
tion Find
Select
Adapt
Integrate
Test
Component Evaluation System Development
