2. Software Development Process

What is Software?

1) Instructions (computer programs) : 컴퓨터에 수행할 작업을 알려주는 일련의 명령
2) Data structures : 데이터를 저장하고 관리하기 위해 정리된 형식입니다. 이를 통해 컴퓨터 프로그램은 정보를 효율적으로 조작하고 처리할 수 있음
3) Documents: 소프트웨어 사용 방법과 작동 방법을 설명하는 서면 문서

Engineering Approach for Building a Software

• Requirement Analysis
  개발할 소프트웨어의 요구사항을 수집하고 분석
• Design
  수집한 정보를 바탕으로 소프트웨어의 아키텍처, 구성요소, 인터페이스 등을 설계
• Coding
  설계 단계에서 정의된 설계 사양을 바탕으로 실제 코드를 작성
• Unit Testing
  개발된 코드의 각 단위(함수나 메소드 등)가 예상대로 정확하게 작동하는지 검증
• Integration Testing
  개별적으로 테스트된 소프트웨어의 구성요소나 모듈을 통합한 후, 이들이 함께 제대로 작동하는지 검증
• System Testing
  전체 시스템이 사용자의 요구사항을 만족시키는지 확인하기 위해 종합적인 테스트를 수행
• Delivery
  테스트 단계를 성공적으로 통과한 소프트웨어는 고객에게 배포
• Maintenance
  소프트웨어가 배포된 후에는 지속적인 유지보수가 필요

Software Development Process

1. Requirement Analysis and Specification

Requirement

• 원하는 것 또는 필요한 것을 의미
• 사용자가 문제를 해결하거나 목표를 달성하기 위해 필요한 조건이나 기능

Non-functional requirements

• 시스템이 어떻게 운영되어야 하는지에 대한 요구사항으로, 시스템의 품질 속성을 정의
• performance, security, portability, interoperability, maintainability 등

• 사용자의 문제 분석
• 시스템이 제공할 내용의 명세화
  수집된 정보를 기반으로 시스템이 해결해야 할 문제와 제공해야 할 기능을 명확하게 정의
• ‘누가 사용할 것인지’, ‘시스템이 무엇을 할 것인지’,’ 언제 어디서 사용될 것인지’에 대한 답변을 명확히 함

2. Architectural Design

Software architecture is
• 기술적 및 운영적 요구사항을 만족시키는 솔루션을 정의하고 구조화하는 것
• 아키텍처는 시스템을 구성하는 요소들, 그 요소들의 외부로 드러나는 속성들, 그리고 그 요소들 사이의 관계들을 포함하는 하나 이상의 구조로 구성

• 시스템이 ‘어떻게’ 구성되어야하는지에 대한 설명
• 구성요소 간 인터페이서의 명세화
  인터페이스는 구성요소들이 서로 상호작용하는 방법을 정의
• 데이터 설계 (데이터베이스 및 파일)
  시스템에서 사용될 데이터베이스 및 파일의 구조를 설계합니다. 이는 데이터의 저장, 검색, 수정, 삭제 등을 효율적으로 수행할 수 있는 방법을 정의하며, 데이터의 무결성, 보안, 접근성 등을 고려

3. Software Construction

소프트웨어 개발 과정에서 실제 제품을 만들어 내는 중요한 부분

• 상세 설계 (Detailed Design)

  • 상세 설계는 소프트웨어 아키텍처에서 정의된 각 컴포넌트의 내부 구조와 동작을 더욱 구체적으로 정의
  • 개별 구성요소의 내부 설계
  • 논리 및 데이터구조 설계

• 코딩

  • 상세 설계 단계에서 정의된 설계를 실제 코드로 변환하는 작업
  • 컴포넌트 설계를 코드로 매핑

• 단위 테스트 (Unit Testing)
  개별 컴포넌트가 올바르게 작동하는지 테스트하는 과정

Software Integration and Test

개별적으로 개발된 컴포넌트들을 하나의 시스템으로 결합하고, 이 시스템이 전체적으로 사용자의 요구사항을 만족하는지 확인하는 과정

• 통합 테스트 (Integration Testing)
  • 개별적으로 개발된 컴포넌트들을 결합하고, 각 결합 단계에서 컴포넌트들이 제대로 상호작용하는지 테스트하는 과정
• 시스템 테스트 (System Testing)
  • 시스템 테스트는 통합된 전체 시스템이 소프트웨어 요구사항을 충족하는지 테스트하는 과정
  • 개발된 소프트웨어가 실제 운영 환경에서 예상대로 작동하는지 확인하는 중요한 단계
  • 기능성, 성능, 보안, 호환성 등 다양한 측면에서 시스템을 평가
• 수용 테스트 (Acceptance Test)
  • 최종 사용자나 고객이 시스템을 테스트하여 그들의 요구사항과 기대치를 충족하는지 확인하는 과정
  • 실제 사용 환경에서 사용자가 시스템을 평가하며, 만약 시스템이 사용자의 기대치와 요구사항을 만족한다면 최종적으로 소프트웨어를 수용

V Model

• 워터폴(waterfall) 모델의 변형
• 소프트웨어 개발 과정에서 품질을 보장하기 위해 계획되고 실행되는 테스트 및 검증 활동이 개발의 각 단계와 어떻게 연계되어 있는지를 설명
• 개발 과정에서의 다양한 테스트 단계가 각각의 개발 단계와 어떻게 대응하는지를 시각적으로 보여줌
• 개발의 좌측 사이드(하향)와 테스트의 우측 사이드(상향)로 나뉨
• "소프트웨어 요구사항은 수명주기 후반에 테스트된다"
• 개발 초기 단계에서 정의된 요구사항이 개발 과정을 거치며 지속적으로 검증되어야 함을 강조하며, 이를 통해 발견된 문제점은 개발 초기 단계로 되돌아가 수정
• 폭포수 모델이 산출물 중심이라면 V 모델은 각 개발 단계를 검증하는 데 초점을 두므로 오류를 줄일 수 있음

Waterfall vs. Agile Development

추가 요구사항 부분

• 애자일 방법론 : 추가 요구사항을 수용할 수 있는 방법으로 설계 되어 있다.
• 폭포수 모델 : 추가 요구사항을 반영하기 어려운 구조이다.

릴리스 시점

• 애자일 방법론 : 자주 릴리스된다.
• 폭포수 모델 : 최종 완성된 제품을 릴리스한다.

시작 상태

• 애자일 방법론 : 시작단계에서는 부족한 점이 많지만 점차 완성도가 높아진다.
• 폭포수 모델 : 시작 단계에서의 완성도가 매우 높다.

고객과의 의사소통

• 애자일 방법론 : 처음부터 사용자의 참여를 유도하고 많은 대화를 하면서 개발을 진행한다.
• 폭포수 모델: 사용자와 산출물을 근거로 하여 빈번하게 대화하지 않는다.

진행 상황 점검

• 애자일 방법론 : 개발자와 사용자는 개발 초기부터 지속적으로 진행.
• 폭포수 모델 : 단계별 산출물을 중요시 하기 때문에 단계별 산출물에 대한 결과로 개발의 진척 상황을 점검한다.

분석, 설계, 구현 진행과정

• 애자일 방법론 : 하나의 단계 또는 반복안에 분석, 설계, 구현 과정이 모두 포함되어 동시에 진행된다고 볼 수 있다.
• 폭포수 모델 : 분석, 설계, 구현과정이 명확하다.

모듈 통합(컴포넌트 통합)

• 애자일 방법론 : 개발 초기부터 빈번한 통합을 통하여 문제점을 빨리 발견하고 수정하는 방식을 택한다.
• 폭포수 모델 : 구현이 완료된 후에 모듈간의 통합 작업을 수행한다.

➡️ Waterfall 모델은 요구 사항이 명확하고 변경될 가능성이 적은 프로젝트에 적합, 예를 들어, 규제가 엄격한 산업에서는 Waterfall 모델 선호
➡️ Agile 방법론은 변화가 빈번하고, 고객의 지속적인 피드백이 중요한 프로젝트에 적합, 특히 소프트웨어 개발과 같이 빠르게 변화하는 환경에서 유용

Agile Development - Scrum

• Agile 개발 방식 중 하나인 Scrum은 1996년 주목을 받기 시작한 민첩한 프로젝트 관리에 중점을 둔 방법론
• 반복적이고 점진적인 개발을 통해 제품을 만들어가는 과정에 초점
  

1. Product Backlog
   최종 제품에 대한 모든 예상 기능, 개선 사항, 수정 사항 및 요구 사항을 포함하는 우선순위가 지정된 동적 목록
2. Sprint Backlog
   현재 스프린트에서 구현할 제품 백로그 항목의 하위 집합
3. Sprint
   특정 작업 세트가 완료되고 검토 준비가 되어야 하는 시간 제한이 있는 기간, 보통 2-4주
4. Working Increment of the Software
   각 스프린트의 끝에 개발 팀이 제공하는, 실제로 작동하는 소프트웨어의 새로운 버전을 의미

Agile Development – Continuous Integration

• 코드 변경 사항을 자주 (가능한 한 자주, 일반적으로 하루에 여러 번) 메인 코드베이스에 병합하는 프랙티스
• 코드 변경 사항이 메인 코드베이스에 병합될 때마다, 자동화된 시스템이 코드를 빌드하고 다양한 테스트(단위 테스트, 통합 테스트 등)를 실행하여 변경 사항이 기존 기능을 깨뜨리지 않는지 확인

주요 목표

• 버그 감소
  코드 변경 사항을 지속적으로 통합함으로써, 버그를 빠르게 발견하고 수정
• 개발 프로세스 개선
  개발자가 작은 단위로 작업을 수행하고 자주 병합함으로써, 코드베이스의 안정성을 유지하면서도 유연성을 갖춤
• 피드백 루프 단축
  지속적인 통합은 개발자에게 빠른 피드백을 제공하여, 코드의 품질이 기대치를 충족하는지 확인할 수 있음

Agile Development – DevOps

• 개발(Dev)과 운영(Operations)의 결합을 의미
• 개발팀과 운영팀 간의 협력과 의사소통을 강화하여, 소프트웨어 개발과 배포 프로세스를 하나의 연속된 흐름으로 만듬
• 핵심 목표 중 하나는 연속적인 배포(Continuous Deployment)와 연속적인 제공(Continuous Delivery)에 초점을 맞추는 것
• 코드 변경사항이 자동으로 테스트되고 프로덕션 환경으로 배포되어, 배포 과정의 속도를 높이고 자동화
  

시스템 구축

• Process
  스템이 어떻게 작동하는지, 즉 시스템의 동작 방식을 정의
• Data
  시스템이 처리하는 정보를 의미
• Interface
  시스템과 사용자 또는 다른 시스템 간의 상호 작용 방식을 정의

Modeling

모델링은 복잡한 현실 세계를 단순화하고 추상화하여 이해하기 쉽게 만드는 과정

• 시스템 설계의 핵심적인 부분으로, 복잡한 시스템을 이해하고 설계하는 데 있어 필수적인 도구

• 현실세계를 단순화

• 추상화
  복잡도를 관리하기 위해 불필요한 세부 사항을 제거하고 핵심적인 요소만을 강조하는 과정

• 현실세계를 하나의 모델로 표현할 수 없음.

• 관점/목적별 다양한 모델이 존재

• 분석/의사소통/검증의 도구

Software Modeling

• Information Modeling

  • 데이터와 정보에 초점을 맞추며
  • 데이터 엔티티의 개념, 속성, 관계, 제약 조건을 정의
  • Entity Relationship Diagram (ERD), (Domain model) Class diagram

• Behavioral Modeling

  • 소프트웨어의 기능과 행동을 정의
  • 시스템이 어떻게 동작하는지, 다양한 상황에서 어떤 프로세스와 데이터 흐름이 발생하는지를 나타냄
  • Use case model, Activity diagram, Sequence diagram, Statechart diagram, CRUD matrix

• Structure Modeling

  • 소프트웨어의 물리적 또는 논리적 구성을 다룸
  • 소프트웨어의 구성 요소들이 어떻게 조직되고 관련되어 있는지를 보여줌
  • Class diagram, Deployment diagram, Packaging diagram

소프트웨어 개발 방법론

• 구조적 방법론 (Structured)
  • 1970년대, 구조적 프로그래밍에 근간을 둔 절차중심의 방법론
  • Divide & Conquer 원칙, Abstraction, Modularization, Program Logic 에 중점
• 정보공학 방법론 (Information Engineering)
  • 1980년대, 기업의 정보시스템 구축과 경영전략을 지원하는 데 중점
  • 데이터 중심의 분석과 설계를 강조
• 객체지향 방법론 (Object-oriented)
  • 1990년대, 객체지향 언어 등장
  • 실세계를 객체로 표현하며, 프로세스와 데이터를 객체 관점에서 통합하여 분석