Key Takeaway Points
- S/E은 소프트웨어 비용과 출시 기간을 줄이면서 소프트웨어 생산성과 퀄리티를 높이는 것을 목적으로 한다.
- S/E은 소프트웨어 개발, 소프트웨어 품질 보증, 소프트웨어 프로젝트 관리 활동, 이 3가지 트랙이 상호작용하는 life-cylce로 구성된다.
- Object-Oriented(OO) S/E은 S/E의 전문 분야다. 세상과 시스템이 서로 상호작용한다고 본다.
컴퓨터 사용이 확대되는 원동력은 시장 경제이지만, 컴퓨터를 우리가 원하는 방식으로 작동할 수 있는 것은 소프트웨어다.
1. What is Software Engineering?
소프트웨어 시스템은 복잡한 지적 산물이다. 소프트웨어 개발은 소프트웨어 시스템이 요구사항을 충족하고 예산이 초과되지 않으며 시스템이 일정에 따라 제공되도록 보장해야 한다.
S/E은 소프트웨어 비용과 출시 기간을 줄이면서 소프트웨어 생산성과 소프트웨어 품질을 크게 향상시키기 위한 공학적 프로세스 및 방법의 연구, 교육, 적용에 중점을 둔다.
소프트웨어 생산성(Productivity), 품질(Quality) ↑
소프트웨어 생산 및 운영 비용(Cost), 시장 출시 시간(Time) ↓
→ 소프트웨어 엔지니어링의 목표 : PQCT
PQCT 달성을 위한 S/E 프로세스 및 방법에 대한 연구, 교육, 응용은 개발, 품질 보증, 프로젝트 관리 활동 세 가지로 분류된다.
- 개발
초기 시스템 개념을 운영 체제로 변환 - 품질 보증
개발이 올바르게 수행되고 활동에 의해 생성된 산출물이 올바른지 확인함으로써 원하는 소프트웨어 시스템이 생산되고 제공되도록 보장 - 프로젝트 관리
프로젝트를 계획하고, 개발 및 품질 보증 활동에 자원을 할당하며, 시스템이 제때에 그리고 예산 내에서 개발되고 제공되도록 함
2. Why Software Engineering?
-
많은 임베디드 시스템의 경우 소프트웨어 비용이 20년 전 5~10%에서 전체 시스템 비용의 90~95%로 증가했다. 일부 임베디드 시스템은 ASIC과 firmware를 사용한다. 이들은 대체하는데 비용이 많이 들고, 그래서 소프트웨어의 품질이 매우 중요하다. 이들은 시스템 개발에 대한 소프트웨어 엔지니어링 접근 방식을 요구한다.
ASIC(Application-Specific Integrated Circuit) : 특정한 어플리케이션에 맞게 디자인되어 다른 용도로 사용할 수 없는 고유한 기능을 갖는 집적 회로
Firmware : 특정 하드웨어 장치에 포함된 소프트웨어로, 하드웨어의 제어와 구동을 담당하는 소프트웨어라고 한다. -
대규모 시스템 개발에 필요한 팀워크를 지원한다. 대규모 소프트웨어 시스템은 설계, 구현, 테스트에 상당한 노력을 필요로 한다. 둘 이상의 소프트웨어 엔지니어가 협력하여 소프트웨어 시스템을 개발하면 심각한 개념화, 의사소통 및 조정 문제가 발생한다.
개념화(Conceptualization)은 시스템이 구축되는 응용 프로그램을 이해하는 것을 돕기 위한 지적 모델을 형성하기 위해 실제 현상을 관찰하고 분류하는 과정이다. 소프트웨어 엔지니어들은 교육, 문화 배경, 직업 경험, 가정 및 기타 요인의 차이로 인해 세상을 다르게 인식할 수 있다. 이 책에 제시된 모델링 기술은 소프트웨어 엔지니어가 응용 프로그램의 영역과 비즈니스 프로세스에 대한 공통된 이해를 확립하도록 돕는다.
소프트웨어 엔지니어 팀이 함께 일할 때, 그들은 그들의 이해와 설계 아이디어를 교환할 필요가 있다. 소프트웨어 공학은 소프트웨어 엔지니어가 그들의 아이디어를 전달할 수 있도록 통합 모델링 언어 (UML)를 제공한다. 이 책에서 제시하는 애자일 통합 방법론은 소프트웨어 엔지니어들이 모두가 이해하고 따르는 방식으로 협력하도록 한다.
3. Software Life-Cycle Activities
아래 3가지 활동은 소프트웨어 라이프 사이클 전체에 걸쳐 동시에 이루어진다.
-
소프트웨어 개발 프로세스
소프트웨어 개발 프로세스는 초기 시스템 개념을 대상 환경에서 실행되는 운영 체제로 변환한다. 비즈니스 요구 사항을 파악하고, 타당성 조사를 수행하며, 시스템이 제공해야 하는 요구 사항이나 역량을 공식화한다. 또한 대상 환경에 시스템을 설계, 구현, 테스트 및 배포한다. -
소프트웨어 품질 보증
소프트웨어 품질 보증(SQA : Software Qualitiy Assurance)은 개발 활동이 제대로 수행되는지 확인하며, 개발 활동을 통해 생산된 소프트웨어 산출물이 소프트웨어 요구 사항과 원하는 품질 표준을 충족한다. -
소프트웨어 프로젝트 관리
소프트웨어 프로젝트 관리는 개발 및 품질 관리 활동의 제어 및 관리를 감독한다. 프로젝트 관리 활동에는 노력 추정, 프로젝트 계획 및 스케줄링, 위험 관리 및 프로젝트 관리 등이 포함된다. 이러한 활동은 소프트웨어 시스템이 제때에 그리고 예산 내에서 전달되도록 보장한다.
3.1. Software Development Process
소프트웨어 프로세스는 소프트웨어 시스템을 생산하기 위해 수행되는 일련의 활동 단계로 구성된다. 예를 들어 통신 시스템, 메일 처리 시스템, 산업 프로세스 제어 시스템 및 의료 장치는 이벤트를 처리하고 하드웨어를 제어하기 위해 소프트웨어를 사용한다. 이러한 시스템을 임베디드 시스템(embedded system)이라고 한다. 이러한 경우에 소프트웨어 프로세스는 시스템 개발 프로세스 또는 시스템 엔지니어링 프로세스라고 하는 더 큰 프로세스의 일부이다. 시스템 엔지니어링은 소프트웨어 시스템 단독이 아니라 전체 시스템을 고려한다. 소프트웨어 엔지니어링의 역사 동안 많은 소프트웨어 프로세스 모델이 제안된다. 그 중에는 폭포수, 프로토타이핑, 진화, 나선형, 통합 및 애자일 프로세스가 있다.
전통적인 엔지니어링 분야를 차용한 잘 알려진 전통적인 폭포수 프로세스를 보여준다. 프로세스는 시스템 엔지니어링 활동, 즉 시스템 요구 사항 정의, 시스템 설계 및 시스템 요구 사항 할당을 고려한다.
폭포수 프로세스의 단계는 아래에 설명되어 있다.
시스템 요구사항 정의, 시스템 설계 및 할당
임베디드 시스템에 대해 종종 수행되는 시스템 엔지니어링 활동이다. 시스템 요구사항 정의는 전체 시스템에 대한 능력을 파악하여 시스템 요구사항으로 공식화한다.
예를 들어, 무선 통신 시스템(RCS)을 위해 시스템 개발을 고려한다. 시스템은 셀룰러 네트워크에서 셀보다 훨씬 큰 영역을 서비스하는 단 하나의 고출력 기지국을 가지고 있다는 점을 제외하고는 셀룰러 네트워크와 유사하다. 시스템 요구사항은 전체 시스템에 대한 기능을 지정한다. 다음은 확인된 많은 시스템 요구사항 중 네 가지이다.
R1. RCS는 이동 가입자가 다른 이동 가입자 및 유선 전화에 대한 통화를 개시할 수 있도록 허용해야 한다.
R2. RCS는 이동 가입자가 다른 가입자로부터의 통화에 응답할 수 있도록 허용해야 한다.
R3. RCS는 이동 통화 및 요금 청구서를 캡처 및 기록하기 위한 통화 계정을 가입자 계정에 제공해야 한다.
R4. RCS는 승인된 계정 관리자가 하위 가입자 계정을 관리할 수 있도록 허용해야 한다.
시스템 설계는 전체 시스템의 주요 하위 시스템을 결정하고 하위 시스템 간의 관계를 지정한다. 이들은 시스템 아키텍처 설계도로 묘사된다. 그림 1.3은 블록 다이어그램을 사용하여 RCS에 대한 아키텍처 설계를 나타낸다. 이는 모바일 유닛, 기지국, 계정 관리의 세 가지 하위 시스템을 묘사한다.
할당 활동은 시스템 요구사항들을 서브시스템들에 할당한다. 시스템 설계 및 할당은 비교적 독립적이고 인터페이스하기 쉬운 서브시스템들을 초래해야 한다. 시스템 할당은 시스템 요구사항들을 하위 수준의 요구사항들로 분해하여 별개의 서브시스템들에 할당할 수 있다.
소프트웨어 요구사항 분석
소프트웨어 요구사항 분석은 소프트웨어 시스템에 할당된 시스템 요구사항을 구체화한다. 소프트웨어 시스템에 대한 다른 기능도 파악한다. 이들과 정제된 시스템 요구사항은 소프트웨어 요구사항 규격(SRS)에 명시되어 있다.
컨트롤러 계층에서, 컨트롤러는 Account 객체를 생성하고, 데이터베이스 계층을 통해 데이터베이스에 저장한다. 이는 각 계층의 기능이 구현 및 사용하기에 비교적 용이함을 보여준다. N-tier 아키텍처의 또 다른 장점은 계층 간 인터페이스가 변경되지 않는 한, 계층으로의 변경이 다른 계층에 미치는 영향이 거의 없다는 것이다.
소프트웨어 설계
소프트웨어 설계는 소프트웨어 시스템의 소프트웨어 아키텍처, 즉 전체 구조를 결정한다. 이는 하위 시스템, 이들의 관계, 하위 시스템의 기능, 인터페이스 및 하위 시스템이 서로 상호 작용하는 방법을 지정한다. 사용자 인터페이스의 설계는 소프트웨어 설계의 또 다른 중요한 활동이다. 즉, 창과 대화 상자의 모양과 느낌을 묘사하고 시스템이 사용자와 어떻게 상호 작용하는지 설명한다. 소프트웨어 설계는 정보 처리 알고리즘도 지정한다.
RCS의 아키텍처 설계의 예로 그림 1.4는 계정 관리 시스템을 위한 N-tier 아키텍처를 나타낸다. 아키텍처는 클래스 또는 객체를 별도의 계층으로 구성한다. 각 계층에는 명확하게 정의된 책임이 있으며 다음 계층의 서비스를 요청한다.
예를 들어 사용자/장치 인터페이스 계층은 계정 관리자와 소프트웨어 컨트롤러에게 서비스를 제공한다. 이는 컨트롤러 계층의 서비스를 사용한다. 계층 구조는 비즈니스 프로세스의 구현을 단순화한다. 예를 들어 계정 관리자가 계정을 생성하고자 할 때 사용자 인터페이스는 요청을 생성 계정 컨트롤러에게 전달한다
구현, 테스트 및 유지보수
구현 및 단위 테스트 단계에서는 설계를 구현하기 위해 프로그램이 작성된다. 프로그램은 테스트되고, 코딩 표준에 대한 정확성 및 준수를 보장하기 위해 동료에 의해 검토된다. 통합 단계에서는 프로그램 모듈이 통합되고, 서로 작동하는지 확인하기 위해 테스트된다. Acceptance 테스트 중에는 테스트 케이스가 설계되고 실행되어 소프트웨어가 실제로 소프트웨어 요구 사항을 충족하는지 확인한다. 소프트웨어 시스템은 이후 대상 환경에 설치되고 사용자에 의해 테스트된다. 소프트웨어는 유지보수 단계로 진입한다. 유지보수 단계에서는 시스템이 교체될 때까지 수정, 개선 및 개선이 지속적으로 이루어진다.
3.2. Software Qualitiy Assurance
소프트웨어 품질 보증 SQA는 개발 중인 소프트웨어 시스템이 소프트웨어 요구 사항 및 원하는 품질 표준을 충족할 것을 보장한다. verification, validation 및 testing은 이러한 목표를 달성하기 위한 수단이다.
verification은 소프트웨어 프로젝트를 위해 선택된 소프트웨어 프로세스 및 방법에 따라 개발 활동이 수행되는 것을 보장한다. 또한 필요한 소프트웨어 산출물이 생산되고 품질 표준을 준수하는지 확인한다.
validation은 개발 활동에 의해 생산된 소프트웨어 산출물의 정확성을 확인한다. 예를 들어, RCS에 대한 검증은 시스템 및 소프트웨어 요구사항이 실제 비즈니스 요구사항을 명시하는지 확인한다. 또한 시스템뿐만 아니라 소프트웨어 설계가 요구사항 및 제약사항을 충족하는지 확인하고 구현된 소프트웨어 시스템은 의도된 비즈니스 문제를 해결한다.
validation 활동은 static validation과 dynamic validation 활동으로 분류된다.
- static validation은 소프트웨어를 실행하지 않고 소프트웨어 산출물의 정확성을 확인한다. 요구사항 사양 및 소프트웨어 설계 문서와 같이 실행 가능하지 않은 산출물에 적용할 수 있다.
- dynamic validation은 소프트웨어가 작동하고 올바른 결과를 생성하는지 확인하기 위해 소프트웨어를 실행한다. 소프트웨어 테스트는 dynamic validation 기술이다. 테스트 케이스를 사용하여 소프트웨어를 실행하고 테스트 결과가 예상되는 결과와 일치하는지 확인한다. 자동차가 실제로 기능 및 성능 요구사항을 충족하는지 확인하기 위해 시운전하는 것과 유사하다.
Unit 테스트는 인터페이스, 컨트롤러, 비즈니스 객체, 데이터베이스 및 네트워크 계층의 클래스 각각이 클래스의 기능을 올바르게 구현하는지 확인하기 위해 테스트 케이스를 생성한다. → 개별 함수, 개별 클래스 테스트
Integration 테스트는 이러한 클래스가 서로 작동하는지를 테스트하고 보장하기 위해 테스트 케이스를 생성한다. → 클래스 간 상호작용
Acceptance 테스트는 시스템이 요구 사항을 충족하는지 확인하기 위해 계정 관리 시스템의 요구 사항에서 테스트 사례를 도출한다. → 보통 고객 또는 사용자가 기대하는 기능 및 특성을 확인하기 위해 수행하며, 시스템이 실제 환경에서 작동할 때의 동작을 시뮬레이션한다.
검증(Verification)은 소프트웨어가 개발자 입장에서 명세서나 요구사항에 따라 올바르게 구현되었는지를 확인하는 프로세스를 의미합니다. 다시 말해, 개발된 소프트웨어가 기대한 기능을 정확하게 수행하는지 여부를 검사하는 것입니다.
반면에 유효성 검사(Validation)는 실제 사용 환경에서 소프트웨어가 예상대로 동작하는지 확인하는 프로세스를 말합니다. 이는 사용자가 소프트웨어를 사용하여 원하는 결과를 얻을 수 있는지를 확인하는 것을 의미합니다.
즉, 검증은 소프트웨어가 올바르게 만들어졌는지를 확인하고, 유효성 검사는 소프트웨어가 실제로 유용하게 작동하는지를 확인합니다.
3.3. Software Project Management
소프트웨어 프로젝트 관리 활동은 개발 중인 소프트웨어 시스템이 예산 제약 조건 내에서 일정에 따라 전달되도록 보장한다. 이러한 목표를 달성하기 위해 프로젝트 관리는 다음 활동을 수행한다.
-
노력 추정
노력 추정은 개발 및 SQA 활동을 수행하는 데 필요한 인적 자원과 기간을 도출한다. 노력 추정은 예상되는 소프트웨어 크기 및 복잡성뿐만 아니라 필요한 제공 날짜와 같은 다양한 요소에서 이러한 추정치를 도출한다. -
프로젝트 계획 및 스케줄링
프로젝트 계획 및 스케줄링은 프로젝트에 대한 전반적인 계획을 산출하는 것을 목표로 한다. 프로젝트 계획은 프로젝트 팀의 생애 주기 프로세스 전반에 걸쳐 안내한다. 그러나 현실 세계의 변화로 인해 계획은 변화를 반영하여 업데이트 될 필요가 있다. 프로젝트 계획에는 프로젝트 목표, 목표 달성 프로세스, 프로젝트 이정표, 프로젝트 활동 및 성과물의 일정, 프로젝트 팀 구성 및 방식, 프로젝트 예산 등이 명시된다. 품질 보증 계획서에는 품질 표준, 품질 관리 활동 및 그러한 활동의 일정이 명시되어 있다. 또한 프로젝트 계획서에 포함되는 것으로, 아래에 설명되는 위험 관리 계획서가 있다. -
위험 관리
많은 이벤트가 프로젝트를 위태롭게 할 수 있다. 예를 들어, 관리자 또는 주요 기술 직원이 프로젝트를 떠나거나 프로젝트가 일정보다 훨씬 지연된다. 이것들을 위험 항목이라고 한다. 위험 관리는 위험 관리 계획을 통해 그러한 이벤트의 영향을 줄이려고 한다. 위험 관리 계획서는 위험 항목을 식별하고, 프로젝트에 대한 가능성 및 손상에 따라 우선 순위를 정하고, 위험이 발생할 때 그에 대응하기 위한 위험 해결 조치를 명시한다. -
프로젝트 관리
프로젝트 계획서에 명시된 바와 같이 관리 활동을 수행한다. 프로젝트 진행 상황을 지속적으로 모니터링하고 프로젝트를 새로운 상황에 적응시키기 위해 필요한 조치를 실행하는 것과 관련이 있다. 프로젝트 팀 또는 팀원의 조정, 회의 일정 및 수행, 일상적인 문제 해결 등과 같은 프로젝트 활동의 일상적인 관리도 포함된다. -
소프트웨어 구성 관리
개발 프로세스 중에 수많은 소프트웨어 산출물이 생성된다. 여기에는 요구 사항 사양, 소프트웨어 설계, 코드, 테스트 케이스, 사용자 설명서 등이 포함된다. 이들은 개발 프로세스의 다른 단계에서 소프트웨어 또는 그 일부를 구성한다. 예를 들어, 요구 사항 사양은 실행 불가능한 형태의 소프트웨어이다. 설계 사양은 요구 사항 사양을 개선한 것이다. 코드는 설계를 개선한 것이다. 이 문서들은 서로 의존한다. 예를 들어, 소프트웨어 설계는 요구 사항에 따라 달라진다. 요구 사항이 변경되면 설계는 변경되어야 한다. 이는 결국 설계를 구현하는 코드에 대한 변경을 요구할 수 있다. 따라서 소프트웨어 엔지니어링은 일관성 있게 변경이 이루어지도록 조정하는 메커니즘이 필요하다. 이것은 소프트웨어 구성 관리(SCM)이다.
4. Object-Oriented Software Engineering
Object-Oriented Software Engineering(OOSE)은 소프트웨어 공학의 전문 분야이다. OOSE는 세계와 시스템을 서로 관계를 맺고 상호 작용하는 객체들로 구성된 것으로 본다.
OOSE는 OO 소프트웨어 개발을 지원하기 위해 다음과 같은 것들을 제공한다.
- OO 모델링 및 설계 언어
모델링 및 설계 언어는 개념과 표기법뿐만 아니라 표기법 사용 규칙도 정의한다. 통합 모델링 언어(UML)는 가장 널리 사용되는 OO 모델링 및 설계 언어이다. - OO 소프트웨어 개발 프로세스
통합 프로세스(UP)는 잘 알려진 개발 프로세스이지만 최근에는 애자일 프로세스가 등장했다. - OO 소프트웨어 개발 방법론
소프트웨어 프로세스의 활동을 수행하는 방법을 자세히 설명한다. - 00 개발 도구 및 환경
퍼블릭 도메인 소프트웨어뿐만 아니라 상업용 제품도 있다.
예를 들어, NetBeans 통합 개발 환경(IDE)은 자유 오픈 소스 소프트웨어이다. 전체 소프트웨어 개발 수명 주기의 활동을 지원하는 플러그인 번들이 함께 제공된다.
4.1. Object-Oriented Modeling and Design Languages
세 가지 영향력 있는 OO 개발 방법론, 그 중에서도 많은 것들이 제안되었고 소프트웨어 산업에서 널리 사용되었다. 이는 Booch Diagram, OMT(Object Modeling Technique), Use Case Engineering이다. 업계는 곧 서로 다른 방법론을 사용하여 설계 및 구현된 시스템을 통합하는 것이 기념비적인 도전이라는 것을 발견했다. 그 이유는 서로 다른 방법론이 서로 다른 모델링 개념과 표기법을 사용하기 때문이다. 이 문제를 해결하기 위해 OMG(Object Management Group)는 통합 모델링 언어(UML)을 OMG 표준으로 채택했다. UML은 OO 시스템의 다양한 측면을 모델링하고 설계하기 위한 다이어그램 제품군이다. UML 다이어그램은 개발 팀이 기존 애플리케이션의 비즈니스를 이해하는 것을 돕기 위해 요구 사항 분석 단계에서 사용된다. 이 다이어그램은 설계 사양의 일부로 설계 단계에서 사용된다. UML 다이어그램은 이 책의 나머지 부분에 걸쳐 제시될 것이다.
4.2. Object-Oriented Development Processes
객체 지향 개발 프로세스 폭포수 프로세스의 순차적 특성은 요구 사항의 변경이 어렵고 비용이 많이 든다는 것을 의미한다. 요구 사항에 대한 변경이 설계 및 구현에 영향을 미치기 때문이며, 이 또한 변경되어야 한다. 안타깝게도 시장 상황의 변경, 기술의 발전 및 기타 요인으로 인해 많은 실제 프로젝트에서 요구 사항 변경은 흔히 발생한다. 폭포수 프로세스의 개발 기간이 길다는 것은 시스템이 출시되자마자 시대에 뒤떨어지게 된다는 것을 의미한다. 이는 시스템의 기능이나 요구 사항이 오래 전에 확인되었기 때문이다. 이러한 문제를 극복하기 위해 여러 소프트웨어 프로세스 모델이 제안되었다. 이들 모두는 개발 활동의 엄격하게 순차적인 프로세스가 아닌 반복적인 프로세스를 채택하고 있다. 그 예로 나선형 프로세스, 통합된 프로세스, 애자일 프로세스가 있다.
4.3. Object-Oriented Development Methodologies
객체 지향 개발 방법론 소프트웨어 프로세스는 "언제 무엇을 할 것인지"를 지정하지만 "어떻게 할 것인지"는 지정하지 않는다. 즉, 개발 활동은 정의하지만 활동을 수행하는 방법은 정의하지 않는다. UML은 모델링 언어이다. 다이어그램을 사용하여 소프트웨어 엔지니어가 분석 및 설계 아이디어를 설명하도록 한다. 소프트웨어 엔지니어가 분석 및 설계 아이디어를 생산하는 데 도움이 되지 않는다. 소프트웨어 개발 방법론이 그 격차를 메운다. 소프트웨어 프로세스의 활동을 수행하는 단계와 단계를 수행하는 방법을 지정한다. 기존의 OO 개발 방법론에는 Booch Diagram, 객체 모델링 기법(OMT), Use Case Engineering 및 기타 방법이 포함된다. 애자일 방법론에는 스크럼(Scrum), 동적 시스템 개발 방법(DSDM), 특징 기반 개발(FDD), 크리스탈 클리어(Crystal Clear), 익스트림 프로그래밍(XP), 린 개발 방법 등이 있다.
4.4. Will OO Replace the Conventional Approaches?
정답은 여러 가지 이유로 '아니오'다.
- 수많은 기존 시스템을 유지 관리하는 것이 필요하다.
- 수많은 조직이 여전히 기존 접근 방식을 사용한다.
- 과학 컴퓨팅과 같은 일부 프로젝트에는 기존의 방법론이 더 적합할 수 있다.
- 시스템은 기존 및 OO 접근 방식에 의해 개발된 구성 요소로 구성될 수 있다.
따라서 OO와 기존 접근 방식은 수년 동안 공존할 것이다.
5. Software Engineering and Computer Science
소프트웨어 엔지니어링과 컴퓨터 과학은 다르다. 알고리즘 및 데이터 구조, 데이터베이스 시스템, 인공 지능, 운영 체제 등 컴퓨터 과학 분야에서는 계산 효율성, 자원 공유, 정확성, 최적화 및 성능을 강조한다. 이러한 속성은 정량적으로 즉시 측정할 수 있다. 실제로 지난 수십 년(1950-현재) 동안 컴퓨터 과학 연구에 투입된 모든 노력과 자원은 이러한 측면을 개선하는 것을 목표로 한다. 컴퓨터 과학 교과서의 대부분 장은 이러한 측면을 개선하기 위한 방법, 알고리즘 및 기술에 대해 작성된다.
컴퓨터 과학과 달리 소프트웨어 공학은 소프트웨어 PQCT를 강조한다. 예를 들어, 최적의 솔루션을 얻는 것은 종종 컴퓨터 과학의 목표다. 소프트웨어 공학 연구 개발에 투입된 노력과 자원은 소프트웨어 PQCT를 개선하는 것을 목표로 한다. 소프트웨어 공학 교과서의 대부분의 장은 이러한 네 가지 측면을 개선하기 위한 방법과 기술에 대해 작성된다.
안타깝게도 소프트웨어 공학 프로세스 또는 방법론의 영향을 즉시 측정할 수는 없다. 의미를 가지려면 오랜 기간 동안 그 영향을 평가해야 한다. 예를 들어, 연구자들은 통제되지 않은 goto 문이 해롭다는 것을 깨닫는 데 10년 이상이 걸렸다. 즉, goto문의 통제되지 않은 사용은 이해와 테스트가 어려운 부실하게 구조화된 프로그램을 초래한다.
컴퓨터 과학은 기술적인 측면에만 초점을 둔다. 소프트웨어 공학은 비기술적인 문제를 고려해야 한다. 예를 들어, 개발 프로세스의 초기 단계는 비즈니스 요구 사항을 식별하고 요구 사항과 제약 조건을 공식화하는 데 중점을 둔다. 이러한 활동에는 커뮤니케이션, 고객 관계, 비즈니스 분석에 대한 지식, 경험 및 기술이 필요하다. 소프트웨어 공학은 프로젝트 관리에 대한 지식과 경험도 필요하다. 사용자 인터페이스 설계는 사용자 선호도와 사용자가 시스템을 어떻게 사용할 것인지와 같은 인적 요소를 고려해야 한다. 또한, 시스템은 많은 사람들에게 한 가지 또는 다른 방식으로 영향을 미칠 수 있기 때문에 소프트웨어 개발은 정치적인 문제를 고려해야 한다.
그리고 원리들을 예를 들어 데이터베이스에 접근해야 하는 소프트웨어 시스템의 설계를 생각해 보자.
컴퓨터 공학 분야는 효율적인 데이터 저장 및 검색을 강조할 수 있으며 비즈니스 객체가 데이터베이스에 직접 접근하는 설계를 선호할 수 있다. 이러한 설계는 비즈니스 객체와 데이터베이스 사이에 긴밀한 결합을 만든다고 한다.
소프트웨어 공학은 성능이 심각한 문제가 아닌 한 이것을 좋은 설계로 간주하지 않을 것이다. 데이터베이스, 또는 데이터베이스 관리 시스템이 변경되면 비즈니스 객체가 변경되어야 한다. 이것은 어렵고 비용이 많이 들 수 있다. 데이터베이스가 원격 위치에 있다면 비즈니스 객체는 원격 데이터베이스와 통신하는 방법을 알아야 한다. 이러한 결과는 테스트하고 유지 관리하기 어려운 복잡한 비즈니스 객체를 낳는다.
차이점에도 불구하고 소프트웨어 공학과 컴퓨터 과학은 밀접한 관련이 있다. 컴퓨터 공학에서 소프트웨어 공학은 전기/전자 공학에 물리학, 또는 화학 공학에 화학과 같다. 즉, 컴퓨터 과학은 소프트웨어 공학의 이론적이고 기술적인 토대이다. 소프트웨어 공학은 컴퓨터 과학의 응용 분야이다.
그러나 소프트웨어 공학에는 고유한 연구 주제가 있다. 이것들은 여러 가지 중에서도 소프트웨어 프로세스 및 방법론, 소프트웨어 verification, validation 및 테스트 기술에 대한 연구를 포함한다. 소프트웨어 공학 연구는 소프트웨어 PQCT와 이들 사이의 균형을 상당히 개선하는 것을 목표로 한다.
소프트웨어 공학은 광범위한 영역이다. 소프트웨어 공학자는 몇 가지를 언급하자면 데이터베이스 시스템, 운영 체제, 데이터 구조와 알고리즘, 프로그래밍 언어, 컴파일러 구성을 포함한 컴퓨터 과학의 다양한 영역을 알고 있어야 한다. 임베디드 시스템 개발은 소프트웨어 공학자가 전자 회로에 대한 기본적인 이해와 하드웨어 장치와 인터페이스하는 방법을 요구한다. 마지막으로 소프트웨어 공학자가 훌륭한 소프트웨어 설계자가 되기 위해서는 도메인 지식과 설계 경험을 얻는 데 시간이 걸린다. 이러한 도전과 현실적인 요구를 충족시키기 위해 크고 복잡한 시스템을 설계하고 구현하는 능력은 소프트웨어 공학을 흥미로운 영역으로 만든다. 계속해서 확장되는 컴퓨터 응용은 소프트웨어 공학자이자 소프트웨어 공학 연구자인 소프트웨어 공학에게 좋은 기회를 만들어 준다.
