[정처기]소프트웨어 구축 I - 프로젝트 계획, 요구사항 분석, 소프트웨어 설계 etc.

• 소프트웨어 생명 주기(Sofrware Development Life Cycle, SDLC)
  ①프로젝트 계획 ▶︎ ②요구 분석 ▶︎ ③설계 ▶︎ ④구현 ▶︎ ⑤테스트 ▶︎ ⑥유지 보수

폭포수	선형 순차적 개발 / 고전적, 전통적 개발 모형 / Step-by-Step
프로토타입	고객의 need 파악 위해 견본/시제품을 통해 최종 결과 예측 인터페이스 중심 / 요구사항 변경 용이
나선형(Spiral)	폭포수 + 프로토타입 + 위헙 분석 기능 추가(위험 관리/최소화) 점진적 개발 과정 반복 / 정밀하며 유지보수 과정 필요 X ★ 계획 수립 → 위험 분석 → 개발 및 검증 → 고객 평가
애자일(Agile)	일정한 짧은 주기(Sprint 또는 Iteration) 반복하며 개발 진행 → 고객 요구사항에 유연한 대응 (고객 소통/상호작용 중시) Ex. XP(eXtreme Programming), Scrum, FDD(기능중심), 린(LEAN), DSDM(Dynamic System Development Method)

하향식 설계(Top-down): 절차 지향 (순차적) / 최상위 컴포넌트 설계 후 하위 기능 부여
→ 테스트 초기부터 사용자에게 시스템 구조 제시 가능
* Component: 명백한 역할을 가지며 재사용되는 모든 단위 / 인터페이스 통해 접근 가능

상향식 설계(Bottom-up): 객체 지향 / 최하위 모듈 먼저 설계 후 이들을 결합하고 검사
→ 인터페이스 구조 변경 시 상위 모듈도 같이 변경 필요하여 기능 추가 어려움

※ 익스트림 프로그래밍(eXtreme Programming, XP)
- 고객의 요구사항을 유연하게 대응하기 위해 고객 참여와 신속한 개발 과정을 반복
- 5가지 핵심 가치: 용기 / 단순성 / 의사소통 / 피드백 / 존중
- 기본 원리: 전체 팀 / 소규모 릴리즈 / 테스트 주도 개발 / 계속적인 통합 / 공동 소유권(Collective ownership) / 짝(pair) 프로그래밍 / 디자인 개성(리팩토링) / 애자일(Agile) 방법론 활용 상식적 원리 및 경험 추구, 개발 문서보다 소스코드에 중점(문서화 X)

 

① 프로젝트 계획

▶︎ 하향식 비용 산정 기법
- 전문가 감정 기법: 조직 내 두 명 이상의 전문가에게 비용 산정을 의뢰하는 기법 → 개인적 / 주관적 판단 가능
- 델파이 기법: 한 명의 조정자와 여러 전문가의 의견을 종합하여 산정 → '전문가 감정 기법'의 주관적 편견 보완

▶︎ 상향식 비용 산정 기법
- 프로젝트 세부 작업 단위 별로 비용 정산 후 전체 비용을 산정하는 방법

[ 종류 ]
• LOC(Source Line of Code): 코드 라인 총 수 / 생산성 / 개발 참여 인원 등으로 계산
→ 낙관치(a), 비관치(b), 기대치(c)를 측정/예측하여 비용 산정 = a + 4c + b / 6
• 개발 단계별 인월 수(Effort Per Task): LOC 기법 보안 / 생명 주기 각 단계별로 산정

▶︎ 수학적 비용 산정
① COCOMO(Constructive Cost Model): 보헴(Boehm) 제안 / 원시 코드 라인 수 기반
→ 비용 견적 강도 분석 및 비용 견적의 유연성이 높아 널리 통용됨
→ 같은 프로젝트라도 성격에 따라 비용이 다르게 산정

유형	조직형(Organic)	중, 소규모 SW용 / 5만 라인(50KDSI) 이하
	반분리형(Semi-detached)	30만 라인(300KDSI) 이하의 트랜잭션 처리 시스템
	내장형(Embedded)	30만 라인(300KDSI) 이상의 초대형 규모 SW 관리

② PUTNAM: SW 생명주기 전 과정에 사용될 노력의 분포를 이용한 비용 산정, Rayleigh Norden 곡선의 노력 분포도를 기초로 함
★ SLIM: Rayleigh-Norden 곡선 / Putnam 모형 기초로 개발된 자동화 추정 도구

③ Function Point(FP): SW 기능 증대 요인에 가중치 부여 후 합산하여 기능점수 산출
→ SW 기능 증대 요인: 자료 입력(입력 양식) / 정보 출력(출력 보고서) / 명령어(사용자 질의수) / 데이터 파일 / 인터페이스
★ ESTIMACS: FP 모형을 기반으로 하여 개발된 자동화 추정 도구

■ 개발 일정 산정

- WBS(Work Breakdown Structure): 프로젝트 목표 달성을 위한 활동과 업무를 세분화
→ 전체 프로젝트를 분할 / 수행 업무 식별, 일정 및 비용

▶︎ 네트워크 차트

• PERT
  
  • 프로젝트 직업 상호관계를 네트워크로 표현
  • 원 노드(작업)와 간선(화살표)으로 구성(@불확실한 상황)
    → 간선에는 각 직업별 낙관치 / 기대치 / 비관치를 기재
• CPM
  
  • 미국 Dupont 회사에서 화학공장 유지 / 관리 위해 개발
  • 노드(작업) / 간선(작업 전후 의존 관계) / 박스(이정표) 구성
  • 간선(화살표)의 흐름에 따라 직업 진행(@확실한 상황)
    
    

▶︎ 간트 차트
- 각 작업의 시작/종료 일정을 막대 바(Bar) 도표를 이용해 표현
- 시간선(Time-line) 차트(수평 막대 길이 = 작업기간)
- 작업 경로는 표현 불가 / 계획 변화레 대한 적응성이 낮음

 

② 요구사항 분석

■ 요구사항

- 어떠한 문제를 해결하기 위해 필요한 조건 및 제약사항을 요구
- 소프트웨어 개발/유지 보수 과정에 필요한 기준과 근거 제공

► 요구사항의 유형

• 기능적 요구사항: 실제 시스템 수행에 필요한 기능 관련 요구사항
  ex. 금융 시스템은 조회/인출/입금/송금 기능이 있어야 함
• 비기능적 요구사항: 성능, 보안, 품질, 안정성 등 실제 수행에 보조적인 요구사항
  ex. 모든 화면이 3초 이내에 사용자에게 보여야 함
  
  

► 요구사항 개발 프로세스  ★순서 중요
① 도출/추출: 이해관계자들이 모여 요구사항 정의(식별하고 이해하는 과정)
ex. 인터뷰, 설문, 브레인스토밍, 청취, 프로토타이핑, 유스케이스

② 분석: 사용자 요구사항에 타당성 조사 / 비용 및 일정에 대한 제약 설정
ex. 관찰, 개념 노델링, 정형 분석, 요구사항 정의 문서화

③ 명세: 요구사항 쳊계적 분석 후 승인가능하도록 문서화

④ 확인/검증: 요구사항 명세서가 정확하고 완전하게 작성되었는지 검토

► 요구사항 분석 도구

• 요구사항 분석 CASE
  • SADT: SoftTech 사에서 개발 / 구조적 분석 및 설계 분석
  • SREM: 실시간 처리 SW 시스템에서 요구사항 명확한 기술 목적
  • PSL/PSA: 문제 기술언어 및 요구사항 분석 보고서 출력
  • TAGS: 시스템 공학 방법 응용에 대한 자동 접근 방법
• HIPO: 하향식 설계 방식 / 가시적, 총체적, 세부적 다이어그램으로 구성 / 기능과 자료의 의존 관계 동시 표현 / 이해 쉽고 유지보수 간단
  
  

► 구조적 분석 모델

• 데이터/자료 흐름도(DFD, Data flow diagram):
  • 프로세스(Process), 원 / 자료 흐름(Flow), 화살표 / 자료 저장소(Data store), 평행선 / 단말(Terminator), 사각형
  • → 구조적 분석 기법에 이용 / 시간 흐름 명확한 표현 불가 / 버블(bubble) 차트
• 자료 사전(DD, Data Dictionary): 자료 흐름도에 기재된 모든 자료의 상세 정의/설명
• 소단위 명세서 / 개체 관계도(ERD, Entity Relationship Diagram) / 상태 전이도

  ※ 객체지향 분석 모델

• Booch(부치): 미시적, 거시적 개발 프로세스를 모두 사용(클래스/객체 분석 및 식별)
• Jacobson(제이콥슨): Use Case를 사용(사용자, 외부 시스템이 시스템과 상호작용)
• Coad-Yourdom: E-R 다이어그램 사용 / 객체의 행위 모델링
• Wirfs-Brock: 분석과 설계 구분 없으며 고객 명세서 평가 후 설계 작업까지 연속 수행
• Rumbaugh(럼바우): 가장 일반적으로 사용, 객체/동적/기능 모델로 구분
  • 객체 모델링(Object) → 객체 다이어그램 / 객체들 간의 관계 규정/정의
  • 동적 모델링(Dynamic) → 상태 다이어그램 / 시스템 동적인 행위 기술
  • 기능 모델링(Function) → 자료 흐름도(DFD) / 다수의 프로세스들 간의 처리 과정 표현
    
    

► 요구사항 명세

• 정형 명세
  • 수학적 원리 / 정확하고 간결한 요구사항 표현 가능
  • 어려운 표기법으로 사용자 이해 어려움(VDM, Z, Petri-net, CSP)
• 비정형 명세
  • 자연어, 그림 중심 / 쉬운 자연어 사용으로 의사소통 용이하나
  • 작성자에 따라 모호한 내용으로 일관성 떨어짐(FSM, Decision Table, E-R 모델, State Chart)

 

③ 소프트웨어 설계

■ 소프트웨어 설계 원리

1. 분할과 정복: 여러 개의 작은 서브시스템으로 나눠서 각각을 완성

2. 모듈화(Modularity): 시스템 기능을 모듈 단위로 분류하여 성능/재사용성 향상
- 모듈 크기 ▲ → 모듈 개수 ▼ → 모듈간 통합비용 ▼ (but, 모듈 당 개발 비용 ▲)
- 모듈 크기 ▼ → 모듈 개수 ▲ → 모듈간 통합비용 ▲

3. 추상화(Abstraction): 불필요한 부분은 생략하고 필요한 부분만 강조해 모델화
→ 문제의 포광적인 개념을 설계 후 차레로 세분화하여 구체화 진행
① 과정 추상화: 자세한 수행 과정 정의 X, 전반적인 흐름만 파악가능하게 설계
② 데이터(자료 추상화): 데이터의 세부적인 속성/용도 정의 X, 데이터 구조를 표현
③ 제어 추상화: 이젠트 발생의 정확한 절차/방법 정의 X, 대표 가능한 표현으로 대체

4. 단계적 분해(Stepwise refinement): 하향식 설계 전략
- 추상화의 반복으로 의한 세분화 / 세부 내역은 가능한 뒤로 미루어 진행

5. 정보 은닉(Information Hiding)
- 한 모듈 내부에 포함된 절차/자료 관련 정보가 숨겨져 다른 모듈의 접근/변경 불가
- 모듈을 독립적으로 수행할 수 있어 요구사항에 따라 수정/시험/유지보수가 용이함

■ 아키텍처 패턴

• Layer: 시스템을 계층으로 구분/구성하는 고전적 방식(OSI 참조 모델)
• Client-server
  
  • 하나의 서버 컴포넌트와 다수의 클라이언트 컴포넌트로 구성
  • 클라이언트와 서버는 요청/응답 제외 시 서로 독립적
    * 컴포넌트(Component): 독립적 업무/기능 수행 위한 실행코드 기반 모듈
• Pipe-Filter
  • 데이터 스트림 절차의 각 단게를 필터 컴포넌트로 캡슐화 후 데이터 전송 / 재사용 및 확장 용이 / 필터 컴포넌트 재배치 가능
  • 단방향으로 흐르며, 필터 이동 시 오버헤드 발생
  • 변환, 버퍼링, 동기화 적용(ex. UNIX 쉘 - Shell)
• Model-View Controller
  • 모델(Model): 서브시스템의 정보 표시
  • 뷰(View): 사용자에게 정보 표시
  • 컨트롤러(Controller): 사용자로부터 받은 입력 처리
    → 각 부분은 개별 컴포넌트로 분리되어 서로 영향 X
    → 하나의 모델 대상 다수 뷰 생성 ► 대화형 애플리케이션에 적합
• Master-slave: 마스터에서 슬레이브 컴포넌트로 작업 분할/분리/배포 후 슬레이브에서 처리된 결과물을 다시 돌려 받음(병렬 컴퓨팅)
• Broker: 컴포넌트와 사용자를 연결(분산 환경 시스템)
• Peer-to-peer: 피어를 한 컴포넌트로 산정 후 각 피어는 클라이언트가 될 수도, 서버가 될 수도 있음(멀티스레딩 방식)
• Event-bus: 소스가 특정 채널에 이벤트 메시지를 발행 시 해당 채널을 구독한 리스너들이 메시지를 받아 이벤트를 처리함
• Blackboard: 컴포넌트들이 검색을 통해 블랙보드에서 원하는 데이터 찾음
• Interpreter: 특정 언어로 작성된 프로그램 코드를 해석하는 컴포넌트 설계
  
  

■ UML(Unified Modeling Language) → 구성요소: 사물, 관계, 다이어그램

- 고객/개발자 간 원활한 의사소통을 위해 표준화한 대표적 객체지향 모델링 언어
- Rumbaugh, Booch, Jacobson 등 객체지향 방법론의 장점 통합
※ 인터페이스: 클래스/컴포넌트가 구현해야하는 오퍼레이션 세트를 정의하는 모델 요소

1) 사물(Things): 구조(개념, 물리적 요소) / 행동 / 그룹 / 주해(부가적 설명, 제약조건)

2) 관계(Relationship)

• 연관관계(Association): 2개 이상의 사물이 서로 관련
• 집합 관계(Aggregation): 하나의 사물이 다른 사물에 포함(전체-부분 관계)
• 포함 관계(Composition): 집합 관계 내 한 사물의 변화가 다른 사물에게 영향
• 일반화 관계(Generalization): 한 사물이 다른 사물에 비해 일반/구체적인지 표현(한 클래스가 다른 클래스를 포함하는 상위 개념일 때)
• 의존 관계(Dependency): 사물 간 서로에게 영향을 주는 관계(한 클래스가 다른 클래스의 기능을 사용할 때)
• 실체화 관계(Realization): 한 객체가 다른 객체에게 오퍼레이션을 수행하도록 지정 / 서로를 그룹화할 수 있는 관계

3) 다이어그램(Diagram)

• 구조, 정적 다이어그램(클객컴배복패)
  • 클래스: 클래스 사이의 관계 및 속성 표현
  • 객체: 인스턴스를 객체와 객체 사이의 관계로 표현
  • 컴포넌트: 구현 모델인 컴포넌트 간의 관계 표현
  • 배치: 물리적 요소(HW/SW)의 위치/구조 표현
  • 복합체 구조: 클래스 및 컴포넌트의 복합체 내부 구조 표현
  • 패키지: UML의 다양한 모델 요소를 그룹화하여 묶음
• 행위, 동적 다이어그램(유시커상활타상)
  • 유스케이스: 사용자의 요구를 분석(사용자 관점) → 사용자(Actor) + 사용 사례(Use Case)
  • 시퀀스: 시스탬/객체들이 주고받는 메시지 표현 → 구성항목: 액터 / 객체 / 생명선 / 메시지 제어 삼각형
  • 커뮤니케이션: 객체들이 주고받는 메시지와 객체 간의 연관관계까지 표현
  • 상태: 다른 객체와의 상호작용에 따라 상태가 어떻게 변화하는지 표현
  • 활동: 객체의 처리 로직 및 조건에 따른 처리의 흐름을 순서에 따라 표현
  • 타이밍: 객체 상태 변화와 시간 제약 명시적으로 표현
  • 상호작용 개요: 상호작용 다이어그램 간 제어 흐름 표현
    
    

▶︎ UI 설계: 직관성, 유효성(사용자의 목적 달성), 학습성, 유연성

• 설계 지침: 사용자 중심 / 일관성 / 단순성 / 결과 예측 / 가시성 / 표준화 / 접근성 / 명확성 / 오류 발생 해결
• CLI(Command Line): 텍스트, GUI(Graphical): 그래픽, NUI(Natual): 말/행동, VUI(Voice):음성, OUI(Organic): 사물과 사용자 상호작용
• UI 설계 도구
  • Wireframe: 기획 초기 단게에 대략적인 레이아웃을 설계
  • Story Board: 최종적인 산출문서(와이어프레임-UI, 콘텐츠 구성, 프로세스 등)
  • Prototype: 와이어프레임 / 스토리보드에 인터랙션 적용, 실제 구현된 것처럼 테스트가 가능한 동적인 형태 모형
  • MockUp: 실제 화면과 유사한 정적인 형태 모형
  • Use Case: 사용자 측면 요구사항 및 목표를 다이어그램으로 표현