🚩 출처: 인프런 - 일주일 만에 소프트웨어 요구사항 제대로 이해하기
소프트웨어란 무엇인가?
하드웨어 = 컴퓨터 → 계산기
소프트웨어 → 계산 방법
계산이 뭘까? 계산이 눈에 보이는가?
보이지 않는다
→ 소프트웨어는 생각이다
소프트웨어 요구사항 = 생각의 요구사항
눈에 보이지 않는 것을 요구사항으로 만드는 것은 매우 어렵다.
소프트웨어 vs 프로그램
Software = Program + B소프트웨어 = 소스 코드 + 데이터 + 문서
- 1부터 100까지 더하기 → 모호성 없음 (B=0)
- 모호성이 없을 때 프로그램이라고 한다.
- AI 소프트웨어를 설명할 수 있는가? → 모호하다
→ 소프트웨어의 모호성을 없애기 위해 요구사항을 분석한다.
소프트웨어는 시스템인가?
시스템이란?
요소들이 모여서 하나 이상의 목적을 완전히 달성하는 것
소프트웨어만으로 완전한 목적을 달성할 수 있는가?
→ 계산기(하드웨어)가 있어야 동작할 수 있다. 소프트웨어는 자체적으로 시스템일 수 없다.
어느것에 더 큰 영향을 받는가?
- 소프트웨어 중심 시스템: 스마트폰 앱, 웹 서비스 등
- 하드웨어 중심 시스템: 임베디드 시스템, 제어 시스템 등
개발 방법론
생각은 어디서부터 나오는가?
언어로부터 생각이 나온다.
소프트웨어 = 생각 ← 언어(자연어) = 말 + 그림소프트웨어는 눈으로 확인할 수 없다.
오로지 언어로 파악할 수 있기 때문에 언어를 마음대로 써선 안된다.
따라서 언어는 소프트웨어에 엄청난 영향을 미친다.
가장 많이 쓰는 언어는 명사, 동사
- 명사 = 사물의 정적인 모습을 묘사
- 동사 = 사물의 동적인 모습을 묘사
이를 바탕으로 개발 방법론이 생겨났다.
1. 객체지향 개발방법론
- 명사를 중심으로 생각을 정리해서 소프트웨어를 만드는 방법론
- 예시: C++, Java에서 클래스 이름을 다 명사로 작성
- 장점: 유지보수가 편함 (명사는 동사보다 변경이 적음)
2. 절차적 개발방법론 (= 함수적 개발방법론)
- 동사(언어)를 중심으로 생각을 정리해서 소프트웨어를 만드는 방법론
- 예시: 함수 이름은 동사로 작성
- 특징: 시간순서마다 이벤트가 발생 → 동사 중심
소프트웨어는 시간이 지나도 썩지 않는다
→ 유지 보수가 매우 중요!
소프트웨어 요구사항이 변한다면?
- 절차적 개발방법론: 2) 3) 4)와 같이 절차를 고침
- 객체지향 개발방법론: 명사 하나만 고치면 됨
동사 < 명사가 변하는 경우가 더 많다
→ 객체지향이 유지보수에 더 유리
소프트웨어 개발 방법
소프트웨어 = 생각
어떤 방법으로 언어를 생각으로 정리해서 소프트웨어를 만들 것인가?
1. 모델링
모델이란?
진짜가 아닌데 진짜같이 보이는 것(Representation, Abstraction)
- 진짜를 만들 때 시간, 비용이 많이 든다
- 소프트웨어의 진짜가 뭔지 알기 어렵다
초기 단계
요구사항 분석 모델 → 소프트웨어
소프트웨어의 진짜란?
소프트웨어(프로그램)가 컴파일되어 실제 컴퓨터 위에서 실행되는 것
소프트웨어는 컴파일(컴파일러) & 실행(OS)이 자동화
그럼 소프트웨어의 진짜는? = 프로그램 (Source Code)
요구사항 분석 모델을 보는 순간 소스 코드가 보여야 한다.
사용자 입장에서 쓰여있는 동사, 명사가 클래스, 함수명이 되어야 요구사항이 제대로 된 것이다.
작명: 요구사항 분석할 때 50% 이상 결정난다.
모델의 특성
- 소프트웨어가 아닌 모델들은 다 정형 모델
- 형태가 있기 때문에 표현하기 쉽다
- 소프트웨어는 비정형 모델
→ 언어를 통해 형태 그림을 그리는 형태로 가야함
모델링 종류
함수적 모델 vs 객체지향적 모델
- 함수 변환: g(f(x)) → 동사와 동사, 예) C, Go
- 객체 간 연동: x.f().g() → x(클래스명), 명사가 먼저, 예) Java, C++
1) 함수적 모델
기능 분할도(Functional Decomposition)
- 함수 내를 역할과 목적에 따라 서브 함수를 분리하는 방법
- 역할과 목적을 나눠서 표현
- 동사를 어떻게 나눌 것인가
전체 시스템
├── 입력 처리
├── 데이터 변환
└── 출력 생성자료 흐름도(Data Flow Diagram)
- 시스템에서 데이터가 어떻게 흐르고 변환되는지 보여주는 다이어그램
- 프로세스, 데이터 저장소, 외부 엔티티, 데이터 흐름을 표현
출처: Wikimedia
| 구성 요소 | 설명 |
|---|---|
| 원(○) | 프로세스 |
| 화살표(→) | 데이터 흐름도 |
| 직선(단선/이중선) | 자료 저장소 |
| 사각형(□) | 단말(Terminator |
2) 객체지향적 모델
유스케이스(Use Case)
- 요구사항을 기반으로 구분하여 작성한 다이어그램
- 액터와 시스템과의 관계를 표현함
- 그 외에 UML 다이어그램 존재
출처: Wikimedia
UML(Unified Modeling Language) 다이어그램 종류
- 클래스 다이어그램
- 시퀀스 다이어그램
- 활동 다이어그램
- 상태 다이어그램 등
2. 프로세스
모델링과 프로세스는 한 몸이다.
소프트웨어 개발 프로세스 정의: 사용자의 요청(Concerns)을 받아 소프트웨어 시스템을 개발하는 해야 되는 일의 순서를 정의하는 것
사용자의 필요성 → 소프트웨어 개발 프로세스 → 소프트웨어 시스템소프트웨어 트렌드
보다 큰, 복잡한, 다양한, 어려운 시스템으로 가고 있다.
프로세스를 어떻게 진행할 것인지 정해져 있지 않음.
어떻게 진행할지 정하는 것이 모델링.
소프트웨어 개발 생명 주기(SDLC, Software Development Lifecycle)
필수 단계
-
분석
- 주어진 데이터를 나눠서 목적을 달성하는 것
- 요구사항 수집 및 분석
- 시스템의 기능적/비기능적 요구사항 정의
-
설계
- 구현하는 방법을 미리 정의
- 시스템 아키텍처 설계
- 데이터베이스 설계, UI/UX 설계
-
구현
- 실제로 만드는 것
- 코딩 및 프로그래밍
- 단위 모듈 개발
-
테스트
- 성공/실패를 구분
- 단위 테스트, 통합 테스트, 시스템 테스트
- 버그 발견 및 수정
소프트웨어 개발 모델
폭포수(Waterfall) 모델
출처: Wikimedia
- 분석 → 설계 → 구현 → 테스트 순서와 시간이 일치
- 문제점: 소프트웨어는 비정형화되어 있기 때문에 설계→구현을 해봐야 알 수 있음
- 요구사항 변경이 어려움
- 각 단계가 순차적으로 진행
나선형(Spiral) 모델
출처: Wikimedia
- 위험 분석을 중심으로 한 점진적 개발
- 반복적 개발: 계획 → 위험분석 → 개발 → 평가 → 다음 반복
- 위험 요소를 조기에 발견하고 해결
- 대규모 프로젝트에 적합
애자일(Agile) 모델
- 반복적이고 점진적인 개발
- 짧은 개발 주기(스프린트)
- 고객과의 지속적인 소통
- 변경에 유연하게 대응
- 스크럼, 칸반, XP 등의 방법론
V-모델
출처: Wikimedia
- 개발 단계와 테스트 단계를 대응시킨 모델
- 각 개발 단계에서 검증 활동을 강조
- 요구사항 → 시스템 테스트, 설계 → 통합 테스트
