[Software Design] System Development Life Cycle(SDLC)

과거 프로그래머들은 큰 계획없이 바로바로 프로젝트에 착수했다. 그만큼 규모도 작았고, 필요성을 크게 못느끼던 시기였다.

지금은 규모가 매우 크니 구현전 설계는 필수이다. 그리고 설계를 하더라도 (책의 자료에 의하면) 1996년 조사에서 53퍼센트의 IS project가 완성전에 버려졌다. 완성되더라도 계획보다 비용이 커지거나 시간이 길어지거나 구현이 덜 되었을 수 있다. 등등등...

즉, 지금은 제대로 설계를 해도 모자랄판이다.

system analyst는 이런 프로그램 설계를 총괄하기도하지만, 그 외적인 요소도 신경쓰는 사람이다.

고객과 제대로 의사소통해 원하는 것을 파악해야하고, 시스템 설계도 당연히 잘 해야하며, 무엇보다 본인이 속한 조직에 가치있는 것을 만들어야한다.

여기서 가치있는 것이란, 사기업이라면 대부분 금전이겠지만, 공공부문이거나 다른 성격의 조직이라면 다를 것이다.

 

System Development Life Cycle(SDLC)는 4개의 phase로 나뉜다.

planning

analysis

design

implementation

(각 단계별 자세한 설명은 책 p.3)

SDLC는 gradual refinement이다. 각 phase마다 결과물이 나오면 다음 phase에서 그걸 다듬어 다음 phase로 보낸다.

 

methodology란 SDLC를 구현하기위한 공식화된 접근법이다. 다양한 방법이 있다.

methodologies를 분류할 수 있는데,

한 분류 기준으론 data/process 중 어디에 집중할지를 기준으로 분류하는 것이 있다.

1. process-centerd methodology

2. data-centered methodology

3. object-oriented methodology (data/process 모두 한 모델에 넣어서 균형을 맞춤)

 

다른 분류기준으론 SDLC의 phases 순서와 각 phases의 중요도를 기준으로 분류하는 것도 있다.

1. structured design

2. rapid application development

3. agile development

 

1. Structured Design

1-1. Waterfall Development

A Waterfall Development-Based Methodology

그냥 SDLC phases 그대로 쭉 진행하는 것이다.

현재 진행중인 단계가 명확하고, 가시성이 좋다는 장점이 있지만,

Implementation 단계전까진 무엇이 잘못됐는지 알기 힘들 수 있어서 위험부담이 비교적 크다.

 

1-2. Parallel Development

A Parallel Development-Based Methodology

규모가 큰 system의 경우 이렇게 진행한다. 처음 design 단계에서 각 part로 system을 분리해 n개 팀 각각 따로 진행한다.

파트별로 구현까지 마친 후 마지막에 합친다.

 

2. Rapid Application Development (RAD)

structured design의 문제점은 결과물이 나오기까지 오래 걸린다는 것이다. 그래서 구현시 문제점을 중간에 알기 어려울 수 있다.

RAD는 좀 더 빠르게 개발을 진행해서 중간결과물을 볼 수 있도록해서 이를 보완한다.

2-1. Phased Development

A Phased Development-Based Methodology

만들어야하는 system에서 필요한 기능이 n가지 있다고 해보자. Phased 방식은 모든 기능을 한번에 구현하는 것이 아니라 하나씩 구현하며 중간 결과물을 우선 만들어내는 것이다.

이후 고객에게 feedback을 받아서 수정하고, 다음 기능을 만든다.

 

 

2-2. Prototyping

A Prototyping-Based Methodology

홈페이지 같은걸 보통(?) 이런 방식으로 만든다. 계획 후 나머지 단계를 그냥 동시에 진행해서 system prototype을 만들어낸다.

이후 system prototype을 test하며 잘못된 점을 다시 돌아가 보완한다.

그다음 사용자나 의뢰자에게 보여주고 피드백을 받고, 추가해야할 부분을 추가하며 계속 보완해 나가는 것이다.

prototype이 나오기까진 짧은 시간에 가능하다.

하지만 짧은 시간에 하려다보니 체계적이지못해 design이 엉망일 가능성이 있다.

(나중에 개발하다가 그런 근본적인 문제가 발견돼 전부 엎어야할 수도 있다.)

 

 

2-3. Throwaway prototyping

A Throwaway Prototyping-Based Methodology

prototying과 비슷한 면이 있다. 하지만 여기서의 prototype은 위에서의 prototye과는 다른 용도로 쓰인다.

이 prototype은 "design prototype"으로, 작동하는 system이 아니다. user가 issue를 이해하게 할 정도의 수준으로만 구현된다.

예를들어 우리가 의뢰받은 프로그램의 특정 부분이 정확히 어떻게 작동해야할지 잘 모르겠다면 이를 그 수준까지만 구현해 user에게 보여주고 원하는 동작을 파악하는 것이다.

그렇게 issue들이 전부 해결되고나면 다시 design단계로 들어가 본 제품을 구현한다.

 

system이 만들어지기전 prototype을 통해 직접 user와 소통하며 충분히 보완할 수 있고, 그렇다고해서 일반 prototying처럼 기반 design이 엉망인 것도 아닌, 그 사이 balance를 잘 맞춘 형태의 SDLC 방법이다.

 

 

3. Agile Development

모든 Agile development methodologies는 agile manifesto와 12가지 priciples을 기반으로 한다.

애자일 선언문(agile manifesto)

애자일 소프트웨어의 12가지 원칙

 

Agile 방법은 간소화에 초점을 맞췄다. 그래서 modeling이나 documentation을 최대한 제거하여 overhead를 줄인다.

Agile methodologies는 사실상 object-oriented technologies와 같이 쓰인다.(실제 위 선언문이나 원칙이 OO system 개발에서 유용하다.)

 

비판의 목소리도 있다. 우선 현실 비지니스 환경에 적합하지 않다는 것이다. 빠른 개발 프로세스 특성상 의사소통이 많아야해서 모든 개발 팀이 같은 장소에서 개발하는 것이 좋은데, 특정 부분을 하청을 주거나 하게될 경우 현실적이지 않다.

또 document가 부족하다는 등의 비판도 있다.

 

Agile development methodologies엔 대표적으로 Extreme Programming(XP)와 Scrum이 있다.(각각의 세부사항은 p.13부터)

 

 

Object-Oriented Systems Analysis and Design (OOSAD)

problemd을 기존엔 data나 prcoess 둘 중 하나에만 집중해서 해결했지만, OO를 통해 둘 다에 밸런스있게 집중할 수 있다.

OO 접근방법은 위 설명한 methodologies 다 사용가능하지만, 특히 phased development RAD나 agile 방법론이 잘 적용된다.

 

OOAD 과정은 아래 세가지 특성을 갖는다.

1. Use-case Driven

2. Architecture-Centric

3. Iterative and Incremental

 

1. Use-case Driven

: "Use-case Driven"은 use cases가 system의 행동을 결정하는 주요 modeling tool이라는 의미이다. user의 요구인 use-case가 system 개발을 이끌어 나가도록 하란 것.

사용자의 needs를 파악하는 것이다.

use-case를 이용해 system을 만들어야하는 programmer가 requirements를 식별하고 소통할 수 있게 한다.

"전체 system model"을 programmer와 user가 만들어야했던 기존 SDLC 방법론들에 비해,

한번에 하나의 business process에만 집중하는 use-case는 매우 간단하다.

 

2. Architecture-Centric

쉽게말해 system의 세가지 Architectural view를 analysis때 작성하고, 이것을 중심으로 개발하는 것이다.

(1) functional(external) view : user 입장에서 system의 행동을 설명하는 것

(2) structural(static) view : attribute, method, class, relationship으로 system을 설명하는 것

(3) behavioral(dynamic) view : object간에 주고받는 message와 object state 변화를 설명하는 것

 

3. Iterative and Incremental

말그대로 반복적이고 점증적으로 과정을 진행하는 것.. 위에서 말한 세가지 architectural views를 조금씩 쌓아나가는 것이다.

이전 단계를 확인하고 잘못된 부분이 있으면 수정하고 단단하게 기반을 쌓으며 나간다.

(사실 이 방법론에만 적용되는게 아니고 어디든 적용되는 얘기다. 당연한 얘기같지만 실제로 그런 사람은 드물다..)

 

Unified Process

The Unified Process

Unified Process는  OOAD를 할때 언제/어떻게 다양한 UML techniques을 사용할지 계획하기위한 specific methodology이다.

 

일단 한단계씩 모든 과정을 한꺼번에 진행한다.

매 단계마다 비중을 두는 부분이 조금씩 다르다. 보면 알겠지만 초기엔 Business Modeling이나 Requirments 등에 비중을 많이 두고, 중후반으로 갈수록 Implementation이나 Test의 비중이 늘어난다. 매단계별로 중점을 두는 곳이 조금씩 변하는 것이지, 다른 부분도 매번 반복하며 조금씩 진행하긴 한다.

(각 단계에 대한 자세한 설명은 p.25부터)

(UP가 정확히 뭔진 모르겠네 아마 저 그래프대로 해당 과정에 맞게 UML로 설계하는건가? 뭐 나중에 해보면 알겠지)