전공자는 기출만 풀고 가라는 글만 많고 내용 정리된 글은 없는거 같아서 준비하면서 정리도 해두고 싶어서 적어보려고 함..
요구사항 확인
- 소프트웨어 생명 주기
- 스크럼 기법
- XP 기법
- 현행 시스템 파악
- 개발 기술 환경 파악
- 요구사항 정의
- 요구사항 분석
- 요구사항 분석 CASE, HIPO
- UML
- 주요 UML 다이어그램
소프트웨어 생명 주기
- 운용, 유지보수 등의 과정을 단계별로 나눈 것 -> 개발 방법론의 바탕이됨
- 워터폴, 애자일 등등이 있음
- 소프트웨어 공학, 원칙
- 품질과 생산성 향상이 주 목적
- 현대적인 기술을 적용해야함
- 품질 유지를 위해 지속적으로 검증
- 기록을 유지해야함
waterfall model
- 폭포가 한번 떨어지면 다시 못 올라가는 것처럼 소프트웨어도 이전 단계로 돌아갈 수 없다는 것을 전제로 둠
- 그래서 각 단계를 확실히 매듭짓는 것이 중요함
- 소프트웨어 공학에서 가장 오래되고 폭넓은 전통적인 모형
- 한 단계가 끝나야 다음 단계로 넘어가는 선형 순차적 모델
- 각 단계가 끝나면 결과물이 나와야 하고 여러개 병행 수행하지 않음
prototype model
- 시제품(prototype)을 만들어 최종 결과를 예측
- 개발 과정에서 새롭게 나오는 요구사항을 반영할 수 있다는 것이 주요 특징임
- 일단 기초코드 짜보고 요구사항 생길때마다 새롭게 만들면서 구현 -> 단기간 제작이 목적, 비효율적일 수 있음
spiral model
- 보헴이 제안함 -> 워터폴, 프로토타입의 장점에다가 위험 분석 기능을 추가
- 여러 번의 개발과정을 거쳐 점진적으로 완성
- 계획, 분석(위험 분석), 개발, 평가 순서
agile model
- 워터폴과 대조적(애자일은 이전단계로 돌아갈 수 있음)
- 개발주기를 스프린트 or 이터레이션으로 부르고 이를 반복함
- 반복 주기마다 고객의 평가, 요구를 수용
- 애자일 자체가 개발 방법론은 아니고 좋은 것을 낭비없이 고객과의 소통에 초점을 맞춘것을 의미함
애자일 핵심 가치
- 프로세스, 도구보다 개인과의 상호작용에 집중
- 문서보다 실행되는 sw에 집중
- 계약 협상보다 고객, 협업에 집중
- 계획에 따르기보다 변화에 적응하는것에 집중
워터폴 애자일 비교
- 새로운 요구사항
- 애자일이 지속적으로 반영
- 고객과의 의사소통
- 워터폴 < 애자일
- 테스트
- 워터폴 : 마지막에 모든 기능을 테스트
- 애자일 : 일정 주기마다
- 개발 중심
- 워터폴 : 계획, 문서
- 애자일 : 고객
스크럼 기법
- 팀원 스스로가 스크럼을 구성해야하고 개발 작업에 관한 모든 것을 스스로 해결할 수 있어야한다
- PO(제품 책임)
- 제품 이해도가 높고 희사를 결정(주로 의뢰자, 사용자)
- 백로그를 작성(요구사항 모아서 우선순위 메긴거)
- 백로그 스토리(요구사항을 문장화한거)는 팀원이 추가 가능한데 우선순위는 PO만 정함
- 테스트 수행 및 백로그 우선순위 지정
- SM(스크럼 마스터)
- 가이드 역할(통제가 목표아님)
- 회의 주관 진행사항 점검 및 문제 공론화해서 처리
- DT(개발팀)
- 팀원들 디자이너, 테스터등도 포함
스크럼 프로세스
- 백로그 : 요구사항을 우선순위에 따라 나열, 지속적으로 업데이트
- 스프린트 회의 : 백로그 중 이번 스프린트에서 수행할 작업을 선정하고 단기 일정 수립
- 스프린트에서 처리할 요구사항을 태스크 단위(개발작가 작업할 수 있는 단위)로 분할
- 개발자들은 각자 수행할 작업 목록인 스프린트 백로그 작성
- 스프린트: 실제 개발 작업과정 보통 2~4주
- 개발자들이 태스크 선정 및 할당받아서 진행
- 태스크는 to do, in progress, done의 상태가 있다
- 일일 스크럼 회의: 매일 짧게 하는 회의
XP 기법
- eXtreme Programming
- 수시로 발생하는 고객의 요구사항에 대응하기 위해 고객의 참여와 개발 과정의 반복을 극대화
- 몇 개의 요구사항이 적용된 일부 기능이 완성될 때마다 고객에게 보여주고 반응을 확인 -> 이거를 최종 제품이 완성될 때까지 반복
핵심 가치
- 의사소통, 단순성, 용기?, 존중, 피드백
XP 프로세스
- 사용자 스토리: 고객의 요구사항, 기능 단위로 구성
- 릴리즈 계획 수립 : 몇개의 스토리가 적용된 부분적 기능 완성 제품을 제공하는게 릴리즈
- 스파이크 : 위험을 감소시키기 위한 간단한 프로그램
- 처리할 문제만 해결하는 코드(다른 조건 생각안하고 만드는거)
- 이터레이션 : 하나의 릴리즈를 세분화한 단위
- 1~3주정도의 기간
- 이때 스토리가 새로 생길 수 있다
- 승인 검사 : 이터레이션 완료시 실행하는 테스트
- 소규모 릴리즈 : 소규모로 고객 반응 확인, 릴리즈가 최종 완제품이 아니면 다음 릴리즈하고 최종 결과물이면 테스트 수행하고 릴리즈함
주요 실천 방법
- pair programiing : 함께 개발, 책임을 공동으로 나눠가짐
- collective ownership : 코드에 대한 권한, 책임을 공동 소유
- Test-Driven dev~ : 실제 코드 작성 전에 테스트 케이스 작성으로 뭐를 해야하는지 파악
- continous integration : 모듈 단위로 개발하고 작업 마무리 될때마다 지속적 통합
- 디자인개선, 리팩토링 : 기능 변경 없이 단순화, 유연성 강화를 위해
- small releases : 릴리즈 기간을 짧게 둬서 자주 반복 요구사항 변화에 신속히 대응
현행 시스템 파악
KMU SW