이번 글은 한국공학대학교 노영주교수님의 강의와 황기태의 「 소프트웨어 공학의 모든 것 최은만 생능 2020 」을 바탕으로 작성했음을 밝힙니다.
최대한 이해하기 쉽게 적으나, 아직 글 쓰는 것이 미숙하여 보기 불편하실 수 있으니 양해 부탁드립니다.
목차
0. 서론
1.1 소프트웨어
1.2 소프트웨어 개발 작업
1.3 소프트웨어 공학의 접근법
1.4 소프트웨어 공학의 주제
1.5 관련 분야
1장을 마무리하며 (개인생각)
0. 서론
먼저 소프트웨어 공학을 시작하기 전, 소프트웨어의 주기(SW lifesycle)에 대해 알면 좋다.
SW lifesycle이란?
- 소프트웨어가 만들어지고, 업데이트되고, 삭제되기까지의 과정을 말한다. (소프트웨어의 데이터 처리 기능인 CRUD를 생각하면 될 것 같다.)
SW lifesycle은 다음과 같이 진행된다.
Dream, need -> idea -> SW -> Svc -> User
1. 꿈, 목표와 필요성을 찾는다.
2. 1번의 내용을 아이디어로 구체화 시킨다.
3. 해당하는 아이디어를 SW로 구체화 시킨다. (여기까지 진행하는 경우도 있으나, 요즘은 Svc까지 진행하는 경우가 많다.)
4. 사용자에게 서비스를 진행한다
이때 Dream,need -> idea부분은 idea engine, 즉 창의적공학설계에 해당하는 부분이며 SW부분은 SE, 우리가 배울 소프트웨어 공학에 해당하는 부분이다.
즉, 우리는 이 소프트웨어 공학을 통해 SW에서 사용되는 여러 내용을 배울 예정이다.
1.1 소프트웨어
서론에서 해당하는 아이디어를 SW로 구체화시키는 것이 소프트웨어 공학이라고 하였다. 그럼 SW는 뭘까?
책에서 소프트웨어는 다음과 같이 정의한다
소프트웨어의 정의
1. 프로그램의 개발, 운용, 보수에 필요한 정보 일체
2. 개념적이고 논리적이나 무형적(생산물의 구조가 코드 안에 숨어 있음)
다음 내용을 설명하기 전, S/W의 반대는 무엇인가? 바로 H/W, Hardware이다.
하드웨어와 소프트웨어... 비슷하지 않는가? 딱딱한 물체, 즉 만질 수 있는 장치이기 때문에 하드웨어라 불리는 것이다.
소프트웨어는 반대로 못만지는, 무형적인 물체이기에 소프트웨어이다. 그래서 하드웨어의 장치들을 작동하게 만드는 코드들을 소프트웨어에서 진행하기에 개념적이고, 논리적이란 말이 나오는 것이다.
소프트웨어의 특징
– 비가시성(invisibility)
– 유연성(flexibility)
– 순응성(conformity)
– 변경성(changeability)
– 복잡성(complexity)
크게 5가지의 특징이 있으나 다 연관되어 있다.
먼저 소프트웨어, 안보이고, 부드러워 소프트란 이름을 가진 만큼 보이지 않는다. 그리고 코드를 짤때 길이 한가지가 아닌 여러 방식으로 코드를 짤 수 있다.
예를 들어서 "Hello World!"를 3번 출력한다 해보자.
class Hello {
public static void main(String[] args) {
// 1. 3번 출력
System.out.println("Hello, world.");
System.out.println("Hello, world.");
System.out.println("Hello, world.");
// 2. for문을 이용한 출력
for (int i = 0; i < 3; i++) {
System.out.println("Hello World!");
}
// 3. while문을 이용한 출력
int count = 0;
while (count < 3) {
System.out.println("Hello World!");
count++;
}
}
}
이처럼 가장 단순 출력만 해도 여러가지 방법으로 유연하게 할 수 있다. 그리고 코드를 한번 작성하면 끝나는 것이 아닌, 사용자의 요청에 따라, 하드웨어의 성능에 따라 상황에 순응하여 코드를 변형할 수 있다. 이렇게 만들어진 코드는 나중에 보면 엄청나게 복잡하다. 그래서 오류가 날 가능성도 있고, 이를 해결하기 위해 리팩토링도 하고, 유지/보수를 하는 것이다.
소프트웨어의 유형
책에서는 다음과 같은 방식으로 유형을 분류한다.
| 소프트웨어 분류 | 특징 | 사용되는 카피의 수 | 요구되는 하드웨어 성능 |
개발 인력 |
| 주문형 소프트웨어 | 특정 고객 또는 기업의 요구를 만족시키기 위해서 제작된 소프트웨어 |
적음 | 낮음 | 많음 |
| 패키지 소프트웨어 | 패키지화 하여 상업적으로 판매하는 소프트웨어 ex) 워드프로세서, 스프레드시트, 구글시트, 한글 등 |
중간 | 높음 | 중간 |
| 임베디드 소프트웨어 | 다른시스템에 내장된 소프트웨어 | 많음 | 중간 | 적음 |
다음과 같은 방식으로 분류하는 경우도 있다.
Application SW가 가장 넓은 범주로 있고 그 밑에 Technology SW, System SW가 있는 것이다.
여러가지 분류 방식이 있기때문에, 이 분류방식은 틀렸다! 라고 하지 말고 관점이 다르다. 라고 생각하면 좋겠다.
소프트웨어 시스템
소프트웨어 시스템은 책에서 다음 그림과 같은 시스템으로 이루어져 있다 말한다.
입력을 주면 시스템에서 주어진 입력값에 맞추어 출력을 하는, y = F(x)와 같은 함수역할을 하는 것이라 생각하면 된다.
1.2 소프트웨어 개발 작업
소프트웨어는 어떤식으로 개발이 되는가?
책은 다음과 같은 주기로 기본 활동이 이루어 진다 말하고 있다. SW lifesycle의 내용과 매우 비슷하며, 특이사항으로는 유지보수의 기간이 가장 길다는 것이다.
개발 작업의 특징
- 명세화의 어려움
- 재사용의 어려움
- 예측의 어려움
- 유지보수의 어려움
명세화란 어떤 요구사항을 가져와 프로그래머가 자기 기술로 작업을 시작할 수 있는 시점까지 정리하는 과정이다. 이미 있는걸 명세화 시키긴 어렵지 않다. 하지만, 없는걸 명세화시켜서 작업을 하는건 매우 어렵다. 콜럼버스의 달걀처럼 누구나 할 수 있음에도, 그것을 구체화 하는건 어렵다.
객체지향언어인 python, java, c++ 등은 코드를 재활용하기 용이하게 언어가 만들어졌으나, 절차지향적언어인 c, basic 등의 경우에는 그렇지 못하다. 그렇기에 비슷한 프로그램을 만들기 위해선 다시 코드를 작성해야 하는 불상사가 일어나기도 했다.
코드를 작성하다보면 이게 왜 되는거지? 이게 왜 안되는 거지? 라는 소리를 해본적이 있을 것이다. 단순한 프로그램을 짜는데도 이러한 상황이 일어난다. 실제로 프로그램을 배포하면 어떤 버그가 튀어나올지 모른다. 즉, 예측하기가 매우 어렵다.
유지보수를 어떤걸 해야할지, 어디서부터 시작해야할지 판단하고, 찾고, 다른 코드에게 영향이 없는지 증명을 해야하는 것에 대한 어려움이 있다. 그래서 git같은 형상관리툴에서는 branch, merge와 같은 기능이 생겼다고 할 수 있다.
소프트웨어 위기(software crisis)
1960년대 말, 다익스트라가 소프트웨어 위기에 대해 언급하였다고 한다.
옛날에는 프로그램을 작성할 때 goto를 즐겨 썻다고 한다. goto 문법은 프로그램의 흐름을 원하는대로 바꿀 수 있다. 지정된 곳으로 바로 이동하기 때문에, 오류가 날 가능성이 높다. 이런 상황에서 수요는 높아지고 원하는 프로그램의 복잡성은 증가했으나, 기존의 방법이 충분하지 않아 발생한 문제이다.
1.3 소프트웨어 공학의 접근법
백준, 코드잇과 같은 문제풀이 사이트에 대해 작성하는 코드들은 대부분 즉흥적인 소프트웨어 개발일 것이다.
일단 해보고, 안되면 수정하고, 고민하다가 다시 해보고... 이를 반복하는 것을 즉흥적인 소프트웨어 개발이라 한다.
이런 즉흥적인 개발에는 어떤 문제가 있을까?
개발 시간도 못맞추고, 예산도 초과되고, 품질은 좋지 않으며 유지보수도 힘들 것이다. 이런 상황을 방지하기 위해 소프트웨어 공학이란 개론이 있는 것이다.
지금까지 반복해서 소프트웨어 공학에 대해 말하였지만 다시 정의를 내린다면 다음과 같다.
소프트웨어 공학 : 소프트웨어의 개발과 운영, 유지보수, 소멸에 대한 체계적인 접근 방법
그러면 소프트웨어 공학을 통해 하고자 하는건 뭘까? 위에서 말했던 즉흥적인 소프트웨어 개발의 반대이다.
소프트웨어 공학의 목표
- 복잡도 낮춤
- 비용 최소화
- 개발 기간 단축
- 대규모 프로젝트 관리
- 고품질 소프트웨어
- 효율성
여러가지 원리와 방법을 적용하여 품질좋은 소프트웨어를 최소의 비용으로 계획된 일정에 맞춰 개발하는 것이 최종적인 목표라고 할 수 있다.
이를 위해선 여러가지 원리와 방법을 알아야 한다. 그중 하나인 폭포수모델(waterfall model)이다.
폭포수 모델이란?
폭포수 모델(Waterfall Model)이란 소프트웨어 개발 시 단계적으로 개발하는 방법론을 말한다. 분석→설계→개발(디자인→퍼블리싱→프로그래밍)→테스트→적용→안정화의 단계를 따른다. 앞 단계가 먼저 완료되어야 다음 단계의 개발을 진행할 수 있는 것이 가장 큰 특징이다.
책에서는 요구분석 -> 설계 -> 코딩 -> 텍스팅 -> 유지보수 단계로 진행이 된다. 그리고 각 단계가 진행되기 전 확인을 하고 단계에 맞추어 진행 후 검토한다.
검토와 확인의 차이
확인 : evaluation 확인은 요구분석 명세서가 조건에 맞는지, 원시코드가 맞는지, 소프트웨어가 잘 돌아가는지 확인
검토 : verification 검토는 요구분석이 요구분석명세서에 부합하는지, 설계가 정확한지 다시한번 검토하는 것
둘의 뜻이 완전히 다르니 주의!!
프로젝트 관리
프로젝트를 시작했으면 프로젝트 관리 또한 중요하다. 프로젝트를 하게 될 경우 제약조건이 따라올 수 밖에 없는데, 시간, 비용, 범위 이 3개에 의해 만드는 프로젝트의 품질 또한 결정 된다 볼 수 있다.
핵심 키워드 : 시간, 비용, 범위
- 프로젝트 계획
- 자원 관리
-리스크 관리
- 프로젝트 수행과 모니터링
소프트웨어 공학의 연구 결과
책의 표는 다음과 같이 설명한다. 하지만, 소프트웨어 공학은 시간이 지남에 따라 발전함으로 이 또한 하나의 시험을 위한 자료라 봐주면 감사하겠다.
| 주제 | 의미 | 사례 | 요리에 비유 |
| 방법 (method) |
소프트웨어 제작에 사용되는 기법이나 절차 | - 구조적 분서, 설계방법 - 객체지향 분석, 설계 방법 |
익히는 방법 (구이, 찜, 훈제 등) |
| 도구 (tool) |
자동화된 시스템 | - 설계 도구 - 프로그래밍 도구 - 테스트 도구 |
요리 도구 (프라이팬, 압력 솥, 오븐 등) |
| 프로세스 (process) |
도구와 기법을 사용하여 작업하는 순서 | - Unified Process - eXtreme Programming |
조리 순서(레시피) |
| 패러다임 (paradigm) |
접근 방법, 스타일 | - 구조적 방법론 - 객체지향 방법론 |
음식 스타일 (한식, 일식, 중식, 퓨전 등) |
1.5 연관 분야
두 가지 분야
- 컴퓨터 공학의 원리나 기술에 관련된 여러 원리
- 이를 적용하여 특정한 문제를 해결하려는 응용 도메인
결국 소프트웨어 공학 자체는 개발과 관련된 모든것을 아울러서 소프트웨어 공학이라고 한다.
1장을 마무리하며
이번 1장에선 소프트웨어공학이 뭔지, 앞으로 뭘 해야 하는지 대략적으로 설명하는 내용인 것 같다.
소프트웨어 공학은 결국 프로젝트를 만드는 모든 과정에 대한 학문을 알리는 것이 가장 중요하다는 것 같다. 이번 1장을 정리하며, 크게 배웠다 라는 느낌은 없고, 지금까지 알고 있던 개념을 복습한 것 같다.