728x90
반응형
SMALL

구조적 방법론 (1970년대)

구분 설명
정의  - 구조적 프로그래밍이란 코드가 계층적인 형식과 제한된 구조로, 작성된 순서 
    대로 순차적으로 실행함.
 - 알고리즘을 기술하는 데는 순차,선택,반복 구조면 충분하다. (NS차트)
 - 단일입구/단일출구의 처리구조를 가짐.
등장배경 GOTO문을 쓰지말자라는 주장이 호응을 얻으면서 분석과 설계도 구조적으로 
하자라는 의견으로 확대대면서 구조적 방법론의 틀이 완성.
특징  - 데이터 흐름지향. 즉 프로세스 위주의 분석과 설계방식 (DFD/ERD)
 - 모듈의 분할과 정복에 의한 하향식(TopDown) 설계방식
 - 모듈의 구조화를 통한 재사용/유지보수성 제고 
- SDLC 구조를 가진 폭포수 모델이 기본
중점  - 기능중심
단점  - 어플리케이션은 여전히 기능적 설계
 - 기능의 유지보수, 재사용은 낮음. - 데이터의 구성에 대한 설계 방안이 부족
 - 프로젝트의 관리 및 조직,역할등 방법론적 다른 요소들의 정의가 없음.
 - 이것들은 단순한 소프트웨어 개발을 목표로 한다는 점에게 기인 
     -> 정보공학적 개발 방법론  등장.
 - 데이터가 정보 은닉이 안됨.
 - 유지보수, 재사용성 낮음



정보공학적 방법론 (1980년대)

구분 설명
정의 기업정보시스템에 공학적 기법을 적용하여 시스템의 계획,분석,설계 및 구축을 하는 데이터 중심의
방법론
등장배경 정보시스템은 소프트웨어 개발과는 달리 하드웨어, 네트워크 등 여려 소프트웨어와 복잡하게 연결되는 대규모시스템이기 때문에 이러한 시스템을 개발하기 위해서는 장기간, 많은 인력이 소요되므로 철저한 계획,팀워크에 따른 프로젝트 관리, 이의 진행을 위한 잘 짜여진 방법론이 필요
특징 - 일반적인 소프트웨어 개발이 아닌 기업의 Biz전략에 따라 수립된 ISP에 
  따라 정보시스템 통합에  그 초점이 맞추어짐.
 - 따라서 ISP수립 -> 업무영역분석 -> 업무시스템설계 -> 업무시스템구축 
   순서를 가진다.
 - Process는 변하지만 Data는 불변이기 때문에 프로그램 로직은 데이터 
   구조에 종속(CRUD)적이며 데이터 안정성을 추구하기 위한 데이터 
   구조에 중점을 둔다.
 - 기본적으로 정보공학은 공학적 개발방법론이며 자동화도구,CASE Tool을
   이용하여 코드의 자동생성을 목표
중점 데이터 구조 (자료구조)
단점  - 어플리케이션은 여전히 기능적 설계
 - 기능의 유지보수, 재사용은 낮음.



객체지향 방법론 (1990년대)

항목 설명
정의  - 복잡한 현실세계를 모델링
 - 추상화,캡슐화,상속,정보은닉 등 객체를 중심으로 프로그래밍 구조를
   단순화하고 재사용성을 강화
등장배경  - 구조적 방법론이나 정보공학 방법론 모두 프로세스와 데이터를 분리
   하여 처리한다는 단점은 이를 통합하여 처리하는 객체지향의 등장에 
   가장 큰 배경
    * 구조적,정보공학 - Process 와 Data분리
       객체지향           - Process 와 Data 통합 -> Class
특징  - 재사용이 강점 (Whitebox 재사용)
 - 추상화,상속성,다형성,캡슐화
 - 상속이 많으면 상속은 저하되는 단점.
 - 다형성이 많으면 유지보수가 어려워진다.
 - 분석 설계간 Gap 없음.
 - 고도의 모듈화
 - 데이터와 로직을 통합 (객체)
중점  객체중심
단점  - 전문가 부족
 - 기본 SW기술 필요
RUP
원리 개념 역할 특징
추상화
(Abstraction)
현실세계의 사실을 그대로 객
체로 표현하기 보다는 문제의
중요한 측면을 주목하여 상세
내역을 없애 나가는 과정임.
복잡한 프로그램
을 간단하게 해주고 분석의 초점을 명확히 함
클래스를 이용함으로써
데이터와 프로세스를
함께 추상화구조에 넣
어 보다 완벽한 추상화
를 실현함
캡슐화
(encapsulation)
객체의 상세한 내용을 객체
외부에 숨기고 단순히 메시지
만으로 객체와의 상호작용을
하게 하는 것.
객체의 내부구조와 실체를 분리함으로써 내부의 변경이 프로그램에 미치는 영향을 최
소화하여 유지보수 용이하게 함
Public과 Private 
상속성
(Inheritance)
수퍼클래스가 갖는 성질을
서브클래스에 자동으로 부여
하는 것.
프로그램을 쉽게 확장할 수 있도록 해주는 강력한 수단.  
다형성 
(polymorphism)
하나의 인터페이스를 이용하
여 서로 다른 구현 방법을
제공하는 것.
특정지식을 최소화한 관련된 클래스들을 위한 일관된 매개체를 개발 하는 수단을 제공 특정지식을 최소화한 관련된 클래스들을 위한 일관된 매개체
를 개발 하는 수단을 제공



CBD 방법론 (2000년대)

 - 재사용이 가능한 Component의 개발 또는 상용 컴포넌트들을 조합하여 어플리케이션 개발

항목 설명
특징  - BlackBox 재사용 : 인터페이스를 이용해서 재사용
 - 추상화,캡슐화 - Input과 Output만 있음.
 - 표준화된 UML을 통한 모델링 및 산출물 작성
 - 반복 점진적 개발 프로세스 제공
 - 표준화된 산출물 작서잋 컴포넌트 제작 기법을 통한 재사용성 향상.
중점  - 컴포넌트 중심  
컴포넌트
구성요소
1. 컴포넌트 Context - 컴포넌트 기능과 역할
Interface - 기능을 외부에 제공
  2. 컨데이너 컴포넌트를 구현하기 위한 서비스 런타임 환경
컴포넌트 생성 및 소멸 관리
  3. 어플리케이션 서버  
개발순서 도메인 분석 -> 도메인 설계 -> 컴포넌트 추출 -> 컴포넌트 설계 -> 컴포넌트 구현
컴포넌트 방법론 
품질 측정 지료
1. 기능에 대한 이해의 용이성
2. 변경에 대한 용이성
3. 컴포넌트들 간의 결합도 (응집도는 이미 고려되어 컴포넌트가 만들어진 상태임)

CBD방법론

 

728x90
반응형
LIST
728x90
반응형
SMALL

1. 폭포수 모델

      - 개념 정립에서 구현까지 하향식 접근방법 (높은 추상화 단계 -> 낮은 추상화 단계)
      - 응용분야가 단순하고 잘 알고있는경우에 적합
      - 비전문가가 사용할 시스템 개발에 적합
      - 단계별 결과물이 명확해야 한다.
      - 설계와 코딩 및 테스트를 지연시킬 우려가 있다.
      - 시스템의 요구가 설계단계로 넘어가기전에 동결됨을 가정
     - 문서와 결과물 도출에 중점.
     -  단점 : 프로토타입과 재사용의 기회가 줄어든다
                 일정에 융통성이 없으며 이전단계로의 회귀,반복이 계속 된다면 소요자원이 계속 
                 증가할수 있다
                 최종단계가 가야지 결과물을 알수있다.
                 초기에 요구사항 정의가 어려움.
                 중요한 문제점의 발견이 늦어짐.
     - 용도 : 이미 잘알고 있는 문제나 연구중심의 소프트웨어 개발에 적합
                위험이 적은 프로젝트에 적합
                유사한 프로젝트 경험이 있는 경우
                요구사항이 명확히 정의되어 있는 경우


프로토타이핑 모델

      - 요구사항을 초기에 명세하기가 어려운 경우 적합 (요구사항이 모호함)
      - 프로토타입에는 사용자의 경험으로 가치있는 의견을 회수할 만한 기능만을 포함시킨다.
      - 예외처리, 회복, 표준이나 형식의 준수와 같은 것은 포함시키지 않는다.
      - 품질보다는 빠르게 만들어야 한다.
      - 장점 : 요구사항 도출이 용이.
                 시스템의 이해와 품질 향상
                 개발자와 사용자간 의사소통 원활
                 개발의 타당성 검증.
      - 단점 : 발주자가 프로토타입이 최종결과라 믿고 곧 소프트웨어가 개발될꺼라고 오해
                 폐기에 따른 비경제성
                 프로토타입이 전체시스템의 일부분임에도 불구하고 발주자가 개발일정 단축을 
                 요구할수 있어 품질을 저하시킬 수 있다.
               : 프로토타입이 과대선전되어 인수해야할 제품보다 더 많은 기능을 기대하게 된다.
               : 프로토타이핑 과정을 관리,통제 하기 어렵다
               : 중간과정을 점검할 수 있는 일정표와 산출물이 어렵다.
               : 발주자의 참여을 계획하는 것이 쉽지않다.             
      - 종류 : 실험적 프로타이핑 - 시제품 폐기
                 진화적 프로타이핑 - 나선형 모델


나선형 모델

      - 위험분석을 기반으로 한 반복개발
      - 선형모델의 체계적인 측면과 프로토타이핑의 반복적 특성을 결합시킨 형태의 모델
      - 계획수립 - 위험분석 - 개발 - 평가 
      - 대규모시스템을 개발하는데 적합
      - 각 확장단계에서 발생될 위험에 대한 이해와 대책이 가능하다.
      - 비선형적이며 반복적으로 개발이 진행되므로 소프트웨어 품질 중 강인성을 높일수 
       있는 방법이다.
      - 재정적, 기술적으로 위험부담이 큰 경우 위험분석을 해나가면서 시스템 발전
      - 요구사항이나 아키텍쳐를 이해하기 어렵거나, 근본적으로 성능에 문제가 되는 경우
     - 장점 : 정확한 사용자 요구사항 파악
                : 위험부담 감소
                : 품질확보
      - 단점 : 프로젝트 개발에 많은 시간 소요
                 프로젝트 관리에 어려움 
                 충분한 검증 미흡 (참조 사이트가 적음)


점증적 모델

      - 사용자 요구사항의 일부분 또는 제품의 일부분을 반복적으로 개발하여 최종제품을 
        완성하는 모델
         (폭포수모델 + 프로토타이핑 모델 + 나선형 모델)
      - 폭포수모델의 변형으로 증분을 따로 개발 후 통합하는 방법으로 포로토타입의 
        반복개념을 선형순차모델의  요소들에 결합시킨 것.
      - 프로토타이핑과 같이 반복적이나 각 점증이 갖는 제품 인도에 초점
      - Big Bang 릴리스를 보완하려는 방법이다.
      - 릴리스를 여러 번 나누어서 하면서 기능을 확장 개발해 나가는 방법
      ① 점증(증분)적(Incremental) 방법 : 기능별로 하나씩 개발하면서 릴리스 
      ② 반복(진화)적(Iterative) 방법 : 처음부터 전체기능을 개발하되 릴리스할때마다 
                                                그 기능을을 더 완벽히 개발
      - 장점 : 릴리스할때마다 사용자로부터 피드백을을 받아 사용자의 요구사항을
                 빠르게 반영할 수 있다.
               : 증분을 정확히 계획하고, 릴리스한다는 점에서 진화적 모형과는 다르며
              , 고객에게 모든 증분을
               릴리스하고 고객의 우선순위를 고려한다는 점에서 agile 방법론과 비슷하다.


V 모델

      - 폭포수모델에 시스템검증과 테스트 작업을 강조한 것이다.
      - 폭포수모형은 문서와 결과물에 중점을 두는 반면, V모델은 작업과 결과의 
         검증에 초점을 둔다,.
      - 장점 : 모든 단계에 확인과 검증 과정이 있어 오류를 줄일 수 있다
      - 단점 : 생명주기의 반복을 허용하지 않아 변경을 다루기가 쉽지않다.
                 작업이 종료되고 리뷰 후에는 관련된 결과물이 동결된다.
     - 적합 : 높은 신뢰성이 필요한 응용분야 (의료제어시스템, 원전제어시스템...)
                요구의 명세가 확실하여 개발하는 동안 변경이 없는경우에만 적합

728x90
반응형
LIST

+ Recent posts