소프트웨어 생명 주기(Software Life Cycle)
소프트웨어를 개발하기 위한 설계, 운영, 유지보수 등의 과정을 각 단계로 나눈 것
폭포수 모형(Waterfall Model)
이전 단계로 돌아갈 수 없다는 전제하에 각 단계를 확실히 매듭짓고 그 결과를 철저하게 검토하여 승인과정을 거친 후에 다음 단계를 진행하는 개발 방법론
가장 오래되고 가장 폭넓게 사용된 전통적인 소프트웨어 생명 주기 모형
고전적 생명 주기 모형
각 단계가 끝난 후에는 다음 단계를 수행하기 위한 결과물이 명확하게 산출되어야 함
프로토타입 모형(Prototype Model,원형 모형)
실제 갭라될 소프트웨어에 대한 견본품(Prototype)을 만들어 최종 결과물을 예측하는 모형
견본품은 사용자와 시스템 사이의 인터페이스에 중점을 두어 개발
나선형 모형(Spiral Model,점진적 모형)
여러 번의 소프트웨어 개발 과정을 거쳐 점진적으로 개발하는 모형
보헴이 제안하였다.
폭포수 모형과 프로토타입 모형의 장점에 위험 분석 기능을 추가한 모형
계획 수립 -> 위험 분석 -> 개발 및 검증 -> 고객 평가 (계위개고)
애자일 모형(Agile Model)
요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하면서 개발하는 모형
고객과의 소통에 초점을 맞춘 방법론
폭포수 모형과 대조적
- 스크럼, XP, 칸반, Lean, 기능 중심 개발(FDD:Feature Driven Development)
프로세스와 도구보다는 개인과 상호작용에 더 가치를 둚
문서보다 실행되는 SW 중시
계약 협상보다 고객 협업에 가치를 둚
계획보다 변화에 반응하는 것이 가치를 둚
소프트웨어 공학
소프트웨어의 위기를 극복하기 위한 방안으로 연구된 학문
현대적인 프로그래밍 기술을 계속적으로 적용해야 한다
개발된 소프트웨어의 품질이 유지되도록 지속적으로 검증해야 함
소프트웨어 개발 관련 사항 및 결과에 대한 명확한 기록을 유지해야 함
스크럼(Scrum)
팀이 중심이 되어 개발의 효율성을 높이는 기법
제품 책임자(PO:Product Owner) : 백로그(Backlog)를 작성하는 주체
스크럼 마스터(SM:Scrum Master) : 팀이 스크럼을 잘 수행할수 있도록 가이드 역할
개발팀(DT:Developer Team) : PO,SM을 제와한 모든 팀원
스프린트 계획 회의 -> 스프린트 -> 일일 스크럼 회의 -> 스프린트 검토 회의 -> 스프린트 회고
XP(eXtreme Programming)
요구사항에 유연하게 대응하기 위해 고객의 참여와 개발 과정의 반복을 극대화하여 생산성을 향상시키는 방법
핵심 가치 : 의사소통(Communication), 단순성(Simplicity), 용기(Courage), 존중(Respect), 피드백(Feedback) = 용단의피존
릴리즈 계획 수립 -> 이터레이션 -> 승인 검사(인수 테스트) -> 소규모 릴리즈
- Pair Programming(짝) : 다른 사람과 함께 프로그래밍 수행. 개발 책임 공동
- Collective Ownership(공통 코드 소유) : 개발 코드에 대한 권한과 책임을 공동으로 소유
- Test-Driven Development(테스트 주도 개발) : 개발자가 코드 작성 전 자신의 할일이 무엇인지 파악함. 테스트가 지속적으로 진행될 수 있도록 자동화된 테스팅 도구(구조, 프레임워크) 사용
- Whole Team : 참여하는 구성원은 역할에 대한 책임을 가짐
- Continuous Intergration(계속적인 통합) : 모듈 단위로 나눠서 개발된 코드들은 지속적으로 통합됨
- Refactoring(리팩토링) : 프로그램의 변경 없이 시스템을 재구성
목적 : 프로그램을 쉽게 이해, 쉽게 수정하여 빠르게 개발할 수 있도록 하기 위함 - 소규모 릴리즈 : 릴리즈 기간을 짧게 반복. 고객 요구 변화에 신속하게 대응
운영체제(OS,Operating System)
컴퓨터 시스템의 자원을 효율적으로 관리.컴퓨터를 편리하고 효율적으로 사용할 수 있도록 환경을 제공하는 소프트웨어
고려사항 : 가용성,성능,기술 지원,주변 기기,구축 비용
데이터베이스 관리 시스템(DBMS)
사용자와 데이터베이스 사이에서 정보를 생성해주고, 데이터베이스를 관리해주는 소프트웨어
데이터의 종속성과 중복성의 문제를 해결하기 위해 제안된 시스템
고려사항 : 가용성,성능,기술지원,상호 호환성,구축 비용
웹 어플리케이션 서비스(WAS)
동적인 콘텐츠를 처리하기 위해 사용되는 미들웨어
라이브러리 제공. 데이터베이스 서버와 연동해서 사용
고려사항 : 가용성,성능,기술 지원, 구축 비용
오픈 소스
누구나 제한없이 사용할 수 있도록 소스코드 공유
기능 요구사항(Functional requirements)
기능이나 수행과 관련된 요구사항
시스템의 입출력, 시스템이 수행하는 기능, 사용자가 제공받길 원하는 기능
비기능 요구사항(Non-Functional requirements)
품질이나 제약사항과 관련된 요구사항
시스템 장비 구성, 성능, 인터페이스, 품질
사용자 요구사항
사용자 관점에서 본 시스템이 제공해야 할 요구사항. 사용자를 위한 것. 쉽게 작성
시스템 요구사항
개발자 관점에서 본 시스템 전체가 제공해야할 요구사항.전문적이고 기술적 용어로 표현
소프트웨어 요구사항이라고도 함
요구사항 개발 프로세스
도출 > 분석 > 명세 > 확인 (도분명확)
- 요구사항 도출(수집) : 시스템 개발에 관련된 사람들이 서로 의견을 교환하여 요구사항을 식별하고 이해하는 과정.
설문,프로토타이핑,유스케이스 - 요구사항 분석 : 요구사항 중 이해되지 않는 부분을 발견하고 걸러내기 위한 과정
- 자료흐름도(DFD) : 자료의 흐름 및 변환 과정과 기능을 도형 중심으로 기술
프로세스(Process), 자료 흐름(Data Flow), 자료 저장소(Data Store), 단말(Terminator)
- 자료 사전(DD) : ( ) 자료 생략, [ ] 또는(or), { } 반복, " " 주석 - 요구사항 명세 : 분석된 요구사항을 바탕으로 모델을 작성하고 문서화하는 것
기능은 빠짐없이, 비기능은 필요한 것만 기술. 소단위 명세서 사용 - 요구사항 확인(검증) : 요구사항 명세서가 정확하고 완전하게 작성되었는지 검토
형상관리 수행
- 정형 명세 기법
수학적 원리 기반, 모델 기반
요구사항을 정확하고 간결하게 표현
VDM, Z, Petri-net, CSP 등
- 비정형 명세 기법
상태/기능/객체 중심
내용이 쉬워 의사소통 용이
FSM,Decision Table,ER모델링,State Chart(SADT) 등
