부제 ‘ 소프트웨어 공학의 필요성’
학습 순서
- 소프트웨어 정의
- 소프트웨어 결함
- 소프트웨어 이해
- 소프트웨어 공학 기술의 적용
소프트웨어 정의
-
프로그램
- 컴퓨터에 어떤 일을 처리할 순서와 방법을 지시하는 명령어들의 집합
- 쉽게 말해 우리가 하는 알고리즘이나 ,학교과제 따위를 말함
- 프로그래밍한 원시 코드 (source code)
-
소프트웨어
- 프로그램을 비롯해 개발과정에서 생성되는 모든 산출물과 각 단계에서 만들어지는 문서와 사용자 메뉴얼 등
- 소프트 웨어 = 프로그램 + 각종 문서들 및 사용자 메뉴얼
-
프로그램
- 개인적인 문제 해결 목적
- 단순/단일
- 한 가지 언어로 작성됨
- 적은 인원
- 소프트웨어 (SW)
- 일반적인 목적의 문제해결
- 복잡한 작업/과제
- 여러 언어/패키지로 작성
- 다수의 인원
소프트웨어의 활용 및 종류
-
기능에 따라 나눔
-
시스템 소프트웨어(OS)
- 컴퓨터 하드웨어를 관리하고 동작시키는 일을 하는 SW
- 응용 소프트웨어
- 하드웨어를 제어 할 권한은 없고 , 운영 체제 위에서 컴퓨터 사용자가 원하는 작업을 할 수 있도록 만든 소프트웨어
- 특정 목적에 따른 업무를 처리하기 위한 경우가 많음 ( 워드 프로세서 ,엑셀 ,파워포인트)
- 앱 OR 어플
💡 소프트웨어 = 시스템 소프트웨어 + 응용 소프트웨어
소프트웨어 결함
- **사례**
- MCO 위성
- 화성의 궤도 진입하다 통신 두절됨
- MCO는 1(Ns) , 계산 프로그램은 (lbs)를 사용함.
- Jeep 체로키 취약점 (해킹)
- 2014년 밀러와 발라섹이 운행중인 차량 무선 원격 접속
- 급정지 시도 (라디오 모듈에 앱 다운로드 설치)
- 보잉 737 MAX8 추락 사례
- 승객 공간 늘리려고 기종 형상 변경
- → 엔진 위치를 변경했으나 기존 소프트웨어 변경 없이 재사용
- 테슬라,폭스바겐,도요타 사례가 있음. 알아만 두자
해킹 VS 소프트웨어 결함 vs 소프트웨어 결함 비용
| 항목 | 소프트웨어 결함 | 소프트웨어 결함 비용 | 해킹 |
|---|
| 정의 | - 소프트웨어 내부에 존재하는 불규칙성 - 개발 프로세스 내부의 부적절함으로 인한 불 규칙성 - 프로그래밍 언어, 서비스를 구축하는데 사용되는 플랫폼, 서비스 자체의 버전 업데이트로 인한 불규칙성 | - 소프트웨어 결함으로 인한 비용(해킹 포함), 레거시 프로그램을 유지하기 위한 비용 , 중단 된 프로젝트에 투입 되었던 비용 | - 해커로 부터 외부 간섭을 가리키는데 사용 - 해킹은 시스템 관리자의 동의나 허가 없이 해당 서비스의 내용이나 작동 방식을 변경하는 것을 지칭 |
미국의 SW 결함 비용은 급증 중

💡 SW 결함 비용 = SW 운영 실패 비용 + 레거시 시스템 문제 해결 비용
- 레거시 시스템은 바뀌어야 하는가? → 아래에서 살펴보자
왜 SW 결함 비용이 증가하는가?
- 소프트웨어 규모의 대형화 및 복잡도 증가에 따른 개발 비용 증대
- 소프트웨어 유지보수의 어려움과 개발 정체 현상
- 소프트웨어 개발 프로젝트 기간 및 소요 예산에 대한 정확한 예측의 어려움
- 신기술에 대한 교육 및 훈련의 부족
- 사용자의 소프트웨어에 대한 기대치 증가
- 사용자 요구사항의 빈번한 변경 및 반
인공지능 시대의 소프트웨어 위기
인공지능을 기반으로 하는 다양한 학습 모델이 출현하고있고, 활용 영역이 증대되고있다. 하지만, 기계학습 결과에 대한 정확성,신뢰성,안정성등이 보장되지않으며, 윤리 및 도덕적 영역에서의 인공지능의 편향성 문제가 존재한다.
- 소프트웨어 크라이시스 → 복잡도가 점점 증가하니까 새로운 소프트웨어 개발 방법 필요하다 (1968 NATO)
소프트웨어 이해
- 단순 개발은 간단하지만 대기업 단위의 소프트웨어 개발은 매우 복잡하다!
- 개발 참여 인력이 많고, 개발 기간이 길다!
- 소프트웨어는 유지보수가 어렵다
- 하드웨어와 달리 부품이 소모돼서 기능이 떨어지는 것이 아니라
- 잘못 만들면 품질이 떨어진다.
레거시 소프트웨어가 변경되어야 하는 이유
- SW는 새로운 컴퓨팅 환경이나 기술의 요구를 충족시키기 위해 적응되어야 함
- 새로운 비즈니스 요구 사항을 구현해야함
- 더 현대적인 시스템과 DB와의 상호 운용성을 확보해야함
- 소프트웨어 관련 잘못된 믿음 - 관리자
- 잘못된 믿음
- 이미 SW에 개발에 대한 표준과 절차 존재 → 직원이 알아서 하겠지?
- 일정에 뒤 떨어졌네? → 개발자 추가해!
- 현실
- 표준이 존재하겠지만, 대부분이 사용하지 않는다.
- 늦은 SW 프로젝트에 사람이 늘어나는것은 더 늦게 만드는 일이다.
- 소프트웨어 관련 잘못된 믿음 -개발자
- 잘못된 믿음
- 소프트웨어를 작성하고 작동하면 우리 일은 끝이다.
- 프로그램을 작동할 때까지 품질을 평가할 방법이 없다.
- 현실
- 고객에 처음으로 컨택한 후가 소프트웨어 개발 노력의 60%~ 80%를 차지함.
- 소프트웨어 검토는 소프트웨어 결함을 찾는데 효과적이고, 시작부터 적용할 수 있는 가장 효과적인 소프트웨어 품질 보증 메커니즘이다.
- 소프트웨어 관련 잘못된 믿음 -개발자
- 잘못된 믿음
- 성공적인 프로젝트의 결과물은 작동하는 프로그램으로 충분하다.
- SW 엔지니어링은 우리에게 많고 불필요한 문서를 작성하게 만든다
- 이는 우리를 결국 느리게 만든다.
- 현실
- 프로그램은 그저 구성의 일부에 불과하다! 주석,디자인 문서 등의 문서화는 성공적인 엔지니어링의 기초이고, 유지보수 , 사용방법,지원등에 대한 지침을 제공한다.
- SW 엔지니어링은 문서를 작성하는게 아니고, 품질을 만드는 것이다.
- 소프트웨어 관련 잘못된 믿음 -고객
- 잘못된 믿음
- 이루고자 하는 목표가 설명 되어 있다면 프로그램 작성을 시작하기에 충분하다고 생각함. 세부사항은 나중에 채울 수 있다고 믿음
- 프로젝트 요구 사항은 계속 변하지만, 어차피 변경은 유연하게 되니까 나중에 수용하면 되겠지
- 현실
- 정의의 부족은 프로젝트 실패의 주요 원인이며, 기능,동작,성능,인터페이스,설계 제약 조건 및 검증 기준의 형식적이고 상세한 설명이 필수적이다.
- 물론 요구사항은 변할 수 있지만, 변경이 소개되는 시점에 따라 SW에 미치는 영향이 다르다.
소프트웨어 공학 기술의 적용
탐색적 프로그래밍 (비구조적)(1950)
- 어셈블리 언어로 작성됨.
- 프로그램이 매우 작았음.
- 하나의 함수나 바디에 연속된 코드를 작성하는 프로그래밍 기법
- 흐름제어문인 GOTO문으로 코드의 특정 위치로 건너뛰는 형식의 기법
- → 유지보수가 어렵고 ,흐름이 복잡해짐.
구조적 프로그래밍 (1960)
- C언어 ,Fortran,Cobol
- 코드의 위에서 아래로만 진행이 되게 끔 절차와 순서를 갖게 하는 패러다임.
- 순차, 선택, 반복 의 구조를 반복해감.
- 순차 : 코드를 순서대로 진행한다.
- 선택 : 조건문,선택문 (if, switch)
- 반복: 반복문 (for,while)
- GOTO문(흐름제어)을 피하려고함.
- 모듈화 개념과 단계적 상세화 개념 등장.
데이터 구조 중심의 설계 (1970)
- 효율적 데이터 구조 설계 → 좋은 프로그래밍
- 효율적인 데이터 구조를 통해 최적의 시간과 공간 요구사항을 갖는 효율적인 프로그램을 개발 가능하게 됨
데이터 흐름 중심의 설계 (1970)
- 디자인의 원칙
- 좋은 프로그램 구조를 갖기 위해 프로그램의 입력부터 출력까지 데이터가 어떻게 흐르는지를 고려해야 됨.
- 모든 프로그램은 데이터를 읽고, 그 데이터를 처리한다는 사실에 기반한 설계
- 데이터 흐름 구조가 이해되면 프로그램 구조를 유도하는것이 쉬워진다는 점에 기반
객체지향 설계 (1980)
- 최근에 가장 일반적으로 사용되는 기법
- 캡슐화, 정보은닉, 상속, 다형성
- C++, JAVA,PYTHON 등의 언어 출현
- 실세계의 묘사가 직관적임, 재사용을 강조한다!
- 문제에서 자연적으로 발생하는 객체를 먼저 식별하여 설계하는 접근 방식에 기반
- 각 객체는 데이터 숨기기 역할을 가짐.
- 객체 간의 관계를 통해서 프로그램 구조가 결정
소프트웨어 컴포넌트와 재사용 (1990)
- 소프트웨어 컴포넌트란? 재사용 가능한 명세 및 코드의 묶음
- 재사용으로 인한 개발의 신속성 및 품질 향상을 목적으로 함
- 컴포넌트 기반 소프트웨어 개발 방법론이다.
