소프트웨어 공학 개론

소프트웨어 공학에 대해 전반적으로 살펴보고 소프트웨어 개발과 공학의 상관관계를 이해한다.

소프트웨어 공학이란?

개념 이해

소프트웨어 공학(Software Engineering)은 소프트웨어를 개발하는 과정에서 발생하는 문제를 해결하기 위한 학문이다. 일반적으로 소프트웨어는 실용적인 측면이 강하지만 소프트웨어 공학은 이론적인 측면이 강하다고 볼 수 있다.

건축이나 자동차 생산을 예로 들때 조그만 단층 집을 짓거나 자동차 한대를 만들어내는 것은 크게 고려할 것이 많지 않지만 대규모 아파트 단지, 100층 이상의 초고층 건물을 짓거나 수천대의 자동차를 생산하는 것은 많은 고려사항이 필요하다.

이러한 고려사항이라는 것은 결국 생산성, 비용, 효율성, 안정성, 성능, 확장성, 유지보수성 등과 같은 문제로 귀결되며 궁극적으로는 비용의 측면에서 산업적 비용 뿐만 아니라 사회적 비용의 측면에서 중요하다.

소프트웨어 공학이란?

소프트웨어 개발의 여러 문제들을 공학적인 방법으로 해결하는 것.

공학(Engineering)은 과학적인 지식을 바탕으로 실용적인 문제를 해결하는 것.
소프트웨어 공학은 개발 프로세스, 방법론, 아키텍처, 도구, 기법등을 모든 것을 포함 한다.
궁극적으로 소프트웨어 개발의 전 과정을 통해 소프트웨어의 품질을 향상시키고, 비용을 절감하며, 개발 기간을 단축시키는 것을 목표로 한다.

SWEBOK

SWEBOK(Software Engineering Body of Knowledge)는 소프트웨어 공학의 지식을 정리한 것으로 소프트웨어 공학의 학문적인 내용을 정리한 것이다. 전통적으로 소프트웨어 공학의 모든 지식 영역을 정리한 것으로 V3에서는 15개의 지식 영역으로 구성되어 있다.

2024년 2월 까지 V4에 대한 최종 리뷰가 진행되고 있으며 18개 영역으로 구성될 예정이다.

본 교재에서는 V4를 기준으로 다음과 같은 영역을 다루게 된다.

Software Requirements(1): 요구 공학
Software Architecture(2): 소프트웨어 아키텍처
Software Design(3): 소프트웨어 설계
Software Engineering Process(10): 소프트웨어 개발 프로세스
Software Engineering Models and Methods(11): 소프트웨어 개발 모델과 방법론
Software Quality(12): 품질 속성

참고자료

프로세스와 방법론

프로세스(Process)는 소프트웨어 개발을 위한 일련의 절차와 활동을 의미하며, 방법론(Methodology)은 프로세스를 수행하기 위한 구체적인 방법을 의미한다. 프로세스와 방법론은 서로 밀접한 관계를 가지고 있으며, 프로세스는 방법론을 통해 수행된다.

SW 개발 생명주기

SDLC(Software Development Life Cycle)는 소프트웨어 개발의 전 과정을 의미하며, 소프트웨어 개발의 생명주기 라고 한다. 소프트웨어 개발 유형과 규모등은 다양하나 일반적으로 다음과 같은 단계로 구성된다.

소프트웨어 개발 생명주기

graph LR
    A[계획] --> B(요구분석);
    B --> C(설계);
    C --> D(구현);
    D --> E(테스트);
    E --> F(배포);
    F --> G(유지보수);

이러한 개발 생명 주기를 어떤 절차로 진행할 것인가에 대한 문제가 프로세스에 해당되며 방법론은 이러한 프로세스를 수행하기 위한 접근법과 원칙, 철학등을 의미한다.

프로세스

소프트웨어 개발 프로세스를 일반화해서 프로젝트에 적용할 수 있도록 만든것이 모델이며 대표적으로 폭포수 모델, 프로토타입 모델, 나선형 모델, 애자일 모델 등이 있다.

1) 폭포수 모델

폭포수 모델(Waterfall Model)은 가장 오래되고 전통적인 프로세스 모델로 개발 생명주기를 단계적으로 수행하는 모델이다. 주요 특징은 다음과 같다.

각 단계는 순차적으로 진행되고 이전 단계가 완료되어야 다음 단계로 진행.
각 단계는 완료되면 다시 돌아갈 수 없다.
관리가 용이하고 단계별 산출물 관리가 용이하다.
요구사항의 변화가 적은 프로젝트에 적합하다.
기간과 비용 산정에 유리 하다.

V 모델

V 모델은 폭포수 모델을 변형한 것으로 각 단계별 검증을 위한 테스트 단계를 추가한 모델이다. 폭포수 모델이 단계별 산출물 중심이라면 V 모델은 단계별 검증 중심으로 오류를 줄이는데 도움이 된다.

2) 프로토타입 모델

프로토타입(Prototype)이라는 용어는 SW 개발 프로세스와 상관 없이 일반적으로도 많이 사용되는 용어 이다. 보통 아이디어나 제품 설계를 검증하기 위한 시작품의 의미로 사용된다.

소프트웨어 개발에서는 초기에 개발할 시스템의 일부분을 빠르게 구현하여 사용자의 요구사항을 확인하는 방법이다. 요구 분석 단계에서 사용자의 초기 요구사항을 파악해 프로토타입을 만들고 고객 평가를 통해 프로토타입에 대한 조정 과정을 거쳐 요구 사항과 구현의 간극을 줄일 수 있도록 설계된 모델이다.

개발자와 사용자 간의 원활한 의사소통을 통해 요구사항을 정확히 파악할 수 있다.
폭포수 모델에서 단계별 역행이 안되는 부분을 설계 단계 이전에 보완할 수 있다.
요구사항의 변화가 많은 프로젝트에 적합하다.
반복적인 개발을 통해 기간과 비용 산정이 어려워질 수 있다.
프로토타입이 완전한 개발이 아니기 때문에 실제 개발 결과물과 차이로 인한 문제가 있을 수 있다.

3) 나선형 모델

나선형(Spiral) 모델은 요구 분석 -> 위험 분석 -> 개발 -> 사용자 평가 과정을 반복하며 점진적으로 개발하는 모델이다. 프로토타입 모델과 유사한 점이 있지만 위험 분석을 통해 위험을 최소화 하고자 하는 모델이다.

중심에서 부터 회전하면서 점진적으로 바깥 영역을 키워 나가는 구조이다.

위험 분석을 통해 프로젝트 중단과 같은 위험을 최소화 할 수 있다.
사용자 평가가 포함된 반복적인 개발을 통해 요구사항의 변화에 유연하게 대처할 수 있다.
반복적 진행으로 인해 프로젝트 기간이 길어질 수 있다.
위험 관리를 위한 전문가 필요등 추가 비용이 발생할 수 있다.

4) UP(Unified Process)

Unified Process는 UML(Unified Modeling Language)을 기반으로 하는 객체지향 소프트웨어 개발 프로세스이다.

반복적(iterative), 점진적(incremental) 소프트웨어 개발 프로세스로 가장 잘 알려지고 많이 문서화된 통합 프로세스가 바로 RUP(Rational Unified Process) 이다. 이외에 공개 모델인 Open UP와 Agile UP등이 있다. UP는 기본적으로 뒤에 나올 애자일 모델이 많은 영향을 끼쳤다.

UP(RUP)의 기본적인 구조는 다음과 같다.

기본적인 SDLC를 점진적으로 반복적으로 수행하는 모델(V, Spiral 모델로 부터 발전).
Inception, Elaboration, Construction, Transition 4개의 Phase로 구성.
각 Phase는 분석 -> 설계 -> 구현 -> 테스트 -> 배포 과정을 반복.
초기 단계에서는 분석, 설계 비중이 높고 후반부로 갈수록 구현, 테스트 비중이 높아짐.
시장의 흐름이 빠르게 변하고 요구사항의 변화가 많은 프로젝트에 적합.
초기 단계에서 부터 어느정도의 구현이 발생하므로 소프트웨어 품질 향상에 도움이 된다.
프로세스 자체가 복잡하고 비용이 많이 들어간다.
제대로 수행되기 위해서는 체계적인 시스템이 필요하며 전문가의 도움이 필요하다.

Note

기본적으로 Phase 가 진행될수록 리스크는 줄어들고 프로젝트의 가치는 증가해야 한다.

5) 애자일 모델

애자일(Agile)은 민첩, 기민, 날렵한 등의 의미를 가지고 있으며 2001년 당시 여러 유명한 개발자들이 모여 발표한 애자일 소프트웨어 개발 선언(Manifesto for Agile Software Development)을 통해 애자일 개발의 원칙이 제시되었다.

당시에는 RUP가 널리 확산되는 시점이었으나 RUP의 복잡성과 비용이 많이 들어가고 개발의 가치보다는 과정과 문서, 산출물을 중시하는 문제점이 제기되었고 이에 대한 대안으로 애자일 개발이 제시되었다. 애자일은 소프트웨어 개발의 핵심 가치를 다음과 같이 제시하고 있다.

프로세스와 도구보다 개인과 상호작용
문서보다 작동하는 소프트웨어
계약 협상보다 고객과의 협력
계획을 따르기보다 변화에 대응하기
환경과 고객의 변화에 능동적인 대처

애자일 프로세스 기반의 다양한 방법론이 존재하며 대표적으로 XP(eXtreme Programming), Scrum, Lean, Kanban, Crystal, FDD(Future Driven Development)등이 있다.

현재의 대표적인 프로세스 모델은 단연 애자일 이라고 할 수 있으며 완전히 정형화된 하나의 프로세스 모델이 아닌 다양한 방법론을 조합하여 사용하는 형태로 많이 사용되고 있다. 보통은 Scrum을 기반으로 XP, Lean, Kanban등을 조합하여 사용한다.

애자일 프로세스는 다음과 같은 특징을 가지고 있다.

SW개발의 궁극적인 목표는 고객이 만족하는 소프트웨어를 개발하는 것이다.
동작 가능한 소프트웨어를 짧으면 2주, 길어도 2개월 이내로 개발하고 고객의 피드백을 수용하여 개발한다.
프로세스가 진행되는 동안 고객과 개발자가 지속적으로 소통하며 요구사항의 변화에 유연하게 대처한다.
빠른 프로토타이핑과 반복적이고 잦은 출시를 목표로함.

방법론

방법론은 프로세스를 수행하기 위한 구체적인 접근법과 원칙, 철학등을 의미한다.

객체지향 방법론이 대표적이며 애자일에서는 스크럼(Scrum)이 유명 하다.

1) OOAD

객체지향 분석 및 설계(Object Oriented Analysis and Design)는 객체지향 프로그래밍을 위한 분석 및 설계 방법론이다. 객체지향 방법론은 객체지향 프로그래밍의 특징을 반영하여 분석 및 설계를 수행한다.

객체지향 방법론은 프로그램을 객체와 객체간의 인터페이스 형태로 구성하기 위해 문제 영역에서 객체, 클래스 및 이들 간의 관계를 식별해 설계 모델로 변환하는 방법론이다.

복잡한 메커니즘의 현실 세계를 인간이 이해하는 방식으로 시스템에 적용하는 개념으로 이를 위해 객체, 클래스, 메시지를 기본 모형으로 제시 했으며 이를 통해 문제 영역을 추상화 하여 모델링 한다.

객체란 real world에서 어떤 구체적 의미를 구성하는 하나의 실제 단위인 특정 object 및 concept 이다.
객체 지향이란 현실세계를 이해하는 방법으로 분석, 설계, 구현에 적용하는 패러다임
객체는 속성(attribute)과 메소드(method)로 구성.
현실 세계로 부터 객체를 추출하고 추상화하려 클래스를 정의하고 관계를 기술해 나가는 것이 객체 모델링
분석 설계의 결과로 모델이 나올 수 있으며 구현을 통해 실체화 된다.

객체지향 개념, 객체지향 프로그래밍 개요는 다음을 참조 한다.

객체지향 개념

객체지향 분석

요구사항에서 객체를 이끌어내는 분석으로 클래스와 객체의 관점 에서 도메인을 분석한다.

도메인 컨셉을 이해하고 객체를 도출
모델은 무엇인가?
현실 세계를 단순화 하고 모델링
추상화된 시스템
모델링은 반드시 기능적, 성능, 안정성을 요구사항으로 하는 측면에서 검토되어야 한다.

왜 모델링을 해야 하는가?

모델을 만들면 개발하고 있는 시스템을 보다 더 잘 이해할 수 있다.
개발하고자 하는 시스템을 보다 시각적으로 표현하여 이해하기 쉽다.
시스템의 구조를 결정하는데 용이하다.
시스템을 만드는데 필요한 가이드가 된다.
모델 문서는 우리가 선택한 결정을 문서화 한 것이다.

객체지향 설계

정적 관점: 소프트웨어 객체들을 정의하는 것.
동적 관점: 요구사항을 충족 시키기 위해 객체들이 어떻게 협력 하는지 정의하는 것.

제공해야 할 기능을 찾고 세분화 하고 그 기능을 알맞은 객체에 할당하는 과정이다. 기능은 최대한 캡슐화하여 구현하고 객체 간에 어떻게 메소드 요청을 주고받을 지 결정한다.

설계 클래스 다이어그램은 도메인에 존재하지 않는 다양한 솔루션 클래스(엔티티, 제어, 데이터 접근) 포함
설계 클래스를 관련 그룹으로 묶어 패키지 다이어그램 작성
클래스 사이의 관계나 속성 이름, 속성 타입, 메소드 스그니처에 대한 정보 파악
설계 클래스 다이어그램의 품질을 높이기 위해 응집도와 결합도 고려

2) 스크럼(Scrum)

스크럼은 애자일 방법론 중 하나로 1995년 Ken Schwaber, Jeff Sutherland가 고안해낸 소프트웨어 개발 프로세스를 위한 가벼운 프레임워크이다. 스크럼은 프로젝트를 여러 개의 반복적인 개발 주기인 스프린트(Sprint)로 나누어 진행한다.

스크럼이라는 용어의 유래

스크럼이라는 용어는 원래 럭비 경기에서 팀원이 서로 한 덩어리가 되어 상대팀과 경합하는 대형을 말하는 것으로 팀의 중요성을 강조하는 의미를 가지고 있다.

기본 개념

소프트웨어 개발 보다는 팀의 개선과 협업을 강조하는 방법론이다.
경험적인 관리 기법으로 구체적이거나 정형화된 틀이 있는 것은 아니다.
매일 15분 정도의 회의를 포함한다.
개발 주기는 1~4주 정도로 짧게 잡고 주기 마다 실제 동작할 수 있는 결과를 제공한다.

Product Owner

제품이나 서비스에 대한 책임자
제품의 비전을 제시하고 고객의 대변인 역할을 수행
Product Backlog를 제시하고 우선순위를 정한다.

Scrum Master

팀을 보호하기 위해 일을 하는 사람
애자일 코치 역할을 수행

Product Backlog

제품의 요구사항 목록
제품의 요구사항을 우선순위에 따라 정렬한 목록
제품의 요구사항을 User Story로 작성한다.
User Story는 과거 요구사항처럼 복잡한 업무 명세가 아닌 사용자가 사용하는 관점에서의 가치를 중심으로 작성한다.

Sprint

반복 개발 주기
각 스프린트 목표에 도달하기 위한 작업 목록을 Sprint Backlog로 작성한다.
스프린트 백로그: 스프린트 목표에 도달하기 위한 작업 목록
일일 스크럼: 매일 15분 정도 어제한 일, 오늘할 일 해결해야할 문제 등을 공유하는 회의.
스프린트 리뷰: 스프린트 마지막 날 개발 내용을 시연하고 검토.
스프린트 회고: 스프린트 마지막 날 좋았던 점, 개선 사항 등을 도출

참고자료

https://scrumguides.org/scrum-guide.html
https://medium.com/hgmin/devops-jira를-활용한-협업-4f4049a36a56
https://github.com/ParabolInc/parabol/projects/2

실습-1

객체 모델링: 현실 세계의 특정 도메인을 대상으로 객체를 추출하고 추상화하여 모델링 하는 과정을 실습한다.

도메인을 선정한다. ex.) 학사관리, 쇼핑몰, 인터넷 뱅킹, SNS 등
주요 객체를 식별한다.
해당 도메인 특성에 맞게 추상화를 통해 클래스를 정의 한다.
클래스 간의 관계를 정의 한다.(상속, 사용, 집합 등)

실습-2

스크럼 프로젝트 생성

GitHub 계정을 만들고 로그인 한다.
https://www.ssw.com.au/rules/scrum-in-github/ 를 참고하여 GitHub Project 사용법을 익힌다.
자신만의 프로젝트 구조를 만들어 본다.