PDLC .. 계획, 분석, 설계(논리적 설계)

PDLC (Platform Development Life Cycle)

 

용어 정립

System

- 하나의 비즈니스 기능에 사용되는 상호 연관된 절차들의 그룹으로, 구별 가능한 경계를 가짐

- 통합된 전체를 형성하는 규칙적으로 상호 작용하거나 상호 의존적인 단위 그룹

- 모든 시스템은 공간과 시간적 경계에 의해 묘사되고 환경에 의해 영향을 받으며 그 구조와 목적에 의해 기술되고 그 기능으로 표현됨

 

SubSystem

- 서브 시스템은 시스템 자체이자 더 큰 시스템의 구성인 요소 집합

- 서브 시스템은 시스템이 제어하는 운영 환경의 특성을 정의하는 정보를 포함하는 시스템 오브젝트임

 

Component

- 독립적인 단위/소프트웨어 모듈 .. 시스템은 모듈로 구성된 컴포넌트로 나뉨

- 특정 기능이나 관련된 기능들의 조합 .. ex. GUI에서 하나의 단추

 

Function

- 소프트웨어에서 특정 동작을 수행하는 일정 코드 부분

- 하나의 특별한 목적의 작업을 수행하기 위해 독립적으로 설계된 코드(명령어)의 집합

- 반복적인 프로그래밍을 피할 수 있기 때문에 사용

 

Module

- 독립적인 하나의 소프트웨어 혹은 하드웨어 요소

- 프로그램의 기능을 독립적인 부품으로 분리한 것을 모듈이라고 하며, 모듈은 일반적으로 서브루틴과 데이터 구조의 집합체. 그 자체로 컴파일 가능한 단위이며 재사용 가능

- 모듈은 하나 이상의 기능 가지기 가능. (송/수신, 생성/삭제 ..)

- 모듈은 하나 이상의 루틴을 포함하는 소프트웨어 구성 요소 또는 프로그램의 일부

- 독립적으로 개발된 하나 이상의 모듈이 프로그램을 구성

- 모듈을 사용하면 프로그래머가 소프트웨어 응용 프로그램 기능의 한 영역에만 집중할 수 있으므로 프로그래머의 작업이 쉬워짐

- 모듈은 일반적으로 인터페이스를 통해 프로그램에 통합됨

 

Modularization (모듈화)

- 생산성과 최적화, 관리에 용이하게 모듈(기능) 단위로 분할하는 것

- 개념적으로 정의된 시스템이나 프로그램을 기능별로 분해하여 각각의 모듈로 정의하는 것

- 하나의 시스템에서 정의된 모듈은 중복되지 않아야 하고 각 모듈은 하나 이상의 모듈과 연관관계를 가지고 있어야 함

---

PDLC

계획, 분석, 설계, 구현

4단계로 이루어진 SDLC의 기본 틀을 기반으로 플랫폼의 목적, 환경, 구성에 맞게 설계하고 개발할 수 있는 '플랫폼' 개발 생명 주기

 

1단계: 계획

플랫폼에 대한 모든 니즈를 분석하고 정렬, 플랫폼에 대한 잠재적 프로젝트를 정의하고 그 플랫폼의 지속 여부를 결정

 

플랫폼 개발 계획 단계의 개발 프로세스

1. 플랫폼의 확인과 선정

.. 개발자는 3개의 주요 요구에서 플랫폼 주제를 선정할 수 있음

- 새로운 서비스를 제공할 플랫폼의 개발

- 기존에 운영중인 플랫폼의 개선

- 기존에 운영중인 플랫폼보다 더 나은 운영 환경의 개발

 

2. 플랫폼의 초기화와 계획

.. 플랫폼의 전체적인 방향 및 계획에 대한 수립

- 플랫폼 개발 팀의 결성, 플랫폼 개발 환경 결정, 예비 예산 분석, 사용자와의 관계 설정, 기본 개발 계획의 수립 등

 

3. 실현 가능성 (feasibility / realizability) 평가

- 경제적, 운영적, 기술적, 시간적, 법적, 계약적, 정략적

 

4. 기본 플랫폼 개발 계획 구축

 

5. 기본 플랫폼 개발 계획의 검토

 

두가지 주요 활동

1. 보다 새롭거나 발전된 플랫폼의 필요성을 확인

2. 플랫폼을 조사하고 제안된 플랫폼의 범위를 결정

 

* 주요 산출물: 플랫폼 프로젝트 제안서 - 배경, 목표, 계획, 범위, 유사 사례 등..

---

2단계: 분석

분석 단계에서는 요구사항에 대한 조사를 통해 플랫폼에 필요한 요구사항의 정의 및 확립을 진행

 

플랫폼 요구사항 조사

- 플랫폼 개발에 필요한 모든 정보를 수집 분석하는 단계. 플랫폼 목표, 플랫폼을 수행하는데 필요한 정보, 데이터, 사업/시장/비즈니스 환경의 성격을 설명하는 정책 및 지침 등을 작성

- 사용자들이 플랫폼을 통해 얻고자 하는 것을 파악, 그에 따른 어떠한 유사 제품이 있는지, 관련 정책은 무엇이 있는지를 파악해야 함

- 기능적 요구사항(네비게이션, 홍채인식), 비기능적 요구사항(확장성, 안정성)

- 개인 인터뷰, 작업자 관찰, 업무 문서 분석

 

개인 인터뷰

조사 대상:

- 예비 사용자, 프로젝트 개발자, 무작위 시민, 플랫폼 서비스/기술 관련 전문가 등

획득 정보:

- 기존 플랫폼의 문제점 및 개선방안/아이디어

- 플랫폼의 적절성 및 필요성

- 주요 타겟(사용자)의 범위 및 그에 맞는 적절한(필요한) 서비스

- 타겟 시장 현황 및 전망

 

작업자 관찰

조사 대상:

- 이전 플랫폼 개발자, 현재 플랫폼 개발자, 타 플랫폼 개발자, 가상의 플랫폼 개발자 등

획득 정보

- 플랫폼 개발을 위한 최적의 작업 환경

- 업무에 필요한 최적의 인원 구성 및 역할 배정

- 멤버 커뮤니케이션 방법

 

업무 문서 분석

- 이전 플랫폼 설계/개발 문서, 타 플랫폼 설계/개발 문서, 국가에서 배포하는 관련 법규서-규정 문서 등, 관련 기술 논문, 사업보고서/계획서, 개발 블로그 등

획득 정보

- 기존 플랫폼의 문제점 및 개선 방안/아이디어

- 플랫폼 주제 관련 법규 및 규정

- 플랫폼 주제 관련 최신 기술 동향 및 기술 획득 방안

 

요구사항 조사를 통해 분석 및 정의되어야 하는 요소들

분석	정의	산출물
조사를 통해 수집한 데이터의 분석	분석한 결과를 토대로 요구사항 정의	요구사항 정의를 위한 산출물
- 기존 플랫폼의 문제점 및 개선방안/아이디어 - 관련 법규 및 규정  - 주제 관련 최신 기술 동향 및 기술 획득 방안 - 주요 타겟의 범위 및 그에 맞는 적절한 서비스 - 타겟 시장 현황 및 전망	- 플랫폼 배경 및 목적 - 플랫폼 구성 기술 - 주요 서비스 리스트 - 플랫폼 설계 방향 - 서비스 타겟	- 기술 보고서 - 개발 계획서 - 비즈니스 모델
- 제안하는 플랫폼의 적절성 및 필요성	- 플랫폼 유용성 및 필요성	- 인터뷰 / 설문 결과 보고서
- 플랫폼 개발을 위한 최적의 작업 환경 - 업무에 필요한 최적의 인원 구성 및 역할 배정 - 멤버 커뮤니케이션 방법	- 플랫폼 개발 환경 - 플랫폼 커뮤니케이션 도구 - 플랫폼 개발 계획	- 마일스톤 기반 스케줄 표 - 플랫폼 개발 계획표

---

설계

분석 단계에서 정의된 요구사항에 따라 플랫폼을 설계하는 단계

1. 논리적 설계

2. 물리적 설계

 

	개념	주요 산출물
논리적 설계	- 특정 하드웨어 및 시스템 소프트웨어 플랫폼에 얽매이지 않는 방법으로 플랫폼의 비즈니스적 측면에 초점을 맞춘 설계 방법	상황도, 데이터 흐름도(서비스 모델)
물리적 설계	- 논리적 설계만을 기술적인 내역으로 변경시키는 작업. 플랫폼 내의 데이터 흐름, 입출력, DB, 파일 구조, 개발 언어, 네트워크 환경, 모듈 등을 결정하여 하나의 플랫폼 구조도를 작성해야 함 - 물리적 설계와 동시에 개발에 필요한 개발 환경을 설정해야 함	사용자 인터페이스, 데이터베이스, 플랫폼 구조도

 

논리적 설계

플랫폼 요구사항 구조화

- 논리적 설계를 위해 우선적으로 정의된 기능적 요구사항을 구조화(모듈화)해야 함

(요구사항들의 중복성을 제거하기 위해 각 기능을 구조화)

- 요구사항들 간의 상호관계를 분석

- 요구사항에서 발생하는 데이터 구조를 모델링

- 논리적 설계의 산출물인 상황도, 데이터 흐름도는 구체적인 모듈이나 시스템을 표현하지 않으며 이후 논리적 설계 산출물을 바탕으로 물리적인 설계를 수행

 

* 모델링:

- 구조화된 모듈의 상호관계를 데이터 흐름 및 구조에 맞게 표현하는 것

- 현실 세계를 단순화하여 표현하는 기법, 특정한 목적에 맞추어 이용하기 쉬운 형식으로 표현하는 일

 

 

상황도 (Contextual Diagram)

플랫폼의 경계나 범위, 그리고 환경에 대한 관계를 간략하게 표현

- 상황도는 단 하나의 프로세스(시스템)만을 갖고 주요 소스와의 단순한 데이터 흐름을 표현하는 그림

- 데이터 저장소나 세부적인 내용은 표현하지 않음

 

데이터 흐름도 (Data Flow Diagram .. = 서비스 모델)

- 상황도의 하나의 시스템을 여러 프로세스로 분해, 세부적이며 중복되지 않는 기능 설계

- 이해 관게자와 각 프로세스 간의 관계를 설계하고 데이터 흐름을 관계에서 표현

- 이해관계자는 시스템 사용 시 서비스 흐름 이해 가능