1. 소프트웨어 공학이란

소프트웨어 공학이 필요한 이유와 먼지를 알면 됨

소프트웨어와 우리생활

  • 소프트웨어가 생활에서 중요해졌다는 것은 매우 자명한 사실 중 하나
  • 학사 시스템, 줌 등등 모두 다 소프트웨어
  • 소프트웨어 없이 살 수 없는 시대가 옴
  • 더 커진 소프트웨어 의존성(dependability)

연결성(connectivity)의 변화

옛날 – 컴퓨터만 연결됨, personal computer에 올라가는 소프트웨어만 필요

지금 – 모바일에 올라가는 소프트웨어도 필요, 확장됨

ioT – 인식할 수 있는 모든 사물이 모두 인터넷에 연결됨. 이를 위해서는 소프트웨어가 필요

web → mobile → ioT

소프트웨어가 매우 중요해졌다는 것!

핵심 기술인 ioT, 클라우드, 블록체인 등을 위해서는 소프트웨어가 필요

  • 모든 장치들이 예전에 pc를 대체하면서 모든 장치 위에 돌아가는 소프트웨어를 구현해야 한다.
  • 예전에는 편리를 위한 기술이였다면 블록체인 등등 모두 구현해야하므로 복잡도가 커지고 소프트웨어가 더 커짐

1.1 소프트웨어

: 보통 소스코드, 프로그램만 생각하지만 사실 코드부분은 작은 부분이며 돌아가는 돌아가는 코드 + 프로그램 개발하거나 실행하거나 운용하면서 수정하고 고치는 보수 등에 필요한 정보

  • 개념적이고 무형적

ex) 사용자가 사용하게 해주는 메뉴얼도 소프트웨어

개발 중간중간의 산출물도 다 소프트웨어

코드 그것들을 설명해주는 것 모두를 소프트웨어

소프트웨어의 특성

  1. 비가시성(invisibility)

: 보통 눈으로 볼 수 있지만 사실 물리적인 대상과는 다름. Pc나 노트북, 핸드폰 같은 물리적인 장치보다는 개념적이고 무형적임

코드만 보거나 산출물만 보고는 파악하기 힘듦, 대표적인 특성, 비가시성 때문에 소프트웨어의 복잡도가 증가, 사용자가 보이지 않음

개발자, 의뢰자, 참여자들이 보이지 않은 비가시성과 고치기 쉬운 순응성으로 쉽게 고친다고 생각함 -> 엄청난 큰 문제

  1. 순응성(conformity)

: 환경에 따라 고치기 쉬움, 자동차를 찍어내고 나서 고치기는 어렵지만 소프트웨어를 뚝딱뚝딱 고치기 쉬움

Ex) 각 소프트웨어공학을 발표하는 포럼 전에 소프트웨어공학을 도입할 수 밖에 없었다는 사례 발표 시 안철수 왈 혼자 코딩할때는 필요없었는데 요구사항이 많아지면서 공학을 적용하지를 못하게 되었다. 왜 소프트웨어를 불법복제하고 요구사항을 함부로 말할까요?? ㅎㅁㅎ

정신과에 가서 상담 받고 10만원 내면 돈을 아까워 하는 편. 무형이니까. 물리적인 치료를 받으면 아까워하지 않는 편 -> 나갈 때 마다 정신과 의사가 영양제를 주니까 만족해한다

  1. 복잡성 (complexity)

: 수학을 계산하기 위해서 소프트웨어가 나오다가 점점 복잡한 일을 컴퓨터가 대신 해준다. 사람들이 하던 일들을 컴퓨터로 자동화하게 함. 지금은 존재하지 않는 세상을 만들지만 원래의 목적은 복잡한 일을 컴퓨터로 하자임.

  • 개발자들은 다른 공학과 다르게 접근하는 방향이 달라질 수 있다. 창의적인 작업이 될 수 있다. 사고를 구현하는 것이기 떄문에 사람마다 다를 수 있고 여러 의견을 조율하는 것이 어렵기도 하고 구현하기도 복잡하므로 복잡함
    1. 복제가능(Duplicability) : 복제가 쉬운 편
  • 복제 이유 중 하나가 비가시성이기도 함

Ex) 자동차 훔치는 것 vs 코드 가져오는 것

  1. 마모되지 않음
    • 자동차와 달리 낡지 않음

1.1.1소프트웨어의 유형(중요 x)

응용 소프트웨어, application software

시스템 소스프웨어 : 시스템 운영에 사용

주문형 소프트웨어 : si 기업에서 주로 하는 것

패키지 소프트웨어 : 대중들을 상대로 하기 위한 일반 대중들이 위한 기능을 하는 소프트웨어

임베디드 소프트웨어 : 장치 위에 내장됨 소프트웨어, 구글 글래스, 냉장고, 스마트폰 등등

  • 소프트웨는 코드만을 이야기하는 것이 아님

1.2소프트웨어 공학의 필요성(아주아주 중요)

1.2.1 소프트웨어 위기 (Software Crisis)

컴퓨터의 개발 과정에서 소프트웨어 개발 속도가 하드웨어 개발 속도를 따라가지 못해 사용자의 요구사항을 감당할 수 없는 문제가 발생하는 것

Untitled

하드웨어가 비용에서 많은 비율을 차지하고 있음. -> 점점 소프트웨어 관련에 비용이 많아짐 소프트웨어 개발 비용보다 유지보수 비용이 더 많이 든다(엄청 중요)

소프트웨어 비용이 가장 많은데 그 중에서 유지 보수 비용이 더 많이 듦

  • 소프트웨어를 넘겨준 후 유지보수하는데 사실 그 기간은 전 기간이라고 봄.
  • 왜냐면 개발 시 오류가 정말 많고 완벽한 소프트웨어는 없기 때문, 사용자의 요구사항이 또 바뀌면 바뀌어줘야 함
  • 소프트웨어는 늦게 발전하는데 하드웨어는 빨리 발전됨 -> 이거에 맞춰 발전해야 함

많은 방법론의 목표 : 유지 보수 비용이 작게 들게

일차적인 목적 – 고치기 쉽게 하자

Ex) 배열의 길이를 상수로 두는 이유는 지금은 10이지만 20으로 바꾸기 쉽기 때문

하드코딩보다는 상수로 선언해야하고 이직이 많아 나는 기억하지만 다른 사람은 모르게 되기 때문

최상위 이유는 유지보수를 줄이기 위해임!!

  • 하드웨어는 빨리빨리 발전한다(무어의 법칙)
  • 하지만 소프트웨어는 점점 복잡해지므로 비용이 점점 커지게 된다.

1.2.2 개발 지연과 낮은 신뢰도

  • 개발 비용이 늘어나고 점점 개발이 지연되고 고치는 일을 너무 많이 해서 신뢰도가 낮음

개발하고 나서 보니까 대부분 계획에서 벗어난 경우가 많음, 일정에서 벗어나거나 예산에서 벗어나는 경우

일정, 돈 다 무시하더라도 원하는 대로 돌아가지도 않음

  • 개발 지연, 신뢰도가 낮아짐
  • 사용자가 원하게 신뢰도가 맞게 하려면 공학적인 기법이 필요
  • 소프트웨어는 고치기 쉽고 보이지 않기에 변경이 매우 많음

가장 중요한 단어 중 하나 : 변경

  • 바뀔꺼야 생각하고 코딩해야 함, 변경되면 오류가 생기게 됨
  • 하드웨어와 달리 노후화에 의한 물리적 특성의 변화에 의한 것이 아닌 설계, 개발 과정에 유입된 오류에 의한 것

Untitled

하드웨어의 경우)

첨에 엄청 실패하다가 다시 테스트하면서 안정해지다가 나중에 하드웨어는 마모가 되면서 실패율이 올라간다

소프트웨어의 경우)

녹슬지 않기에 이상적으로는 첨에는 실패하지만 결과적으로는 낮아져야 하지만 실제곡선은 변경이 발생하고 그로 인해 실패율이 엄청 증가하고 다시 유지하다가 올라가고 그 과정을 반복 → 이상적인 곡선이 나올 수 없다.

Ex) 소프트웨어 결함 사례- 아리안 5로켓 이륙 폭파 사고

1.2.3 유지보수와 재작업

소프트웨어 비용이 하드웨어 비용보다 너무 많이 필요하게 되고 프로젝트 관리가 잘 안됨(비용 오버, 사용자 원하는 거 못만듦, 기간이 길어짐)그리고 변경이 계속 생기고 수정사항이 생겨서 유지보수가 필요하고 계속 재작업을 해야 함

  • 유지 보수가 필요한 이유 : 변경이 생기고 수정사항이 생기며 시스템에 남아 있는 오류가 있고 소프트웨어는 업그레이드가 흔하기 때문에 수정과 재작업이 필요

→ 막만들면 안된다, 공학적인 기법이 필요

  • 소프트웨어 자체에는 오류가 있고 수정에 의해 오류가 추가적으로 생길 수도 있기 때문
  • 기존의 기능을 뺴서 생기는 문제가 생기기 떄문

소프트웨어 개발의 문제점

  • 개발하고자 하는 바가 개발자도 설계하는 사람도 의뢰하는 고객도 첨에 잘 모름, 요구를 파악하는 것이 매우 어렵고 중간중간에 요구가 바뀌게 되어 변경이 생기고 이로 인해 재작업이 발생됨 → 공학적인 기법이 필요

=>what is needed, on time, and on budget 🙅🏻‍♀️

사용자가 원하는 것, 제 때 예산에 맞춰서 나오지 못한다! 신뢰도가 떨어지고 계획 안에 개발도 안되고 예산도 안맞다

-> 소프트웨어공학을 써야 한다

1.3 소프트웨어 공학이란?

소프트웨어 개발도 하드웨어처럼 공학을 적용해 보자, 건축에서 많이 차용해 옴

정의 : 소프트웨어의 Lifecycle(소프트웨어의 개발, 운영, 유지보수, 소멸)에 대한 체계적인 접근 방법(IEEE)

  • 체계적인 접근 : 한번만 결과를 내는 것이 아니라 누구나 똑같이 적용 시 똑같이 결과가 나오도록
  • 사용자의 요구를 만족시키기 위해 소프트웨어를 체계적으로 개발
  • 반복가능해야하고 재현 가능해야 한다. 일관성이 있어야 한다

소프트웨어 공학의 목표

품질 좋은 소프트웨어( 사용자가 원하는 기능)이 일번, 이것을 예산과 일정에 맞게 공급하는 것

소프트웨어 공학의 고려사항

  • 규모 : 규모에 따라 공학적인 기법을 적용할 수 있어야 한다
  • 품질과 생산성 : 품질을 만족시키고 생산성을 만족시켜야 한다. 즉 예산에 맞게 일정에 맞게
  • 일관성과 재현성 : 이 공학적인 기법들을 적용 시 일관적이고 동일한 기법 사용시 동일한 결과가 나와야 한다
  • 변경: 변경을 고려해야 한다

1.3.1 규모

조그만한 공학에서는 공학이 필요 없지만 소스코드의 줄이 길어지게 된다면 엔지니어링 식 접근 방법과 프로젝트 관리기법이 요구됨

  • 소규모일 때에는 정형화될 필요없지만 대규모되면 정형화되어야 한다.

엔지니어링 접근 방법이 요구됨 : 방법(method), 방법을 제공하는 절차(process), 절차를 지원해주기 위한 도구(tool)가 필요

프로젝트 관리 기법이 요구됨 : 전체 예산과 인력을 관리할 수 있는 관리 기법

Untitled

1.3.2 품질과 생산성

엔지니어링 작업에는 비용, 일정, 품질과 같은 변수가 중요

품질

: 최소한 사용자가 원하는 기능

비용과 일정

: 생산성이라고도 함

품질도 표준이 존재

품질의 표준 속성

Untitled

기능성(functionality)- 사용자가 원하는 기능(원래 정한 또는 내재된 요구를 만족시키는 기능을 제공하는 능력)을 만족

신뢰성(reliability) – 성능 만족, 소프트웨어가 정해진 수준의 성능을 유지할 수 있는 능력

사용용이성(usability) – 사용하기 쉬워야 한다, 쉽게 이해되고 배울 수 있고 사용될 수 있는 능력

효율성(efficiency)- 자원을 적절히 잘 써야 한다, 자원의 양에 따라 적절한 성능을 제공할 수 있는 능력

유지보수성(maintainability) - 유지보수, 정정&개선 시킬 목적으로 수정될 수 있는 능력

이식성(portability) – 별도의 수단이나 작동 없이 다양한 환경에서 적응될 수 있는 능력

ex) 윈도우, 리눅스 이식해도 잘 돌아가야 한다

1.3.3 일관성과 재현성

똑같은 방법을 해도 똑같은 결과가 나와야 한다

프로세스의 표준화가 필요

일관성

프로젝트 결과를 어느 정도 정확하게 예측이 가능

  • 일관된 품질을 일관된 생산성으로 만들어야 한다.

재현성

개발하는 시스템마다 높은 품질과 생산성을 갖도록 만드느 것

  • 개발능력, 결과의 재현성

1.3.4 변경

변경을 고려해야 하는데 소프트웨어는 순응성이라고 하여 비가시적이기에 고치기 쉬운데 사용자의 요구사항도 자꾸자꾸 바뀌므로 배포 이후 하드웨어 업그레이드도 있으므로 변경을 피할 수 없으므로 변경을 조절하고 수용 또한 중요

  • 비지니스 환경 변화는 매우 빠르고 소프트웨어는 변경을 어렵게 하는 물리적인 부분이 없으며 계속 소프트웨어는 계속 진화하고 변경됨

  • 변경을 조절하고 수용하는 것이 또 하나의 과제

    ex)생산성 좋은데 변경 수용이 안되면 그 방법론은 좋은 방법론이 아님

    • 일차 목표가 유지 보수비용을 떨어트리는 것이기 때문

변경은 소프트웨어 공학의 중요한 성장 요인

1.4 소프트웨어 공학의 접근 방법

Untitled

일반적인 프로젝트 수행 시 품질 생산성이 좋아질려면 기술, 인력, 프로세스가 좋아야 한다

소프트웨어에서는 주로 프로세스에 초점을 둔다(일을 하는 과정, 절차)

  • 소프트웨어를 개발하는 프로세스를 소프트웨어와 분리
  • 소프트웨어 자체에 집중 x. 개발 프로세스(소프트웨어 제작과정)에 집중

소프트웨어 엔지니어링 작업의 종류

  • 소프트웨어 개발 프로세스 : 시스템에 대한 비젼과 개념을 목표로 하는 컴퓨터 환경에 실행되는 소프트웨어로 바꾸는 작업, 개발과정이 잘되면 결과가 좋을 것
  • 품질보증 : SQA(software quality assurance) 개발 작업이 적절히 수행되었는지 확인, 성능을 만족하는가
  • 프로젝트 관리 : 전체 일정, 인력, 예산, 리스크 관리

1.4.1 단계적 개발 프로세스

Untitled

요구분석 -> 어떻게 구현할 것인지 설계 -> 실제로 구현 코딩 -> 품질보증하는 테스팅 …

단계를 나눠놓고 코딩하는 이유

  • 각 개발 단계에서의 관점이 다르기 떄문

    ex) 요구분석은 사용자의 관점만 필요, 설계,코딩에는 개발자의 관점, 테스팅은 개발자와 사용자의 관점

  • 개발하는 동안 정해진 시점에 품질과 진행을 체크할 수 있음

    ex) 이렇게 하면 인력이 얼마나 필요한지 산출물이 얼마나 필요한지 그 산출물이 설계의 입력이 될 것 -> 입력과 출력을 명확하게 알 수 있어 잘 진행되는지 확인이 가능

-단계가 병렬적으로 여러번 동시로 돌아가기도 한다.

1) 요구분석 : 시스템이 풀어야 하는 문제를 이해, what?

: 일층에는 머가 있고 이층에는 머가 있고 등등, 사용자가 먼지 해결해야하는 문제가 무엇인지. 여기서 초점은 what, 어떻게 만드는지는 들어가면 안됨, 개발자의 관점이 들어가며 안됨

  • 시스템으로부터 무엇이 필요한가
  • 문제를 분석 : 문제와 그 배경을 잘 이해하고 개발한 시스템의 요구 찾기
  • 요구를 정리 : 요구 명세서(requirement specification), 시스템 기능 외에도 설계에 영향을 주는 모든 요인을 문서에 기술

2)설계 : 문제의 솔루션을 계획, how?

: 개발자 입장에서 어떻게 구현할 것인지, how가 중요, 크게 설계하는 아키텍처, 모듈을 설계하는 상세설계

  • 요구를 어떻게 만족시킬 것인지 추구
  • 아키텍처 설계 : 시스템을 여러 컴포넌트의 집합체로 보고 각 컴포넌트가 어떻게 상호작용하는지에 초점
  • 상세 설계 : 모듈 내부 논리를 작성

3)코딩

: 설계도면을 보고 개발자들이 구현한다, 유지보수하기 쉽게 만들어야 한다

  • 시스템 설계를 프로그래밍 언어로 변환
  • 단순함과 명확성을 추구

4) 테스팅 : 소프트에어의 결함을 찾아냄

: 목적은 오류를 찾아내는 것, 기본적인 품질보중해주는 수단이 되고 하나의 모듈만 테스트, 내함수와 다른 함수 연결해서 테스트, 전체 시스템 테스트, 사용자 입장에서 테스팅하는 것

  • 단위 테스팅(unit testing) : 모듈이나 컴포넌트를 개별적으로 시험
  • 통합 테스팅(integration testing) : 모듈 사이의 연결을 시험
  • 시스템 테스팅(system testing) : 시스템이 모든 요구를 만족하고 있는지
  • 인수 테스팅(acceptance testing) : 시스템이 잘 실행되는지 고객에게 데모

Untitled

앞단계와 마무리에 프로젝트 관리가 전체적으로 들어감

1.4.2 품질 보증

Untitled

1)확인(verification) : 선택된 프로세스와 방법에 맞게 수행되었는지 체크

각각의 단계가 잘 진행되었는지, 입력과 출력이 잘 되었나 확인

프로세스와 방법이 맞게 잘 수행되었는지

2)검증(validation) : 생성된 결과물의 정확성을 체크 **

나온 산출물들이 제대로 완성되었는가

  • 정적 확인 : 소프트웨어를 실행하지 않고 결과물의 정확성을 체크
  • 동적 확인 : 소프트웨어를 실행시켜 잘 작동하는지 확인

3)테스팅

동적 확인 작업, 테스트 결과가 예상되는 결과와 일치하는지 체크

1.4.3 프로젝트 관리

  • 작업과정에서 자원을 어떻게 할당할 것인가

    cf. 여기서 자원 시간, 비용, 인력. 리스크 관리 등등을 말함(인력관리, 시간관리, 리스크관리)

  • 계획단계에서 주로 일어남