Process Activities
소프트웨어 개발 단계는 소프트웨어 공학 게시글에서도 다룬,
- Specification
- Design and implementaion
- Validation(Testing)
- Evolution(Maintenance)
의 4 단계가 있다.
이들은 개발 방식에 따라 조금씩 다르게 구성되곤 하는데, waterfall 방식에서는 일련의 과정으로 구성되지만, incremental development에서는 개별적인 과정으로 구성된다.
Software Specification
소프트웨어의 요구 사항들을 결정하는 것을 말한다.
요구 사항으로는 해당 프로그램에서 꼭 있어야하는 필요 기능과, 프로그램 개발에 있는 제약 사항들이 있을 것이다.
소프트웨어 개발에 들어가기 전에 정확히 무엇을 만들어야하는지를 알고 들어가기 위해 요구사항들을 결정한다.
“자기가 뭘 만드는지도 모르고 개발을 시작할 수가 있나요?”
대략적으로 어떤 시스템을 만드는지는 알아도 시스템 안의 세부적인 내용들을 모를 수가 있다.
예를 들면, 사진을 보여주는 갤러리 어플을 만든다고 하자.▼
‘사진을 보여주는 것’이라는 목표는 단순하지만 너무나도 추상적이다.
사진을 어떻게 보여주는 지에 대한 정보가 하나도 없다.
그렇기에 사진을 보여주는 방법, 보여줄 사진의 확장자, 한 번에 보여줄 사진의 개수 등을 확실히 알고 개발에 들어가야한다.
그래서 아래의 세 과정을 통해 요구사항을 명확하게 분석해야한다.
- 요구사항 도출 및 분석
고객(의뢰인)이 시스템에게 기대하는 점은 무엇인지 알아야 한다. - 요구사항 명세화
요구사항들을 자세히 정의해야 한다. - 요구사항 검증
도출된 요구사항의 내용을 검증해야 한다.
System design and implementation
글 혹은 문서(System Specification)로 써놓은 것을 바이너리 코드로 바꾸는 것을 말한다.
Software design
Software design은 기능 명세를 따르는 소프트웨어 구조(structure)를 고안하는 것을 말한다.
여기서 구조, Structure는 Class라고 이해하면 쉽고, 디자인 한다는 것은 Class를 만드는 것을 말한다.
“Class를 만드는 거면 디자인이 아니라 구현에 가까운 것 아닌가요?”
한 Class의 모든 요소를 만드는 것이 아니라
- Class 이름
- Class 안의 Public 함수들의 이름
- Public 함수의 반환 값
- Public 함수의 매개변수의 타입
- Public 함수의 매개변수의 의미
- Public 함수이 하는 일
을 정의하는 것을 말한다.
즉, 아래와 같이 틀을 짜놓는 것을 말한다.
class Gorani {
private:
char* goraniHouse;
public:
void goraniRunning(int distance) {}
void goraniEating(Food food) {}
};
Implementation
구현 단계는 Public 함수 채우기 단계라고 할 수 있다.
디자인 단계에서 인풋 아웃풋 다 정해놨기 때문에, 이 단계에서는 Public 함수를 채우기만 하면 된다.
디자인 단계에서 많은 것들을 정의해놓고 가기 때문에 구현보다 디자인에서 시간이 더 오래걸리는게 이치상 맞다.
그러면 그냥 Public 함수를 채우면 되는걸까 싶지만, 한 가지 주의해야할 것이 있다.
프로그래밍을 할 때 필요하면 디자인 단계에서 정의하지 않은 함수들이 필요할 때가 있다.
모든 것을 다 디자인 하고 갈 수는 없기 때문에 필연적으로 일어나는 상황이라고 볼 수 있는데, 이런 경우에 private 함수라면 얼마든지 더 넣어도 괜찮다.
추가로 클래스 안에서 쓰게될 구조나 다른 클래스를 더 만들 수도 있다.
하지만 Public 한 건 더 생기면 안된다.
이 이유는 뒤의 Object Orient Programming 파트에서 더 자세히 다룰 것이다.
General Model of Desgin Process
Design Input들을 받아 Design Activities를 수행하면 가장 우리가 원하는 Design Outputs가 나오는 흐름으로 진행이 된다.
Design Input
- Platform Information (플랫폼 정보)
OS나 프로그래밍 언어들에 대한 정보이다.
디자인 이후에 함수를 채우는 과정이 나오는데, 함수를 채울 때 어떤 OS에서 어떤 언어로 구현을 할 지를 정해야하기에 필요하다. - Requirements Specification (요구 사항)
Design Input에서 가장 중요한 것이다.
무엇을 디자인 할 지를 알려주는 가장 중요한 부분이다. - Data description (데이터 정보)
DB정보를 말한다.
DB 스키마와 같은 정보이다.
어떤 데이터를 어떤 형식으로 저장해서 사용할 지를 알려주는 정보이다.
Design activities
- Architectural Design (구조 디자인)
전반적인 구조, 큰 그림을 아키텍쳐라고 부른다.
아래의 그림은 안드로이드 OS의 소프트웨어 아키텍쳐를 표현한 그림이다. ▼
전반적인 서브시스템들, 컴포넌트, 관계가 정의된 아키텍쳐 그림을 만들어야 한다.
- Database design (데이터 베이스 디자인)
데이터에 대한 것들만 뽑아서 er diagram, schema 만드는 것을 말한다. - Interface design (인터페이스 디자인)
컴포넌트들은 완전히 독립적으로 일하지 않는다.
모두 다른 컴포넌트들과 interaction이 있을 것이다.
Interaction이 있다는 것은 다시 말하면 다른 컴포넌트의 함수를 쓴다는 것이고, 이를 정의하는 것을 interface design이라고 한다. - Component selection and design (컴포넌트 선택과 디자인)
컴포넌트는 reusable하면 가져다가 쓰면 되는거고, 그게 없으면 디자인을 새로 한다.
Design Outputs
위의 activities를 수행하면 그에 맞는 Output들이 문서의 형태로 나오게 된다.
이 문서들이 나오면 디자인 과정은 끝이 난다.
System implementation
Programming is a personal activity
“There is no standard programming process.”
프로그래밍에는 특별한 프로세스가 있지는 않다는 말로 구현은 각자의 방법으로 하라는 의미이다.
다르게 말하면 앞에 했던 디자인 과정이 중요한 것이고, 구현을 하는 것은 디자인 만큼 중요하지 않다는 것이다.
지금까지는 구현만 했고, 구현이 가장 중요한 것으로 알았지만 사실 누구나 할 수 있는 것이라는 것이다.
교수님이 제시하는 바람직한 코딩 방향
하지만 그렇다고 대충 코드를 짜면 또 안된다.
아래는 교수님이 제시하는 코드를 모범적인 방안이다.
1. Readable하게 작성해라.
코드를 읽기 쉽게 작성해야한다.
술술 읽히는 코드를 만드는게 핵심이다.
"그렇다면 어떻게 해야 readable하게 코드를 짤 수 있을까?"
가장 쉬운 방법은 convention을 지키는 것이다.
Convention은 naming rule, comment template, 띄어쓰기와 같은 약속을 말한다.
모두가 컨벤션을 지키면서 코딩을 하면 코드를 읽기 쉽다.
2. 남의 코드를 많이 봐라.
다른 사람들이 어떻게 짜는지를 익혀야한다.
잘 짠 코드를 봐야 어떻게 짜야 잘 짜는지를 알 수 있다.
우리가 막 배울 때 짜는 코드는 솔직히 잘 짠 코드라고 하기 힘들다.
그런데 못 짠 코드만 보면 어떤 것이 잘 짠 코드인지 알 방법이 없으므로, 계속 스스로의 코드만 보게 되면 계속해서 못 짠 코드만 보면서 허술한 코드만 학습하게 된다.
그렇기에 다른 잘 짠 코드를 보지 않고 계속해서 변수 이름 대충 짓고, 양식 안지키고 코딩을 하게 되면 잘 짠 코드에 도달할 수 없다.
위에서 바람직한 코딩 방향을 제시해주셨지만, 그럼에도 불구하고 알아서 하는 영역이므로 정해진 답안은 없다고 하셨다.
Debugging
디버깅은 프로그램의 결점을 찾고 그 결점을 고치는 것을 말한다.
버그 위치 찾고, 에러를 어떻게 고칠 지 디자인, 실제로 고침, 그리고 다시 테스트 하는 과정을 거친다.
이 때 두 번째 단계는 에러를 고치는 방법에 대한 디자인이지 디자인 오류를 찾아서 고치라는 것이 아니다.
디자인 오류를 고치는 것은 구현 단계가 아니라 디자인 단계에서 다 하고 넘어와야한다.
Software validation
Verification and validation (V & V)
검증 과 확인이라는 말로 뜻 자체는 거의 유사하다고 할 수 있다.
"그렇다면 어떤 차이점이 있길래 두 단어를 사용하는 것일까?"
차이점은 주체에 있다.
Verification
Verification은 개발자 입장에서 스펙이 맞게 동작하는 지를 말한다.
Validation
Validation은 유저 입장에서 스펙이 맞게 동작하는 지를 말한다.
만약에 유저가 원하는 게 아닌데 일단 잘 만들었다고 해 보자.
그렇다면 Validation에는 좋은게 아니다.
하지만 Verification에는 좋은게 맞다.
개발자들이 정한 스펙에는 맞게 잘 만들었으니 말이다.
Testing Stages
Component testing
Unit test 와 같은 말이다.
각 컴포넌트가 제 기능을 하는 지 확인해보는 것을 말한다.
System testing
전체 테스팅, 다 합친거 테스트라고 보면 된다.
인터페이스 테스팅이라고 보면 된다.
Aceeptance testing
개발회사에서 하는 마지막 테스트를 말한다.
실제 유저가 사용하듯이 테스팅을 수행한다.
유저가 사용하는 시나리오대로 테스팅하는 것을 말함.
알파 테스팅이라고도 한다.
Testing phases in a plan-driven software process
Software evolution
버전 업 하는 것을 말한다.
“한 번 잘 만들면 되는거지 왜 버전 업을 해야되는거죠?”
소프트웨어는 계속 변화해야 하기 때문이다.
비즈니스 설계하는 단계에서 요구 사항들이 바뀌므로 당연히 그에 맞춰 소프트웨어도 바뀌게 된다.
그래서 기존에 있던 시스템들을 평가하고 뭘 추가할 지를 판단한다. ▼
위의 프로세스가 계속 반복되면서 버전업이 된다.
환경
데이터의 타입은 계속해서 성장해나가고 있다.
처음에는 텍스트로만 데이터를 주고 받았다.
이후에는 사진을 저장하게 되었고, 그 사진들을 연속적으로 이어붙여 2d 비디오로 데이터가 확장이 되었다.
심지어 그 2d 비디오도 240 * 360 부터 화질이 계속해서 증가하여 4K 비디오까지 등장하게 되었다.
4K 비디오 그 다음엔 3차원으로 넘어가 vr 데이터들이 등장했고, 아직 등장하지는 않았지만 기술이 발전되면 홀로그램들도 나올것이다.
이렇게 데이터 양이 계속해서 커지고 프로세스 과정도 복잡해지면서 환경이 발전해나가고 있다.
하드웨어 환경만 봐도 CPU, RAM 등등… 이전과 비교하면 말도 안되게 증가했고, 네트워크도 그에 맞춰 발전하여 이제는 8K 비디오 스트리밍도 된다.
이렇게 많이 발전했다.
'CS > 소프트웨어 공학' 카테고리의 다른 글
| 6. Agile (0) | 2024.01.21 |
|---|---|
| 5. Process Iteration (0) | 2024.01.21 |
| 3. 소프트웨어 프로세스 모델 (0) | 2024.01.19 |
| 2. 소프트웨어 공학이란 (0) | 2024.01.19 |
| 1. 소프트웨어 공학 개요 (0) | 2024.01.18 |
