본문 바로가기

CS/소프트웨어 공학론

CH1. 소프트웨어 공학 개요

CH1. 소프트웨어 공학 개요
1.1 소프트웨어 고장 사례
1.2 소프트웨어 위기
1.3 소프트웨어 공학 기술의 적용

 

 기존 소프트웨어의 사고 사례를 통해, 소프트웨어에 체계적·공학적 방법을 적용하여 개발하는 이유를 생각해보고 소프트웨어 공학의 필요성을 알아본다.

 

 주요 개념

  • 소프트웨어 위기의 원인과 증상 - 8, 6가지
  • 소프트웨어 개발이 어려운 이유 - 6가지
  • 소프트웨어의 특성 정보, 왜 공학적 기술을 도입해야 할까? - 4가지
  • 소프트웨어 공학적 기법의 종류 - 9가지
  • 소프트웨어 공학의 원리 - 8가지

1.1 소프트웨어 고장 사례

소프트웨어 개요

소프트웨어 = 소스 코드 + 프로그램 + 문저의 집합

 

소프트웨어의 특징

  • 비가시성 : 눈에 보이지 않음
  • 복잡성 : 다양한 구성 요소와 상호 작용으로 구성
  • 변경성 : 시간에 따라 변경될 수 있음
  • 순응성, 적합성 : 요구사항과 기준에 적합해야함

그 외에도 무형성, 복제성 등이 있다.

 

 IT 기술이 발전함에 따라 소프트웨어 또한 발전해왔다. 그러나 언제나 정상작동해온 것만은 아니다. 소프트웨어의 고장 및 오작동은 심각한 피해를 불러올 수 있다. 이러한 소프트웨어 결함으로 인한 사건 사고는 지속적으로 발생하고 있다.

 

  • 화성 기후 관측 위성 결함 사례
  • 자동차 해킹 사례
  • 보잉 747 추락 사례
  • 테슬라 자율 주행차 사고 사례

 이러한 소프트웨어 결함을 완벽하게 제거하는 것은 불가능하다. 따라서 '어떻게 해야 결함이 적은 높은 품질의 소프트웨어를 개발할 수 있을까?'는 매우 중요한 문제이다.

 

1.2 소프트웨어 위기

정의 

하드웨어의 급속한 발전 대비 소프트웨어 개발 방법론이 뒤쳐지며 발생한 문제의 집합.

1968년 NATO 소프트웨어공학 학회에서 처음 등장한 단어이다.

= '정확하고 이해할 수 있고 검증 가능한 컴퓨터 프로그램을 만드는 것이 얼마나 어려운가?'

 

 

 소프트웨어 위기의 원인

  1. 소프트웨어 규모의 대형화 및 복잡화에 따른 개발 비용 증대.
  2. 하드웨어 기술의 급진전으로 인한 소프트웨어 개발 기술의 상대적 부진
  3. 하드웨어 비용 대비 소프트웨어 가격 상승 폭 증가
  4. 소프트웨어 유지보수의 어려움과 개발 정체 현상 발생
  5. 소프트웨어 개발 프로젝트 기간 및 소요 예산에 대한 정확한 예측의 어려움
  6. 신기술에 대한 교육 및 훈련의 부족
  7. 사용자의 소프트웨어에 대한 기대치 증가
  8. 소프트웨어에 대한 사용자 요구사항의 빈번한 변경 및 반영

 

소프트웨어 위기의 증상

  1. 예산 초과
  2. 일정 지연
  3. 낮은 품질의 소프트웨어 개발
  4. 비효율적인 소프트웨어 개발
  5. 사용자 요구사항 불만족
  6. 산출물 관리의 어려움

  → 개발 실패 or 사용자에게 전달 실패

 

그렇다면 소프트웨어 개발이 어려울까? 그 이유를 살펴보도록 하자.

 

소프트웨어 개발이 어려운 이유

  1. 의사소통의 문제 : 다양한 역할 담당자들이 자기 자신의 언어로 소통. 때문에 소통 오류가 빈번하게 발생.
  2. 시스템의 순차 특성 : 소프트웨어 엔지니어들은 3차원적 상황을 2차원 평면에 정리해야 함.
  3. 개발에 의한 결과물 : 개발자 개인의 경험과 지식이 중요하게 작용.
  4. 프로젝트의 복잡한 특성 : 프로젝트마다 상이한 개발 기간, 채택한 기술, 참여 인원 수, 프로젝트의 목적에 따라 프로젝트의 관리 방식이 달라져야 함.
  5. 개발자의 특성 : 개발자 개개인의 특성에 따라 쉬울 수도 있고, 어려울 수도 있음.
  6. 다양한 관리 이슈 : 팀 기반의 소프트웨어 개발. 수많은 세부 관리 활동이 수반됨. 오케스트레이션 필수.

소프트웨어의 특성 정보

 = 왜 소프트웨어는 단순한 개발 활동이 아닐까? 공학적 기술을 도입해야 하는 이유.

 

  • 소프트웨어 개발 비용 : 소프트웨어 개발에서 분석 및 설계가 코드 개발보다 중요하고 비중있게 수행되어야한다.
  • 소프트웨어 개발 및 유지 보수 : 개발된 소프트웨어를 수정하고 개선하기 위한 노력이 개발 노력보다 더 많이 요구된다.
  • 소프트웨어 개발 시 오류의 근원 : 기능에 대한 오해나 로직 설계의 오류보다는 코딩하는 과정에서 발생하는 오류나 문서화 과정에서 발생하는 오류가 훨씬 많다.
  • 소프트웨어 고장 그래프 : 변경 과정이 반복되면 오류의 발생 빈도가 높아져 하드웨어와 같은 실제 패턴 Real curve이 나타난다. 따라서 소프트웨어 운영 과정에서 변경으로 인해 소프트웨어 구조가 바뀌지 않도록 코드 구조를 체계적으로 모듈화하고 융통성 있게 작성하는 것이 매우 중요하다.

인공지능 시대의 소프트웨어 위기

 현재는 정보 혁명이라고 불리는 4차 산업혁명의 시기이다. 초연결, 초융합, 초지능이 특징인 정보 혁명은 인공지능, 빅데이터, 가상현실, IoX, 사이버 물리 시스템 분야의 기술이 확산되고 있다. 이에 따라 인공지능 소프트웨어 또한 범람하고 있다. 인공지능을 기반으로 하는 다양한 학습 모델이 출현하였고, 인공지능과 기계 학습 기반의 소프트웨어 개발 및 활용 또한 증대했으며 이에 대한 결과로 인공지능 소프트웨어의 위기 개념이 새롭게 도입되었다. 소프트웨어 공학의 필요성은 점점 높아지고 있다.

 

1.3 소프트웨어 공학 기술의 적용

 소프트웨어 개발에 적용하는 공학적 기법은 소프트웨어의 품질을 높이고, 신속하게 사용자에게 소프트웨어를 전달하는 것을 목표로 한다. 이를 위해 쓰이는 공학적 기법에 대해 알아보겠다.

 

소프트웨어 공학적 기법

  1. 구조적 프로그래밍 (1970년대) : 어셈블리어 → 고급 프로그래밍 언어. 이해하기 쉽고, 체계적으로 논리를 표현할 수 있는 공학적 접근 방법에 대한 고민. 프로그램 구성은 순차, 반복, 선택의 세 가지 기본 구조로 구성될 수 있다. 모듈화, 단계적 상세화 개념 제시.
  2. 객체지향 프로그래밍 (1980년대) : 클래스 개념. 실세계 묘사가 직관적이며, 재사용을 강조하는 공학적 접근방법. UML (Unified Modeling Language) 기반 객체지향 분석 및 설계. 
  3. 시스템 컴포넌트 및 재사용 (1990년대) : 소프트웨어 컴포넌트 = 재사용 가증한 기능의 최소 단위. (≠ 모듈 = 연관성 있는 함수/클래스의 묶음. 재사용 시 호환문제 있을 가능성 有, 따라서 컴포넌트 등장), 재사용으로 인한 개발의 신속성 및 품질 향상. 오픈 소스 소프트웨어 재사용을 통한 소프트웨어 개발 확대.
  4. 통합 개발 환경 : 이클립스, VScode 등의 통합 소프트웨어 개발 환경.
  5. 소프트웨어 개발 프로세스 : 폭포수 모델, 점진적 개발 방식, 프로토 타입, DevOps 등
  6. 소프트웨어 검사 및 검증 : 대표적으로 소프트웨어 테스트가 있다. 테스트 케이스를 이용하여 소프트웨어가 정확하게 동작하는지 확인 및 잠재된 결함 확인.
  7. 소프트웨어 형상 관리 : 버전 관리. 소프트웨어의 변경 사항을 추적하고 통제하는 활동.
  8. 소프트웨어 프로토 타이핑 : 최종 소프트웨어 개발 전 사용자가 원하는 소프트 타입의 원형 즉, 프로토타입을 보여줌. 사용자의 요구사항 명확하게 반영함.
  9. 소프트웨어 아키텍쳐 : 코드 수준이 아닌 소프트웨어 설계 구조에서 변화를 체계적으로 반영할 수 있는 아키텍쳐.

소프트웨어 공학의 정의

소프트웨어 공학의 목표

 사용자의 요구사항을 충족시키는 좋은 품질의 소프트웨어 개발

 

소프트웨어 공학의 원리

  1. 엄격성과 정형성 : 지나치게 자유로우면 안된다. 누구나 동일한 의미로 해석할 수 있어야 함. 프로젝트 관리, 스케줄 관리, 문서화 요구 시에도 적용되는 원리.
  2. 관심사의 분할 : 복잡한 문제를 단순한 문제로 분리하여 적용하는 소프트웨어 개발 활동. SW 개발 과정의 분할 = 요구사항 분석  설계  구현 테스팅 | SW 테스트 과정의 분할 = 단위 테스트 통합 테스트 시스템 테스트
  3. 점진성 : 단계적이며 순차적으로 소프트웨어를 개발하고자 하는 공학적 원리. 작은 단위의 소프트웨어를 반복 개발하면서 전체 시스템 완성. 단계적인 개발과 배포를 통한 사용자 피드백의 수집과 반영.
  4. 명세화 : 소프트웨어 개발 과정과 대상물에 대한 정보를 체계적으로 기술하는 원리. 팀 기반의 개발 활동을 지원하기 위한 정보의 공유 지원. 지속적으로 진화하는 소프트웨어에 대한 이력서. 
  5. 모듈화 : 모듈 = 독립적인 기능을 갖는 프로그램의 조각. 소프트웨어 변경이 발생할 것으로 예상되는 부분을 모듈화 구조로 분리. 높은 응집력과 낮은 결합력을 갖도록 소프트웨어 구조 설계.
  6. 추상화 : 세부사항은 감추고 대표적인 속성으로 대상물을 정의하는 공학적 원리.
  7. 일반화 : 다양한 플랫폼, 다양한 환경, 다양한 사용자를 지원하기 위한 원리. 하드웨어 성능이나 사양에 의존적이지 않은 소프트웨어 개발.
소프트웨어 위기 : 복잡도 증가, 규모의 대형화, 사용자 요구사항 급변에 대응하는 소프트웨어 개발 필요
→ 공학적 원리 및 기법의 적용을 통한 품질 좋은 소프트웨어 개발

 

소프트웨어 공학의 목표 : 고품질 소프트웨어의 효율적인 개발 및 운영을 위한 학문

개발, 운용, 유지보수 같은 수명 주기를 체계적·서술적·정량적으로 다루는 활동

'CS > 소프트웨어 공학론' 카테고리의 다른 글

CH3.2 소프트웨어 개발 프로세스  (2) 2024.04.24
CH2. 소프트웨어 품질  (3) 2024.04.23