System analysis design
시스템:
컴퓨터에 의해 처리가 가능한 형태로 자료를 변환하여 입력하고, 그 자료를 저장,처리,가공하여 필요한 시점에
정보를 출력할 수 있도록 설계되고 구현된 정보 체계
시스템 개발에는 누가 참여하는가?
SDLC 모형의 5단계
sdlc란 소프트웨어 개발 수명 주기임.
이건 시스템 엔지니어링, 정보 시스템, 또는 소프트웨어 공학에서 정보 시스템을 계획, 개발, 시험, 채용하는 과정임.
분석,설계,구현,테스트,유지보수 단계로 이루어짐
SDLC 모형의 장단점
장점:
1. 시스템 개발의 각 단계가 비교적 명확함.
2. 각 단계들 간에 유기적인 연관성을 가지고 있어 쉽게 적용할 수 있음.
단점:
1. 충분한 분석을 기반으로 개발이 진행되지 않으면 테스트,유지보수 단계에서 문제점이 노출
-> 이를 개선하는데 많은 비용과 시간이 소요됨.
2. 대형 프로젝트는 개발기간동안 외부환경이나 내부 정책이 변화할 소지가 크며, 이를 개선하려면 이전 단계로
되돌아가 변경관리를 해야 하므로 막대한 시간과 비용 듬.
프로토타입 모형
사용자의 요구사항을 정확히 파악하기 위해 소프트웨어 시제품을 만들어 최종 결과물을 예측하는 모형.
요구사항 수집, 개략 설계, 시제품 구축, 요구사항 평가 수정, 생산품 개발 단계로 이루어짐.
프로토타입 모형의 장단점
장점:
1. 개발 초기에 미리 결과물을 확인할 수 있다는 점에서 사용자의 이해를 도움
2. 개발 초기 단계에서 수정,보완할 사항을 미리 파악할 수 있음.
3. 분석 및 설계 과정에 사용자가 동참하여 즉각적인 피드백 가능
단점:
1. 일회적 프로젝트나 대규모 프로젝트의 개발에는 적용하기 어려움
2. 불완전한 요구사항 바탕으로 시제품 만들기에, 결과적으로 불완전한 시스템 산출하여 수정,보완에 많은 인력,시간 소요
프로젝트 관리자의 활동
제안서 작성, 프로젝트 계획과 일정 수립, 비용산정, 모니터링과 중간평가, 실무자 선정과 평가, 보고서 작성과 발표
프로젝트 계획
프로젝트 계획과 함께 수립해야 할 계획들
품질계획: 품질을 위한 계획과 표준을 설명
검증계획: 시스템 검증을 위한 접근방법, 자원, 일정을 설명
구성관리계획: 구성관리 방안과 구조를 설명
유지보수계획: 유지보수를 위한 요구사항, 비용, 노력을 설명
인력개발계획: 팀원들의 경험 축적과 기술개발 설명
1. 프로젝트 일정 수립(언제 뭐 개발할건지 다짜야됌)
2. 품질관리(설계품질(사용자의 요구 반영한것), 적합품질로 나뉨(설계 명세서대로 이행))
개발주기 전체에 걸쳐 시행하는 검열, 검토, 테스트등을 말함.
3.위험관리
위험관리 프로세스
1단계 위험 인식
2단계 위험 분석
3단계 위험 계획
4단계 위험 모니터링
기능 모델링
구조적 분석 방법론:
1980년대부터 활용 시작
현재 요구사항 분석에 가장 많이 활용
사용 도구로는 자료흐름도, 자료사전, 소단위 명세서등이 있음
구조적 분석 방법론의 특징:
매우 간결
이해하기 쉬움
검증 가능
체계적
SADT:
시스템 구조를 계층적으로 기술
이 SADT는 다음과 같은 사항을 수행하기 위한 방법론 제공:
대규모이고 복잡한 문제를 구조적으로 생각하게 함.
각 작업자의 노력,역할 나누고 또 통합해서 팀으로서 효과적으로 활동하게함.
명료,정확한 표기법에 의해서 인터뷰,분석,설계의 결과 전달.
SADT표기법
PSL/PSA:
정보처리 시스템에 대한 요구사항 분석과 문서화를 지원하는 시스템
동적모델링
실시간 시스템:
제한된 시간 내에 외부에서 주어진 사건에 응답하고 자료를 처리하는 시스템
실시간 시스템의 예:
통신 시스템, 비행기 운행관리 시스템, 자동차 속도 조절장치, 원자력 발전소의 원자로 제어장치
상태변화도:
시스템의 제어흐름과 동작의 순서를 나타낸 도식
정보 모델링
시스템에 필요한 엔티티를 정의, 엔티티 사이의 연관성을 규명
대표적 도구: ERR 모델
객체지향 모델링
데이터와 행위를 하나로 묶어 객체를 정의하고 추상화
요구사항 조사방법
관찰 조사: 실제 현장 방문
질문지 조사: 질문지로 정보수집
면담 조사: 보편적,중요한 정보수집 방법 직접대화통해 시스템 문제점및 개선 요구사항등을 파악 가능
요구사항 조사내용
조직에 대한 정보
현재 사용중인 제반 서식
시스템 인프라
현재 운영중인 시스템
기존 검토회의의 문제점
참석자의 역할과 책임 불명확
산출물보다 사람평가 경향
검토회의 목적 불분명
구조적 검토회 효과
역할,책임 명확하게 정의
참여자들 갈등 해소
분명한 목표
개발초기 문제점 발견 가능
프로젝트 진척도 확인가능
공동 책임의식 고취
구조적 검토회의 참석자 역할
산출물 발표자: 검토회의 참석자들에게 산출물 설명
중재자: 검토회의가 효율적으로 순조롭게 진행되도록 회의 계획, 진행 조정
서기: 검토회의에서 발견된 오류나 기타 문제점 기록
산출물 검토자: 산출물 검토, 표준화,유지보수 요원있음
사용자 대표: 요구사항 충족확인, 피드백,조언
제안요청서: 전문 개발업체에게 개발을 의뢰할 경우 작성하는 문서
제안서: 제안요청서를 받은 후보 개발업체들이 작성(개발업체의 사업 수행 능력을 간접적으로 보여줄 수 있는 문서)
사업수행 계획서: 제안요청서를 바탕으로 사업수행에 필요한 제반 계획사항들을 명확히 기술하는 문서
-산출물계획, 일정계획, 품질관리계획, 보고계획, 위기관리 및 보안대책, 교육계획, 주관기관 협조 요청사항
설계명세서: 설계과정에서 산출된 각종 설계 문서를 뜻함.
-시스템 구조도, 데이터베이스 설계문서, 프로그램 작성 지침, 인터페이스 설계문서등이 포함됨.
전통적인 모델의 문제점 구현
폭포수 모델의 문제점
사용자 요구 파악과 명세의 어려움(정확한 요구를 상대방에게 전달하기 어려움)
일정을 못 맞출 위험(이전단계에 모든것이 완료되었을때만 다음단계로 진행)
요구 변경을 수용하기 어려움(변경에 필요한 비용이 뒤로 갈수록 커짐)
품질 확보가 어려움(프로젝트 종료 시점에 테스트를 함)
반면 애자일 모델은 짧은 개발주기를 가지고있음.(단기간에 개발하여 중간 결과를 확인가능)
우선순위가 높은 필수 기능부터 만들고, 요구하는 기능을 순차적으로 추가 하면서 개발,
비전이 기능의 규모를 결정, 분업화를 추구하지 않으며 하나의 팀과 모든일은 팀의 책임임
애자일
고객 중심
큰 프로젝트를 작게 분할
스크럼 - 실제 구현하고 싶은 유저 스토리라는 짧은 문장으로 표현
테스트 중심
테스트 반복 및 일상화
피드백
올바른 목표를 향하여 가고있는지 정기적으로 고객에게 물음
프로젝트관리
작업 추정 - 각 반복주기(스프린트)의 유저 스토리에 대하여 규모와 복잡도를 고려한 점수화
진행속도 - 각 스프린트에 대하여 평균 유저 스토리 점수로 진행 속도 예측
진도 측정 - 유저 포인트 수를 추적하는 그래프
애자일 프로세스
스프린트 계획 -> 스프린트 -> 스프린트 리뷰 -> 회고를 반복
스프린트 계획: 실현하고자 하는 것을 짧은 문장으로 표현한 유저 스토리 집합
스프린트: 스프린트 계획에서 합의한 스토리에 대하여 설계 및 구현, 테스트
데일리 스크럼: 개발자 전원이 수행하는 간단한 회의(작업전 아침실시, 진도확인 및 작업상황,문제점 파악)
스프린트 리뷰: 생성된 결과물을 발주자 측과 확인(구현을 계획한 스토리가 완료되었는지 판단)
스프린트 회고: 스프린트에 대하여 좋았던 일이나 과제 확인, 검토 측정,돌아보기
1. 프로젝트 비전 공유(sw 프로젝트 시작전 중요한일)
- 비전 공유, 역할 분담
- 한팀이 되는 것이 중요(서로 도와주는 것을 소중하게 여김)
2. 개발 팀 구성
- 프로덕트 오너(sw 개발 책임자, 명세 결정 권한)
- 스크럼 마스터(스크럼의 리더)
- 팀원(개발 담당)
3. 인셉션 덱
- 프로젝트 전체의 배경, 목적, 방향, 가치관에 대한 인식 맞추는 작업
- 짧은 문장 안에 프로젝트에 대한 생각을 담아 개발 작업의 기준으로 삼음
- 10가지 활동을 통한 개념 정립
4. 08 스크럼
- 프로덕트 백로그 작성
- 스프린트 계획
- 스프린트 활동
- 스프린트 리뷰
- 스트린트 회고
5. 프로덕트 백로그 작성
- 백로그: 프로젝트를 위하여 남은 일
- 우선 순위가 지정된 아직 실행되지 않은 일
- 구현, 버그 수정, 인프라 변경 등 활동 목록
프로덕트 백로그의 변경: 우선순위 항목의 순서는 언제든 바뀔 수 있음, 항목은 언제나 추가 될 수 있음,
항목은 언제든 분할 될 수 있음, 항목은 언제든 삭제될 수 있음
6. 유저스토리 매핑
사용자의 행동에 기초하여 sw에 담아야 할 기능을 도출하는 작업
고객 중심 뷰
1. 사용자 행동을 카드 1장에 하나씩 작성
2. 유저 스토리를 시간 순으로 나열
3. 유저 스토리에 제목 지정
4. 기본 기능을 나열
5. 상세한 유저 스토리로 분할
7. 유저 스토리 작성
한장의 카드에 who는 what을한다. 왜냐면 why하고 싶으니까
유저 스토리를 시간순으로 정렬(같은 시간에 일어나는 것이 있으면 병렬로 나란히 배치)
8. 유저 스토리에 백본(척추)을 지정
9. 기본 기능을 나열
- 각 주제 밑에 필요한 기본 기능(에픽)을 찾아 나열
에픽: 상세화 하면 하나 이상의 유저 스토리가 될 수 있는 기본 기능
10. 상세한 스토리로 분할
- 필요한 경우 에픽을 스토리에서 분할
- 또는 에픽이 다른 에픽과 통합
11. 스프린트 계획
- 스프린트 주기(1~4주)동안 구현이 가능한 것을 프로덕트 백로그중에서 범위로 정하여 개발 시
12. 스프린트 회의
13. 플래닝 포커
1. 기준 스토리 결정
2. 백로그 아이템 규모 추정
14. 추정값 결정
1. 추정할 스토리의 기능요구를 프로덕트 오너가 설명
2. 개발 멤버 전원이 스토리의 개발에 필요한 추정값을 카드에서 선택
3. 만장일치인가?
4. yes라면 추정값으로 결정
5. no라면 불일치하는 추정값을 낸 이유를 듣기시작(그 후 2번으로)
15. 스프린트 활동
페어 프로그래밍:
2명씩 1대의 모니터를 사용하여 프로그래밍 작업 수행 ->
코드 작성하는 드라이버, 코딩 가이드하고 리뷰하며 테스트하는 네비게이터가 협동하여 구현 ->
정기적으로 역할 교대
16. 데일리 스크럼
- 선채로 15분정도 진행
- 작업의 진행 과정이 아니라 서로의 상황 공유하기 위한 회의
17. 태스크 보드
- 스프린트 백로그의 진행 상황이 어떤 상태인지를 나타내기 위한 도구
18. 스프린트 리뷰
- 스프린트가 끝난 후에 현재 시점에 완성된 결과물에 대해 검토
19. 완료의 정의
20. 프로덕트 백로그 검토
- 다음 스프린트 계획
- 백로그 재검토(우선순위 조정 or 상세화)
- 완료되지 않은 스토리를 전체 스토리 풀에 추가하여 우선순위를 다시 매김
- 우선순위가 높은 스토리가 다음 스프린트의 작업 대상
21. 스프린트 회고
- 행동이나 생각 공유 가능하며 팀 성장 촉진
- 문제점 파악 가능
- 3가지 질문(잘된것(계속 해야될것), 개선하여야할것(멈춰야할것), 다음스프린트에서 개선할 사항(시작할것))
22. 회고에 대한 자세
- 적극적으로 임하기
- 개인화 하여 말하지 않기
- 실천 사항에 집중
- 비밀 유지
- 창의적인 마인드
시스템 분석 설계 접근 방법론
구조적 방법론, 객체 지향 방법론으로 구분
구조적 방법론:
시스템의 대표적인 기능 찾아내고 대표기능 수행하기 위한 서비스기능을 찾아가는 방법(하향식)
예시: 사람의 구조적인 분석
대표기능 밥먹기: 서브기능(이빨로 자른다 > 목구멍으로 넘긴다 > 식도를 타고 내려간다 > 위에서 녹인다 >
장에서 흡수한다 > 항문에서 배출한다)
서브기능: 장에서 흡수한다(세부기능: 모세혈관이 흡수한다 > 심장이 보낸다 > 동맥을 통해 근육과 내장기관에 보낸다)
구조적 분석 기법:
- 자료 흐름도(DFD):
외부객체(시스템 외부에서 시스템과 정보 주고받는 사용자등 외부객체), 프로세스(시스템안에서 정보 처리,변환),
데이터 항목(프로세스 사이의 정보 흐름), 자료 저장소(데이터 베이스)
특징: 도형 중심 표현, 하향식, 다차원적, 제어흐름 중요시 하지않음
효과: 요구사항 쉽게 문서화, 사용자와 분석가 사이 공용어 역할, 일관성 있음
4가지 구성요소: 처리(입력되는 자료흐름을 출력되는 자료흐름으로 변환), 자료흐름(자료흐름도에서 구성요소들 간의 접속관계),
자료 저장소(머무는 자료군의 집합), 단말(상세한 자료흐름도 이해할수있게 사각형의 단말)
자료흐름도 작성 7가지 원칙:
- 자료 보존의 원칙: 어떤 처리의 출력 자료흐름은 반드시 입력 자료흐름을 이용해 생성.
- 최소 자료 입력의 원칙: 어떤 처리가 출력 자료흐름을 산출하는데 반드시 필요로 하는 최소의 자료흐름만 입력
- 독립성의 원칙: 자기의 처리는 오직 자신의 입력 자료와 출력 자료 자체에 대해서만 알면됨.
- 지속성의 원칙: 자료 흐름 기다릴때 제외하고는 다시 시작,멈추면안됨
- 순차 처리의 원칙: 처리에 입력되는 자료흐름의 순서는 출력되는 자료흐름에서도 지켜져야함.
- 영구성의 원칙: 자료저장소의 자료는 제거되지 않아야함
- 자료 변환의 원칙: 자료 본질의 변환
작성 절차:
- 시스템 경계의 입출력 식별
- 시스템 경계 내부의 작성
- 자료흐름의 명명
- 소단위 명세(mini-spec):
분할이 완료된 자료 흐름도의 프로세스가 어떤 기능을 수행하는지 기술한 것
더이상 쪼개지지않는 최하위 프로세스를 설명함.
- 자료사전(DD):
자료 흐름도에 나타난 데이터 정보를 모아놓음으로써 개발자나 사용자들이 편리하게 사용할 수 있도록 한것
객체 지향 방법론:
시스템의 구성 요소들을 찾아내고 구성 요소들간의 연관성을 증명해내는 과정(상향식)
예시: 사람의 객체지향적인 분석
객체 모델링:
뇌, 척수,.. / 눈,코,귀... / 이빨,목구멍,식도,장,위,.... / 근육,내장기관,....
동적 모델링:
음식물: 초기상태 > 잘린상태 > 녹은 상태 > 흡수상태 > 배출상태
기능 모델링:
[초기 상태] 이빨로 자른다 > [잘린 상태] 위로 전달해 위액으로 녹인다 > [녹은 상태] 소장으로 전달한다 >
[흡수 상태] 대장으로 전달한다 > [배출 상태]
객체지향적 분석 기법:
- 유스케이스:
고객의 요구사항을 알아내는데 효과적이다.(이해 관계자 찾아내고 역할에 따라 나누어 엑터로분류)
각 use case에 대하여 시나리오를 만들고 상호작용하는 환경, 배경등을 표현 가능
- 정보 모델링:
UML의 다이어그램으로 나타내어 클래스의 속성과 관계만 표현된 다이어그램 얻어낼 수 있다.
-동적 모델링:
객체의 상태나 동작의 변화 혹은 객체 사이의 상호작용에 관심을 두고 오퍼레이션을 찾는 과정
-기능 모델링:
처리과정을 다이어그램으로 표현
시스템 분석 설계 접근 방법론의 특징:
구조적 방법론:
상하관계가 명확하고 결합도가 강하므로 어떻게 처리가 진행되는지 따라가기 쉬워서 사소한 기능 수정에 매우 편리
하지만 새로운 기능 추가하거나 재활용 하려면 각 기능을 뜯어고쳐내야해서 상당한 노력 소모
객체지향 방법론:
각 개체는 독립적(응집성 높고, 결합도 낮음)이라 개별적인 객체의 작동 파악 쉬움
하지만 전체의 작동원리 알기 위해서는 객체간 연관관계에 대한 이해가 필요해서 객체간 관계정립없이 작업 진행 어려움
하지만 객체 요소들이 독립적이라 새 기능 추가하거나 재활용 할때는 기존 구조에 영향 안주고 수정 가능
구조적 방법론의 개요:
도형화된 도구를 이용해 정형화된 분석 절차에 따라 사용자 요구사항을 파악하고 문서화하는 분석 기법
사용하는 도구로는 자료흐름도, 자료사전, 소단위 명세서등이 대표적
구조적 분석의 기본원리: 추상화원칙, 정형화원칙, 분할 정복, 계층적 구조의 개념
모형화 도구를 사용하는 이유?
비용 감소, 위험도 최소화, 시스템분석가가 제대로 이해하고 문서화했는지 검증 가능, 낮은 비용으로 모형 구축,
쉽게 이해가능, 생각 정형화 가능
모형화 도구 특성
도형적 모형: 시스템을 설명할때 텍스트보다 도형을 통해 더 잘 설명 가능
하향식 분할 모형: 각각의 구성 부분을 독자적으로 표시하고, 시스템 모형을 한부분에서 다른 부분으로 간단히 연결할 수 있어야댐
최소중복모형, 투명적 모형, 다양한 모형
구조적 분석의 4단계 절차:
- 현 물리적 모형화 (업무 수행 절차 및 환경을 있는 그대로 모형화)
- 현 논리적 모형화 (의존적인 물리적 특성 제거해 모형화)
- 신 논리적 모형화 (새로운 시스템에서 수행될 모든 기능, 필요 자료에 대한 모형 구축)
- 신 물리적 모형화 (현실적 물리적 환경 감안해 최종 모형 제시)