1-9

SEC 1) 소프트웨어 생명주기(A)

 

• 소프트웨어 생명주기(Software Life Cycle) : 소프트웨어를 개발하기 위한 과정을 각 단계별로 나눈 것   

 

필기20.9, 20.8, 20.6

• 폭포수 모형(Waterfall Model) - 이전 단계로 돌아갈 수 없고 각 단계를 확실히 매듭짓고 다음 단계를 진행
• 프로토타입(Prototype Model,원형모델)-실제 개발될 소프트웨어에 대한 견본품만들어 결과물 예측하는 모형

필기 20.9,20.8,20.6

• 나선형 모형(Spiral Model, 점진적 모형)-여러번 개발 과정을 거쳐 점진적으로 개발하는 모형

20.7 필기 20.8

• 애자일 모형(Agile Model)-고객 요구사항에 유연하게 대항할 수 있도록 일정 주기를 반복하면서 개발하는 모형

Ex) 스크럼(Scrum), XP(eXtreme Programming), 칸반(Kansan), Lean, 기능중심개발(FDD;Feature Driven Development)

필기20.8

• 애자일 개발 4가지 핵심가치

• 프로세스와 도구보다는 개인과 상호작용에 더 가치를 둠
• 방대한 문서보다는 실행되는 SW에 더 가치를 둠
• 계약 협상보다는 고객과 협업에 더 가치를 둠
• 계획을 따르기 보다는 변화에 반응하는 것에 더 가치를 둠

필기 20.8

• 소프트웨어 공학(SE; Software Engineering)은 소프트웨어의 위기를 극복하기 위한 방안으로 연구된 학문
• 소프트웨어 공학의 기본 원칙

• 현대적인 프로그래밍 기술을 계속적으로 적용
• 개발된 소프트웨어의 품질을 유지되도록 지속적으로 검증해야함
• 소프트웨어 개발 관련 사항 및 결과에 대한 명확한 기록을 유지해야함

 

SEC 2) 스크럼(Scrum) 기법(B)

• 스크럼(Scrum)-팀이 중심이 되어 개발의 효율성을 높이는 기법
• 스크럼팀

구성원	역할
제품 책임자 (PO; Product Owner)	요구사항이 담긴 백로그(Backlog)를 작성하는 주체 이해관계자들 중 개발될 제품에 대한 이해도가 높고, 요구사항을 책임지고 의사를 결정할 사라믕로 선정
스크럼 마스터 (SM; Scrum Master)	스크럼팀이 스크럼을 잘 수행할 수 있도록 가이드 역할을 수행함
개발팀 (DT; Development Team)	제품 책임자와 스크럼 마스터를 제외한 모든 팀원으로 제품 개발을 수행함

 

• 스크럼 개발 프로세스

프로세스	내용
스프린트 계획 회의 (Sprint Planning Meeting)	제품 백로그 중 이번 스프린트에서 수행할 작업을 대상으로 단기 일정을 수립하는 회의
스프린트(Sprint)	실제 개발 작업을 진행하는 과정,2~4주 정도의 기간 내에서 진행함
일일 스크럼 회의 (Daily Scrum Meeting)	모든 팀원이 매일 약속된 시간에 약 15분 동안 진행 사항을 점검하는 회의 남은 작업 시간은 소멸 차트(Burn-down Chart)에 표시함
스프린트 검토 회의 (Sprint Review)	부분 또는 전체 완성 제품이 요구사항에 잘 부합하는지 테스팅하는 회의
스프린트 회고 (Sprint Retrospecive)	정해놓은 규칙 준수 여부 및 개선할 점을 확인하고 기록하는 것

 

SEC 3) XP(eXtreme Programming)(A)

• XP(eXtreme Programming): 요구사항에 유연하게 대응해 개발 생산성을 향상

>> 핵심가치: Communication/ Simplicity/ Courage/ Respect/ Feedback

필기 20.9, 20.6

• XP 개발 프로세스

프로세스	내용
Release Planning	개발 완료시점에 대한 일정을 수립
Iteration	실제 개발 진행하는 과정,1~3주
Acceptance Test	하나의 이터레이션 안에 부분 완료제품이 구현되면 수행하는 테스트
Small Release	유연하게 대응할 수 있도록 릴리즈의 규모를 축소

 

*XP의 주요 실천 방법

실천방법	내용
필기 20.9 Pair Programming	개발에 대한 책임을 공동
필기 20.9 Collective Ownership	개발 코드에 대한 권한과 책임을 공동으로 소유
Test-Driven Development	코드 작성전에 테스트 작성하므로 무엇을 해야할지 정확히 파악
Whole Team	각자 맡은 역할에 책임
필기 20.9 Continuous Integration	모듈 단위로 나눠서 개발된 코드를 지속적으로 통합
20.10 Refactoring	기능 변경없이 시스템 재구성
Small Release	릴리즈 기간을 짧게 반복해 요구변화에 대응

 

SEC 4) 현행 시스템 파악(D)

 

1단계) 시스템 (구성/기능/인터페이스) 파악

2단계) (아키텍쳐/ 소프트웨어) 구성파악

3단계 (하드웨어/ 네트워크) 구성파악

 

** 서버의 이중화(Replication): 운용서버 장애 발생시 서비스 유지하도록, 대기 서버에도 동일하게 복제되도록 관리

 

SEC 5) 개발 기술 환경 파악(B)

• OS(Operating System): 컴퓨터를 잘 사용하도록 환경을 제공하는 소프트웨어

>> 고려사항: 가용성/성능/기술지원/주변기기/구축비용

• DBMS(DataBase Management System): 데이터베이스 관리해주는 소프트웨어

>>고려사항: 가용성/성능/기술지원/상호호환성/구축비용

*WAS(Web Application Server): 동적인 콘텐츠 처리를 위해 사용되는 미들웨어

>> 고려사항: 가용성/성능/기술지원/구축비용

• Open Source:공개 소프트웨어

>> 고려사항: 라이선스의 종류/사용자수/기술의 지속가능성

 

SEC 6) 요구사항 정의(B)

유형: (기능/비기능/사용자/시스템) 요구사항

• Functional Requirement:기능이나 수행과 관련된 요구사항
• Non-Functional Requirement: 품질이나 제약사항과 관련된 요구사항
• User-Requirement: 사용자 요구사항
• System-Requirement:개발자 관점에서 시스템에서 제공해야할 요구사항(전문적, 기술적 용어로 표현)

 

SEC 7) 요구사항 개발 프로세스(B)

Elicitaiton -> Analysis -> Specification -> Validation

 

*요구사항 명세 기법

정형 명세 기법	비정형 명세 기법
수학적 기호	자연어 기반

 

SEC 8) Requirement Analysis (A)

사용자의 요구사항을 이해하고 문서화 하는 활동

 

• 구조적 분석 기법: 자료의 흐름과 처리를 중심으로 하는 요구사항 분석 방법

주요 도구) 자료흐름도(DFD)/자료사전(DD)/개체 관계도(ERD)/상태 전이도( STD)/제어 명세서

• DFD(Data Flow Diagram): 자료 흐름 및 변환과정과 기능을 도형 중심으로 기술하는 방법
• DD(Data Dictionary): 자료 흐름도에 있는 자료를 정의하고 기록한 것

=	자료 정의
+	연결(and)
[ ]	또는(or)
{ }	반복
( )	생략
**	주석

 

SEC 9) 요구사항 분석_CASE/HIPO (B)

필기 20.9

• 요구사항 분석용 CASE(자동화 도구): 요구사항 자동분석, 분석 명세서를 기술하는 도구

필기 20.9 SADT	구조적 요구 분석을 위해 블록 다이어그램을 채택한 자동화 도구
SREM=RSL/REVS	RSL,REVS를 사용하는 자동화 도구
PSL/PSA	PSL, PSA를 사용하는 자동화 도구
TAGS	시스템 공학 방법 응용에 대한 자동 접근방법, 개발 주기의 전 과정에 이용할 수 있는 통합 자동화 도구

필기 20.9

• HIPO(Hierarchy Input Process Output)

• 시스템의 분석 및 설계, 또는 문서화에 사용되는 기법, 시스템 실행 과정인 입력,처리,출력의 기능을 표현한 것
• 하향식 소프트웨어 개발을 위한 문서화 도구
• 기능과 자료의 의존 관계를 동시에 표한가능
• 기호, 도표등을 사용하므로 보기 쉽고 이해하기도 쉬움
• 시스템의 기능을 여러 개의 고유 모듈로 분할해 이들 간의 인터페이스를 계층구조로 표현한 것을 HIPO Chart라고 함