🖱️소프트웨어 생명 주기 : 소프트웨어를 개발하기 위한 과정(설계, 운용, 유지보수 등)을 각 단계별로 나눈 것
🖱️폭포수 모형(waterfall model, 선형) : 각 단계를 확실히 매듭짓고 그 결과를 검토하여 승인 과정을 거친 후 다음 단계를 진행하는 개발 방법
- 가장 오래되고 폭넓게 사용된 전통적인 소프트웨어 생명 주기 모형 (-> 경험과 성공 사례가 많음)
- a.k.a 고전적 생명 주기 모형
🖱️프로토타입 모형(prototype model, 원형) : 실제 개발될 소프트웨어의 견본품을 만들어 최종 결과물을 예측하는 모형
- 견본품은 사용자와 시스템 사이의 인터페이스에 중점을 두어 개발
🖱️나선형 모형(spiral model, 점진적 모형) : 나선을 따라 돌듯 여러 번의 소프트웨어 개발 과정을 거쳐 점진적으로 완벽한 최종 소프트퉤어를 개발하는 모형
- 보헴이 제안
- 폭포수 모형, 프로토타입 모형의 장점에 위험 분석 기능을 추가
- 누락/추가된 요구사항 첨가 가능
- 유지보수 과정이 필요 없음
- 계획수립, 위험분석, 개발 및 검증, 고객평가 반복
🖱️애자일 모형(Agile model) : 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하면서 개발하는 모형
- 특정 개발방법론이 아니라 좋은 것을 빠르고 낭비 없게 만들기 위해 고객과의 소통에 초점을 맞춘 방법론을 통칭
- 폭포수 모형과 대조적
- 핵심가치 : 프로세스와 도구<개인과의 상호작용, 문서<실행되는 SW, 계약/협상<고객과의 협업, 계획<변화에 반
- 대표적인 개발 모형
| 이름 | 특징 |
| 스크럼(scrum) : 팀 중심으로 개발효율성 향상 | - 팀원 스스로 팀을 구성 -> 개발 작업에 관한 모든 것을 스스로 해결 - 구성원 : - 제품책임자( Product Owner) : *백로그(backlog) 작성, 제품에 대한 이해도가 높고 요구사항을 책임지고 의사를 결정할 사람으로 선정 - 스크럼 마스터(Scrum Master) : 스크럼 팀이 스크럼을 잘 수행하도록 가이드(일일 스크럼 회의 주관, 진행사항 점검, 장애요소 공론화 등) - 개발팀(Development Tesm) : 위 두사람을 제외한 모든 개발팀원 * 백로그 : 요구사항을 우선순위에 따라 나열한 목록 - 개발 프로세스 : 1. 제품책임자가 제품 백로그(product backlog) 우선순위 결정 2. 스프린트 계획 회의(sprint planning meeting) : 단기 일정 수립, 스크럼 마스터 주관 3. 스프린트(sprint) : 약 2~4주의 개발 과정 4. 일일 스크럼 회의 : 매일 약 15분정도 진행되는 짧은 회의 , 소멸차트(burn-down chart)에 남은 작업시간 표시 5. 스프린트 검토 회의(sprint review) : PO 주관 회의로 요구사항 부합 여부 확인 테스트 수행 및 회의 6. 스프린트 회고(sprint retrospective) : 스프린트 주기를 되돌아보며 규칙 준수 여부, 개선점 등을 확인하고 기록 |
| XP(eXtreme programming) : 요구사항에 유연하게 대응하기 위해 고객의 참여와 개발 과정의 반복을 극대화하여 생산성을 향상 (반복적인 개발주기, 단순한 설계, 고객의 적극적 참여, 릴리즈의 기간을 짧게 반복, 요구사항 반영에 대한 가시성을 높임) | - 5가지 핵심 가치 : 용기(courage), 단순성(simplicity), 의사소통(communication), 피드백(feedback), 존중(respect) - 개발 프로세스 : 1. 사용자 스토리(요구사항) -> 테스트시나리오 2. 릴리즈 계획 수립(release planning) : 부분/전체 개발완료 시점에 대한 일정 수립 3. 주기(iteration) : 약 1~3주의 개발 과정 (새로운 사용자 스토리가 추가되면 불확실한 추정으로 스파이크(별도 프로그램)를 만들어서 성공하면 확신하는 추정이 됨) 4. 승인검사/인수테스트 (acceptance test): 사용자 스토리를 통해 작성된 테스트 시나리오 진행 5. 소규모릴리즈 (small release): 요구사항에 유연하게 대응할 수 있도록 릴리즈의 규모를 축소한 것 *릴리즈 : 몇개의 스토리가 적용되어 부분적으로 기능이 완료된 제품 제공하는 - 주요 실천방법 : 1. 짝 프로그래밍(pair programming) : 다른 사람과 함께 프로그래밍을 수행하여 개발에 대한 책임을 공동으로 나눠 가짐 2. 공동 코드 소유(collective ownership) : 개발 코드에 대한 권환과 책임을 공동으로 소유함 3. 테스트 주도 개발(test-driven-development) : 개발자가 실제 코드를 작성하기 전에 테스트 케이스를 먼저 작성하므로 자신이 무엇을 해야할지를 정확히 파악 4. 전체 팀(whole team) : 개발에 참여하는 모든 구성원들은 각자의 역할이 있고 그에 따른 책임을 가져야 함 5. 계속적인 통합(continuous integration) : 모듈단위 개발을 하나의 작업이 마무리 될 때마다 지속적으로 통합 6. 리팩토링(refactoring) : 프로그램의 단순화, 유연성 강화 등을 위해 기능의 변경없이 시스템을 재구성하는 것 7. 소규모릴리즈 (small release) : 릴리즈 기간을 짧게 반복함으로써 고객의 요구 변화에 신속하게 대응 |
| 칸반(kanban) | |
| Lean | |
| 기능중심개발(feature driven development) | |
| 기 스 X L 칸 (기스 나기 싫으면 XL 칸으로 가자) | |
🖱️소프트웨어 공학 : 소프트웨어의 위기를 극복하기 위한 방안으로 연구된 학문
- 소프트웨어의 품질과 생산성 향상을 목적의 여러가지 방법론, 도구, 관리 기법
- 기본원칙 : 현대적 프로그래밍 기술을 계속적으로 적용, 개발된 소프트웨어의 품질이 유지되도록 지속적 검증, 소프트웨어 개발 관련 사항 및 결과에 대한 명확한 기록을 유지
🖱️현행 시스템 파악
| 절차 | ||
| 1단계 | 시스템 구성 파악 | 기간 업무(조직의 주요 업무 담당), 지원 업무(기간 업무 지원)로 구분하여 기술 |
| 시스템 기능 파악 | 현재 제공하는 기능들을 주요 기능, 하부 기능, 세부 기능의 계층형으로 표시 | |
| 시스템 인터페이 파악 | 시스템 간 주고받는 데이터의 종류, 형식, 프로토콜, 연계 유형, 주기 등을 명시 | |
| 2단계 | 아키텍처 구성 파악 | 최상위 수준에서 계층별로 표현한 아키텍처 구성도를 작성 |
| 소프트웨어 구성 파악 | 소프트웨어들의 제품명, 용도, 라이센스 적용 방식, 라이센스 수 등을 명시 | |
| 3단계 | 하드웨어 구성 파악 | 단위 업무 시스템들이 운용되는 서버의 주요 사양과 수량, 그리고 서버의 이중화 적용 여부를 명시 |
| 네트워크 구성 파 | 서버의 위치, 서버 간의 네트워크 연결 방식을 네트워크 구성도로 작성 | |
| 구기인 아소 하네 (구기인이라는 친구한테 부탁하니 아랐소 하네) | ||
🖱️개발기술환경파악 : 개발하고자 하는 소프트웨어와 관련된 운영체제(OS), 데이터베이스 관리 시스템(DBMS), 미들웨어 등을 선정할 때 고려할 사항 기술 + 오픈 소스 사용 주의점 제시
| 운영체제(Operation System) | - 컴퓨터 시스템의 자원을 효율적으로 관리 / 컴퓨터를 편리하고 효율적으로 사용할 수 있도록 환경을 제공하는 소프트웨어 ex) 컴퓨터 - Windows, UNIX, LINUX, Mac OS 등 / 모바일 - iOS, Android 등 - 컴퓨터 하드웨어와 사용자 간의 인터페이스로 동작하는 시스템 소프트웨어 - 다른 응용 프로그램이 유용한 작업을 할 수 있는 환경 제공 - 운영체제 관련 요구사항 식별 시 고려사항 : 가용성, 성능, 기술 지원, 주변 기기, 구축 비용 |
| 데이터베이스 관리 시스템(Database Management System) | - 사용자와 데이터베이스 사이에서 요구에 따라 정보 생성, DB관리 기능을 제공하는 소프트웨어 - 기존 파일 시스템이 갖는 데이터 종속성, 중복성의 문제를 해결하기 위해 제안된 시스템 - 모든 응용 프로그램들이 데이터베이스를 공용할 수 있도록 관리함 - DBMS 관련 요구사항 식별 시 고려사항 : 가용성, 성능, 기술 지원, 상호 호환성, 구축 비용 |
| 웹 애플리케이션 서버(Web Application Server) | - 사용자의 요구에 따라 변하는 동적인 컨텐츠를 처리하기 위해 사용되는 미들웨어 - DB 서버와 연동해서 사용 - AWS 관련 요구사항 식별 시 고려사항 : 가용성, 성능, 기술 지원, 구축 비용 |
| 오픈소스(Open Source) | - 제한없이 사용할 수 있도록 소스 코드가 공개된 소프트웨어 - 오픈 소스 라이선스를 만족함 - 오픈소스 관련 요구사항 식별 시 고려사항 : 라이선스 종류, 사용자 수, 기술의 지속 가능성 |
