소프트웨어 시스템을 만드는데 요구되는 프로세스
-
Specification (명세화)
고객의 요구사항 : 기능적, 비기능적 요소들, 제약조건 등을 바탕으로 명세서를 만드는 과정 -
Design and implementation (설계,개발)
설계 )
기존 시스템과의 연동관계, 모듈들간의 인터랙션 등 -
Validation (검증)
"고객이 원하는 대로" 잘 작동하는지 검증
(고객의 니즈와 일치하는지) -
Evolution (진화)
유지보수
Software process models
waterfall model
- 많은 시간이 소요되고 flexible하지 않음
- 오류가 굉장히 치명적인 시스템 ( 안전성 중심 시스템 ) 에 주로 쓰임
Incremental development
- 신속하게 개발해야하는 경우 , 트렌디한 SW를 개발하는 경우
Integration and configuration
- 기존의 코드를 재활용하며 새로운 기술에 집중해서 개발
- 빠른 개발이 가능하며, 기존의 코드들은 이미 검증되었기 때문에 안정적이다
Waterfall model 🌊
앞의 단계가 완전히 끝나야만 다음단계로 넘어갈 수 있다
다음 단계로 넘어가면 앞의 단계로 돌아갈 수 없다
[명세화]
요구사항 정의
어떤 기능, 제약사항을 넣을 것인지 결정
다른 모델들에서보다 waterfall에서 특히 더 중요시되는 단계
- 명세화 단계에서 고려할 수 있는 모든것들을 다 고려해야만 한다요구사항이 바뀌면 아키텍처가 바뀜
= 잠재적 오류의 발생가능성이 매우 높아짐[개발]
시스템/소프트웨어 설계
하드웨어, 소프트웨어의 아키텍처를 설계구현 및 단위 테스팅
구현) 프로그래머 투입 시작
단위 테스팅) 각각의 모듈들이 잘 작동하는지 확인하는 것[검증]
통합 및 시스템 테스팅
동작성, 비기능적 요구사항들까지 모두 확인한다[인수]
[진화]
운영 및 유지보수
Waterfall model 이 적합한 경우
- Critical system ( 안전성 중심 시스템 )에 적합하다
경제, 비즈니스, 생명에 치명적인 영향을 미칠 수 있는 시스템
📍 critical system의 종류
safety system :
고장으로 인해 사람의 부상이나 사망을 일으키는 시스템
- ex) 비행기 컨트롤하는 시스템mission system :
고장으로 인해 업무수행이 마비될 수 있는 시스템
- ex ) 금융시스템 등 ( 어음의 경우 몇시몇분까지 입금하지 않으면 부도처리가 되는데 이때 시스템에 고장이 나서 입금을 할 수 없게 된다면..?)business system :
고장으로 인해 비즈니스에 굉장히 큰 비용이 부과되는 경우
- ex) 결제가 안되는 경우
- 협업해서 만드는 시스템 ( 여러 파트너사들이 같이 투입되어 개발하는 경우 )에 적합하다
📈 Incremental development 점증적 개발 모델
가장 많이 쓰는 기능 (코어기능) 몇개를 먼저 개발하여 배포
❓코어기능을 먼저 개발하여 배포하는 이유 :
- 개선시킬 수 있는 시간적 여유가 확보됨
- 사용자가 익숙해질 수 있음
배포한 기능들에 대한 피드백을 바탕으로 개선 + 새로운 기능들 추가하여 2번째 버전 배포
또 피드백을 받아 개선 + 새로운 기능들 추가하여 n번째 버전 배포
Incremental development 가 사용되는 상황
- 고객의 요구사항이 계속해서 바뀌는 경우
- critical하지 않은 시스템의 경우
- 빠르게 개발하고 trendy한 기술을 개발할 때 사용
benefits
- 사용자의 변화하는 요구사항들을 수용하는데 발생하는 비용이 줄어든다
- 고객의 피드백을 반영하는데 유리하다
- 빠른 인수 가능
- 고객의 니즈를 즉각적으로 반영가능
- 먼저 배포한 기능에 대한 충분한 디버깅이 가능하다
= 코드 안정화가 가능하다 - 버전별로 나오기 때문에 사용자의 피드백을 반영하여 사용자의 만족도를 높일 수 있다
- 사용자의 입장에서 더 신뢰가능하고 안심가능하다
problems
- process is not visible
= document를 상대적으로 적게 만들기 때문에 개발과정이 가시적이지 못하다
( 명세서를 waterfall에 비해 부실하게 만듦 ) - system structure tends to degrade as new increments are added
= 코드의 구조가 깨질 수 있으며, 그 결과 에러 발생가능성이 높아짐 ( 품질이 나빠짐 )코드를 여러번 고침 = 코드의 구조가 깨질 수 있음
= 유지보수가 힘듦 = 품질이 나빠짐
= 시스템이 잘 정리되어있지 않기때문에 복잡해지고 나중에 찾기도 힘듦
=> 💡REFACTORING 필요
💡Refactoring
코드를 짠 본인이 수행하는 작업으로, 자신의 코드를 잘 다듬는 것
결과의 변경 없이 남들이 코드를 잘 이해할 수 있도록 코드의 구조를 재조정한다
가독성 향상, 유지보수성 향상, 버그 제거
중복된 코드, 임시 필드, 데이터 클래스, 거대한 클래스, 주석, 긴 파라미터 리스트 를 대상으로 한다
⚙️ Integration and configuration 통합과 환경설정
기존의 코드를 가져다가 새로운 코드와 '통합'해서 사용한다
코드 재사용의 장점 : 시간절약, 성능 검증
COTS (Commercial Off The Shelf)
= 이미 존재하는 기능,완제품 ( 수정불가 )
요구사항 명세화
소프트웨어 발견 :
고객의 니즈에 해당하는 "기존의" 소프트웨어가 있는지 찾는다
소프트웨어 평가 :
찾은 기존의 sw를 사용할 수 있는지, 본 프로젝트에 적합한지 평가한다
요구사항 정제 :
찾은 모듈/COTS 가 100% 내 입맛에 맞을 수 없다
=> 고객들의 요구사항을 조정하여 COTS에 맞도록 정제한다( COTS 인 경우 ) 애플리케이션 환경설정
COTS는 수정불가능하므로 COTS에 맞게 환경을 설정한다( COTS 아닌 경우 ) 컴포넌트 수정, 신규 컴포넌트 개발
COTS가 아닌 오픈소스 등을 내 입맛대로 수정 / 나에게 필요한 컴포넌트(기능) 개발
Advantages
-
개발비용, risk가 줄어듦
이미 사용되고 있는 모듈들의 경우 성능이 보장되어있고 어떤 문제점이 있는지도 알 수 있다
-
빠른 개발, 빠른 인도
Disadvantages
고객의 니즈를 COTS에 맞춰야한다 - 협상,타협과정이 필요하다
주도권을 잃는다 = 진화시키기 어렵다
COTS 부분은 COTS 개발 측에서만 수정가능하다
