'분류 전체보기'에 해당되는 글 304건

  1. 2008.08.21 구조적 설계
  2. 2008.08.21 자료사전
  3. 2008.08.21 개체관계도
  4. 2008.08.21 자료 흐름도
  5. 2008.08.21 시스템 분석
  6. 2008.08.21 타당성 검토
  7. 2008.08.21 프로젝트 계획
  8. 2008.08.21 개발의 중요문제
  9. 2008.08.21 시스템분석가의 역할
  10. 2008.08.21 소프트웨어와 소프트웨어 공학
11. 구조적 설계
1. 구조적(構造的) 설계(設計)
구조적 설계란?
프로그램의 내부구조를 설계하기 위한 하나의 방법론
- 연속(sequence)
- 선택(selection)
- 반복(repetition)      으로 구성
구조적 설계의 필요성
- 이해·개발 쉽게
- 개발자와 완성예정일 등을 예측
- 프로젝트 진척상황 관리 쉽게
- 모듈별 시스템 시험 ⇒ 오류발견·수정 쉽게
- 유지·보수 쉽게
- 예상비용 산정 쉽게
 
모듈단위 구조로의 분할
- 프로그램 작성이 쉽다
- 유지보수 및 수정, 변경작업이 쉽다
- 시스템 수명이 길어진다
- 생산성이 향상

프로그램 개발
1) 외부적인 양식 설계
2) Process Flowchart작성
3) 입력과 출력의 형식 작성
4) 처리 조건 설정
5) Coding
6) Test
7) 적용
모듈의 전개과정
  
                 
 
2. 종래의 모듈설계와 구조적 설계의 차이
모듈이란?
어떤 특정기능의 결과를 얻는 명령들의 집합
· 몇 개의 명령어로 구성되어 어떤 목적의 결과를 얻는 것.
· 별개의 명령어 집단으로 명확히 구분된 것.
· 하나의 입구와 출구를 가진 서브루틴이나 서브프로그램
구조적 설계에서의 모듈화 목표
· What : 무엇을 모듈화 할 것인가 ?
· Why : 무엇 때문에 모듈화 하는가 ?
· How : 어떻게 모듈화 할 것인가 ?
모듈 분할의 지침
모듈의 기본적인 성질
 · 기능 : What
 · 논리 수순 : How
 · 인터페이스
 · 크기가 작을수록 좋다
             
 
3. 구조적 설계의 지침
구조적 설계란
· 계층 구조적인 모듈의 세분화
· 독립된 모듈로 분할하는 것
· 이해하기 쉽게 하는 것

프로그램의 내부구조 설계 요령
◉ 독립된 프로그램단위로의 분할
◉ 모듈구조로의 설계
◉ 모듈구조의 평가

4. 모듈 결합도와 응집도                                                
모듈 결합도
· 자료 결합도(Date coupling)  결합도가 약함(좋은 결합)  
· 구조 결합도(Stamp coupling)                           
· 제어 결합도(Control coupling)                                                   
· 외부 결합도(External coupling)                                                  
· 공통 결합도(Common coupling)                                                  
· 내용 결합도(Content coupling)            결합도가 강함(나쁜 결합)

모듈 응집도
· 기능적 응집도(Functional cohesion)     응집도가 강함(우량)
· 순차적 응집도(Sequential cohesion)
· 통신적 응집도(Communicatioal cohesion)
· 절차적응집도(Procedual cohesion)
· 시간적 응집도(Temporal cohesion)
· 논리적 응집도(Logical cohesion)
· 우연적 응집도(Coincidental cohesion)       응집도가 약함(불량)
 
5. 모듈의 설계에 관한 다른 지침
(1) 결정 수준(Decision Level)
(2) Black-Box화
(3) 1 모듈 1 기능의 원칙
(4) 조건 판정 경우(Test case)를 작게
 
6. 모듈화의 수순
- 자료구조중심형 설계
- 자료흐름중심형 설계
- 기능구조중심형 설계
 
7. 자료 구조 중심 모듈 분할방법
모듈 분할 순서
① : 주어진 문제를 3~10개의 기능으로 분할 ⇒ 데이터 흐름에 따라 나열
② : 데이터 흐름을 분석 ⇒ 흐름, 주된 데이터, 출력데이터 파악
③ : 입력데이터의 추상화
④ : 입력, 변환, 출력기능을 계층구조로 표현
⑤ : 각 모듈에 ①부터 ④까지 적용하고 하위 모듈을 분할
⑥ : 하위모듈의 세분화 한계 설정
⑦ : 모듈 구조 평가

자료구조중심형 모듈 분할방법
1) Flow-chart
2) 파일 형식
3) 프로그램 조건
프로그램 조건
① : 조건을 분석 ⇒ 필요 기능 파악
② : 프로그램 조건에 대한 구조 작성 ⇒ 처리기능 식별
③ : ②에서 구분한 입력, 처리, 출력기능을 계층구조도로 표시
④ : 기본구조도의 기능을 세분화 ⇒ 종속모듈 정의
⑤ : 모듈 구조를 평가 ⇒ 재 배열, 재 구조화
⑥ : 세분화 진행 한계 설정
 
8. 기능 구조 중심 모듈 분할방법
 · 어떻게(How)가 아니라 무엇(What)을 단위로 세분화
 · 기능을 파악하여 하향식 분할
 · 제어기능을 중심으로 분할
 · 여러 제어기능 중에 큰 제어기능 중심
 · 세밀하게 기능분할
 · 모듈로서 존재하는 상태의 단위를 찾아낸다.

모듈의 종류
주요기능으로 분류
① 주 제어 모듈
② 부 제어 모듈
③ 처리 모듈
④ 입,출력 모듈
⑤ 예외처리 모듈

모듈분할의 수순
㉮ : 주 모듈의 기능을 분해
 
                          
 
㉯ : 프로세스처리의 최대 제어기능은 종료하는 제어다
㉰ : 제어기능의 하위에 종속하는 처리기능을 찾는다
㉱ : 이 처리기능에 포함되는 제어기능을 찾는다.
㉲ : 이 제어기능의 하위에 종속하는 처리기능을 찾는다.
㉳ : 제어기능이 없을 때까지 분할
㉴ : 단일기능으로 분할
㉵ : 가능한 수준까지 분할
㉶ : 공통적으로 사용할 수 있는 내부 서브루틴 파악
㉷ : 기능을 집약
㉸ : 각 모듈에 대해 이해하기 쉬운 이름 부여
㉹ : 초기, 종료처리에서도 같은 방법으로 기능의 세분화를 진행

'UP! > Software Engineering' 카테고리의 다른 글

코드체계  (0) 2008.08.21
프로세스 명세서  (0) 2008.08.21
자료사전  (0) 2008.08.21
개체관계도  (0) 2008.08.21
자료 흐름도  (0) 2008.08.21
Posted by 으랏차
,
10. 자료 사전
자료 사전은,
- 자료 요소, 자료 요소들의 집합, 자료의 흐름, 자료 저장소의 의미와 그들간의 관계, 관계값, 범위, 단위들을 구체적으로 명시하는 것
- 파일 혹은 데이터베이스에 있는 자료에 대한 자료 또는 각 자료 항목에 주어진 이름과 길이
  그리고 서술과 같은 데이터를 포함하는 참조를 위한 작업
자료 사전을 작성하는 목적은,
- 조직 속에 있는 다른 사람들에게 특정한 자료 용어가 무엇을 의미하는지를 알려주기 위하여,
  용어의 정의를 조정하고 취합하고 문서로 명확히 하는 것
 
1. 자료 사전의 이해
자료 사전의 기능
(1) 문서화 기능
(2) 중복 정의 방지, 일관성 유지
(3) 자료흐름도를 완전, 정확하게 이해
(4) 파일에 저장될 자료 내용을 결정
 
자료 사전에 포함되는 내용
(1) 자료에 관한 정보.
(2) 절차적인 논리.
(3) 설계 내역.
(4) 자료 관계.
(5) 프로젝트 요구와 양도 가능한 최종 시스템.
(6) 프로젝트 관리 정보.

2. 자료 사전에서 사용하는 기호
① = is composed of
② + and         
③ ( ) optional   
④ ¹{}∩  iteration 
⑤ [ ]  selection     
⑥ |  seperator       
⑦ @  key field      
⑧ *  comment     
⑨ ** no comment  

3. 자료 저장소에 대한 자료 사전
자료 저장소에 대한 설명
- 자료 구조를 설명하는 것
- 자료 구조는 앞에서 설명한 기호를 사용하여 표현

4. 자료 흐름에 대한 자료 사전
자료 흐름에 포함되는 정보
① 정보의 의미를 함축하는 명칭과 일반적인 서술
② 자료 흐름 출처와 목적지 표기
③ 자료 흐름의 수량과 유형
④ 자료 구조의 이룸
⑤ 자세한 설명을 위한 영역시스템 분석과 설계 10장

'UP! > Software Engineering' 카테고리의 다른 글

프로세스 명세서  (0) 2008.08.21
구조적 설계  (0) 2008.08.21
개체관계도  (0) 2008.08.21
자료 흐름도  (0) 2008.08.21
시스템 분석  (0) 2008.08.21
Posted by 으랏차
,
9. 개체 관계도
9.1 개체의 개요
개체관계도란?
∙업무 영역과 관계 있는 모든 개체들의 관계를 보여주는 것
∙개별적 개체와 관계는 표현하지 않고, 개체와 관계 집합 표현
개체란?
∙정보를 표시하는 개념 또는 사람, 사물, 장소, 사건
∙1개 이상의 속성
∙서로 다른 키
∙직사각형으로 표시
개체의 종류
(1) 물리적 개체 : 사람, 장소, 사물
(2) 개념적인 개체 : 시장, 계획, 판매
(3) 상황적인 개체 : 납품, 검사
개체가 될 수 없는 것
(1) 계산 값
(2) 개체 설명 또는 개체를 가리키는 것
(3) 처리 절차
(4) 개체의 속성을 나타내는 보고서
개체를 찾는 요령
(1) 인터뷰나 질문
(2) 패러다임 적용과 집단화
(3) 원천과 종점 파악

개체의 명명과 정의
(1)개체의 명명 기준
-명사 또는 명사절, 단수형으로 표시
-개체가 실제 업무에 사용되는 이름과 동의어
(2)개체의 정의 절차
-개체의 이름 선정
-간단 명료한 정의
-실 업무의 예 사용
-정의 대신 예 사용금지
-예를 들 때 대문자 사용
-개체 정의 경우, 자기 자신의 일부 사용금지
개체의 유형
(1)기본 개체
(2)종속 개체
(3)연관 개체
개체의 속성
(1)속성의 종류
①물리적 속성
②위치적 속성
③정량적 속성
(2)속성의 정의 절차
① 속성의 이름을 명명
② 개체와 속성을 설명하는 양식을 이용하여 정의, 키의 종류와 유형도 같이 정의한다.
개체의 관계
∙두 개체 사이에 포함된 의미 있는 관련 표현
∙동사 또는 동사절로 표현
∙관계는 개체 사이를 직선으로 연결
(1) 개체관계의 종류
① 관계 수
② 선택 수
(2) 개체관계의 정의 절차
① 개체 사이를 굵은 선으로 연결
② 연결된 선을 기준으로 개체들의 관계를 동사절로 표현
③ 항상 시계 방향으로 읽는다
④ 최소와 최대 연결 수를 나타내는 숫자나 기호 표시
9.2 개체관계도 작성요령
개체 관계도의 기호
(1) 개체
(2) 속성
(3) 관계

개체 관계도의 표현
(1) 개체유형 설명 도표
(2) 외부 Entity
(3) 업무 기능
(4) 장기 목표


(1)키의 종류
①후보 키
②복합 키
③제 1 키
④대체 키
⑤외부 키
(2)키의 식별 방법
개체의 속성을 조사 ⇒ 유일한 식별 속성들의 조합 결정
(3)제1키 선정
제1키는 시간이 지나도 안정적, 키의 길이를 충분하게
(4)키를 제외한 속성
개체를 기술하거나 설명, 유일하게 정의는 못하는 속성
(5)키 이주
이주하는 키가 키를 받는 개체를 유일하게 식별할 필요가 있을 때 그러한 관계를 식별 관계라고 부른다
9.3 모형화
1 모형화의 필요성
모형화란? 바람직한 최종 산출물을 표시하는 것, 문자 형식에 대응한 도형 또는 물리적인 표시
필요성
- 오류 발견, 설계 상의 문제를 구축 전에 확인
- 정교하게 프로젝트를 세분화
- 품질 향상과 예측이 가능
- 보완 또는 유지 보수비용 감소
2 모형화 방법
∙ 방법(how)과 목표(what)를 분리
∙ 목표, 상황과 우선순위 설정
∙ 정규화 시행
3 정규형
(1)제 1 정규형
-반복되는 집단 제거
-원래의 개체에 “자”인 새로운 개체 만듦
-업무 규칙에 근거, 새로운 개체의 키를 결정
-2개의 개체 사이의 관계를 이름짓고 관계 수를 결정
(2)제 2정규형
-반복되는 그룹을 제거
-복합 키 전체에 대하여 종속적이 아닌 속성을 제거
-제 2정규형으로 분해
(3)제 3정규형
-반복되는 집단 제거
-복합키의 전체에 대해 종속적이 아닌 속성들을 제거
-기타 키가 아닌 속성들과 종속적인 속성들을 제거한다.
-제 3정규형으로 분해
(4) 선택수
- 개체 사이에 관계가 없는 경우를 허락하는 업무 규칙이 존재할 때 사용
- 물리 데이터베이스  설계를 위한 기초로서 자료 모형을 쓰는 데 유용
- 시스템 편집 규칙을 결정하는 데도 사용

'UP! > Software Engineering' 카테고리의 다른 글

구조적 설계  (0) 2008.08.21
자료사전  (0) 2008.08.21
자료 흐름도  (0) 2008.08.21
시스템 분석  (0) 2008.08.21
타당성 검토  (0) 2008.08.21
Posted by 으랏차
,
8 자료 흐름도
모형을 사용하는 3가지 이유
1) 중요 특징 부각, 중요하지 않은 특징 생략
2) 위험부담 최소화, 사용자 요구사항의 빠른 수렴
3) 이해 확인, 문서화
모형 특성
∙ 간략한 문자로 상세한 표현이 가능한 도형 중심
∙ 시스템을 하향식이고 분할된 형태로 표현
∙ 최소한의 중복성
∙ 시스템의 처리 결과 예측
∙ 명확한 표현 가능

1. 자료흐름도(DFD : Data Flow Diagram)
자료흐름도 작성 5단계
1) 자료 흐름 유형 확정
2) 자료 흐름 경계 표시
3) DFD를 프로그램 구조로 사상
4) 제어 계층을 분해시켜서 정의
5) 결과 구조는 설계측정들과 경험적 학습법을 사용해서 정제
4 가지 기본도형
                            
         
                                 
자료흐름도 작성시 고려 사항
① 프로세스, 흐름, 저장소 와 단말의 이름은 의미를 포함할 것
② 프로세스에는 일관성 있게, 어떤 수행의 순서를 알 수 있도록 부여할 것
③ 복잡한 자료흐름도는 피할 것
④ 논리적으로 정확하고 이해하기 쉽게 그려질 때까지 여러 번 수정 및 반복하여 그릴 것

자료흐름도의 장,단점
(1) 장점
· 시스템 모형과 세부기능에 대한 모형을 묘사할 수 있다.
· 그림으로 표현 ⇒ 시스템 운영, 관계자료의 흐름을 요약, 파악 ⇒ 이해하기 쉽다
· 복잡한 시스템을 개발할 경우, 총체적, 세부적 구조의 문서로 사용
(2) 단점
· 순서도와 혼동되면 혼란을 일으킬 수 있다.
AJ.A· 요구사항을 기술하는 데 불충분
· 자료사전이나 프로세스 명세서 같은 설명문 추가 필요
· 단말내용, 작업방법 변경이 불가능
· 단말사이에 존재하는 어떤 관련성도 이 흐름도에서 찾아 볼 수 없다.
· 데이터가 어떻게 흘러 다니는지는 알 수 있지만 제어나 순서에 관한 정보는 알 수 없다.
자료흐름도 작성시 고려 사항
① 프로세스, 흐름, 저장소 와 단말의 이름은 의미를 포함할 것
② 프로세스에는 일관성 있게, 어떤 수행의 순서를 알 수 있도록 부여할 것
③ 복잡한 자료흐름도는 피할 것
④ 논리적으로 정확하고 이해하기 쉽게 그려질 때까지 여러 번 수정 및 반복하여 그릴 것

자료흐름도의 장,단점
(1) 장점
· 시스템 모형과 세부기능에 대한 모형을 묘사할 수 있다.
· 그림으로 표현 ⇒ 시스템 운영, 관계자료의 흐름을 요약, 파악 ⇒ 이해하기 쉽다
· 복잡한 시스템을 개발할 경우, 총체적, 세부적 구조의 문서로 사용
(2) 단점
· 순서도와 혼동되면 혼란을 일으킬 수 있다.
· 요구사항을 기술하는 데 불충분
· 자료사전이나 프로세스 명세서 같은 설명문 추가 필요
· 단말내용, 작업방법 변경이 불가능
· 단말사이에 존재하는 어떤 관련성도 이 흐름도에서 찾아 볼 수 없다.
· 데이터가 어떻게 흘러 다니는지는 알 수 있지만 제어나 순서에 관한 정보는 알 수 없다.
 
2. FLOW CHART
미리 정의된 기호와 그들을 서로 연결하는 선을 사용하여 그린 도표
기호는 1962년 국제 표준화 기구 (ISO)에서 정한 것을 표준으로 사용
(1) 장점
· 설계표현을 위해 가장 많이 사용
· 처리과정을 자세히 설명할 수 있다
(2) 단점
· 전체 시스템 구성을 설명해 줄 수 없다.
· 구조적 프로그램 작성을 방해
· 지엽적(枝葉的)인 문제에 집착하도록 하는 경향
· 포함된 루프나 포함된 조건으로부터 탈출하는 경우 비효율성 야기
· 제어흐름 모호, 오류발생의 가능성 증가, 이해 유지 나쁨
· 기능적인 영역에 위배되는 화살표 사용
 
                  
 
3. 결정 테이블(Decision Table : 판단표)
        Conditions & Actions                  Rules 
        --------------------------------------------------------------             
              조건 표제란                   조건 기입란
              행위 표제란                   행동 기입란
                            <결정 테이블 모형>
 
(1) 장점
· 완결성, 일관성의 체계적 점검 가능
· 복잡한 논리를 한 눈으로 알 수 있게 표현
· 누락과 오류 방지
· 복잡하게 얽힌 분기의 논리 등을 구조화하는데 적합
(2) 단점
· 순서, 반복 또는 시간에 관련된 정보를 나타낼 수 없다.
· 어느 처리를 어떤 순서로 하는가를 한눈으로 알 수 없다.
 
4. N-S 도표(Nassi-Shneiderman Chart)
                 
(1) 장점
· 기능영역이 잘 정의되고 세부적인 논리표현에 적합한 다이어그램 표현기법이다.
· 전역 또는 지역 데이터의 영역이 쉽게 표현된다.
· GO TO문을 사용하여 프로그램이 알기 어렵게 되는 것을 피했다. 따라서 프로그램 모듈의 논리를 구조화하여 표현하고 문서화하는데 편리하다.
· 읽기 쉽고 프로그램 코드로 변환하기가 쉽다.
 
(2) 단점
· 프로그램의 구조가 잘 이해되지 않고 대형 프로그램일 때 자료의 흐름을 표현하기에는 적합하지 않다.
· 제어의 임의의 전달은 불가능하다.
· 처리요소들은 표현하고 있으나 이들간의 인터페이스는 표시하지 못한다.
· 처리설계에만 적용되고 데이터 구조 설계에는 적용할 수 없다.
· 데이터베이스에 기초를 두지 않았다.
· 데이터 모델이나 자료사전과 관련을 맺기가 어렵다.

5. JACKSON DIAGRAM(METHOD)
네 가지 기본형으로 표현
1) 기본 : 더 이상 분해할 수 없는 기본이 되는 단위
2) 순차 : 둘 이상의 요소로 구성, 각각의 요소는 정해진 차례로 1회만 나타난다.
3) 선택 : 둘 이상의 요소로 구성된다는 점은 연접과 같다.
             다만 연접과는 달리 한번에 그중의 어느 하나만이 나타난다.
             선택을 나타내기 위해 。 표를 붙인다.
4) 반복 : 그 속에 포함되어 있는 요소가 몇 번이라도 반복한다.
             반복 표시를 위해 기호의 오른쪽 위에 *를 넣는다.
 
                          
(1) 장점
· 직접적으로 순차, 조건, 반복을 포함한 절차적 구성
· 역추적 상황 완화, 구조 불일치 해결, 소프트웨어 최적화에 사용
· 예비설계 기술보다 세부적인 설계 기술에 근접
(2) 단점
· 중간 파일 이용이 비효율성 증가, 개념상 불필요
· 프로그램 이해 곤란, 유지보수 곤란, 오류 유발
· 논리 또는 파일 시스템 등의 데이터베이스 시스템 설계에는 유용하지 않다.
 
6. HIPO
                   
 
           
(1) 장점
· 전체 또는 상세한 부분까지도 쉽게 알아본다
· 문서화의 표준화로 올바르게 생각 전달
· 구조화 프로그래밍 기법과 결합, 고도의 모듈화 실현 기대
· 기능구조가 계층적으로 도식화, 작업을 위에서 아래로 논리적으로 전개 가능
· 기능, 입력, 출력자료가 나타나 있으므로 자료가 변해 가는 과정을 시각적으로 볼 수 있다
· 작은 프로그램 개발에 좋은 도구
(2) 단점
· 그리기 어렵다.
· 프로그램구조를 구체적으로 표현하는 방법이 없다.
· 처리단계나 입출력항목이 많아지면 표현이 어렵다.
· 데이터구조나 데이터간의 관계를 표현할 수가 없다.
· 시스템 분석가나 설계자 또는 프로그래머를 위한 어떤 지침, 책략, 절차 등이 없다.
 
7. 의사코드(Pseudo-code)
 
  SALE_PRICE = PRICE * ( 1 - DISCOUNT_RATE )
  PROFIT = ( SALE_PRICE  - PURCHASE_PRICE ) * AMOUNT
  IF PROFIT IS GRATER THEN UPPER_LIMIT
  THEN MOVE EXCELLENT_CHARACTER TO ASSESS
   GO TO PRINT_ASSESS
  END-IF
  IF PROFIT IS GRATER THEN OR EQUEL TO LOWER_LIMIT
  THEN MOVE GOOD_CHARACTER TO ASSESS
   GO TO PRINT_ASSESS
  END-IF
  IF PROFIT IS LESS THEN LOWER_LIMIT
  THEN MOVE BAD_CHARACTER TO ASSESS
  END-IF
 PRINT_ASSESS.
  CALL PRINT_RECORD
 
1) 의사코드의 필요성
    플로우 챠트 :
    “어떤 순서로 처리하는가(How) ?” 표현 수단
    “무엇을 하는가(What) ?” 표현 수단으로 부적합
    의사코드 :
    What 과 How 를 동시 표현
    문서화
    생각 도구
    프로그램 설계정보 전달 도구
    자연어와 유사
2) 의사코드의 표현방법
 판매단가 = 정가 * ( 1 - 할인율 )
 이익 = ( 판매단가  - 구입단가 ) * 수량
 IF (이익 > 목표상한)
 THEN 평가 = “매우 우수”
 ELSE IF (이익 >= 목표하한)
  THEN 평가 = “우수”
  ELSE 평가 = “불량”
  END-IF
 END-IF
 인쇄하는 부프로그램 CALL

8. 워니어-오어(Warnier-Orr) 다이어그램
                         
Warnier-Orr 다이어그램
계층적 구조를 표현
제어와 흐름 표현
실행될 함수의 횟수 표현
실행제어 논리는 각주로 표기
선택구조는 (0, 1)을 함수이름 아래에 기술
+(OR), (Exclusive OR) 표기를 한다
◉ 장점
· 새로운 시스템의 설계와 기존의 시스템에 대한 문서로 광범위하게 사용된다.
· 구조화된 프로그램 코드로 옮길 경우 Begin-End 블럭구조 형식을 사용하여 간단하게 해결할 수 있다.
· 데이터 구조에 대한 효과적인 문서를 제공한다.
· 4개의 기본적인 다이어그램 기법으로 구성되어 있기 때문에 사용법이 쉽다.
◉ 단점
· 구조를 확실하게 표현할 수 있지만 세부적인 단계에서는 부피가 커지기 때문에 읽기가 어렵다.
· 제어 논리를 각주로 이용하기 때문에 읽기가 불편하다.
· 데이터베이스에 기초를 둔 것이 아니기 때문에 계층적 구조만을 기술하고 있다.

'UP! > Software Engineering' 카테고리의 다른 글

자료사전  (0) 2008.08.21
개체관계도  (0) 2008.08.21
시스템 분석  (0) 2008.08.21
타당성 검토  (0) 2008.08.21
프로젝트 계획  (0) 2008.08.21
Posted by 으랏차
,
7. 시스템 분석
시스템 접근법(systems approach)
문제점을 찾아내서 원인을 분석하고 대책을 세우는 방법
경영에 컴퓨터를 이용하게 된 이유
 ① 할 수 없었던 일들을 하기 위해
 ② 문제점들을 신속, 정확하게 파악하기 위해
 ③ 창의적이고 전문가적인 일을 하기 위해
 ④ 조직운영의 융통성
컴퓨터를 효율적으로 활용하기 위한 고려사항
 ① 일을 선택할 기준 설정
 ② 컴퓨터의 종류를 용도에 맞게 선택
 ③ 대상 업무 처리에 맞는 컴퓨터 언어 선택
 ④ 요구를 분석하고 새로운 시스템을 설계

1 시스템 요구사항 분석 및 정의
시스템 개발 작업이란?
컴퓨터를 이용하고자 하는 목적에 따라 요구하는 사항을 분석하고 정의하는 것
 
분석이란?
① 문제점 파악하고, 해결하기 위해 문제제기 하는 것
② 문제를 해결하기 위하여 보다 작은 요소로 분해하는 일련의 과정
③ 어떤 행동을 취하기 전에 문제를 연구하여 문제의 속성, 기능, 관련성을 파악하여 비구조적인 문제로부터 구조적인 모형을 추출,
    명세화하는 행위
 
소프트웨어 요구 분석이란?
① 문제의 연구 및 해결책을 찾기 위한 체계적인 접근방식 적용
② 정보의 흐름과 구조를 파악하여 소프트웨어를 개발하기 위한 기본을 제공하는 것
③ 목적하는 소프트웨어가 가져야할 상세한 기능을 하드웨어와 소프트웨어에 맞게 분석
④ 설계 또는 이행상의 제약사항을 결정하기 위해 시스템이 수행해야할 기능들을 정의
 
요구분석의 주요 활동
① 현재의 방법을 분석, 사용자가 원하는 요구 추출
② 소프트웨어가 이러한 요구를 어떻게 해결할 것인가를 기술
 
요구정의란?
 제기된 문제를 해결하기 위한 수단을 찾아내기 위해, 사용자 요구사항을 파악하여 실현 가능한지를 검토한 후
 새로운 시스템이 필요로 하는 명세서를 작성하는 것
 
요구분석 및 정의의 목표를 달성하기 위한 고려사항
 · 시스템 분석방법
 · 현 시스템에 대한 조사절차
 · 신 시스템에 대한 요구명세서 작성

2 시스템 분석방법
시스템 분석
1) 시스템의 기능과 구조를 명확히 한다.
2) 문제의 본질을 세분화하여 근본적인 문제점을 파악
3) 불명확한 문제를 찾아 해결방법과 대체 안을 마련
4) 복수의 해결법을 검토하여 근본적인 해결책 모색

3 시스템 분석 접근방법
   ① 하향식 접근방법(Top-down approach)
   ② 상향식 접근방법(Bottom-up approach)

4 시스템 조사 방법
1) 자료 수집법 : 필요한 자료를 수집하여 정리하는 방법
    수집해야할 필요한 자료
     · 각종 설명서, 해설서
     · 계획서
     · 논문, 문헌
     · 신문, 잡지의 관련기사
     · 관계 법규, 회사 내규 및 직무 명세서
     · 카다로그
     · 보고서, 통계 데이터
     · 조직도표, 시스템 흐름도
     · 조직 방침

2) 현장 관찰법 : 현장 관찰, 실제 경험 방법
   ① 실무자들을 지원하기 위한 관찰
   ② 현업 책임자들을 지원하기 위한 관찰
   ③ 중간 관리자들을 지원하기 위한 관찰
   ④ 최고 경영자들이 활용할 수 있는 정보를 제공하기 위한 관찰
       a 기업의 내적요인들
       b 기업의 외적요인들

전략적인 계획 수립
 . 제품계획
 . 자금소요계획
 . 소요인력계획
 . 자원계획
 . 운송계획
 . 재고계획
 
3) 면담법
  ∙ 면담하는 사람의 견해를 찾아내야 한다.
  ∙ 견해에 추가하여, 면담에 응하는 사람의 배경을 감지하려 시도해야 한다.
  ∙ 목적 또한 중요한 정보는 면담을 통하여 확립할 수 있다.
 
면접의 방법
 ① 개별 면접
 ② 집단 면접
 
면담을 위한 주요 사항
 ① 배경 정보의 이해
 ② 면담 목적의 설정
 ③ 면담할 사람의 결정
 ④ 면담 당사자에 대한 준비
 ⑤ 질문 형식과 구조의 결정
 
1) 질문의 형식과 내용
 ① 개방형 질문
 ② 폐쇄형 질문 : 대답에 제한을 두는 질문
 ③ 증명형 질문
 
2) 면담시 유의사항
 (1) 유도형 질문은 피할 것
 (2) 질문은 간단 명료하게
 (3) 전문적인 전산용어 피할 것
 (4) 논리적 순서에 따라 질문
      ① 귀납적 방식 : 피라미드 모양으로 가시화 할 수 있다.
      ② 연역적 방식 : 개방형 질문, 연역적으로 시작, 폐쇄형 질문을 사용, 폭이 좁은 응답
      ③ 다이아몬드형 : 다양한 질문을 통해 면담에 응하는 사람의 흥미와 주의를 끌 수 있다
 (5) 기록을 하게되면 상대방이 더욱 신중한 답변을 하도록 하는 효과는 있으나
      잘못하면 심문 받는 분위기를 만들게 되므로 주의해야 한다. 기록하는 대신 녹음기를 사용하기도 한다.
      ① 녹음기를 사용(Using a Tape Recorder)하는 방법
      ② 노트에 기록(Notetaking)하는 방법
 
5 설문지의 사용
 ∙광범위한 의견 수렴에 사용
 ∙전체조사, 표본조사로 구분
 
5.1 설문지 작성
방식
  ① 다지선택방식(Multi-choice)과 자유기술방식(Free-answer)
  ② 기명방식과 무기명방식
용도
  ① 수집해야할 정보가 지역적, 시간적으로 멀리 떨어져 있거나
  ② 정보수집 대상이 아주 많은 경우에 주로 사용
  ③ 결과는 통계적인 방법을 사용하여 결론을 유도
  ④ 프로젝트의 계획을 세우기 전, 전체적인 방향, 윤곽 설정을 위해 사용
 
5.2 설문지 작성시의 유의사항
 1) 단어의 선택
     ① 단순한 단어 사용, 막연한 단어보다 전문용어를 비롯한 특수 단어 사용
     ② 질문은 짧게, 저급언어 사용 회피
     ③ 두 가지 뜻을 가진 단어의 사용을 피한다
     ④ 질문의 대상을 명확히 하여 응답자의 수준에 맞는 질문
     ⑤ 질문의 내용이 기술적으로 정확한지 확인
 2) 스케일의 사용
     ① 명목(Norminal) 척도
        <예> : 직업구분 코드, 남녀구분 코드, 지역구분 코드의 사용
     ② 순위(Ordinal) 척도
        <예> : 등수, 도착순서, 일련번호 등
     ③ 등간(Interval) 척도
        <예> : 학점(A,B,C.D), 연령구분(10대, 20대, 30대, 40대 ····), 소득구분 등
     ④ 비율(Ratio)척도
 
 3) 설문지의 형식
     ․충분한 여백 확보
     ․숫자의 범위를 사용
     ․형식을 결정하고, 형식에 일관성을 유지
     ․질문의 순서를 결정
     ․첫 번째 질문에 주제를 담고, 응답자의 관심을 유발시키는 질문
     ․논쟁의 여지가 없는 항목을 앞에 배치
     ․유사한 내용의 질문은 하나의 집단 아이템으로 구축, 연상되는 질문을 차례로 배치

'UP! > Software Engineering' 카테고리의 다른 글

개체관계도  (0) 2008.08.21
자료 흐름도  (0) 2008.08.21
타당성 검토  (0) 2008.08.21
프로젝트 계획  (0) 2008.08.21
개발의 중요문제  (0) 2008.08.21
Posted by 으랏차
,
6장  타당성 검토
프로젝트 기초들
문제 인식
 
6.1  프로젝트 기초들
프로젝트 가능성 결정
프로젝트 착수
프로젝트의 일정계획 수립
생산성 향상 활동
팀 구성원 관리
 
6.2  문제 인식
시스템 프로젝트 개발 이유
 1) 현재의 시스템으로 해결하기 어려운 문제들을 해결하기 위해
 2) 기능이나 성능의 향상을 얻기 위해서
 
1) 조직 안에서의 문제들
    시스템 분석가의 도움이 필요한 이유
    1) 적시에 제공되지 못하거나 불완전하고 부정확하게 만들어진 출력자료
    2) 기능, 성능에 대한 목표설정 미흡
    3) 근로자들의 결근, 이직, 직업에 대한 불만족의 증가로 인한 관리의 어려움
2) 개혁을 위한 기회들
     - 성능을 향상시킬 수 있는 곳 파악
     - 복잡한 문제  ⇒ 분석하면 개혁을 위한 기회
     - 시스템 분석가 능력 : 개혁을 위한 기회 파악
3) 프로젝트의 선택
    프로젝트의 선택 평가 기준
    - 경영자의 의지
    - 프로젝트 수행을 위한 적당한 투자 시간
    - 목표 달성의  가능성
    - 시스템 분석가와 조직을 위한 견지에서 실제적 동원 자원
    - 투자할 수 있는 다른 프로젝트 및 방법들과 비교
   
3. 현상 분석
1) 타당성 조사
   1 단계 : 이해 당사자의 요구조사
              ∙ 현 정보흐름과 사용자의 역할
              ∙ 업무 개선
              ∙ 사용자의 원, 불원
              ∙ 성취 목표
   2 단계 : 프로세스의 특성 규명
              ∙ 해야할 일
              ∙ 사용자가 해야할 일
              ∙ 그 다음 해결책
   3 단계 : 프로세스 진행상의 타당성 규명
              ∙경제적, 기술적, 운영상의 성공요인과 장애요인 파악
              ∙주요 성공요인과 장애요인에 대한 대안 파악
              ∙주요 평가척도 기준
   4 단계 : 최적안 선택
              ∙ 미리 정한 평가기준에 따라 최적안 선택
              ∙ 프로젝트의 계속진행 여부 결정
2) 타당성 분석
                                         타당성 검토를 위한 도표의 예 : 가중치는 임의적인 숫자임

3) 타당성 결정
타당성 결정 : 프로젝트 계속 여부를 결정
기술적 타당성
경제적 타당성
운영의 타당성
 
프로젝트 수행 목적과의 일치
- 오류감소
- 비용 절감
- 기능과 역할 통합
- 고객 서비스 제고
- 입력의 신속화
- 자료처리 시간의 단축
- 자동화
 
목적에 포함시킬 내용
 ‧ 해결해야 할 문제가 무엇인가?
 ‧ 어떤 위치로 향상될 것인가?
 ‧ 기대가 무엇인가?
 
4 소프트웨어 패키지의 활용
 1) 패키지 도입의 장점
    - 시간과 비용 절약
    - 성능이 보장
 2) 패키지 도입의 단점
    - 요구에 부합되는 패키지 없다
    - 변조에 시간과 비용이 필요
    - 공급자에 대한 의존도가 높다
    - 강제 적용에 불만 발생
 3) 패키지 도입시의 고려사항
    - 여러 종류의 패키지를 비교
    - 패키지 도입시의 선정기준을 결정
      기능, 성능, 사용 용이성, 변경 용이성, 계속 지원 가능성, 제품의 신뢰성, 사용 고객들의 평판,
      문서화, 사용자 교육, 가격 등에 가중치 적용 여러 사람이 평가
    - 하드웨어는 적정 수준 이상인지를 검토

'UP! > Software Engineering' 카테고리의 다른 글

자료 흐름도  (0) 2008.08.21
시스템 분석  (0) 2008.08.21
프로젝트 계획  (0) 2008.08.21
개발의 중요문제  (0) 2008.08.21
시스템분석가의 역할  (0) 2008.08.21
Posted by 으랏차
,
5. 프로젝트 계획
프로젝트 계획수립의 목표
프로젝트 계획
소프트웨어의 범위
소프트웨어 개발자원
소프트웨어 개발도구
소프트웨어 비용산정
소프트웨어 개발 추진일정
과거 대형 프로젝트의 실패원인 :
능력보다는 관리 기술의 문제
경험이 부족
소형 프로젝트의 관리기술을 적용
성공적인 소프트웨어 개발 프로젝트 수행
수행할 업무 범위, 소요 자원, 비용, 일정 등에 관한 사항을 관리하는 능력 필요
소프트웨어 프로젝트 관리 과정
프로젝트 계획 수립 활동
- 조사 연구 ⇒ 기능, 성능, 신뢰도, 인터페이스, 범위 결정
- 예측 ⇔ 시스템 명세서
예측 작업에 영향을 미치는 요소 :
1) 프로젝트 복잡도
2) 프로젝트 규모
3) 프로젝트 구조

1. 프로젝트 계획수립의 목표
프로젝트란
1) 프로그램 설계, 연구개발 계획, 건설공사 등의 일이나 사업
2) 단체나 조직에서 창조, 수정, 결합을 위해 사용되는 수단

2. 프로젝트 계획
프로젝트 계획수립이란
계획을 만들고 수행하는 과정의 활동
프로젝트를 계층적으로 분류 ⇒ 명확, 간결하게
책임과 노력을 구조화 ⇒ 비용과 일정을 계획하고 통제
프로젝트 계획 단계에서의 활동
1) 수행해야 할 기능을 인식하고 정의
2) S/W의 계획 작성과 요구 사항에 대한 분석작업
3) S/W의 성능, 특성, 제한사항, 검증기준과 접속관계 등을 기술

3 소프트웨어의 범위
소프트웨어 영역의 결정 : 기능, 성능, 신뢰도, 규모, 제약, 비용, 방법, 도구 등 한계가 명확해야 한다.
 
4 소프트웨어 개발 자원
 1) 인적 자원
 2) 하드웨어 자원
 3) 소프트웨어 자원
 
 
5 소프트웨어 개발도구
CASE(Computer-aided software engineering)
- 비즈니스 시스템 계획 수립 도구

'UP! > Software Engineering' 카테고리의 다른 글

시스템 분석  (0) 2008.08.21
타당성 검토  (0) 2008.08.21
개발의 중요문제  (0) 2008.08.21
시스템분석가의 역할  (0) 2008.08.21
소프트웨어와 소프트웨어 공학  (0) 2008.08.21
Posted by 으랏차
,
4. 개발의 중요 문제
조직의 형태 이해
조직의 정보이용
 
정부가 기업 정책 결정에 미치는 영향
1) 통제를 가하여, 기업의 전략 결정이 용이하도록
2) 육성을 통하여, 기업의 의사 결정 자유를 구속
3) 정비와 강화를 위하여, 공적인 의사 결정으로 대치해서, 극단적인 경우 국유화 또는 공기업화 한다.
 
지역사회가 기업에 미치는 영향
좋은 면 :
① 지역 기반시설 확충
② 고용확대로 지역사회 형성∙발전
나쁜 면 :
① 소음, 수질오염, 공기오염 등 공해유발
② 산업재해
 
1 조직의 형태 이해
1.1 기업형태의 분류
1.2 개인기업
1.3 공동기업

1.1 기업형태의 분류
1) 자본적 규모에 따른 분류 : 대, 중, 소기업
2) 업종에 따른 분류 : 농, 공, 상, 광, 금융 및 서비스업
3) 출자자의 성질에 따른 분류 : 공, 사, 공·사 공동기업
4) 법률 규제에 따른 분류 : 합명, 합자, 유한 및 주식회사
5) 소유와 지배형태에 따른 분류 : 개인, 공동기업

1.2 개인기업
1) 장점
① 개업과 폐업이 용이
② 이익 독점
③ 신속한 의사결정
④ 기밀 유지
⑤ 개인 소득세만 납부, 법인세를 절약
 
2) 단점
① 능력 한계
② 개인과 기업이 공동운명
③ 손실과 채무가 자본금을 상회하더라도 무한책임
 
1.3 공동기업
1) 공동기업의 형태 및 분류
2) 공동기업의 내용
3) 주식회사
4) 공기업
5) 공사 공동기업(公私共同企業)
6) 협동조합
 
1) 공동기업의 형태 및 분류
  ① 법률에 따른 분류 :
    - 조합 ; 민법상의 협동조합과 상법상의 익명조합
    - 회사 ; 합명회사, 합자회사, 유한회사, 주식회사
  ② 형태별 분류 :
    - 일반 공동기업 ; 합명회사, 민법상의 조합
    - 특수 공동조합 ; 익명조합, 합자회사, 유한회사, 주식회사

2) 공동기업의 내용
① 민법상의 협동조합
② 익명조합
③ 합명회사
④ 합자회사
⑤ 유한회사
3) 주식회사
① 증권제도
② 유한책임제도
③ 소유와 경영의 분리
④ 책임경영제도
 
4) 공기업
① 공익성
② 공공성
③ 통제성
④ 독립채산제
⑤ 순수 행정기업, 독립적 공기업, 법인형태의 공기업
 
공기업의 장점
① 자본조달이 용이
② 조세면제의 특혜
③ 구매와 판매상의 특권
 
공기업의 단점
① 자유재량권의 결여
② 사무처리의 복잡성
③ 독창성의 결여

5) 공사 공동기업(公私共同企業)
공사공동기업의 장점
① 많은 자본조달이 용이하다.
② 과당경쟁 요인을 국가적인 차원에서 제거
③ 원료구입, 상품판매에 우선권 공사공동기업의 단점
① 정부 인사권 ⇒ 전문경영인 투입 곤란
② 경영 책임소재 불분명
③ 민영화를 전제 ⇒ 적극성, 창조성이 결여

6) 협동조합
협동조합의 특성
① 생산자와 소비자가 공동으로 출자하여 구매, 생산, 판매, 신용 등의 편의와 권익을 도모
② 가입과 탈퇴 자유, 평등 의결권 부여  ⇒ 민주적 관리방식 운영
③ 조합원의 이용과 편의제공 목적  ⇒ 잉여금 발생하면 조합원 이용도 따라 배분함을 원칙
 
2 조직의 정보이용
2.1. 전자자료처리 시스템
2.2. 경영 정보 시스템
2.3. 의사결정 지원 시스템
2.4. 사무자동화
2.5. 광속교역(CALS)

2.1. 전자자료처리 시스템
EDPS의 특징
① 자료, 자료보관, 자료처리와 작업상의 흐름에 촛점
② 능률적인 자료의 처리
③ 정해진 컴퓨터의 최대 활용
④ 관련된 작업의 각종 장부출력
⑤ 관리자를 위한 종합 또는 요약 보고서 작성
 
2.2. 경영 정보 시스템
MIS란?
① 조직체 내부, 외부환경에서 발생되는 정보자료 처리
② 조직구성원의 의사결정에 필요한 자료처리와 정보산출
③ 정보제공에 관련된 인력, 기술, 제도, 절차를 포함한 인간, 기계, 조직의 총체적인 종합 시스템
④ 조직체의 정보시스템은 운영관리, 경영관리, 전략계획 등 경영각층에서의 경영관리업무를 지원
 
경영 각층
1) 최고 경영층(top management zone)
2) 중간 관리층(middle management zone)
3) 하부 감독층
 
MIS의 특징
① 중간 관리자를 위한 정보에 중점
② 정보흐름의 구조화, 체계화
③ 경영기능에 의한 자료처리의 종합
④ 데이터베이스의 활용

2.3. 의사결정 지원 시스템
의사결정이란?
목표 달성을 위한 몇 가지 대안 중 가장 유리하고 실행 가능한 안을 선택하는 합리적 인간행동
 
DSS란?
① 관리자의 의사결정을 지원해 주는 시스템
② 문제해결을 위한 대안을 분석 평가 지원하는 시스템
  
DSS의 특징
① 최고 경영자 또는 의사결정자를 위한 자료생성에 중점
② 융통성과 신속성에 중점
③ 사용자가 직접 의사결정을 위한 자료처리
④ 모든 사무계층에 대한 지원
⑤ 조직내의 의사결정자들의 의사소통
⑥ 정보처리 시스템으로부터 얻을 수 있는 정보중의 하나
 
2.4. 사무자동화
사무자동화 종류
① 워드프로세싱
② 탁상출판
③ 전자우편
④ 전자결재
⑤ 광 파일시스템
 
사무 자동화에 대한 기대효과
① 서류 작성 및 검색시간 단축
② 보관장소 절약
③ 서비스 확대
④ 중복보관 방지
⑤ 기밀유지
⑥ 문서의 중앙집중관리로 파손방지 및 소재 명확
⑦ 문서전달 및 복사시간 절약
⑧ 떨어진 장소에 있는 문서를 보기 위한 이동 없음
⑨ 동일 문서를 여러 사람이 동시 조회 가능
⑩ 생산성 향상

2.5. 광속교역(CALS)
CALS란?
CALS 개념의 변천
CALS적용의 기대효과
CALS의 적용을 통하여 기대할 수 있는 효과
 
CALS란?
설계, 개발, 구매, 생산, 판매 및 물류에 이르기까지의 모든 정보를 표준화하여 기업이나  국가간에 공유하도록 하는 정보화시스템 방법론
 
CALS 개념의 변천
① Computer-Aided Logistics Support('82)
② Computer-aided Acquisition & Logistics Support(‘88)
③ Computer-aided Acquisition & Life-cycle Support('92)
④ Continuous Acquisition & Life-cycle Support(‘92)
⑤ Commerce At the Light Speed(‘95)

CALS적용의 기대효과
① 서류의 감소
② 업무처리 시간의 단축
③ 비용과 인력 절감
④ 정보의 공유로 기업 통합 가능
 
CALS의 적용을 통하여 기대할 수 있는 효과
① 신속한 정보 서비스
② 인력과 비용의 절감
③ 품질의 향상
④ 산업 경쟁력 강화

'UP! > Software Engineering' 카테고리의 다른 글

타당성 검토  (0) 2008.08.21
프로젝트 계획  (0) 2008.08.21
시스템분석가의 역할  (0) 2008.08.21
소프트웨어와 소프트웨어 공학  (0) 2008.08.21
시스템의 특성  (0) 2008.08.21
Posted by 으랏차
,
3 시스템 분석가의 역할
시스템 분석의 역할
시스템 분석가와 프로그래머의 임무
시스템 분석가의 자질
 
1 시스템 분석의 역할
컴퓨터 시스템공학이란
바람직한 시스템 기능들을 발견하고 분석하여 개별적인 시스템 요소들에 할당하는 문제 해결 활동
시스템 분석이란
경영문제의 해결을 위한 컴퓨터 기술의 적용 방법론
∙무엇을 요청할지를 고객에게 주지시켜 고객의 필요사항을 식별
∙H/W, S/W, 인간요소, 자료구조 및 다른 요소들에 요구하는 기능을 할당
∙비용, 일정, 제약 요소들 중, 문제 요소 파악하여 개발 가능성 및 타당성 검토
타당성 검토란
① 경제적인 관점 : 개발과 구입의 비교
- 투자 효율성
- 시장성
- 비용과 수익의 비교
② 기술적인 관점 : 사용자 요구 기능 성능 vs. 제공 가능성
- 사례 연구
- 실패 사례 연구
- 모의 실험
- 프로토타이핑
③ 법적인 관점
- 사용 도구들의 법적 권한
- 시장, 관행들에 대한 조사

2 시스템 분석가와 프로그래머의 임무
시스템 분석가의 역할
시스템 분석가의 조건
현 시스템의 개선을 위해 고려해야할 사항
신 시스템을 개발할 때의 유의사항
시스템 분석의 결과 평가

시스템 분석가의 역할
어떻게(How)해야 하는지를 사용자에게 질문하는 것이 아니라
무엇(What)을 해야 하는지를 요청
① 사용자, 설계자 프로그래머 사이 정보교량 역할
② 경영자의 정보 욕구 확인
③ 고객 요구사항 파악
④ 시스템의 필요성∙약점∙잠재력 인식
⑤ 타당성분석 및 평가
⑥ 시스템 기능별로 정확하게 정의
⑦ 소요 자원 파악(H/W, S/W, 인력, 비용, 시간, 최신 기술)
⑧ 표준화, 문서화

시스템 분석가의 조건
① 컴퓨터에 관한 전문지식
② 기업의 목표 이해
③ 기업경영에 필요한 요소 추출 능력
④ 소프트웨어 생산에 영향을 미치는 인간심리 파악 능력
⑤ 사용자, 프로그래머, 설계자, 관리자, 경영자의 심리 이해능력
⑥ 의견교환 능력
⑦ 관리 능력(인력, 일정, 비용)
⑧ 통솔력(leadership)
⑨ 문서작성 능력

현 시스템의 개선을 위해 고려해야할 사항
1) 능률 향상
2) 처리절차 방법의 단순화 간략화
3) 불필요한 처리, 절차, 방법
4) 새로운 도구, 기기 도입
5) 시스템 개발 이후의 현재 조직
6) 시스템의 유효기간
신 시스템을 개발할 때의 유의사항
1) 백지상태에서 출발
2) 과감한 변화 추구, 평범한 범위의 처리에 중점
3) 혁신기술 동원 가능성
4) 사용자들에 대한 교육계획
시스템 분석의 결과 평가
① 문제에 대한 이해도
② 문서화
③ 문제와 해결방안
④ 해결방안의 명확한 전달을 위한 노력
3 시스템 분석가의 자질
1) 의견교환 능력
2) 관리 능력(인력, 일정, 비용)
3) 분석 능력(추상화)
4) 창조적인 능력
5) 통솔력(leadership)
6) 이해력(조직, 고객환경 등)
7) 경험, 지식

'UP! > Software Engineering' 카테고리의 다른 글

프로젝트 계획  (0) 2008.08.21
개발의 중요문제  (0) 2008.08.21
소프트웨어와 소프트웨어 공학  (0) 2008.08.21
시스템의 특성  (0) 2008.08.21
분산시스템아키텍처  (0) 2008.08.21
Posted by 으랏차
,
2 소프트웨어와 소프트웨어 공학
소프트웨어의 중요성
소프트웨어
소프트웨어 공학
소프트웨어 생명주기
 
1 소프트웨어의 중요성
소프트웨어 공정의 문제점
 - 비용 초과
 - 기간 지연
 - 성능 저하
 - 신뢰성 저하
 - 유지보수 불가능
 - 엄청난 유지보수 비용
소프트웨어 위기 : 소프트웨어의 요구와 그 공급 능력간의 차이가 갈수록 심화
1.1 소프트웨어의 개념
소프트웨어란?
  협의 : 프로그램들의 집합, 프로그램 그 자체
  광의 : 프로그램,  프로그램 개발,  설치,  시험,  이용,  유지보수 과정,  필요한 문서체계
 
소프트웨어 구성요소
1) 실행할 때 원하는 기능과 성능을 제공해 주는 명령어들
2) 프로그램이 정보를 알맞게 조작하도록 해주는 자료구조
3) 프로그램의 수행과 사용을 설명해 주는 문서

1.2 소프트웨어의 발전

소프트웨어의 발전과정
 1) 1950년 - 1960년대 중반 (초창기 : Early Era)
   - 소프트웨어 초보단계, 자체사용 목적의 주문에 의해 설계, 개발
   - 한사람이 설계(design), 문서(documentation)는 거의 작성 안함.
   - 일괄처리 작업 수행
   - FORTRAN, COBOL, ALGOL과 같은 고급언어 개발
 2) 1960년 중반 - 1970년대 말 (2세대 : 성장기 Growing Era)
   - 1세대 데이터베이스 관리시스템 등장
   - Interactive기법
   - Realtime system등장
 3) 1970년 중반 - 1980년대 말 (3세대 : 세련기 Refining Era)
   - 소프트웨어 패키지 등장
   - 소프트웨어의 개발에 더 많은 투자
   - 통신분야 : WAN, LAN 출현
 4) 1980년 말 -  ...  (제 4세대) (4세대 : 숙련기 Maturing Era)
   - 전문가 시스템
   - Artificial Intelligent 소프트웨어 실용화
   - 객체지향기술 발전

2. 소프트웨어
2.1 소프트웨어의 특성 :
(1) 소프트웨어 개발의 특성
     ① 제조, 생산되는 것이 아니라 개발되거나 공학화되는 것이다.
     ② 소프트웨어는 “마모되는 것”이 아니라, 질이 나빠지는 것이다.
     ③ 소프트웨어는 하드웨어보다 유지보수가 상당히 복잡하다.
     ④ 기존의 구성요소를 조립하기보다는 주문하여 만든 것이다.
     ⑤ 수학적이지 못하고 논리 및 관리기술이 중요 ⇒ 비 과학성
 
(2) 소프트웨어가 가져야 할 특성
     ① 사용자가 원하는 대로 작동하여야 한다
     ② 사용하기 편해야 한다
     ③ 신뢰성이 높아야 한다
     ④ 효율적이어야 한다.
     ⑤ 유지보수가 용이해야 한다
     ⑥ 내포된 오류가 적어야 한다
(3) 소프트웨어 개발시의 유의 사항
     ① 단계적으로 추진
     ② 요구사항을 명확히 정의
     ③ 표준방법과 절차를 준수하여 생산성을 향상
     ④ 결과의 미비함을 보완시켜 신뢰도를 향상
     ⑤ 기간 안에, 예산범위에 공정관리
     ⑥ 신기술 도입 검토.
(4) 소프트웨어의 특성
     ① 유형성(Tangibility) : 인쇄된 Source code, 요구명세서, 상세설계서, 자료구조도, 시험계획서 등
     ② 행위성(Dynamic Behavior) : S/W는 H/W에서 작동되는 Program이다
     ③ 상품성(Goods) : Program은 제품이지만 S/W는 상품이다.
     ④ 견고성(Hardness) : S/W는 한번 구성되면 계속 사용하여야 하며, 구조성을 잃으면 사용 불가
2.2 프로그래밍 언어
(1) 기계중심 언어
(2) 고급 언어 : FORTRAN, COBOL, C, PASCAL 등
(3) 비 절차 언어 : LISP, PROLOG, RPG 등
 
2.3 소프트웨어 분류
응용 영역으로 분류
  1) 시스템 소프트웨어(system software)
  2) 실시간 소프트웨어(real-time software)
  3) 비즈니스 소프트웨어
  4) 공학 및 과학 소프트웨어
  5) 내장 소프트웨어 : ROM에 내장
  6) 개인용 컴퓨터 소프트웨어
  7) 인공지능 소프트웨어
 
적용분야별로 구분
  1) 응용 소프트웨어
  2) 시스템 소프트웨어
  3) 지원 소프트웨어

3. 소프트웨어 공학
소프트웨어 공학이란? : 소프트웨어 개발에서 부딪치는 일정, 비용, 생산성, 품질 등의 문제점과 원인을 인식하고 그 난관을 극복하는 모든 원리와 방법을 찾는 것

소프트웨어 공학의 여러 측면
- 지식-집약적 작업이다.
- 소프트웨어 표현 관한 지식 요구됨
- 소프트웨어 공정에 관한 지식 요구됨
  ∙프로그래밍
  ∙소프트웨어 개발 공정
  ∙도구, 환경
  ∙소프트웨어 프로젝트 관리
  ∙형상 관리
  ∙품질 관리
- 응용 분야에 관한(Domain-specific) 지식
 
3.1  소프트웨어 공학의 정의
① Fritz Bauer (1969) : 신뢰성 있고 실제 기계에 효과적으로 작동하는 소프트웨어를 경제적으로 얻기 위해서 올바른 공학적 원리들을 체계화시키고 이용하는 것
② Fritz Bauer (1972) : 컴퓨터 하드웨어에서 신뢰성 있게 운용되는 소프트웨어를 경제성 있게 개발하기 위해 공학적 원리를 응용하고 확립시킨 이론
③ Bohem (1978) : 컴퓨터 프로그램을 설계하고 개발하며, 개발․운용․유지보수에 관련된 문서를 작성하는 데 필요한 과학적인 지식의 실용화
④ IEEE Computer Society (1983) : 소프트웨어의 개발․운용․유지보수 및 폐기처분을 위한 제도적인 접근방안
⑤ Fairley (1985) : 전산학, 경영학, 경영과학 및 의사소통 기술과 문제해결을 위한 공학적인 접근방안을 토대로 소프트웨어개발에 임하는 기술적 체계
⑥ 권용래 (1986) : 최소의 경비로 품질 높은 소프트웨어를 개발하기 위한 기법․도구․관행의 총칭
⑦ 이철희 (1988) : 신뢰할 수 있고 요구기능을 수행하는 소프트웨어를 경제적으로 획득하기 위하여 공학적인 원인이나 방법을 창출하고 사용하는 기술
⑧ 이주헌 (1993) : 최소의 경비로 품질 높은 소프트웨어 상품의 개발․유지보수 및 관리를 위한 모든 기법․도구․방법론의 총칭으로서 전산학․경영학․심리학을 토대로 한 종합학문

3.2  소프트웨어 공학의 구성요소
1) 방법(method) :  소프트웨어 구축 기술인 “how to”를 제공
    ① 프로젝트의 계획수립과 추정
    ② 시스템과 소프트웨어 분석
    ③ 자료구조
    ④ 프로그램 구조
    ⑤ 알고리즘
    ⑥ 코딩
    ⑦ 테스팅
    ⑧ 유지보수
2) 도구(Tool)
3) 프로시듀어(procedure)

4 소프트웨어 생명주기
소프트웨어 생명주기란
  - 소프트웨어 프로세스 모형
  - 소프트웨어가 계획되어 더 이상 사용되지 않을 때까지의 기간
  - 순서 있는 작업에 의하여 목적한 제품을 생산
    ∙기술과 절차의 통합
    ∙프로젝트가 어떻게 일을 수행하여야 하는가 안내
    ∙소프트웨어 개발 단계의 순서를 결정
    ∙각 단계에서의 완성 기준 설정
  - 소프트웨어 개발 :
    ∙창조(creation)라기보다 점증적 개선(evolution)
 
소프트웨어 공학 파라다임(paradigm)
  ① 고전적 생명주기 : 폭포수 모형(waterfall model)
  ② 원형(prototyping)
  ③ 나선형 모형(spiral model)
  ④ 4세대 기술(fourth generation technology)

4.1 폭포수 모형(waterfall model)
고전적인 생명주기(classic life-cycle) :
 
 
1) 계획수립 및 정의단계(Planing & Definition Phase) :  무엇(what)에 초점
  ① 시스템 요구분석 단계(System Requirement) :
  ② 소프트웨어 요구분석 단계(Software Requirement) :
2) 개발단계(Development Phase) :  어떻게(How)에 초점
  ① 개략 설계 단계(Preliminaly Design) :
  ② 상세 설계 단계(Detailed Design) :
  ③ 코딩 및 디버깅 단계(Code and Debug) :
  ④ 시험 및 운영준비 단계(Testing and Preoperation) :
3) 유지 보수 단계(Maintenance Phase) :
① 수정적 유지 보수
② 적응적 유지 보수
③ 기능 향상
    폭포수 모형(Waterfall Model) 특징
    - 각 단계가 다음 단계 시작 전에 끝나야 함.
    - 각 단계 사이에 중복이나 상호작용이 없음
    - 각 단계의 결과는 다음 단계가 시작되기 전에 점검됨
    - 프로토타이핑이나 재사용을 배제
    - 설계, 코딩, 테스트의 지연
    - 소용없는 여러 종류의 문서를 생산

4.2 원형(Prototyping)
특징
 ① 사용자와 개발자 사이의 의사소통을 원활하게 함
 ② 갑작스런 사용자 요구 수용 가능 ⇒ 사용자 만족도 제고
 ③ 정확한 요구사항 전달 ⇒ 신뢰할 수 있는 문서화 가능
 ④ 생산성 향상 ⇒ 개발비용 절감
 ⑤ 사용자의 직접적인 참여 ⇒ 사용자로부터 품질보증.
 ⑥ 사용자에 대한 훈련시간 감소
 ⑦ 개발초기에 만족감을 줌
 ⑧ 프로젝트의 관리가 쉽다
 ⑨ 유지보수 노력 감소 ⇒ 유지보수 비용 절감
 
원형(Prototype)작성을 위한 순서
 ① 원형 작성 타당성 검토
 ② 기본 요구사항 확인 ⇒ 원형 개발
 ③ 개발된 원형을 사용자와 함께 사용해보고 평가
 ④ 문제점을 추출하여 보완
 ⑤ 문제점 없으면 최종 시스템으로 변환

4.3 나선형 모형(Spiral Model)
나선형 모형 구성의 4개 활동
 1) 계획 수립
 2) 위험 분석
 3) 개발
 4) 고객 평가
 
나선형 모형의 특징
 1) 대규모에 적합한 현실적 접근방법
 2) 개발자와 사용자가 위험을 이해하고 대응책 제시
 3) 각 단계마다 위험 감소장치로서 원형 적용 사용 가능
 
4.4  4 세대 기법

4세대 기법(fourth-generation techniques)
4GT :
- 소프트웨어의 특징만 명시하면 도구가 자동적으로 원시코드를 생성해주는 기법
- CASE도구로 알려진 도구의 사용 방법
- 대표적인 도구는 4GL

4.5  통합 패러다임
여러 패러다임을 사안이나  기능 또는 편이성에 따라
선택해서 하나의 패러다임으로 만들어 사용하는 것
4.6  기타
OOSE(Object-Oriented Software Engineering)패러다임

'UP! > Software Engineering' 카테고리의 다른 글

개발의 중요문제  (0) 2008.08.21
시스템분석가의 역할  (0) 2008.08.21
시스템의 특성  (0) 2008.08.21
분산시스템아키텍처  (0) 2008.08.21
소프트웨어 공학 개요 및 사회, 기술적 시스템  (0) 2008.08.21
Posted by 으랏차
,