프로그래밍 언어의 역사

  ** OOP는 필연성을 가지고 등장

  * 객체지향 기술에 대한 일반적인 견해
 – 현실 세계의 사물을 보는 견해에 따라 소프트웨어를 만드는 전혀 새로운 사고 방식
 – 종래의 개발 기술을 바꾸어 놓을 것.

  * OOP(필자의 견해)
 – 그 이전의 프로그래밍 기술을 기초로 결점을 보완하기 위해서 고안된 것.

  * 객체지향 기술
 – OOP를 발전, 응용한 것으로 종래부터 있던 우수한 개발 기술의 연장 선상에 있던 것.
 – 품질 좋은 프로그램을 높은 생산성으로 만들기 위한 실천적인 기술.

   ** 초창기에는 기계언어로 프로그램을 작성

  * 컴퓨터?
 – 2진수로 스여진 기계 언어밖에 해설할 수 없음.
 – 1940년대 처음 등장

   ** 프로그램 언어의 첫걸음은 어셈블리 언어

   ** 고급 언어의 발명으로 보다 친숙해진 프로그램

  * 고급언어
 – 컴퓨터가 이해하는 명령어를 하나하나 기술하는 것이 아님
 – 보다 사람이 알기 쉬운 “고급스러운” 형식으로 표현
 – FORTRAN(1957년), COBOL(1960년)

  * 1960년대 말 북대서양조약기구(NATO)
 – “소프트웨어 위기” 선언

   ** 알기 쉬움을 중시하는 구조적 프로그래밍

  * 구조적 프로그래밍
 – “소프트웨어 위기”에 대응하기 위해 제안된 아이디어
 – 기본적인 사상
+ 바르게 동작하는 프로그램을 작성하기 위해서는 알기 쉬운 고조로 하는 것이 중요하다.
 – 구체적인 방법
+ GOTO문 폐지
+ 프로그램 논리를 3가지 구조(순차 진행, 조건 분기, 반복)만으로 표현

   ** 서브루틴의 높은 독립성을 유지보수에 강점

  * 서브루틴?
 – 1940년대 발명
 – 여러 장소에 나타나는 같은 명령의 나열을 한곳에 모음
 – 효과
+ 프로그램 사이즈가 작아짐
+ 프로그램 작성 시간 절약

  * 서브루틴의 독립성을 높이는 방법
 – 메인루틴과 서브루틴에서 공유하는 정보를 적게 하는 것.

  * 전역변수(global variable)의 문제점
 – 프로그램 전체의 어디에서도 접근 가능
 – 어느 서브루틴이 언제 변경하거나 참조하고 있는지 알기 어려움
 – 전역변수의 변경 시 : 프로그램 전체 논리 확인 필요

  * 전역 변수 문제점의 해결 방안
 – 지역변수 사용
 – 값 복사에 의한 인수값 전달 방법(Call by value)

   ** “GOTO 없는 프로그램” 구조적 언어

  * 구조적 언어 등장
 – 구조적 프로그램 이론을 기초로 함
 – ALGOL, Pascal, C언어 등
 – 명확한 제어 기술 가능
+ if문, case문, while문, for문 등의 명령을 사용
+ 당시 COBOL과 FORTRAN등에서는 기본 3구조를 기술할 수 없음
 – 별칭 “GOTO없는 프로그래밍”
 – 대표적인 언어 : C

   ** 진화 방향은 유지보수성과 재사용성

 – 기계언어 : 컴퓨터가 직접 해석하는 기계 언어를 2진수/16진수로 기술
 – 어셈블리 언어 : 기계 언어를 기호로 기술
 – 고급 언어 : 복수의 기계 언어를 중요한 고급 문법으로 기술
 – 구조적 언어 : 기본 3구조(GOTO 없는)의 제공으로 서브루틴의 독립성 강화

   ** 남겨진 문제는 전역변수와 빈약한 재사용

  * 구조적 프로그래밍
 – 수년 전까지 대학과 기업의 신입사원 연수에서 거론되는 주제
 – 아직 해결되지 않은 2가지 주제가 남아 있음
 – 2가지 문제
+ 전역변수
+ 빈약한 재사용

  * 전역변수 문제
 – 해결안 : 지역변수 사용, Call by value
 – 미해결 부분 : 전역변수로 보전
 – 대규모 프로그램에서 전역변수 문제는 심각

  * 빈약한 재사용의 문제
 – 구조적 언어에서 재사용 가능한 것은 “서브루틴”

SW 프로젝트 작업

    1.6 소프트웨어 프로젝트 작업

  * 소프트웨어 프로젝트 작업
 – 요구분석, 설계, 프로그래밍, 품질보증, 프로젝트 관리
 – 작업의 종류와 순서는 개발 프로세스 모형에 따라 다름

   1.6.1 요구분석과 명세화

  * 고객 문제 해결 방법
 – 고객의 비지니스 환경, 문제점, 기술 이해
 – 작업과 순서 결정
 – SW가 제공해야 할 기능 결정

  * 도메인 분석
 – 관련 배경 지식 이해
 – ex) 기업회계 SW : 장부기장 방법, 회계 시스템
 – ex) 운영체제 SW : 프로세스 관리, 메모리 관리, 파일관리 기법

  * 문제 정의
 – 시스템의 범위를 더 좁혀 나가는 작업

  * 요구 추출
 – SW가 해야 하는 일에 대한 사람들의 아이디어 취합

  * 요구 분석
 – 정보 정리, SW기능 결정

  * 요구 명세화
 – 기능 정의를 위해 명령어 형태로 작성

   1.6.2 설계

  * 요구 사항들을 어떻게 구현할 것인가를 결정하는 과정

  * 시스템 엔지니어링
 – HW구현 부분, SW구현 부분 결정
 – 임베디드 시스템, 리얼타임 시스템에서만 필요

  * SW 아키텍처
 – 서브시스템으로 분할 방법, 서브시스템간의 상호 작용 결정

  * 상세 설계
 – 각 서브시스템의 상세한 사항데 대한 구성 방식 결정
 – 상세 사항 : 자료구조, 클래스, 알고리즘, 프로시져

  * 사용자 인터페이스
 – 사용자가 시스템과 어떻게 상호작용 하는지 결정

  * 자료저장 형태 결정
 – 자료를 어떻게 저장하는지 결정

   1.6.3 모델링

  * 모델링[정의]
 – 도메인이나 SW의 표현을 만들어 나가는 과정
 – 요구 분석, 설계에서 모델링 접근 방법 사용

  * 사용사계 모델링
 – SW 사용자에 의하여 수행 되는 작업을 순서대로 표현

  * 정적 모델링
 – 도메인이나 SW에 존재하는 클래스나 객체를 표현

  * 동적 모델링
 – 시스템의 상태 변동 또는 수행하는 작업과 같은 것을 나타냄

   1.6.4 프로그래밍

  * 프로그래밍
 – SW ENG.의 모든 작업을 통합
 – 높은 수준의 설계를 정해진 프로그래밍 언어로 옮김.
 – 디자인의 마지막 단계

  * SW Architect
 – 상위 수준의 설계를 담당하는 인력

  * SW ENG.연구의 목적
 – 프로그래밍의 자동화

  1.6.5 테스트

  * 단위(모듈) 테스트
 – 개별 코드 테스트

  *통합 테스트
 – 모듈을 연결하여 테스트
 – 전체 모듈이 모두 연결될 때 까지 하나식 점증적으로 추가

  * 시스템 테스트
 – 완성된 시스템이 원하는 대로 작동하는지
 – 성능은 어떤지 요구 분석 결과와 비교

   1.6.6 품질 보증

  * 품질 보증[정의]
 – 품질 목표를 달성하려고 작업하는 모든 프로세스

  * 리뷰와 인스펙션
 – 요구, 설계, 코드가 원하는 수준에 맞는지 토의

  * 테스트
 – SW가 예상대로 작동하는지 체계적으로 수행

  * 검증(Validation)
 – 요구가 교객이 요구하는 문제인지 아닌지를 결정

  * 검토(Verification)
 – 요구를 설계하고 구현하는 과정이 맞는 것인지 판단

   ** 프로세스 관리(관리자의 역할)

  * 시스템 비용 추정
 – 요구사항 연구, 디자인, 구현하는데 드는 노력 결정

  * 계획
 – 개발자들에게 일 할당
 – 완료 일정 결정

   ** SE 토픽 1.5 – ISO 12207 SW 프로세스 표준
 – SW 개발 관리를 위한 절차, 방법, 도구들을 자세히 정리하여 틀을 정해 줌.
 – SW 공급자나 발주자 사이에 정확한 의사 전달을 위하여 사용

 – 입찰 준비부터 공급하기까지 프로젝트의 계약에 관한 작업
 – 개발, 운영, 유지보수 하는 입장의 작업
 – 품질 관리 등 보조 작업
 – 프로세스 관리차원의 작업

   ** 초보 엔지니어링에게 가이드 역할
 – SW 개발 프로세스의 성숙도 평가에 관한 기준으로 사용

품질

    1.4 소프트웨어 공학 품질

  * 소프트웨어 공학의 목표?

  * 질 좋은 소프트웨어?
 – (예) 신발의 품질 요소(발이 편한지, 내구성이 있는지, 용도에 적합한지, 디자인이 마음에 드는지)

  * 소프트웨어 품질을 정의하기 어려운 이유?
 – 매우 많은 품질 요소들이 소프트웨어에 내포
 – 관련자에 따라 중요하게 생각하는 품질 요소가 다름

   1.4.1 소프트웨어 품질 관점

  * 고객
 – SW 구매, 주문 주체
 – 경제적 관점에서 평가

  * 사용자
 – 신뢰도 및 효율성
 – 배우고, 사용하기 쉽게

  * 개발자
 – 오류가 적은 SW
 – 문서화가 잘된 SW

  * 개발관리자
 – 매출이 증가하는 SW
 – 고개 지출 절약되는 SW

  * 소프트웨어 품질에 대한 관점
 – 발주자(최소 비용, 생산성, 융통성)
 – 사용자(효율성, 기능의 정확성, 이해 용이성, 사용 용이성, 일관된 통합)
 – 유지 보수자(신뢰성, 이식성, 재사용성, 유지 보수성, 상호 운용성)

   1.4.2 소프트웨어 품질 특성

 – 사용 용이성(usability), 효율성(efficiency), 신뢰성(reliability), 재사용성(reusability), 유지 보수성(maintainability)

  * 사용 용이성(usability)
 – 사용자가 소프트웨어를 사용하기 쉬운 성질
 – 초보자가 쉽게 배울 수 있는 특성
 – 전문가가 효율적으로 사용할 수 있는 특성
 – 오류를 쉽게 다룰 수 있는 특성

  * 효율성(efficiency)
 – 자원 사용이 적은 것
 – CPU시간, 메모리
 – 디스크 용량, 네트워크 대역

  * 신뢰성(reliability)
 – 결함이 적은 SW
 – 구현과 변경이 쉬운 설계
 – 고장 시 쉽게 복구 가능한 SW

  * 유지 보수성
 – 소프트웨어를 쉽게 변경할 수 있는 성질

  * 재사용성
 – SW 부품을 조금만 변경하여 다른 시스템에서 사용

 
   1.4.3 SW 품질 요소는 trade-off 관계

  * 효율성 <-> 이해 용이성
  * 신뢰성 <-> 효율성
  * 사용용이성 <-> 효율성

   1.4.4 좋은 엔지니어링 작업이란?

 – 품질 목표 설정
 – 시스템 디자인
 – 특정 디자인 요소의 최적화

    1.4.5 외부 품질 요소

  * 정확성(Correctness)
 – 기능적으로 맞게 동작, 표준에 적합
 – 요구 분석서의 기능과 일치하는지 점검

  * 신뢰성(Reliability)
 – 소프트웨어가 주어진 기간동안 제대로 작동할 확률
 – 오류에 비례
 – 정확성을 위한 필요조건

  * 강인성(Robustness)
 – 요구 명세에 표시하지 않은 상황(오류 입력)에서도 제대로 작동하는 성질

  * 성능(Performance)
 – 수행속도
 – 알고리즘의 시간 복잡도
 – 시뮬레이션, 스트레스 테스트

  * 사용 용이성(Usability)
 – 시스템을 친근하게 느낄 수 있는 성질
 – 사용 대상에 따라 달라질 수 있음
 – 사용자 인터페이스, Human factor

  * 유지 보수성(Maintainability)
 – 보수성 : 정해진 기간에 SW 결함을 해결할 수 있는 성질
 – 진화성 : 잠재적 발전 가능성

  * 재사용성(Reusability)
 – 소프트웨어 부품(라이브러리, 클래스 등)의 성질
 – 확장 가능성 : openness
 – 적응성 : adaptability
 – 이용 용이성 : closeness

   1.4.6 내부 품질 요소

 – 원시코드에 있는 주석의 분량
 – 종복 구조의 깊이로 측정되는 프로그램의 복잡성

소프트웨어 공학

    1.3 엔지니어링과 소프트웨어 공학

  * 복잡한 대규모 문제 해결 방법?
 – 엔지니어링 접근 방법

  * 요리의 예
 – 가정집인 경우
 – 음식점인 경우 : 재료 구입 계획, 조리 과정 연구 필요
 – 음식점 체인인 경우 : 요리 프로세스의 표준화, 마케팅 전략, 전문 인력 교육 필요

   1.3.1 엔지니어링의 발전 원리

  * 단계적으로 발전
 – 개인의 재주(art)에 의존 -> 숙련공(craft)의 일반화 -> 공학 탄생

  * 엔지니어링 원리의 발전 단계
 대량생산—–|—- 산업화-|— 엔지니어링
 장인들의 기술 -|      과학–|

   1.3.1-1 소프트웨어 공학의 출현 배경

  * 소프트웨어 분야도 엔지니어링 원리의발전 단계를 밟아 발전
 – 개인 프로그래밍 능력에 의존 -> 공학적 접근 방법 필요

  * 소프트웨어 공학의 출현 배경
 – 소프트웨어 개발, 구입 비용의 급증
 – 질 높은 소프트웨어 중요성의 인식
 – 소프트웨어 분야에도 엔지니어링 원리에 관심이 모아짐
 – 개발, 유지보수 비용의 효율적에 대한 극대화 필요
 – 해결안 : 유지보수의 체계적, 합리적인 접근 방법 필요

  * 소프트웨어 공학 정의 [IEEE 소프트웨어 공학 용어 표준]
 – “소프트웨어의 개발, 윤용, 유지보수 및 팍에 대한 체계적인 접근 방법”

   1.3.1-2 공학

 – 과학과 수학을 기초로 하여 구조나 기계, 생산 공정, 시스템 등의 생산에 체계적인 방법을 적용시키는 것
 – (예) 토목 엔지니어가 도로나 댐, 교량과 같은 구조물 건설에 공학 원리와 기술을 적용하는 것.
 – 절차와 표준 : 구조 설계, 건설
 – 지침(guideline) : 지진과 바람의 영향에 대하여 설계할 때 고려사항
 – 고려 사항 : 철골, 콘크리트, 기타 자재가 견딜 수 있는 허용 외압
 – 시험 : 설계가 완성되면 모형에 의 한 시험
 – 토목 엔지니어에게는 기술, 절차, 도구가 잘 계발되어 있음

  * 소프트웨어 공학
 – 공학적 원리에 의하여 소프트웨어를 개발하는 것.

   1.3.1-3 소프트웨어 공학의 목표

  * 품질 좋은 소프트웨어를
 – 개발이 제대로 되고 있는지 확인, 품질 점검

  * 최소의 비용으로
 – SW를 최적의 비용으로 계획된 예산에 맞추어 개발하는 것

  * 계획된 일정에 맞추어 개발한다.
 – SW는 계획된 기간 내에 개발되어 정해진 날에 인도

  * 생산성 향상
 – 여러 가지 방법론, 도구, 관리 기법 사용

   1.3.1-4 방법

  * 방법이라는 단어의 사용 예
 – 요리는 잘하는 방법

  * 방법의 특징?
 – 작업 과정과 밀접한 관계를 가지고 있다.
 – 하나의 작업 단계에도 적용할 수 있는 여러 가지 방법이 있다.
 – (예) 음식을 익히는 방법(증기에 찌는 방법, 졸이는 방법, 불에 굽는 방법)

  * 방법이란?
 – 어떤 결과를 생성하기 위해 적용하는 기법과 절차

  * 소프트웨어 공학에서의 방법
 – 요구 분석 방법
 – 설계 방법 및 표현 방법

   1.3.1-5 도구

  * 일상 생활에서 도구라는 단어가 쓰이는 곳?
 – 목수의 연장
 – 요리사의 조리 도구
 – 워드프로세서

  * 소프트웨어를 개발하는 과정에서의 도구?
 – 설계 도구, 프로그래밍 도구, 프로젝트 관리 도구 등

  * 요리 도구만 좋으면 맜있는 요리가 나온다!!!

  * 도구란??
 – 기구, 자동화된 시스템

   1.3.1-6 프로세스

  * 작업 순서, 작업 공정, 작업 절차
 – 조리 순서(recipe)
 – 자동차 조립 과정

  * 프로세스란?
 – 도구와 기법을 사용하여 작업하는 순서

  * 소프트웨어 개발 프로세스?
 – 프로젝트 팀이 정한 절차

  * 많은 경험은 최적의 프로세스를 만든다

  * 프로세스의 성숙도를 단계적으로 정의한 모델?
 – CMM(Capability Maturity Model)
 – ISO 15504(SPICE)

   1.3.1-7 패러다임

  * 패러다임의 일반적인 사용 예
 – 음식 스타일(예. 한식, 일식, 중식, 퓨전 등)

  * 소프트웨어 개발에서의 패러다임
 – 절차적 프로그래밍
 – 객체지향 프로그래밍
 – 컴포넌트 개발 방식

  * SE 토픽 1.4 소프트웨어 공학 관리자
 – 사용자 : 개발한 소프트웨어를 사용할 사람
 – 고객 : 소프트웨어를 주문하고, 구매하는 담사자
 – 소프트웨어 개발자 : 소프트웨어 엔지니어. SW를 개발, 유지 보수하는 사람
 – 개발 관리자 : 소프트웨어 개발 부서를 관리하는 사람

소개

    소프트웨어의 영향

  * 소프트웨어의 영향
 – 기업의 경영과 시장, 학교 교육, 사무실의 작업환경
 – 가정 생활과 여가 활동
 – 미래의 경제와 우리 생활

  * 소프트웨어의 개발
 – 전문적인 기술을 가진 엔지니어가 필요
 – 과거의 소프트웨어 : 개인의 특출한 솜씨로 게작 가능

  * 소프트웨어 개발과 오케스트라
 – 전체적인 하모니가 중요
 – 그 집단의 엔지니어링 숙달정도에 크게 좌우

    1.1 소프트웨어

  * 소프트웨어
 – 프로그램과 프로그램의 개발, 운용, 보수에 필요한 관련 정보 일체
 – 프로그램 +(문서, 정보)

  * SE 토픽 1.1 소프트웨어가 다른 점
 – 다른 엔지니어링 결과물에 비해 개념적이고 무형적임
 – 적은 비용으로 복제, 대량 생산 가능
 – 노동 집약적 산업
 – 초심자의 제품은 이해하기 어렵고, 수정하기 어려움
 – SW는 쉽게 변경 가능
 – SW는 닳아 없어지지 않음

  * 소프트웨어 특징
 – 품질 향상의 어려움
 – 사용자 수준에 못 미치는 품질

  * 소프트웨어 위기 현상(발생 원인)
 – 납기 미 준수
 – 예산 초과
 – 결함으로 인한 부적합, 폐기, 수정의 필요
 – 폭발적으로 늘어나는 수요
 – 기하급수적으로 커지는 공급
 – 느린 생산성 향상
 – 품질 향상의 어려움

  * 소프트웨어 위기 이유
 – 소프트웨어의 복잡성
 – 인간의 작업에 대한 예측의 어려움

  * 소프트웨어 공학의 목적
 – SW에 대한 공학적 접근 방법 습득

    1.1.1 소프트웨어의 유형

  * 주문형 소프트웨어
 – 특정 고객의 수요를 만족하기 위하여 개발된 SW
 – (예) 웹사이트, 대학의 종합정보시스템

  * 패키지형 소프트웨어
 – 공개된 시장에 내놓고 판매하기 위한 것
 – (예) 워드프로세서, 웹브라우저, 운영체제

  * 임베디드 소프트웨어
 – 시장에서 판매되는 하드웨어 장치
 – (예) 세탁기, VCR, 자동차 등에서 수행되는 소프트웨어

    1.2 소프트웨어 공학

  * 소프트웨어 개발 = 소프트웨어 공학(?)

  * 집안 연못에 다리 구조물 설치 vs 한강 다리 건설

  * 소프트웨어 엔지니어링이란?
 – 고객의 문제를 해결해주기 위하여 대규모의 품질 좋은 소프트웨어 시스템을 정해진 시간과 비용으로 개발하거나 발전시키는 체계적인 프로세스.

   1.2.1 고객의 문제를 해결

  * SW ENG. 목표
 – 고객의 문제 해결

  * SW ENGer. 의 역할
 – 현 시스템 그대로 사용, 새로 개발, 기성 제품 구입 판단 및 결정

   1.2.2 체계적인 개발과 발전

  * 소프트웨어 개발
 – 엔지니어링 작업
 – 개발자가 잘 이해하고 있는 기술을 조직된 원리와 방법으로 적용하는 과정

   1.2.3 대규모 고품질 소프트웨어 시스템

  * 소규모 시스템
 – 프로그래머 홀로 성공적으로 개발 가능

  * 대규모 시스템
 – 매우 복잡함
 – 엔지니어링 원리 적용이 필요
 – 팀워크의 중요성
 – 작업 분할 방법

   1.2.4 비용, 시간 제약

  * 엔지니어링 작업의 특징
 – 경제적 제약 사항 고려

  * 경제적인 제약이란?
 – 시간, 인력 등의 자원에 대한 제한
 – 비용 대비 이득이 있는가

  * 소프트웨어 엔지니어 약할
 – 정해진 예산과 시간 안에 완성
 – 실현 가능한 계획 작성
 – 시스템 개발 시 필요한 작업, 기간 예측 가능해야 함