소프트웨어 소프트웨어란? 소프트웨어의 특성 프로그램과 프로그램의 개발, 운용, 유지보수에 필요한 관련 정보 일체

Presentation on theme: "소프트웨어 소프트웨어란? 소프트웨어의 특성 프로그램과 프로그램의 개발, 운용, 유지보수에 필요한 관련 정보 일체"— Presentation transcript:

1 소프트웨어 소프트웨어란? 소프트웨어의 특성 프로그램과 프로그램의 개발, 운용, 유지보수에 필요한 관련 정보 일체
프로그램과 프로그램의 개발, 운용, 유지보수에 필요한 관련 정보 일체 소프트웨어는 프로그램의 동적인 의미. 프로그램은 형식 언어(formal language)로 표현된 지적 구축물 소프트웨어의 특성 비가시성(Invisibility) 개념적, 무형적 구조가 코드 내에 내재 복잡성(Complexity) 개발 과정이 복잡 대상 업무, 대상 시스템이 난해 순응성(Conformity) 요구나 환경 변화에 적절히 변형 가능 복제 가능성(Duplicability) 테스팅의 어려움(Intestability) 변경 가능성(Changeability) 응용 종속성(Application dependency)

2 소프트웨어의 유형 소프트웨어 분류 체계 기능에 의한 소프트웨어의 분류 기능 : 시스템 소프트웨어, 응용 소프트웨어
개발 과정 : newly-built, 재사용(reuse), modification and adaptation of existing software, porting 하드웨어 환경 : multiprocessor, ... 요구되는 신뢰도 : critical, ...., non-critical 소프트웨어 크기 : programming-in-the-small, .... 데이터 특성 : 그래픽, 이미지, 텍스트, 음성, .... 기능에 의한 소프트웨어의 분류 < 시스템 소프트웨어 > 운용 : Operating systems, DBMS, .... Utility 구현 : Compiler, 여러 개발 도구들, .... < 응용 소프트웨어 > 모델링, 시뮬레이션 : flight simulation, OR, war games, ... 응용 기술 : OA, CAD/CAM, POS, CAI, ...

3 소프트웨어의 유형 정보 시스템(Information Systems) 대량의 데이터의 분류, 저장, 검색에 관심
컴퓨터 초심자들도 데이터베이스에 쉽게 접근할 수 있도록 인터페이스 제공 < 시스템 사례 > electronic fund transfer network credit card authorization services airline reservation systems air traffic control systems < 정보 시스템의 특성 > 시스템이 정적(static)이지 않다. 데이터 설계는 비중이 큰 반면 제어 구조는 비교적 간단하다. 개발, 운용 및 유지 보수에 많은 노력과 비용이 든다. 도큐먼트가 중요한 요소 < 경영 정보 시스템(MIS) > 조직에서의 경영, 의사 결정 등을 지원하기 위해 여러 정보를 효과적으로 제공하는 통합된 시스템 TPS, EDPS, DSS, EIS, SIS, Information Center, OA

4 소프트웨어의 유형 제어 시스템(Control Systems) 내포 시스템(Embedded Systems)
프로세싱을 유발하는 이벤트를 감지하여 처리하고 주기적으로 시스템의 상황을 보고하는 시스템 monitor sensors control equipment display operator input processing interface peripheral equipment < 시스템 사례 > 공정 제어(process control) 교통 제어(traffic control) 의료 시스템(medical systems) 무기 제어(firing weapons) 내포 시스템(Embedded Systems) A system that is logically incorporated in a larger system whose primary function is not computation large scale, long-lived real-time response, fail-safe reliability tend to be asynchronous, highly parallel, and distributed 비행기 유도 시스템(flight guidance) 교환기 시스템(switching systems)

5 소프트웨어와 관련된 질문 1. 소프트웨어 시스템을 개발하는 데 드는 비용 중 프로그래밍(코딩)에 드는 비용은 어느 정도인가?
가. 20% 나. 30% 다. 40% 라. 50% 2. 중간 사이즈의 소프트웨어 시스템을 개발할 때 한 프로그래머가 일년에 만드는 실행 코드(executable code)는 평균 몇 줄(line)이나 될까? 가. 5,000줄 이하 나. 5,000 ~ 10,000줄 다. 10,000 ~ 15,000줄 라. 15,000줄 이상 3. 사용자에게 배달되는 소프트웨어 시스템의 실행 코드 1,000줄 당 예상되는 오류의 개수는? 가. 4개 미만 나. 4 ~ 6개 다. 7 ~ 9개 라. 10개 이상 4. 사용자가 발견하는 소프트웨어 시스템의 오류는 어떤 것에서 기인하는 경우가 많은가? 가. 설계의 오류 나. 프로그래밍의 오류 다. 제안서와 사용자 요구 사항에 대한 잘못된 이해 라. 테스팅의 오류 5. 소프트웨어 시스템을 유지 보수하는 데 드는 비용이 개발 비용의 몇 배 정도 될까? 가 나 다 라. 2

6 소프트웨어 위기 소프트웨어 개발의 문제 소프트웨어 위기(Software Crisis) 예산 초과(Cost Overruns)
개발 일정 지연(Late Delivery) 불충분한 성능(Inadequate Performance) 신뢰하기 어려운 품질(Unreliability) 유지 보수의 어려움(Impossible Maintenance) Prohibitive Maintenance Costs 소프트웨어 위기(Software Crisis) 컴퓨터 하드웨어의 급속한 발전과 컴퓨터의 대중화로 인해 소프트웨어의 수요가 급증하였으나 소프트웨 어의 생산성과 생산 기술은 그에 미치지 못함으로서 나타난 현상

7 소프트웨어 공학 소프트웨어 공학이란? The disciplined application of engineering, scientific, and mathematical principles and methods to the economical production of quality software 소프트웨어의 개발, 운용, 유지 보수 및 파기에 대한 체계적인 접근 방법(IEEE) 품질 좋은 소프트웨어를 최소의 비용으로 계획된 일정에 맞추어 개발하기 위하여 여러 가지 공학적 원리와 방법을 체계적으로 적용하는 것

8 소프트웨어 공학 소프트웨어 공학의 여러 측면들 소프트웨어 공학은 지식 집중(knowledge-intensive)적인 활동
소프트웨어 표현과 관련된 지식 소프트웨어 개발 과정과 관련된 지식 programming software development processes tools and environments software project management configuration management quality assurance 응용 영역에 대한 지식 기타 필요한 지식 hardware characteristics human factors technical communication and documentation

9 소프트웨어 공학 소프트웨어 공학의 역사 소프트웨어 위기의 인식 ~1970 소프트웨어 공학의 탄생
소프트웨어 위기의 인식 ~1970 소프트웨어 공학의 탄생 high-level language programming interactive programming Goto 논쟁 (1965) 소프트웨어 위기 해소책 모색 ~1980 소프트웨어 공학 학문으로 정착 하드웨어로부터 독립된 개념의 소프트웨어 software lifecycle methodology and tools programming-in-the-large information hiding structured design 소프트웨어 공학의 발전 ~to date software environment software reuse software factory CASE (Computer Aided Software Engineering)

10 소프트웨어 공학 소프트웨어 공학의 여러 이슈들 저 수준의 소프트웨어 생산성 및 품질 노동 집약적인 소프트웨어 생산 과정
가격 상승의 주요 원인 향상된 기술에 둔감하다. 숙련된 소프트웨어 공학자의 부족 늦은 속도의 기술 이전(technology transfer) 소프트웨어 개발 기술의 개발 소프트웨어 생산 과정의 자동화 표준화된 부품을 이용한 생산 소프트웨어의 입지 확보 Software mind 직업으로서의 소프트웨어 공학 legal protection and market development

11 소프트웨어 공학 소프트웨어 공학에서의 크기 요소 <Programming-in-the-Small>
비교적 잘 정의된 문제의 구현에 관심 정확한 프로그램의 개발이 목표 명세(specifications)이 좀처럼 변경되지 않는다. <Programming-in-the-Large> Problem definition Changing requirements Interface between components System integration and testing Configuration management Maintenance Documentation Information management <Programming-in-the-Many> Communication의 문제 : 팀 원 간의 정보 교환 Work assignment Quality assurance : 표준화(기법, 표기법)의 필요 Project management : 계획 및 제어, 팀 조직, 팀 원의 이적, 요구의 변화

12 소프트웨어의 크기 범주

13 소프트웨어에 대한 오해 관리자의 오해 고객의 오해
소프트웨어 개발에 관한 좋은 책들이 있고 책 안에 개발 표준과 단계가 제시되어 있어 우리에게 필요한 모든 것을 제공할 것이다. 개발자들에게 필요한 최신 기계(Workstation)나 CASE 도구를 도입하였으니 좋은 제품을 빠른 시일 내에 만들 수 있을 것이다. 엔지니어들이 요구 분석을 하고 있으면 생산적이지 못한 일을 하고 있다고 생각한다. 공정이 지연될 경우 인력을 더 투입하면 해결된다. 고객의 오해 목표에 대한 개략적인 기술만 해놓으면 소프트웨어를 만드는 데 충분하다. 세부적인 것은 나중에 채워 넣으면 된다. 사용자의 요구 사항은 계속 변하며 소프트웨어는 융통성이 있어 쉽게 변경을 수용할 수 있다.

14 소프트웨어에 대한 오해 엔지니어의 오해 일단 프로그램이 만들어지고 작동하면 우리의 임무는 끝난다.
시스템을 작동시켜 보기 전까지는 품질을 평가할 방법이 없다. 프로젝트의 결과는 작동하는 프로그램뿐이다.

15 좋은 소프트웨어의 조건 소프트웨어의 품질 발주자 관점에서의 소프트웨어 품질 사용자 관점에서의 소프트웨어 품질
소프트웨어 자체(Product)의 품질 관점에 따라 품질에 대한 평가기준이 다름 발주자, 사용자, 유지보수자 소프트웨어 프로세스(Process)에 대한 품질 발주자 관점에서의 소프트웨어 품질 효율성 신뢰성 최소 비용 생산성 융통성 사용자 관점에서의 소프트웨어 품질 기능의 정확성 이해 용이성 사용 용이성 일관된 통합

16 좋은 소프트웨어의 조건 유지보수자 관점에서의 소프트웨어 품질 소프트웨어 Process 품질 모델 신뢰성 이식성 재사용성
유지보수성 상호운용성 소프트웨어 Process 품질 모델 CMM (Capability Maturity Model) : 미국방성 SPICE (Software Process Improvement and Capability dEtermination) : ISO

17 소프트웨어 생명 주기 모델 소프트웨어 생명 주기(software life cycle)
소프트웨어 제품이 고안될 때부터 시작하여 그 제품이 더 이상 쓸모없게 되기까지의 시간 구간. A time-ordered activities, which if performed in a manner that satisfies the ordering relationship, will produce the desired product. 소프트웨어 개발을 위한 기술과 절차들의 통합을 위한 framework. 프로젝트 수행을 위한 지침(guidance) 소프트웨어 개발과 관련된 여러 단계(stages)들의 순서를 결정 단계들 간에 전이를 위한 기준 (중간 제품의 정의) Evolution rather than creation will be the dominant development mode development use modification

18 소프트웨어 생명 주기 기존의 개발 Paradigm <개발 접근 방법>
비 정형화된 명세(Informal specification) Design decisions are lost Prototype is created manually and discarded Manual implementation Maintenance on source code Code is tested Requirements Informal Specification Prototype Concrete Source Program Analysis Validation Coding Testing Tuning Maintenance

19 소프트웨어 생명 주기 폭포수 모델 - 단계별 모델
각 단계는 다음 단계가 시작되기에 앞서 반드시 완료되어야 한다. =>순차적(sequential) 각 단계의 결과는 다음 단계가 시작되기에 앞서 정확성에 대한 검사가 이루어져야 한다. 프로토타입과 재사용의 가능성을 떨어뜨린다. 설계, 코딩, 테스팅이 지연된다. 별로 사용되지 않을 도큐먼트를 위해 너무 많은 노력이 든다. Data Collection System Analysis Requirements Definition Preliminary Design Detailed Design Coding Testing Installation

20 소프트웨어 생명 주기 점진적(incremental) 개발 모델
특정 기능이나 능력을 점진적으로 추가하는 방식으로 소프트웨어를 개발한다. Reduce risk : 핵심 기능 먼저, 기능 추가 시 변경 용이 Ease testing : 새로운 기능을 추가할 때마다 전체 시스템과 통합하여 테스팅 한다. 자연스러운 feedback RELEASE 1 RELEASE 2 RELEASE N Prelim Analysis System Test Software Requirements

21 소프트웨어 생명 주기 프로토타입 모델 인간 - 기계 상호작용 프로토타입
working 프로토타입 : 소프트웨어 기능의 일부분 실현 요구되는 기능의 일부 또는 전체 수행 <-- 개선을 목표 Prototype Development/ Refinement System Analysis Requirements Definition/ Design Evaluation Full-scale Implementation Installation

22 소프트웨어 생명 주기 나선형 모델(spiral model) 고전적 생명 주기 모델 + 프로토타입핑 + “위험 분석”
계획 수립 : 목적, 대안, 제한들의 결정 위험 분석 : 대안의 분석과 위험의 식별, 해결 방안 공학 : “다음 수준” 제품의 개발 고객 평가 : 공학 결과의 평가

23 소프트웨어 생명 주기 새로운 소프트웨어 개발 Paradigm <자동화 기반 개발 모델>
Convert a formal software specification into a program satisfying the specification Formal specification Maintenance on specification Specification is the prototype Machine-aided implementation Testing is eliminated Development is automatically documented Decision and Rationale Informal Requirements Formal Development Requirements Analysis Formal Specification (prototype) Mechanical Optimization Concrete Source Program Validation Tuning Maintenance

24 S/W 개발에 영향을 미치는 요소 S/W 개발 프로젝트의 성공 요소 의사 소통 (Communication) 의사 소통
프로젝트의 성격 프로그래머의 역량 프로젝트 관리 기법 의사 소통 (Communication) 사용자와 개발자 사이의 의사 소통 프로젝트 팀 구성원 사이의 의사 소통 프로젝트의 크기 ==> 표1.1 참조 소프트웨어의 복잡도 소프트웨어 개발 및 유지보수는 노동집약적 프로그래머의 생산성 차이: 25대1 프로그래머의 능력 프로그래밍에 관한 능력 팀 구성원으로서 일할 수 있는 능력 응용 분야에 대한 이해도