250914 - 소웨공 chap0 복습

하드웨어 = 제조, Manufacturing, 무결함률 99.99966%

소프트웨어 = 개발, Development, 성공률 30%

 

소프트웨어 개요

어디에나 존재하는 소프트웨어 → 고장 사례도 많음, 특히 최근 자동차 사고는 소프트웨어 결함

 

소프트웨어

: 프로그램 + 프로그램의 개발, 운용, 보수에 필요한 정보 일체

즉 한 번 만들고 끝나는게 아니라 만드는 과정에서 생산되는 모든 산출물들을 포함

 

소프트웨어의 특징

• 복잡성(complexity) : 그냥 단순히 동작하는게 x
• 순응성(conformity) : 에전에 만든 시스템을 환경에 맞춰 고쳐 사용
• 변경성(changeability) : 사용자 요구사항, 설계, 코드… 등 변경 발생 가능
• 비가시성(invisibility) : 눈에 보이지 않기 때문에 관리가 어려움. 특히 시스템 구조의 경우

 

소프트웨어 유형

 

소프트웨어 시스템

System : 필요한 기능을 실현시기키 위해 관련된 요소들을 어떤 법칙에 따라 조합한 집합체

연결 요소가 많아서 점점 복잡해진다

 

소프트웨어 개발작업

소프트웨어 개발의 기본 활동

• 명세화
• 설계
• 구현
• 검증
• 유지보수

소프트웨어는 사람의 지적 활동에 의해 구축된다

 

소프트웨어 개발 작업의 특징

• 명세화의 어려움 : 설계로 넘어가기 전, 의뢰인도 자기가 뭘 원하는지 잘 모르는 문제
• 재사용의 어려움 : 그부분만 딱 떼어 사용 가능하게 만들어야!
• 예측의 어려움
• 유지보수의 어려움 : 코드 개발자 ≠ 유지보수 하는 사람

 

소프트웨어 위기(software crisis)

: 소프트웨어 수요가 급격히 증가하고 그 복잡성이 증가함에 따라 기존 방법이 충분하지 않아 발생한 문제

 

소프트웨어 공학

공학적 접근 : 즉흥적인 개발(Code-and-Fix)

 

문제점 : 개발 지연, 예산 초과, 낮은 품질, 유지보수 곤란, 재작업

⇒ ok, 이런 문제를 공학적으로 해결해보자!

 

소프트웨어 공학의 정의

: 질 좋은 소프트웨어를 경제적으로 생산하기 위해 공학, 과학 및 수학적 원리와 방법을 적용하는 것

: 소프트웨어의 개발, 운용, 유지보수에 체계적이고, 숙달되고 수량화된 접근법을 적용하는 것 즉 소프트웨어에 공학을 적용하는 것

 

공학적 접근이 필요한 이유

: 보고 만질 수 없는 무형성, 진화성 등 소프트웨어 자체의 특성 + 제조가 아닌 개발 과정

• 수시로 바뀌는 요구사항
• 사람에 의존하여 개발되는 특성 (개인의 특성)
• 요구되는 신뢰도에 따라 분석의 종류와 깊이를 알 수 없음 (의사소통의 어려움)
• 프로젝트 규모에 따른 인력, 비용, 의사소통, 복잡도 등이 기하급수적으로 증가

 

소프트웨어 공학의 목표

• 복잡도 낮춤
• 비용 최소화
• 개발기간 단축
• 대규모 프로젝트 관리
• 고품질 소프트웨어
• 효율성

⇒ 여러가지 원리와 방법을 적용하여 품질 좋은 소프트웨어를 최소의 비용으로 계획된 일정에 맞추어 개발하는 것!

 

공학적 접근 방법 - 방법, 절차, 도구 사용

• 엔지니어링 작업에서는 비용, 일정, 품질과 같은 변수가 중요
• 일관성 : 프로젝트의 결과를 어느 정도 정확하게 예측 가능, 더 높은 품질의 제품을 생산
• 프로세스의 표준화 필요
• 결과의 재현성

오늘날 비즈니스 환경 변화는 매우 빠름 → 변경을 조절하고 수용해야!

 

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

품질과 생산성을 좌우하는 세가지 : 인력, 프로세스, 기술

• 인력 : 능력, 교육 및 동기가 부여된 인원
• 프로세스 : 작업들의 관계를 정의하는 절차와 방법
• 기술 : 도구와 장비

⇒ 소프트웨어를 개발하는 프로세스를 소프트웨어 자체와 분리

 

소프트웨어 공학의 작업

1. 단계적 개발 프로세스
2. 품질 보증(QA)
3. 프로젝트 관리

 

1. 단계적 개발 프로세스

: 소프트웨어의 문제를 나눠 여러 개발 단계에서 다른 관점을 다루기 때문

소프트웨어 개발을 코딩에 치중하지 않고 요구분석, 설계, 코딩, 테스팅 등 정해진 절차에 따라 작업

 

   2. 품질보증

: 개발되고 있는 소프트웨어가 요구와 품질 수준을 만족시킬 것이라는 것을 보장하는 작업

• 확인(verification) : 요구분석 → 설계 → 코딩 → 테스팅 → 유지보수
• 목표에 맞게 되었는지 단계 별로 확인
• 검증(validation) : 요구분석명세서, 원시코드, 소프트웨어
• ex. 유효성 검증 : 사용자가 원하는 대로 유용하게 만들어졌는가?

   3. 프로젝트 관리

소프트웨어 프로젝트에 대한 세 가지 제약 조건 → 범위, 시간, 비용

프로젝트 관리 활동

• 프로젝트 계획
• 자원관리
• 리스크 관리
• 프로젝트 수행과 모니터링

 

소프트웨어공학의 원리

1. 정형성(Formality)

• 수학적 표현이 가능하고 이를 증명하는 것이 가능해야 한다
• 프로그래밍 언어들은 정형성을 근거로 만들어짐
• 분석 및 설계에서 사용되는 정형화 기법
• 사용자 요구사항을 표현하는 UML 모델도 정형화의 원리

 

   2. 엄격

• 정형화 대신 사용할 수 있는 원리
• 소프트웨어의 명세 또는 문서화를 엄격하게 함으로써 프로세스의 재사용을 향상

⇒ 정형성과 엄격함은 명확한 표현을 통해 모호함을 줄이려는 원칙

 

   3. 관심사의 분리

• 개발하는 소프트웨어의 규모가 크고 복잡해짐에 따라 해결해야 하는 문제들을 효과적으로 다루기 위한 방법
• 소프트웨어 개발 과정에서 각 단계별, 품질별, 크기별, 역할별로 분리하여 문제를 해결
• ex. 분석 과정에서는 사용자의 요구사항에 집중하고, 요구사항을 명확하게 정의하는데 관심

 

   4. 모듈화

• 소프트웨어 공학에서 가장 많이 사용되고 있는 중요한 원리
• 소프트웨어는 수많은 모듈로 구성
  • 모듈들이 정보를 서로 교환
  • 가능한 모듈 간의 정보를 공유하거나 교환하는 횟수를 줄일 수 있는 방법으로 설계
  • 모듈화의 기준 : 응집력과 결합력
  • 객체기반개발(OOD), 컴포넌트기반개발(CBD), 서비스기반 아키텍처(SOA)등이 모듈화를 기반으로 하는 기법들

   5. 추상화

• 현실세계의 주어진 문제나 요구사항을 중요하고 관련 있는 부분만을 왜곡하지 않게 추출하여 간결하게 기술하거나 만드는 작업
  • 복잡한 소프트웨어 개발을 단계적으로 구현하기 위해 각 단계별 목적에 필요한 정보 이외의 내용은 생략함으로써 사용자나 개발자가 쉽게 문제를 이해할 수 있음
  • ex. 설계 시 사용되는 디자인패턴

 

   6. 변화 예측

• 소프트웨어를 개발할 때 미래에 예상되는 변화를 예측하여 변화에 쉽게 대응할 수 있도록 하자
• ex.
  • 3-tier 형식의 클라이언트/서버 구조 : UI와 business logic 구분
  • SOA(Service-Oriented Architecture) 와 웹서비스 : 이기종간의 통합과 연계이슈 해결을 위한 변화 예측의 원리 적

 

   7. 일반화와 점진화

• 일반화객체와 컴포넌트가 대표적인 일반화의 예
• : 가능하면 에외적이거나 특이한 사항이 아닌 공통적으로 활용 가능한 솔루션을 제공하여 재사용성을 높이고자 함
• 점진화분석, 설계, 구현 등으로 분리한 소프트웨어 개발 과정은 점진화를 이용한 것!
• : 개략적인 것부터 해결하고 순차적으로 조금씩 덧붙여서 완성해 나가는 방법