소프트웨어 프로세스 모델과 민첩한 개발

객체지향 설계 프로세스 모델과 민첩한 개발

Software Process Models

Structured Development - 구조화된 개발

 

구조화된 개발 모델은 프로젝트를 한 단계씩 순차적으로 진행하는 것이다. 한 단계가 끝나지 않으면 다음 단계를 시작해선 안된다. 구조화된 개발의 모델을 보자.

 

폭포수 모델

각 단계를 완전히 다 끝낸 후 다음 단계로 들어가는 방식이다.

예를 들어 디자인에 들어가면 다시 분석으로 돌아갈 수 없다.

이 모델은 요구사항 변경에 대처하기 어렵다는 단점이 있다.

대신 그만큼 요구사항 변경이 없으면 신속하게 개발이 가능하다.

또한 분석이 끝났으니 다음 단계로 넘어가려는 판단력이 필요하다.

따라서 우수하고 능력있는 팀장이 없으면 폭포수 모델은 좀 어렵다.

 

Waterfall Mode

Parallel Development(병렬 개발) 모델

전체 큰 시스템을 몇 개로 쪼개서 각각 다른 팀에서 개발하는 것이다.

각 팀에서 인터페이스를 명확하게 정의하고 변경사항이 없도록 해야한다.

시스템을 분할해야 하므로 소프트웨어 기능이 확실해야 한다.

확실하게 팀 별 역할을 구분하여 서로 영향을 최소화 해야한다.

통합하기위한 추가적인 자원이 들고 통합 과정에 발생한 문제를 해결하기도 더 어렵다.

그만큼 병렬적으로 개발하므로 개발 기간이 짧다는 장점이 있다.

 

Parallel Development Model

 

Rapid Application Development - 신속한 응용 개발

이 방법은 빠르게 개발한 후 사용자에게 visible한 어플리케이션을 제공해서 피드백을 받아 수정된 요구사항대로 수정하는 개발 방법이다. 더 효율적이고 빠르게 market share를 해서 시장을 선점할 수 있다는 장점이 있다.

이 방법은 몇 가지 요소를 함께 사용해야 한다.

• CASE tools를 사용해야 한다.
• JAD sessions를 이용해야 한다. JAD는 joint app, devel의 약자로 개발자와 사용자가 연합한다는 뜻이다.
• 개발 언어와 코드 자동 생성도 적극 활용해야 한다.

신속하다 = 비용절감?

아니다. 차피 과정을 거치니 비용은 쓰인다. 그럼에도 신속을 원하는 이유는??

1. 사용자에게 피드백을 빨리 받으려고

2. 새제품으로 돈을 벌기 위해서 , 마켓시장을 빠르게 접근하는 비즈니스 관점이 있다.

 

Incremental development model - Phased Development

 

전체 시스템에 대해 상위 분석을 먼저 한다.

상위 분석에서는 어떤 기능을 사용자에게 가장 먼저 보여줄지 결정한 후 개발해서 배포한다.

그 후 받은 피드백과 다음에 보여줄 기능을 포함하여 버전을 점점 업그레이드시키는 방식이다.

Version 1 -> Version 1 + @ -> ,,,,

 

이 방법은 사용자의 요구사항을 빠르게 받아들일 수 있다는 장점이 있다.

하지만 피드백과 함께 다음 버전의 내용도 분석, 설계해야하기에 개발의 양이 궁극적으로 많아진다.

-> 개발자 많이 필요 -> 바용 많이 들 수 밖에 

 

 

Prototyping-based Model

프로토타입을 개발하고 이를 기반으로 개발하는 방식이다.

분석, 디자인, 구현 후 시스템 프로토타입을 제공하여 사용자 피드백을 받고 다시 분석 단계로 돌아가는 과정을 거친다.

 

사용자가 만족하면 System Prototye 에서 Implementation 단계로

불만족한다면 다시 분석 단계 OK??

Prototyping-based Model

Prototyping - Throwaway prototyping(design prototyping)

프로토타입을 개발하고 그 프로토타입은 더이상 사용하지 않고 사용자의 피드백만 받는 용도로 사용한다.

그래서 만든 거 base로 다시 진행한다.

분석후 디자인 과정에서 여러 디자인 프로토타입을 만들고 구현해서 사용자 피드백을 받고 선택된 디자인 프로토타입으로 구현하는 과정을 거친다.

화면의 전개 방식같은 UI가 중요하다면 이 방식을 많이 선택한다.

 

Throwaway prototyping

 

Agile Development - 기민한 개발

지금까지 개발 방식은 분석 과정을 마치고 나온 분석 보고서, 설계 완성도 등 단계 산출물을 가지고 개발자 혹은 사용자들과 의사소통이 필요하다.

Agile 방식은 문서 작업 없이 간단하게 분석과 설계를 하고 코딩 중심으로 개발을 진행하고 문서화를 나중에 하는 방식이다.

eXxtreme Programming approach(XP)

XP는 다음과 같은 과정을 거친다.

요구사항에 대한 이해만 갖춘 상태로 Code →

Pair programming(한 명은 개발, 한 명은 오류 탐지) →

Unit test → Pair negotiation(사용자와 개발자의 협력, 피드백) →

Stand-up meeting(간단한 미팅) → Acceptance test(사용자에게 인수할것인지 테스트) →

Iteration plan → Release plan

 

이런 과정에서 많은 실천 사항들이 필요하다.

• The Planning Game : 이 시스템을 가지고 사용자가 어떻게 사용할지 user story 파악
• Small Releases : user story에 따라 작은 기능들로 분류하여 일부 릴리즈
• Metaphor : 사용자와 개발자간의 의사소통 언어체계 확립
• Simple Design
• Testing
• Refactoring : 프로그램의 기능은 변경하지 않고 포맷이나 인터페이스만 변경하는 재구조화
• Pair Programming
• Collective Ownership
• Continuous Integration : 지속적 통합
• 40-hour week
• On-site Customer : 고객이 항상 개발자와 같은 공간에 존재해야 한다.
• Coding Standard : 코딩 표준을 지켜야 한다.

 

Scrum approach

Aigle 개발에서 가장 많이 사용하는 방법이다.

Product Owner가 요구사항을 관리하고 사용자와 계속 소통하면서 개발팀에 요구사항을 업데이트시켜서 알려준다.

요구사항의 우선순위를 정해서 Product Backlog를 기록해두고 계획한다.

 

계획한 업무들을 Sprint Backlog로 기록해두며 task들을 개발하기위한 주기를 sprint라 한다.

sprint는 1~4주정도로 두고 개발자들은 sprint안에 개발해서 제시해야 한다.

 

sprint 안에서 Daily Standup Meeting이라는걸 꼭 해야 한다. 어제 개발했던 일과 문제점, 필요 사항들을 서로공유하는 시간이다.

주어진 task에 대한 작업이 끝나면 Sprint Review 후 Sprint Retrospective(회고)를 한다.

 

각 모델별 특징 정리

Criteria for Selecting a Process Model

Criteria for Selecting a Process Model

 

complex가 높다면 

분할 / 정복 (분석 & 설계) 하기

 

Software Development Methodology

소프트웨어를 개발할 때 방법론 또한 선택해야 한다.

방법론을 선택해야한다는 말인데 이 수업에서는 객체지향적 분석과 설계를 배울 예정이다.

 

Methodology
 SDLC/Process 모델 구현을 위한 정형화된 기법

Process 모델은 what to do 
 "개발 방법"에 대해 설명합니다

 

Representative Methodologies

 

 Structured Analysis and Structured Design (SASD)

 Information Engineering

 

이까지는 잘 안쓰고 요즘은 아래 것들을 사용한다.

 Object-Oriented Analysis and Design

 Component-Based Software Development

 Product-Line Engineering

 In future ?

Software Development Methodologies

다른 소프트웨어 개발 방법론을 알아만 보자.

• Structured Analysis and Structured Design (SASD)
  • 프로세스를 중심으로 설계한다.
  • data flow diagram 등이 있다.
• Information Engineering
  • 데이터를 중심으로 설계한다.
  • 엔티티 관계 다이어그램, CRUD matrix 등으로 데이터가 어떻게 어디서 활용되는지를 중요하게 생각한다.
• Object-Oriendted Analysis and Design
• Component-Based Software Development
  • Component는 재사용가능한 모듈의 집합으로 클래스가 될 수도 있다.
• Product-Line Engineering
  • 소프트웨어가 가지고 있는 특성은 공통 특성, 변화 특성으로 구별된다. 변화 특성은 해당 모델만 가지고있는 계속 변하는 특성이다.
  • 공통 특성은 재사용하고 모델별로 변화되는 부분만 갈아끼우는 형태로 접근하는 방법론이다. 그러려면 Software Architecture가 굉장히 중요하다.

프로세스 모델링은 무엇을 해야할지 정의하고 방법론은 어떻게 해야할지를 정한다.

 

Evolution of Software

Evolution of Software