프로그램과 프로그램 개발

1.      마인드 맵

A.     프로그램

B.     프로그램 개발

2.      내용 정리

A.     프로그램(Program)

                i.         정의: 예정된 일의 순서의 집합 / 시간적 작업의 순서

1.      계획서, 작업 지침서

2.      컴퓨터가 해야 할 일의 지침서

               ii.         Process: 프로그램보다는 더 정형화 됨, 더 크다.

1.      처음 Process를 도입: 군인 à 군인을 부품화

A.     모든 것을 지침서 안에서 정형화된 행동을 하도록 함

B.     정형화된 조직 à Process 성숙도 Level 3의 조직임

2.      업무의 집합

3.      어떻게(How), 언제(Sequence) 하느냐

4.      초기 Process 모델 à 단계가 정해져 있음

B.     프로그램 개발

                i.         Processing을 두 개로 나눈다.

1.      독립적 / 구체적 기능

A.     기능(Input à Output)을 만들어 냄 à 독립적 기능을 독립적은 I/O가 나온다.

2.      재사용 / 시간의 흐름

               ii.         개발 과정

1.      요구 사항 à 분석(정리) à 설계(시스템적으로) à 구현(컴퓨터 언어를 사용)

2.      Process Component à (연결) à 프로그램(=Delivery Process)

A.     무조건 연결이 되는 것은 아니다. 상황에 따라, 때론 환경에 따라

B.     상황이나 환경이 어떤 상황이나 환경을 말하는지 기억이 안 남. 그리고 왜 프로그램을 Delivery Process라고 했을까? Process Component에서 나온 결과를 다른 Process Component에게 전달해 주기 때문에?

              iii.         구체적 프로그램 개발 방법

1.      Engineering: Requirement à Analysis à Design à Implement

A.     에러 처리, 감리, 회계 같은 것을 포함하지 않음(나누는 기준이 다르기 때문에 나중에 이와 관련된 부분이 나옴)

B.     프로젝트 관리 관점: 프로세스 구성요소(계획 à 점검 à 감리)

              iv.         직교한다. à 다른 영향을 받지 않고 값이 일정

1.      관점에 따라 축을 잘 나누면 복잡도가 감소한다.

A.     N1 X N2 = N^2 à N1 + N2(이와 같은 복잡도가 감소할 수 있음)

B.     분류기준을 잘 나누는 방법 à 서로 영향도가 없도록 한다.

2.      Aspect(개인적인 생각이지만 기능별로 나눈다.)

A.     Cross-Cutting Concern(교차 절단 관계(?)) 이라고도 함

B.     프로그램을 짤 때 에러 처리를 Aspect하게 쓴다.

                                           i.         프로그램(컴퓨터) 본연의 업무에 충실하게(Aspect Oriented Programming)

                                          ii.         유지보수가 쉬워진다.

                                         iii.        

               v.         Test: 모든 과정에 적용할 수 있다.

1.      각각의 Process가 진행되는 중간에 삽입하여 적용

              vi.         시스템 개발 프로세스

1.      각각의 역할은 교차되는 지점 없이 직교하며 그에 따른 세분화된 역할도 시간의 흐름에 따라 절차적으로 진행한다.