[소프트웨어공학] 1장. SW 개발 프로세스

https://thunder-moss-b97.notion.site/fbe6396406a5491c851dd00ff3cfff59?pvs=4

소프트웨어공학

1장. SW 개발 프로세스

1. 소프트웨어 개발 프로세스

• 소프트웨어 목표(요구사항)은 같더라도, 과정은 고려사항에 따라 다르다.

[소프트웨어 개발 프로세스]

• 소프트웨어 프로젝트?
  • 수행할 작업을 조직화한 프로세스를 이용
  • 비용, 일정, 품질(보장)에 대한 목표를 성취하는 것
• 프로세스의 정의(사전적)
  • 어떤 일을 하기 위한 특별하 방법으로써 일반적으로 단계나 작업으로 구성
• 소프트웨어 개발 프로세스 (작업 순서)
  • 순서제약이 있는 작업의 집합
  • 높은 품질, 생산성이 목표

[Code-and-Fix(즉흥적 개발)]

• 프로세스가 없는 개발 = Code-and-Fix(즉흥적 개발)
• → [문제점] SW 구조를 만들 수 없다.
• Code-and-Fix의 문제점 (*과정이 존재 X → 일관성 있는 결과 X)
  • 요구나 설계 작업의 중요성을 깨닫지 못함
  • 사용자의 높은 요구 수준 도달 어려움 & 계속 고치는 작업 필요
  • 좋은 소프트웨어 구조를 만들 수 없음
• 프로세스가 없는 개발은 계획 X, 목표 X (일관성 X, 재현성 X)
  • 잘했는지 못했는지 결과 판단이 어려움
  • 비용과 일정 조절 불가
  • 테스트 작업, 품질보증 X ⇒ 발견되지 않은 결함 존재. 시스템 악화

2. 전통적인 소프트웨어 개발 프로세스

• 일종의 가이드 라인
• SDLC(SW Development Life Cycle) : 소프트웨어(정보 시스템)를 개발하는 절차. 혹은 개발 단계의 반복하는 과정
• 전통적인 프로세스 모델
  • 폭포수 모델(Waterfall Model)폭포수 모델(Waterfall Model)
    • 1970년대 소규모 프로그램에 적용하는 Code-and-Fix model 문제를 해결하기 위함.
    • 각 단계가 완료된 후 다음 단계로 진행, 이전 단계로 돌아갈 수 없음! **문제가 생길 경우, 한 사이클이 완전히 끝난 후, 순차적으로 돌아와 수정한다. *순차적=각 단계 사이 중복X, 상호작용X.
    • 각 단계의 결과는 다음 단계가 시작 되기 전에 점검*
    • 🌟결과물 정의가 중요 : 산출물들 관리를 엄격하게 함.
    
    
    • 앞 단계에서 너무 치중하다보면, 뒤의 작업 단계 시간이 부족할 수 있다.
    • 피드백이 없어 문제를 뒤늦게 발견할 수 있어 시스템 품질에 문제가 생길 수 있다.
    • 변경에 대한 대응력이 많이 떨어진다. → 초반 문제들이 누적되면, 나중에 더 큰 문제로 이어질 수 있음.
    ⭕ 장점
    • 단계가 나누어져 있어 관리하기 좋다.
    When?/ 요구사항이 비교적 명확히 정의되어 있는 경우 적용
  • </aside>
  • ⇒ 기술 위험이 낮고, 유사한 프로젝트 경험이 있는 경우
  • ❌ 문제점
  • [특징]
  • <aside> 🚿 *위에서 아래로 작업이 순차적으로 이루어지도록!
  • 프로토타이핑 모델(Prototyping Model)프로토타이핑 모델(Prototyping Model)
    • 사용자 요구사항을 충분히 분석할 목적으로, 시스템의 일부분을 일시적으로 간략히 구현(프로토타입)한 다음 다시 요구사항을 반영하는 과정을 반복하는 개발모델
    [목적]
    • 요구 분석의 어려움 해결 ⇒ 사용자의 참여 유도
    • 요구 사항 도출과 이해에 있어 사용자와의 커뮤니케이션 수단으로 활용 가능 (프로토타입=의사소통 도구)
    • 사용자 자신이 원하는 것이 무엇인지 구체적으로 잘 모를 때, 간단 시제품으로 개발
    • 개발 타당성으로 검토
    • 요구사항을 검증하기 위해 프로토 타입 개발 → by. 폭포수 모델, 전체 시스템 개발 (∴폭포수 모델의 단점 보완)
    
    • 프로토타입을 통해 요구 사항 도출 용이 (가장 큰 장점)
    • 실제 모습을 확인할 수 있기 때문에 시스템의 이해와 품질 향상
    • 개발자와 사용자 간 의사소통 용이
    ❌ 단점
    • 프로토타입 결과를 최종 결과물로 오해할 수 있음
    • 잘못된 프로토타입 개발 시 폐기 처분에 따른 경제적인 손실 발생 가능
    • 프로토타입에 대한 산출물 관리가 어려움 </aside>
  • ⭕ 장점
  • [정의]
  • <aside> 👥 * 사용자 요구사항이 분명하지 않을 때 사용하면 좋음!
  • 진화적 모델(Evolutionary Model)진화적 모델(Evolutionary Model)
    • 빠른 시간 안에 시장에 출시해야 이윤에 직결 ⇒ 시스템을 나누어 릴리즈. 릴리즈 할 때마다 기능의 완성도를 높임!
    • 개발된 모듈을 업그레이드 하는 방식으로 SW가 진화해 가는 개념 *기존에 쓰던 걸 잘 바꾸지 않는 소비자 심리 → 우선 시장을 선점하자!
    
    • 사용자의 요구를 빠르게 반영
    • 새로운 기능을 가진 SW에 대한 시장을 빨리 형성
    • 가동 중인 시스템에서 일어나는 예상하지 못했던 문제를 신속하고 꾸준하게 고쳐나갈 수 있음
    ❌ 단점
    • 프로젝트 관리가 복잡
    • 반복적인 프로세스로 끝이 안 보일 수 있어 실패의 위험이 커짐 : 언제 끝날 지 명확하지 X (몇 번을 릴리즈 해야 완제품이 나오는가?) </aside>
  • ⭕ 장점
  • [목적]
  • <aside> 📈 * 일단 만들고자 하는 프로그램을 부족해도 먼저 출시하고, 버전을 높여 프로그램을 업그레이드하며 소프트웨어를 완성시킴.
  • 나선형 모델(Spiral Model)나선형 모델(Spiral Model)
    • 복잡해지고 있는 소프트웨어 개발 환경에 위험요소를 분석하고 해결할 수 있도록 지원하는 모델
    • 여러 번의 점증적인 릴리즈 🌟위험평가: 진행여부를 판단(O/X) ~> 다른 모델과의 차이점
    
    • 대규모 시스템 개발에 적합
    • 반복적인 개발 및 테스트로 강인성(robustness) 향상
    • 한 사이클에 추가 못한 기능은 다음 단계에 추가
    ❌ 단점
    • 관리 및 위험 분석이 중요하므로 매우 어렵고, 개발기간이 장기화될 가능성
    When?</aside>
  • ⇒ 재정적 또는 기술적으로 위험 부담 큰 경우 / **요구 사항(명확X)**이나 아키텍쳐 이해가 어려운 경우 적용
  • ⭕ 장점
  • [정의]
  • <aside> ➰ ≠진화적 모델! *폭포수 모델과 프로토타입 모델의 장점 활용
  • 점증적 모델(Incremental Model)점증적 모델(Incremental Model)
    • 사용자 요구사항의 일부분, 제품의 일부분을 반복적으로 개발하면서 대상 범위를 확대해 나가아서 최종제품을 완성
    [특징]
    • 폭포수 모델의 변형으로 증분을 따로 개발 후 통합
      • 프로토타이핑과 같이 반복적이나, 각 증분마다 실행이 가능한 완성 모듈을 인도
      • 규모가 큰 개발 조직일 경우 자원을 증분 개발에 충분히 할당할 수 있어 병행 개발 가능
    
    • ?
    ❌ 단점
    • 진화적 모델, 점증적 모델 등 여러 단계가 반복되는 경우는 관리가 어려움
    When?</aside>
  • ⇒ 규모가 큰 개발 조직*(증분을 동시에 할 수 있어, 병행 개발 가능)*
  • ⭕ 장점
  • [정의]
  • <aside> ⤴️
  • V 모델(Verification & Validation Model)V 모델(Verification & Validation Model)
    • Verification: 각 단계별로 목표에 대해 수행한 결과 확인
    • Validation: 사용자 요구사항을 제대로 반영했는지 확인
    • 감추어진 반복과 재작업을 드러냄
    • 작업과 결과의 검증에 초점
    [차이점] : 다른 모델도 이러한 테스트 과정을 거치지만, V 모델은 테스트에 대한 기준이 처음부터 각 단계별로 엄격하다!
    • 소프트웨어 개발 결과물에 대한 단계적인 검증과 확인 과정을 거침으로써, 오류를 줄일 수 있음
    ❌ 단점
    • 폭포수 모델을 적용함으로써 개발 활동에 대한 반복이 없어 변경을 다루기가 어려움 → 위에서 언급한 특수 분야들에서는 변경이 잘 이루어지지 않기에, 오히려 테스트를 많이 하는 것이 중요함!
    When?</aside>
  • ⇒ 의료, 국방, 우주개발 소프트웨어 등 아주 작은 오류도 치명적인 분야에 적용
  • ⭕ 장점
  • → 기준이 엄격하기에, 테스트 여러 번 한다. 따라서 오류 줄어듦↓ 예) 의료, 국방, 우주개발 소프트웨어 등 아주 작은 오류도 치명적인 분야에서 주로 사용!
  • [정의]
  • <aside> 📈 * 폭포수 모델 확장.

 

3. 애자일(Agile) 방법론

: 낭비 없이 좋은 걸 빠르게 만들기 위해 만들어진 모델.

*RAD: 단계별 사전계획. 문서 지향이 아닌, 코드를 어떻게 빨리 돌릴 수 있는가에 초점! (문서도, 코드도 잘 안 만들어지는 문제 해결.)

🚨핵심 1) 빨리, 2) 사용자 요구사항

• = 좋은 것을 빠르고 낭비 없게 만드는 개발을 가능하게 해주는 방법론 전체 (able to move quickly and easily)
• 대표적인 애자일 방법론들
  • 적응형 소프트웨어 개발
  • 크리스털 패밀리(Crystal Family)
  • 익스트림 프로그래밍(XP)
  • 스크럼(Scrum) // 최종적으로 지금은 거의 이 두 가지 방법론多
  • `(∵다른 애들을 포함하고 있기 때문)`
  • 린 소프트웨어 개발(Lean Software Development) : 자동차 생산라인에서 사용하던 것을 가져온 것으로, 낭비(오류)를 줄임.
  • 기능 주도 개발(Feature Driven Development)

[적용 원리]

신속한 소프트웨어 개발을 위한 원칙

<aside> 👉🏻 - 고객 만족을 가능한 빨리 이끌어내고, 유연한 소프트웨어를 지속적으로 사용자에게 제공

• 개발과정에서 늦은 시점일지라도 요구사항 변경을 적극 수용 → 고객들의 요구사항 반영👍🏻
• 실행 가능한 소프트웨어를 1~2주일에 한 번씩 사용자에게 배포
• 사용자와 개발자 간 친밀한 미팅을 거의 매일 수행
• 프로젝트는 신뢰할 수 있고 동기가 부여된 개인을 중심으로 진행
• 의사소통을 위해 가능하면 한 곳에 모여 대화
• 실행 가능한 소프트웨어를 기주능로 프로젝트 진척률 결정
• 일정한 개발속도를 유지하며, 지속 가능하도록 소프트웨어를 개발
• 우수한 기술의 도입과 좋은 설계에 지속적인 관심 갖기
• 단순화는 필수
• 최상의 아키텍처, 정제된 요구사항, 좋은 설계는 잘 구성된 팀을 통해 개발이 가능
• 팀은 더 효과적인 방법의 적용, 적절한 조정 과정을 정기적으로 수행

</aside>

XP(eXtream Programming) 프로세스

[실천사항]

• 증분계획(incremental planning): 우선순위를 따져, 그에 따라 계획
• 작은 배포(small release)
• 단순 설계(simple design): 단순 설계를 위해 표준화된 설계방식을 사용
• 테스트 우선 선발(test-first development): 설계하면서, 테스트 케이스까지 함께 개발 *테스트 케이스를 먼저 하면, 잠재된 오류를 빠르게 캐치할 수 있음
• 재구조화(refactoring)
• 페어 프로그래밍(pair programming): 2인 1조, 두 명의 개발자가 함께 코드 작성하는 것 *코드의 품질이 좋아진다.
• 공동소유권(collective ownership)
• *코드의 소유권은? → 작성한 사람이 가지고 있으나, 1팀으로 작업하면 팀 전체에 소유권이 있음
• 지속적 통합(continuous integration)
• 현장 고객(on-site customner)

[개발 사이클]

• 엔지니어링 사이클
• 
• 배포 사이클*[참고] 사용자 스토리 : 사용자에게 가치있는 주요 요구사항의 기능 설명을 사용자 관점에서 이야기 하는 것 → “~는 ~하기 위해 ~할 것이다.”(높을수록 만들기 어려움 - 높은 것 우선적으로 작업하나, 적절히 분배해 증분 계획을 세운다)
• // 스토리 포인트 부여
• 

스크럼(Scrum) 프로세스

: 스크럼(Scrum)? 반복적 개발의 관리 관점을 강조

[관련 용어]

• 스프린트(sprint): 반복적인 개발 주기 *보통은 4주를 개발주기로 함
• 제품 백로그(backlog): 개발할 제품에 대한 요구사항(=사용자스토리) 목록
• 스프린트 백로그: 스프린트 목표에 도달하기 위해 필요한 작업 목록
• 제품 증분
• 번다운 차트, 번업 차트
• 스크럼 마스터: 프로젝트 관리자

<aside> 💡 스크럼은 특정 언어나 방법론에 의존적이지 않은, 넓은 응용 범위의 개발 기법

</aside>

[특성]

• 개발할 기능 및 개선점에 대한 우선순위 부여
• 개발 주기를 30일 정도
  • 개발 주기마다 실제 동작할 수 있는 결과를 제공
  • 개발 주기마다 적용할 기능이나 개선 목록을 제공
• 날마다 15분 정도 회의
• 원활한 의사소통을 할 수 있도록, 구분 없는 열린 공간을 유지

4. 카오스(Chaos)와 데브옵스(DevOps)

• 기존 서비스: 발생한 오류가 사용자들에게 치명적이지는 X,
• 넷플릭스와 같은 최근 서비스: ~

→ 평소에 사용자 단계에서 발생할 수 있는 문제를 미리 테스트해서 해결하자!

Chaos Engineering

*넷플에서 만들어낸 용어

• 다양한 서비스 운영 환경에 대응하고 새로운 기능을 중단 없이 제공하기 위해서, 기존 서비스에 임의의 결함을 주입하고 이들이 어떠한 행동을 보이는지 동적으로 검사하면서*(=실제로 해봄)*, 시스템 운영에 대응하는 방법을 찾는 것.
• 예측 불가능한 상황에서 나타나는 시스템 동작의 규칙성을 찾아내고 이에 대응하는 활동

DevOps (= Development + Operations)

: 소프트웨어 개발자와 정보기술 전문가 간의 소통, 협업 및 통합을 강조하는 개발 환경이나 문화

[정의]

• IBM: 소프트웨어 개발 팀과 운영 팀 간의 조정을 위하여 제시된 프로세스
• IEEE 표준: 소프트웨어 개발과 관련된 스테이크 홀더들이 소프트웨어 시스템 또는 서비스를 명세, 개발, 운영하고 시스템 전체 수명주기에 걸쳐 지속적 개선 도모를 위해 의사소통과 협업 증진하기 위한 원리와 실천 사항들

[등장 배경]

• 사일로기반 개발방식의 문제: SW 개발의 각 단계가 종료된 후 다음 단계로 진행되기에 생기는, 각 단계 간 상호작용 부재.

*[핵심 원리] 기술의 표준화 → 도구를 사용

• 자동화: 운영 환경의 오류를 신속하고 일관성 있게 해결
• 반복: 모니터링된 요구사항을 시스템에 반영해 개발(반복 개발 형식)
• 자기 서비스: 협업및 자동화를 통해 개발자와 운영자가 서로 방해없이 독립적으로 일할 수 있도록 함
• 지속적 개선: 사용자의 피드백을 SW 및 운영 환경 개선 위해 활용
• 협업
• 지속적 테스트: 일정 시점이 아닌, 계속 테스트! ⇒ 품질보증팀, 운영팀 등이 성능테스트
• 지속적 통합과 지속적 배포

DevOps 프로세스

• 소프트웨어 요구사항을 작은 단위의 개발 태스크로 분할
• 각 태스크에 대한 개발 및 배포 계획을 수립(Plan)한 후, 이 계획에 따라 단위 소프트웨어 컴포넌트를 개발(Code)
• 개발된 코드들은 상호 통합되어 배포 가능한 기능으로 구성(Build)
• 이는 테스트(Test) 과정을 거쳐 Ops로 릴리즈(Release)

<aside> 💡 DevOps 프로세스 실현을 위해서는 자동화 필수!

• [목표] 애플리케이션 배포 및 운영환경과 개발 및 테스트 환경 간의 격차 줄이기 ⇒ 애플리케이션 배포시점에서 발생할 수 있는 환경 불일치 문제를 완화. *이를 위해 사용되는 도구 모임: ‘DevOps Toolchain’

</aside>

5. 소프트웨어 프로세스 개선

: “SW 품질은 제품을 개발하고 유지보수 하는데 사용하는 프로세스의 품질에 의해 결정된다.”

• 소프트웨어 개발의 문제점: 낮은 생산성/품질 저하
  • 소프트웨어 프로젝트의 납기 지연 및 비용초과
• 프로세스 개선의 필요성
  • 좋은 프로세스가 없으면 좋은 품질 소프트웨어 제품 생산 불가. ⇒ 품질 계획 및 관리가 불가하며, 좋은 품질 SW 얻었다 하더라도 보장 X
  • [해결방향]
    • 하드웨어 개발 접근 방법의 도입 : 제도 및 생산공정, 철저한 품질관리 및 지속적인 공정개선

• •