소프트웨어 분석 & 디자인
SW 분석 (Analysis)
•
정보 시스템이 무엇을 하여야 하는지 자세히 이해하고 명세로 나타내는 일
ㅌ
SW 디자인 (Design)
•
정보 시스템이 어떻게 구현되어야 하는지 자세히 나타내는 일
소프트웨어 디자이너, 분석가
•
비즈니스 니즈를 만족시키기 위하여 분석과 설계 기술을 사용하는 전문가
•
목표
◦
SW를 사용하는 기관에게 이익을 가져다주는 기업의 창출
◦
SW는 단순 도구에 그치는 것이 아니라, 기관이나 기관 경영이 세운 목표에 좋은 성과를 달성하게 하는 통합 요소가 되어야 한다
소프트웨어 디자인의 목표
•
기관의 가치 창출
•
비즈니스 목표 달성
시스템 개발과정
•
계획 → 분석 → 설계 → 구현
각 단계별 산출물을 바탕으로 개발 과정을 점진적으로 구체화해 나가야한다.
계획 (Planning)
•
왜 Information System을 구축하여야 하는지 이해
•
타당성 분석
◦
기술적, 경제적, 조직적 타당성
•
작업 계획 수립
•
팀 조직 수립
•
프로젝트 관리 계회
프로젝트 계획서
분석 (Analysis)
•
질문
◦
누가 사용하나?
◦
언제 사용하나?
◦
시스템이 무엇을 해야하나? (기능)
•
작업
◦
분석 전략 수립
▪
SWOT 분석
▪
현재 시스템 (as-is system) 및 새로운 시스템 (to-be system) 분석
◦
요구 수집
▪
인터뷰, 설문
◦
문서화
▪
제안서 문서 작성
설계 (Design)
•
시스템 어떻게 구축? (시스템이 어떻게 동작하는지 결정)
•
시스템의 동작을 결정
◦
UI, 입력 양식, 보고서
◦
프로그램
◦
디비, 파일
•
설계 전략 수립
•
아키텍처 설계
◦
SW 아키텍처, 인터페이스 설계
•
데이터 설계
•
프로그램 설계
구현 (Implementation)
•
구축 또는 컴포넌트 통합으로 설계를 현실화
•
작업 단계
◦
시스템 구축과 부분 테스트
◦
시스템 설치, 전환
◦
지원 계획
SW 개발 방법론
•
방법론 (Methodology)
◦
소프트웨어 개발 생명주기 (SDLC) 를 구현하기 위하여 따라야 할 가이드 라인이나 정형화된 접근 방법
•
모델
◦
실세계를 특정한 관점으로 표현한 것
ex) 흐름도, 자료흐름도, 아키텍처, 유스케이스 다이어그램, 클래스 다이어그램..
•
도구
◦
설계, 구현, 유지보수 ,테스트 등 SW 산출물 생산에 도움을 주는 SW툴 : CASE
•
기술
◦
개발 작업을 완성할 수 있도록 도움을 주는 가이드라인
SW Process Model
•
프로세스
◦
SW를 개발해 나가는 단계나 과정
◦
오래 걸릴 수 있음
•
각 단계의 목표
◦
명확한 작업 단계
◦
손에 잡히는 결과
◦
작업의 검토
◦
다음 단계의 명시
•
Code - and - Fix
◦
생명 주기가 없음
Waterfall Model (폭포수 모델)
•
각 단계가 다음 단계 시작 전에 끝나야 함
◦
순서적이다
▪
각 단계 사이에 중복이나 상호작용이 없음
◦
각 단계의 결과는 다음 단계가 시작 되기 전에 점검
◦
바로 전단계로 피드백
•
단순하거나 응용분야를 잘 알고 있는 경우에 적합하다
◦
한 번의 과정, 비전문가가 사용할 시스템 개발에 적합
•
장점
◦
프로세스가 단순 → 초보자 쉽게 적용 가능
◦
증간 산출물이 명확 → 관리하기 좋다
◦
코드 생성 전 충분한 연구, 분석
•
단점
◦
처음 단계를 지나치게 강조하면 코딩, 테스트가 지연
◦
각 단계의 전환에 많은 노력이 필요
◦
프로토타입과 재사용의 기회가 줄어듦
◦
소용 없는 다종의 문서를 생산할 가능성 있다
•
적용
◦
이미 잘 알고 있는 문제나 연구 중심 문제에 적합하다
◦
변화가 적은 프로젝트에 적합
•
변형
◦
병렬 개발 모형 (Parallel Model)
▪
대규모 시스템을 쪼개어 병렬로 진행
Prototyping Model (프로토타입 모델)
•
프로토타입 (quick and dirty) 의 적용
◦
사용자의 요구를 더 정확히 추출 가능
◦
알고리즘의 타당성, 운영체제와의 조화, 인터페이스의 시험 제작
•
프로토타이핑 도구
◦
화면 생성기
◦
비주얼 프로그래밍, 4세대 언어 등
•
공동의 참조 모델
◦
사용자와 개발자의 의사소통을 도와주는 좋은 매개체
•
프로토타입의 목적
◦
단순한 요구 추출 → 만들고 버림
◦
제작 가능성 타진 → 개발 단계에서 유지보수가 이루어진다
•
단점
◦
오해. 기대심리 유발, 관리 어려움 (중간 산출물 정의가 난해)
•
적용
◦
개발 착수 시점에 요구가 불투명할 때
◦
혁신적인 기술을 사용해 보고 싶을 때
Spiral Model (나선 모델)
•
여러 버전으로 나누어 순차적으로 개발
•
장점
◦
유용한 시스템을 빠른 기간 내에 사용자의 손에 들려준다
◦
중요한 추가 요구를 조기에 발견한다
•
단점
◦
의도적인 미완성 시스템을 가지고 작업하기 시작
◦
로드맵을 다 그려야한다
Agile Model (애자일 모델)
•
Heavy 한 프로세스
◦
과다한 단계
◦
과다한 문서
◦
코드가 나오기까지 시간이 많이 소요된다
→ 애자일 모델로 불편함 씻자
•
과도한 모델링과 문서화의 짐을 과감히 생략하고 개발에 집중한다!
◦
Extreme Programming, Scrum, DSDM
•
Extreme Programming 의 핵심가치 4가지
◦
의사소통
◦
단순함
◦
피드백
◦
격려
프로젝트 팀 구성
시스템 분석가 (소프트웨어 설계자)
•
시스템 개발에서 제기된 이슈를 다룸
•
비즈니스 프로세스 개선
•
분석과 설계 작업에 대한 훈련과 경험
사용자 지원
•
기술적 정보
•
교육, 생산성 지원
•
헬프 데스크, 고객 센터
품질 보증
•
품질 관점에서 모든 결과물을 체크
•
테스트
•
개발과 별도의 조직
데이터베이스 관리자 (DBA)
•
데이터베이스 설계 관리
•
보안, 백업, 사용자 접근 제어
•
데이터베이스 튜닝
네트워크 관리자
•
네트워크 장비의 관리 및 유지보수
•
보안
Planning
프로젝트 (Project)
•
비즈니스 가치를 창조하는 시스템을 만드는 처음부터 마지막까지의 작업 집합
새로운 프로젝트의 시작
•
비즈니스를 이해하고 목표를 정하는 것으로부터 출발
•
유행에 따라가면 실패할 가능성 높다
•
많은 프로젝트의 실패 사례
◦
비즈니스 가치와 위험 관리를 이해하여 분석 설계에 충분한 관심을 기울이지 않았을 때
◦
타당성 검증이 반드시 필요하다
▪
기술적, 경제적, 조직적 측면
Work steps for Planning Stage
1.
비즈니스 목표 설정
2.
시스템 개발 요청 정의
3.
타당성 분석
4.
프로젝트 개발 일정과 비용 산정
5.
일정 계획
6.
조직 구성
비즈니스 목표 설정
•
전략적 계획 (Strategic Planning)
◦
장기적인 목표나 전략, 이를 위한 자원
◦
로드맵, 큰 그림을 그리는 과정
◦
소프트웨어 분석가, IT 관리자의 역할이 중요
•
현재 상황을 잘 인식하고 미래에 대한 분명한 비전이 필요
•
전략적 계획의 대표 방법 : SWOT 분석
SWOT 분석
•
강점 (Strength) → 어떻게 최대화?
•
약점 (Weakness) → 어떻게 극복?
•
기회 (Opportunity) → 어떻게 이용?
•
위협 (Threat) → 어떻게 제어 (control)?
경영 목표
•
Mission Statement (미션 선언문)
◦
기업이나 기관의 목적, 비전, 가치를 선언
◦
기업이나 기관의 장단기 목표, 비즈니스 활동을 위한 기초
◦
Mission Statement 는 Project Planning 의 시작점
시스템 개발 요청 정의
•
프로젝트의 시작
◦
시스템을 구축하여 얻을 비즈니스 가치를 발견했을 때 start!
•
프로젝트의 필요성 제기
◦
소프트웨어 시스템 개발을 요청하는 6가지 주요요인
1.
서비스 향상
2.
성능 개선
3.
비용 절감
4.
제어력 강화
5.
정보 중대
6.
신제품 또는 서비스 지원
◦
시스템 개발 요청서
▪
시스템 구축의 필요성과 시스템이 제공할 것으로 예상하는 가치를 정리한 문서
Validity Analysis (타당성 분석)
1.
기술적 타당성 → 개발할 수 있는가?
•
응용 분야에 익숙한가? → 미숙할수록 위험
•
기술에 익숙? → 미숙할수록 위험
•
프로젝트 크기 → 클수록 위험
•
호환성 → 현재 가동되는 시스템과 연동, 통합 시도가 많을수록 위험이 큼
2.
경제적 타당성 → 개발하여야 하는가?
•
개발 비용
•
운영 비용
•
연간 이익
•
정성적 비용과 이익
3.
조직적 타당성 → 조직 운영에 얼마나 잘 융합될 수 있는가?
a.
시스템 완성 후 사용자에게 얼마나 잘 받아들여질 것인가
b.
조직에서 진행 중인 운영에 얼마나 효과적으로 사용될 수 있는가?
•
프로젝트 관리자
•
고위 경영층
•
사용자
•
기타 관련자
•
비즈니스와 전략적으로 정렬시킬 수 있는가?
프로젝트 개발 일정과 비용 산정
•
Estimation
◦
프로젝트 수행에 필요한 작업이 어떤 것이고, 얼마나 걸릴 것인지 전체적인 규모 및 비용 등을 예측
•
다양한 방법들이 연구
◦
Function Point Analysis → 규모 산정
◦
COCOMO → 비용 산정
◦
Data-based Estimation → 비용 산정
규모 산정
Function Point Analysis (기능 점수 분석)
•
소프트웨어가 갖는 기능 (입력, 출력, 질의, 인터페이스 등)을 점수로 환산하여 소프트웨어 규모 산정 방법
•
국제표준 ISO/IEC 20926 로 지정
→ 계산 절차
1.
시스템의 주요 요소 파악으로 시작 → 요소(Component 나열)
•
입력 (input) ← 자료 입력 화면과 같은
•
출력 (output) ← 보고와 같은
•
질의 (query) ← 데이터베이스
•
파일 (file)
•
인터페이스 (interface)
2.
시스템에 포함될 각 component의 개수를 기록하고 복잡도를 상, 중, 하로 분류한다
3.
정해진 가중치를 곱하여 총합으로 계산
1) 기능 파악과 점수 계산
2) 복잡도를 고려한 과정
3) size로 환산
Function Point Analysis 의 특성
•
장점
◦
어떤 프로그래밍 언어를 사용하느냐에 좌우되지 않고, 시스템의 규모를 파악할 수 있음
◦
프로젝트를 진행하면서 시스템에 대해, 보다 구체적으로 파악하게 된다면,
◦
상세한 지식을 이용하여 더 정확한 예측이 가능하다
•
단점
◦
계획 단계에서 시스템의 정확한 특성이 결정되지 않는 경우도 있어
◦
입력, 출력, 질의 등이 시스템에 몇 개나 있을지 예측하기 어려울 수도 있다
▪
프로젝트 매니저의 경험 및 예측 능력이 중요하다
프로젝트 비용 산정 (Cost Estimation)
COCOMO 모델 활용
•
공수(Effot) 예측
◦
공수 - 시스템의 크기와 단위시간당 작업량(생산성)을 곱한 것
◦
실제 SW 개발을 위해 투입한 시간 (duration과의 차이 이해)
•
공식 활용
◦
10만 LOC
▪
10명 이하의 인원이 소요되는 소~중규모 SW 프로젝트에 대한 모델
◦
노력 (man-month)
▪
1.4 x 1000줄 코드
COBOL
243 AFP x 110 = 26,730 (LOC)
-) 1.4 x 26.73 = 37.42 인원-월 (man-month)
정확한 예측을 위한 노력
•
과거의 데이터 이용 및 분석이 필수적
•
실제 프로젝트 매니저의 예측값이 정확
일정 계획 (Schedule)
•
Estimation 이후 작업 계획 수립
•
프로젝트 전반에 걸쳐 성취하여야 할 모든 작업을 기록하고 추적할 일정을 의미
◦
각 작업이 언제 완성되어야 하고, 산출물이 어떤 것인지 등등 → WBS 구성
◦
R&R (Role and Responsibilities) 정립
•
Gantt 차트 (간트 차트) 작성
◦
프로젝트의 작업계획을 그래프 형태로 표시
▪
MS Project
조직 구성
•
프로젝트에 필요한 평균 인원 수 결정
ex) 40 man-month → 4명이 10개월
•
Mythical man-month
◦
늦은 프로젝트에 더 많은 인원을 투입해도 빨리 끝나지 않는다
•
보고 구조 단순하게
◦
8~10 명 작은 팀 유지
동기부여 (Motivation)
•
하지 말아야 할 것
◦
비현실적 일정
◦
열심히 일하는 것을 무시하지 않는다
◦
형편없는 제품 만들지 않는다
◦
참여자 모두에게 같은 보상 주지 않는다
◦
중요한 결정은 팀원에게 의사 묻는다
◦
작업 환경 열악하지 않아야한다
•
프로젝트 관리의 균형
1.
시스템 규모 (기능)
2.
시간 (일정)
3.
자원 (개발 인력)
UML (Unified Modeling Language)
•
UML은 객체지향 시스템 개발 분야에서 가장 우수한 모델링 언어로 인식되고 있다
◦
구현에 앞서 표준화되고 이해되기 쉬운 방법으로 SW를 설계
◦
효율적으로 의사소통 할 수 있는 메커니즘 제공해준다
UML 의 특징
•
가시화 언어
◦
시간적인 그래프 형태로 작성
◦
표기법에 있어서 각 symbol에 명확한 정의가 존재
◦
개발자 사이에 오류없는 원할한 의사소통 가능
•
명세화 언어
◦
정확하고, 명백하며, 완전한 모델을 만드는 것 의미
◦
분석, 설계, 구현 단계의 각 과정에서 필요한 모델을 정확하고 완전하게 명세화 할 수 있는 언어
•
구축 언어
◦
다양한 프로그래밍 언어로 표현 가능
◦
설계 모델 소스코드로 변환하여 구축 가능
◦
구축되어 있는 소스 → UML로 분석하는 역공학 가능
•
문서화 언어
◦
문서화를 다루며, 요구사항을 표현하고, 시스템을 테스트하는 언어 제공한다
◦
CASE 툴을 이용하여 설계한 내용 자동으로 문서화 가능하다
→ 객체지향 모델링 언어를 정희하기 위한 노력의 결과로 탄생
UML의 용도
•
설계도 역할
•
성공적으로 시스템 만들기 위해서
•
객체지향적인 분석과 설계를 위한 표준으로 인정받는 UML이 필요
•
개발방법론에 관계없이 적용 가능
모델링 (Modeling) 개념
Modeling
•
시스템을 구축할 때, 개발자가 고민하고 결정하는 모든 활동
Model
•
모델링 활동의 결과
◦
분석 모델, 설계 모델
Modeling Language
•
모델을 표현할 때 사용되는 언어
◦
UML은 바로 이러한 목적으로 사용될 수 있게 정의된 모델링 언어 중 하나
•
UML은 개발 전 과정에서 사용된다
•
개발 별 UML 다이어그램
실시간 시스템
•
상태 다이어그램
•
시퀀스 다이어그램
•
타이밍 다이어그램
분산 시스템
•
배치 다이어그램
객체지향 방법론
•
유스케이스 다이어그램
•
클래스 다이어그램
•
상호작용 다이어그램
CBD 방법론
•
컴포넌트 다이어그램
•
복합구조 다이어그램
구조 다이어그램 (Structural Diagram)
•
클래스 다이어그램
•
패키지 다이어그램
•
컴포넌트 다이어그램
•
컴포지트 구조 다이어그램
•
배치 다이어그램
행위 다이어그램 (Behavior Diagram)
•
유스케이스 다이어그램
•
상태 다이어그램
•
활동 다이어그램
•
상호작용 다이어그램
◦
시퀀스 다이어그램
◦
커뮤니케이션 다이어그램
◦
상호작용 오버뷰 다이어그램
◦
타이밍 다이어그램
클래스 다이어그램 (Class Diagram)
•
시스템을 구성하는 클래스들, 클래스들간의 관계
•
파트의 클래스와 인터페이스 표현
패키지 다이어그램 (Package Diagram)
패키지
•
개념적 유사성
•
기능적 유사성
•
변화의 유사성
•
관리적 유사성
상태 다이어그램( State Machine Diagram)
시퀀스 다이어그램 (Sequence Diagram)
•
참여자간의 시간적 순서에 따른 상호작용을 표현
•
객체들 간의 cowork를 설명
◦
객체들간의 동작을 표시
요약
구조 다이어그램
행위 다이어그램
SW 프로젝트 착수 이후 개념화 작업
•
기능을 잘 정리하고 표현하는 방법으로 기술
◦
유스케이스
◦
프로토타입
◦
Natural language
Use case (유스케이스)
•
외부에서 본 시스템의 view, 행위 (시스템은 Black Box)
•
시스템에 무슨 서비스가 있는지, 사용자의 관점을 본 것 (기능 중심)
•
개발 대상이 되는 시스템이 제공하는 개별적인 기능
•
시스템의 범위에 해당되어 개발될 시스템의 단위기능
•
시스템 - 외부 액터
•
목표 지향적 interaction 의 집합
Use case 작성 목적
•
시스템의 범위를 정하는데 도움
•
개발 과정을 계획하는데 사용
•
요구를 개발하고 검증하는데 사용
•
테스트 케이스를 정의하는 기초
•
사용자 매뉴얼 구성하는데 사용될 수 있음
Use case Diagram
•
사용자의 관점에서 시스템의 서비스 혹은 기능 및
•
그와 관련된 외부 요소를 보여주는 다이어그램
•
고객과 PM이 함께보며 요구사항 조율
•
요구사항 정의 → 개발, 설계에 매우 큰 비중 차지
구성요소
1.
System 시스템
2.
Actor 액터
3.
Use case 유스케이스
4.
Association 관계
시스템 (System)
•
만들고자 하는 시스템의 범위
•
표기법
◦
유스케이스를 포함한 사각형 틀로 표현
액터 (Actor)
•
시스템과 상호작용하는 시스템 외부의 존재
•
시스템으로부터 서비스를 받을 필요가 있는 외부 요소
•
시스템의 외부에 있으면서, 시스템과 상호작용을 하는 “사람” 또는 “다른 시스템”
•
주요기능을 사용하는 사용자는 누구?
•
시스템을 지원하기 위해 필요한 사람은 누구?
•
유지하고 관리하는 사람은 누구?
•
필요한 하드웨어 장치는 무엇?
•
시스템과 상호작용하는 다른 시스템은 무엇?
•
시스템의 처리결과에 연결되는 사람 또는 사물은 무엇?
유스케이스
•
액터에게 서비스를 제공하기 위하여 시스템이 수행하는 중요 기능
•
시스템의 요구사항을 보여줌
•
각 유스케이스가 개발될 기능 하나와 연결될 수 있도록 해야함
관계 (Association)
•
액터와 유스케이스 사이의 관계
•
연관 관계 (Association)
◦
액터와 유스케이스 간에 상호작용이 존재하는가?
•
포함 관계 (Include)
◦
이 유스케이스를 실행하기 위해, 반드시 실행되어야 하는 유스케이스 존재?
•
확장 관계 (extend)
◦
이 유스케이스 실행함으로써 선택적으로 실행되는 유스케이스 있나?
•
일반화 관계 (Generalization)
◦
유스케이스 이벤트 흐름에서 중복된 흐름을 가지는 액터 있나?
유스케이스 다이어그램 작성 순서
1.
액터 식별
2.
유스케이스 식별
3.
관계 정의
팁
•
SW가 제공할 기능에 집중
•
사용자 관점으로 작성
•
목표 지향적으로 작성
•
시스템 흐름도와는 다르다
•
읽기 쉽게 작성