1. 방법론, 모델, 툴 그리고 기법
1.1. 분석과 설계 단계에 사용
1.2. 방법론
1.2.1. SDLC의 모든 행위의 종합적 가이드라인
1.2.2. 모델,툴,기법의 집합체
1.2.3. 모델
1.2.3.1. 실 세계 관점의 표현법
1.2.3.2. 다이어그램, 차트
1.2.4. 툴
1.2.4.1. 모델 생성용 소프트웨어
1.2.4.2. 역공학 툴
1.2.4.2.1. 코드로부터 모델 생성
1.2.4.2.2. 문서화가 없거나, 일부일때 사용
1.2.4.3. CASE 툴
1.2.4.3.1. 시스템 분석가가 개발태스크를 완료하도록 도와주는 종합툴
1.2.4.3.2. Rational Rose
1.2.5. 기법
1.2.5.1. 시스템분석가가 개발 태스크를 완료하도록 도와주는 가이드라인의 집합체
1.2.5.2. 모델을 생성하기 위한 단계별 명령 포함
1.2.5.3. 사용자로부터 정보수집 위한 조언 포함
2. Two Approaches to System Development
2.1. 전통적인 접근방법
2.1.1. 구조적 시스템개발
2.1.2. 구조적 프로그래밍 기법
2.1.2.1. 프로그램 품질개선
2.1.2.2. 다른 프로그래머가 코드를 쉽게 읽고 수정하도록 허용
2.1.2.3. 프로그램모듈은 시작과 끝 가짐
2.1.2.4. 각 프로그램 실행단계는 세가지 프로그래밍 구성체 중 하나로 구성
2.1.2.4.1. 순차
2.1.2.4.2. 결정
2.1.2.4.3. 반복
2.1.2.5. 하향식 프로그래밍
2.1.2.5.1. 복잡한 프로그램을 모듈들의 계층으로 분할
2.1.2.5.2. 상위 모듈이 하위 모듈 호출하여 실행제어 (함수처럼)
2.1.3. 구조적 설계 기법
2.1.3.1. 가이드라인 제공위한 개발
2.1.3.2. 구조적 차트 사용하여 모듈 사이의 정렬을 그래픽적 표현
2.1.3.3. 원리
2.1.3.3.1. 느슨한 결합도
2.1.3.3.2. 높은 응집도
2.1.3.4. ♂ 기호 사용
2.1.4. 구조적 분석 기법
2.1.4.1. 개발자가 시스템이 필요로 하는 것을 정의하게 도움
2.1.4.2. DFD
2.1.4.2.1. 입력,처리,저장,출력을 보여주는 그래픽모델
2.1.4.3. ERD
2.1.4.3.1. 정보사이의 관계를 보여주는 그래픽모델
2.1.4.3.2. A ---+ B
2.1.4.3.3. A ---<-B
2.1.4.3.4. A --o+ B
2.1.4.3.5. A --o<-B
2.2. 객체지향 접근방법
2.2.1. 정보시스템을 태스크를 수행하기 위해 함께 동작하는 객체들의 상호작용하는 집합체로 봄
2.2.2. 객체지향분석
2.2.2.1. 객체들의 모든 타입정의
2.2.2.2. 상호작용표현
2.2.3. 객체지향설계
2.2.3.1. 시스템의 사람과 장치가 통신하기 위한 추가 객체타입정의
2.2.3.2. 구현 위해 객체 타입정제
2.2.4. 클래스 다이어그램
2.2.4.1. 객체들의 클래스 표현
2.2.4.2. ▤기호사용
2.2.5. 이해가 어려움
2.2.5.1. 전통적인 방법과 객체지향 방법을 결합해 사용
3. System Development Life Cycle Variations
3.1. 단계명의 변형
3.1.1. 서로 다른 단계명 사용
3.1.2. RUP
3.1.2.1. 4단계
3.1.3. SDLC with Activity Names for Phases
3.1.3.1. 동사,명사 형태의 여덟단계 구성
3.2. 반복에 기반한 변형
3.2.1. 처음엔 올바른 결과를 얻지 못한다 가정
3.2.2. 반복과 함께 필요한 결과에 근접하도록 정제
3.2.3. 점진적 개발
3.2.3.1. 핵시점 기능부터 정의,구현 하고 점진적으로 별도 기능 구현
3.2.4. 프로토타입모델
3.2.4.1. 효과적인 상황
3.2.4.1.1. 요구사항 명세가 어려운 경우
3.2.4.1.2. 프로젝트의 타당성이 의심스러운 경우
3.2.4.2. 개발단계
3.2.4.2.1. 요구사항 수집
3.2.4.2.2. 프로토타입 설계
3.2.4.2.3. 프로토타입 구현
3.2.4.2.4. 고객평가
3.2.4.2.5. 프로토타입 정제
3.2.4.3. 장점
3.2.4.3.1. 다양하게 활용
3.2.4.3.2. 고객과 원활한 의사소통
3.2.4.3.3. 정확하고 고품질의 요구사항 명세 작성
3.2.4.3.4. 개발 시스템 가능성, 유용성을 관리자에 제시
3.2.4.3.5. 제품의 윤곽, 기능을 고객에 제시
3.2.4.4. 단점
3.2.4.4.1. 잘못된 믿음 야기
3.2.4.4.2. 프로토타입에 대한 지나친 강조
3.2.4.4.3. 관리, 제어 어려움
3.2.5. 점진적 모델
3.2.5.1. 프로토타입모델의 반복개념 + 폭포수모델의 순차개념
3.2.5.2. 소프트웨어의 기능 나누어 점진적 개발
3.2.5.3. 완전한 산출물 나올때까지 반복
3.2.5.4. 이전순차의 다음순차와 오버랩 됨
3.2.6. 나선형 모델
3.2.6.1. 폭포수 모델 + 프로토 타입모델 + 위험분석
3.2.6.2. 단계
3.2.6.2.1. 고객과의 의사소통
3.2.6.2.2. 계획 및 정의
3.2.6.2.3. 위험분석
3.2.6.2.4. 구축(제품개발)
3.2.6.2.5. 고객평가
3.2.6.2.6. @구조
3.2.6.3. 장점
3.2.6.3.1. 위험감소
3.2.6.3.2. 대형시스템에 적합
3.2.6.3.3. 개발자,고객이 개발과정에 따른 위험 대처가능
3.2.6.4. 단점
3.2.6.4.1. 대규모나 내부 프로젝트에만 유용
3.2.6.4.2. 프로젝트 관리 및 제어 어려움
3.2.6.4.3. 위험 분석위해 경험, 기술 필요
4. Current Trends in Development
4.1. Extreme Programming (XP)
4.1.1. 4가지 가치
4.1.1.1. 단순성
4.1.1.1.1. 설계를 단순, 명확하게 유지
4.1.1.2. 커뮤니케이션
4.1.1.2.1. 고객, 개발자, 관리자 간 의사소통 중시
4.1.1.3. 피드백
4.1.1.3.1. 계속적인 테스트를 통한 피드백
4.1.1.4. 용기
4.1.1.4.1. 요구사항 및 기술 변경에 용감히 대처
4.1.2. 역할
4.1.2.1. 고객
4.1.2.1.1. User Story 작성
4.1.2.1.2. Release 결정
4.1.2.1.3. 우선순위 결정
4.1.2.1.4. 사용자 승인테스트 정의
4.1.2.2. 프로그래머
4.1.2.2.1. User Story 난이도 추정
4.1.2.2.2. 시스템 분석, 설계, 테스트, 프로그래밍, 통합
4.1.2.3. 관리자
4.1.2.3.1. 고객, 프로그래머 협동지원
4.1.2.3.2. 프로젝트 자원제어
4.1.2.3.3. 문제점 해결 보상 수여
4.2. Rational Unified Process (RUP)
4.2.1. 개념화에서 제품인도까지 개발을 유발하는 단계들의 집합
4.2.2. 단계
4.2.2.1. 인지단계
4.2.2.1.1. 초기분석
4.2.2.1.2. 요구사항 식별
4.2.2.1.3. 유스케이스 다이어그램화
4.2.2.2. 정교화단계
4.2.2.2.1. 설계팀이 유스케이스로 시스템 구축될 퉁합이미지 획득
4.2.2.2.2. 시스템을 여러 하위 시스템으로 나누어 각각 모형화
4.2.2.3. 구축단계
4.2.2.3.1. 실제적 제품 구축
4.2.2.3.2. 설계변경 유발, 분석 궁금증 발생
4.2.2.3.3. 새 구성요서 설계 위해 정교화 단계로 되돌아감
4.2.2.4. 변환단계
4.2.2.4.1. 실제 고객에게 제품인도
4.2.2.4.2. 유지보수
5. Tools to Support System Development
5.1. Case Tools
5.1.1. 시스템개발 작업속도와 품질새선 위한 자동화 툴
5.1.2. ICase Tool
5.1.2.1. Upper CASE + Lower CASE
5.1.2.2. Upper CASE
5.1.2.2.1. 분석, 설계 단계 지원
5.1.2.3. Lower CASE
5.1.2.3.1. 구현 단계 지원
6. System Development Life Cycle
6.1. 시스템 개발 프로젝트
6.1.1. 큰 규모, 계획된 작업
6.2. 성공조건
6.2.1. 상세한 계획
6.2.2. 작업조직화
6.2.3. 방법론적 순서
6.3. 주요행위
6.3.1. 분석
6.3.1.1. 비지니스 정보의 요구사항 이해
6.3.2. 설계
6.3.2.1. 비지니스요구 만족하는 새로운 시스템구조정의
6.3.3. 구현
6.3.3.1. 실제 구축
6.3.3.2. 테스트
6.3.3.3. 설치
6.3.4. (추가)계획
6.3.4.1. 허가 얻고,초기화
6.3.5. (추가)지원
6.3.5.1. 유지보수,개선
6.4. 접근방법
6.4.1. 예측적접근
6.4.1.1. 미리 계획,조직 될 수 있다 가정
6.4.1.2. 잘 이해하고 정의된 시스템 구축에 유용
6.4.1.3. 직원은 이미 요구사항 이해, 새로운 처리추가 필요없음
6.4.1.4. 주의깊게 계획 명세에 따라 구축
6.4.2. 적응적 접근
6.4.2.1. 미리 계획 될 수 없다 가정
6.4.2.2. 진행에 따라 변경
6.4.2.3. 시스템의 요구와 사용자 필요가 잘 이해되지 않을 때 사용
6.4.2.4. 시스템의 일부요구는 개발 끝난 후 결정
6.5. 단계
6.5.1. 계획
6.5.1.1. 범위 확인, 프로젝트 계획
6.5.1.2. 문제정의
6.5.1.3. 프로젝트 스케쥴 생산
6.5.1.4. 인원선발
6.5.1.5. 실행가능성 확인
6.5.1.6. 프로젝트시작
6.5.2. 분석
6.5.2.1. 사용자 필요 이해, 요구사항 발견
6.5.2.2. 정보수집
6.5.2.3. 시스템 요구사항 정의
6.5.2.4. 요구사항용 프로토타입 구축
6.5.2.5. 대안의 생성, 평가
6.5.2.6. 경영자와 추천안을 평가
6.5.3. 설계
6.5.3.1. 솔루션 시스템 설계
6.5.3.2. 네트워크 설계
6.5.3.3. 애플리케이션 아키텍쳐 설계
6.5.3.4. 사용자,시스템 인터페이스 설계
6.5.3.5. DB 설계
6.5.3.6. 상세설계용 프로토타입
6.5.3.7. 시스템 제어 설계
6.5.4. 구현
6.5.4.1. 새 시스템 구축, 테스트 ,설치
6.5.4.2. 소프트웨어 컴포넌트들 구축
6.5.4.3. 검증, 테스트
6.5.4.4. 데이터 변환
6.5.4.5. 사용자 교육과 시스템 문서화
6.5.4.6. 시스템 설치
6.5.5. 지원
6.5.5.1. 설치되고 수행중인 시스템 생산성있게 유지
6.5.5.2. 시스템 유지보수
6.5.5.3. 시스템 개선
6.5.5.4. 사용자 지원
6.6. 스케쥴링
6.6.1. 폭포수 모형
6.6.1.1. 가장 오래됨
6.6.1.2. 하향식 생명주기 모형
6.6.1.3. 단순하여 개발에 능숙치 못한 고객들에게 쉽게 설명가능
6.6.1.4. 실제 프로세스와차이 있음
6.6.1.5. 앞단계가 끝난 후 단계 별로 다음 단계 이동
6.6.2. 오버랩
6.6.2.1. 발생 원인
6.6.2.1.1. 효율성
6.6.2.2. 발생안하는 원인
6.6.2.2.1. 의존성
6.6.3. 반복
6.6.3.1. 시스템개발 원리
6.6.3.2. 동일 개발 행위 반복
6.6.3.3. 상세함, 정확성을 증가시키며 반복