📕 목차

1. What is Software? 
2. Software Engineering
3. Software Programming vs. Software Engineering
4. Software Failure Cases
5. Software Crisis
6. 4C in SE

1. What is Software?

 

📌 Software
  • 컴퓨터 프로그램 + 관련 문서
  • 소프트웨어 전문가가 구축하고 장기적으로 지원되는 product

 

📌 Software Product
  • Generic : 다양한 범위의 고객들에게 판매하기 위해 개발되는 것
  • Custom : 특정 고객이 요구하는 사양을 충족시키기 위해 개발되는 것

 

📌 Characteristics (SW 개발이 어려운 이유)
  • Invisibility : SW는 육안으로 확인할 수 없다.
  • Complexity : 본질적인 복잡성을 줄일 수 없다. (단, code size를 줄임으로써 다소 완화할 수 있다.)
  • Changeablitiy : SW는 완성 직후에도 진화하고 있다.
  • 개발 단계에서는 어떤 입력값이 존재할 지 불확실하다.
  • 완전히 자동화할 수 없다.
  • 커뮤니케이션을 요구한다.
  • 관리 문제

 

2. Software Engineering

 

📌 Concept
  • NATO 회의에서 시작된 용어 (23년 기준 약 50년 전)
    • Garmisch, Germany, October 7-11, 1968
    • Rome, Italy, October 27-31, 1969
  • 기초 과학 중 하나인 Computer science
    • 수년간의 연구/경험/통계가 기초를 제공한다.
    • 많은 부분들이 체계적으로 만들어졌다.
      • Method / methodologies / techniques
      • Languages
      • Tools
      • Processes

 

📌 Definitions
💡 소프트웨어의 개발, 운용, 유지보수와 같은 수명 주기 전반을 체계적·서술적·정량적으로 다루는 활동의 총체적 모임

Goal of SE

  • "고품질 소프트웨어를 경제적으로 생산하기 위해 공학적, 과학적, 수학적 원리와 방법들을 체계적으로 적용하는 것이다." - Watts Humphrey 
  • "소프트웨어 개발, 운영, 유지, 폐기에 대한 체계적 접근 방식" - IEEE Computer Society
  • "멀티 비전 소프트웨어의 다중 인력 구축" - D.L. Parnas
  • "대규모 소프트웨어 시스템의 설계, 구축 및 유지" - Ian Sommerville

 

📌 8 Principles
  • 엄격성과 정형성 (Rigor and Formality)
    • SW는 개발자 경험과 지식에 의존적인 창의적·공학적 활동의 산출물
    • SW 개발은 주어진 시간과 비용에서 명확하게 개발되어야 한다. (엄격성)
    • 기술한 내용을 모두 동일한 의미로 해석할 수 있어야 한다. (정형성)
  • 관심사의 분할 (Separation of Concerns)
    • 복잡한 문제를 단순한 문제로 분리하여 적용하는 SW 개발 활동
    • SW 개발 과정 분할 : Analysis → Design → Implementation → Testing 등
    • SW 테스트 과정 분할 : Unit Test → Integration Test → System Test 등
  • 모듈화 (Modularity)
    • 독립적 기능을 갖는 Program 조각
    • 높은 응집력, 낮은 결합력을 갖는 SW 구조 설계
    • 이해도를 높이고 변경에 대한 영향을 최소화할 수 있는 공학적 원리
  • 추상화 (Absraction)
    • 세부 사항은 감추고 대표적 속성으로 대상물을 정의
    • 대상물에 대한 직관적인 이해를 높이고 관심사만을 표현할 수 있다.
    • ex. 함수 정의, 매크로 함수, 인터페이스, 추상 데이터 타입 등
  • 변경 예측 (Anticipation of Changes)
    • SW 개발 단계에서 변경 발생을 피할 수 없는 사건
    • 변경이 발생할 것으로 예상되는 부분을 모두 모듈화 구조로 분리
    • 외부에서는 모듈 내부 구조의 변화를 신경쓰지 않고 똑같이 사용할 수 있게 된다.
  • 일반화 (Generality)
    • 다양한 플랫폼, 다양한 환경, 다양한 사용자를 지원하기 위한 원리
    • HW 성능, 사양에 의존적이지 않은 SW 개발
  • 점진성 (Incrementality)
    • 단계적이며 순차적인 SW 개발
    • 작은 단위의 SW를 반복 개발하면서 전체 시스템 완성
    • 단계적 개발과 배포를 통한 사용자 피드백의 수집과 반영
  • 명세화 (Documentation)
    • SW 개발 과정 및 대상물에 대한 정보를 체계적으로 기술
    • 팀 기반의 개발 활동을 지원하기 위한 정보 공유 지원
    • 지속적으로 진화하는 SW에 대한 이력서

 

📌 Computer Science vs. Software Engineering

  1. Computer Science
    • 미래 기술과 알고리즘 연구
    • 이론 중심적
    • 알고리즘 개발
    • Computer Sientist는 이론적인 문제 해결 능력을 요구한다.
  2. Software Engineering
    • SW 개발 및 유지 보수
    • 실무 중심적
    • SW 품질 개선 연구
    • Software Engineer는 SW Project의 성공적인 완료를 목표로 한다.

 

📌 Relation between CS an SE

  • CS는 SE의 이론적 기반을 마련하고, SE는 CS의 이론을 현실 세계 SW 개발 및 유지 관리에 적용한다.
  • CS는 새로운 SW 기술 및 tool 개발에 공헌하며, SE는 이러한 기술과 도구를 사용하여 실제 SW를 개발한다.
  • CS는 단순히 더 나은 기술적 성능 개선에 집중하지만, SE는 고객의 니즈에 맞추어 품질 향상에 초점을 맞춘다.
    • 공학자 관점에서 성공이란 신기술 개발이나 기존 기술의 성능 향상이지만, 고객의 입장에서는 낮은 비용으로 원하는 만큼의 성능을 보장받길 원한다.

 

📌 How to do software engineering

  1. System Engineering 단계
    • 성공적인 시스템 구현을 가능케 하는 Interdisciplinary 접근법이자 도구
    • Engineering 원칙으로 고객과 이해 관계자의 Requirement가 시스템의 모든 Lifecycle 동안 고품질·신뢰성·예산 및 일정을 충족하도록 지원하는 Interdisciplinary Process를 생성하고 이행하기 위한 목적을 가진다.
    • Interdisciplinary : System Engineering Process를 수행하는 과정에서 수행 대상 Process 뿐 아니라 연관 Process의 활동도 함께 수행되는 것
  2. 요구 사항 분석
  3. 프로젝트 계획
  4. 구조 설계
  5. 세부 사항 설계
  6. 구현
  7. 릴리즈
  8. 유지·보수 (피드백)

 

3. Software Programming vs. Software Engineering

 

📌 Software Programming
  • 혼자 개발.
  • "Toy" applications. (단순함)
  • 짧은 개발 기간
  • 적은 이해 관계자
    • 설계자 = 개발자 = 관리자 = 테스터 = 고객 = 유저
  • 시스템의 한 종류이자 일부분
  • 밑바닥부터 구현

 

📌 Software Engineering
  • 여러 책인을 가지고 있는 개발자 팀으로 구성
  • 복잡한 시스템
  • 무기한 개발 기간
  • 수많은 이해 관계자
  • 시스템 제품군
  • 새로운 SW 개발에 재사용

 

4. Software Failure Cases

 

📌 Example

1️⃣ Tesla Model S (2016.05) 사고

 

자율주행 첫 사망사고 충격…센서만으론 한계 드러낸 무인차 - 매일경제

밝은 하늘과 흰색 트레일러 분간 못해 `쾅`"무인차 상용화 연기" 신중론자 목소리 커져차량사고때 법적책임 문제도 다시 불거질듯

www.mk.co.kr

  • 오토 파일럿 기능이 흰색의 트럭과 흰 구름의 인식 오류로 발생

 

2️⃣ Boeing 737 MAX 추락 사고 (2018.10.29)

 

막을 수 있었던 보잉737맥스8 연쇄 추락사고의 내막 추적

오만한 보잉의 배신! 세계 항공사상 최악의 은폐로 346명 사망

monthly.chosun.com

  • 기체 변동으로 인한 엔진 위치를 비행기 출시 1년 앞둔 상황에서 기존 SW 변경 없이 재사용
  • MCAS(자세 제어 시스템)에 입력되는 노즈 센서 값 오류로 노즈가 계속 하강
  • 위급 상황에서 조종사로의 제어 인양 기능 부재

 

3️⃣ Amazon 클라우드 NoSQL DB 4시간 사용 불능 (2017.02.28)

  • Amazon Alexa 등 수많은 IoT 서비스 사용 불가
  • 수많은 사용자들이 비지니스 손실

 

4️⃣Tesla 자동차의 API에 장애 (2017.03.10)

  • 사용자들이 앱으로 차량 잠금 해제 불가

 

5️⃣코레일 중앙 관제 센터 장애 (2017.06.16)

  • 다량의 열차 지연
  • 시스템이 너무 복잡하여 오류 원인을 파악하는데 많은 시간 소요

 

6️⃣ 독일 폭스바겐 자동차 조립 공장 인명 피해 (2015.06.29)

  • 차량 조립 과정에서 생산라인의 로봇 팔이 오작동

 

5. Software Crisis

 

📌 Concept
  • Computer에 의한 계산 용량과 문제 복잡성이 급격히 증가함에 따라 발생
  • 정확하고, 이해할 수 있고, 검증 가능한 Program 작성이 얼마나 어려운가를 의미한다.

 

📌 Caues

성공 비율이 증가는 하지만, challenged와 failed가 혁신적으로 감소하진 않음.

  • SW 규모의 대형화 및 복잡도 증가에 따른 개발 비용 증대
  • SW 유지보수의 어려움과 개발 정체 현상
  • SW 개발 프로젝트 기간 및 소요 예산에 대한 정확한 예측 어려움
  • 신기술에 대한 교육 및 훈련 부족
  • 사용자의 SW 기대치 증가
  • SW에 대한 사용자 요구사항의 빈번한 변경 및 반영 (아, 듣기만 해도 화나네..^^)

 

📌 인공지능 시대의 Software Crisis
  • 4차 산업혁명 시대
    • 초연결, 초융합, 초지능
    • A-ICBM (AI, IoT, Cloud, Big data, Mobile)
    • D.N.A (Data, Network, AI)
  • AI software 범람으로 인한 기계 학습 결과에 대한 정확성, 신뢰성, 안전성 등의 문제
  • 윤리 및 도덕적인 영역에서의 AI 편향성 문제

 

6. 4C in SE

 

📌 What to manage in SE
  • Complexity
  • Change
  • Cost
  • Communication

 

📌 Complexity
  • 어떻게 SW가 복잡해지는가?
  • 어째서 SW는 시간에 따라 복잡도가 증가하는가? (4장에서 다룰 주제)
  • 어떻게 SW 개발 중에 복잡도 증가를 개선시킬 수 있는가?

 

📌 Change
  • SW 개발 과정 중 무엇이 변하는가?
    • 요구 사항, 디자인, 코드, 이해 관계자 등

(좌) 이상적인 SW 실패 곡선 / (우) 실제 SW 실패 곡선

  • Reliability (신뢰성) : SW 품질 목표 중 주어진 시간 동안 주어진 기능을 오류 없이 수행하는 정도

 

📌 Cost

  • SW 사업에서의 주요 비용 요소
    • SW 개발
    • SW 유지
    • SW 인수
    • SW 운영
  • Nasa Space Shuttle control software는 역대 최고의 소프트웨어라고 불린다.
    • 420,000 LOC
    • 마지막 3가지 버전에서 에러는 단 하나
    • 전체 11가지 버전에서 에러는 고작 17개
  • Nasa와 우리의 차이
    • Nasa 만큼의 예산을 가지고 있지 않다.
    • bug가 사람을 죽이지 않는다. (Nasa는 SW가 실패하면 인명 피해가 발생한다.)
    • 산업 프로젝트는 더 많은 요구 사항을 받는다.
    • 사용자는 어느 정도의 버그는 용인한다. (더 신속하게 시장에 진출하기 위해서)
  • SE가 고려해야 하는 것
    • 어떻게 비용을 줄이거나 관리할 수 있는가?
    • 제한된 시간과 예산에서 어떻게 고품질의 SW를 만들 것인가?
    • 어떻게 개발한 SW로부터 수익을 창출할 것인가?

 

📌 Communication

  • SE는 같은 직책 뿐 아닌 다른 직책의 사람들과도 소통해야 한다.
    • R&R : Role and Responsibilities

 

저작자표시 비영리 (새창열림)

티스토리툴바