�ݺ�ߣ

An introduction to
computer
Science
- Software Engineering
2017. 05. 23
황태욱

01 File System
02 Main Memory Management
CONTENTS
03 Further Study

1.1 Software Engineering
소프트웨어 공학(software engineering)은 소프트웨어의 개발, 운용, 유지보수 등의
생명 주기 전반을 체계적이고 서술적이며 정량적으로 다루는 학문이다; 즉, 공학을
소프트웨어에 적용하는 것이다.
소프트웨어 공학의 영어 낱말 software engineering이라는 용어가 처음 나타난 곳은
1968년 나토 소프트웨어 공학 학회로, 당시에는 소프트웨어 위기에 관해 사람들이
주의를 기울여 생각할 것을 장려하기 위해서였다.
소프트웨어의 정의 및 특성
- 프로그램과 프로그램의 개발, 운영, 유지보수에 필요한 정보 일체
소프트웨어 공학 3요소
방법(method)
- 프로젝트 계획 수립과 추정, 시스템과 소프트웨어 분석, 자료구조, 프로그램 구조
알고리즘, 코딩, 테스트 유지보수 등
- 특수한 언어중심 또는 그래프 표기법 및 소프퉤어 품질에 대한 일련의 평가 기준
도구(tool)
- 소프트웨어 개발을 지원하는 시스템 설정
절차(procedures)
- 방법과 도구를 결합하여 소프트웨어를 합리적이고 적시에 개발하도록 함

1.2 소프트웨어공학의 과정
정의 과정: 무엇(What)에 초점
1. 시스템 분석
- 컴퓨터기반 시스템에서 각 요소가 해야 할 역할 정의
- 소프트웨어가 수행해야 할 역할 할당
2. 프로젝트 계획 수립
- 위험분석, 자원할당, 비용 추정, 작업내용과 일정 결정
3. 요구사항 분석
- 개발방향 제시 (개발된 소프트웨어에 대한 정보와 기능의 상세한 정의)
개발 과정: 어떻게(How)에 초점
1. 설계
- 소프트웨어에 대한 요구사항을 자료구조, 알고리즘적 절차, 인터페이스의
특성을 묘사하는 인련의 표현으로 변환
2. 구현
- 설계 표현은 컴퓨터에 의해 실행되어질 수 있는 프로그램언어로 변환되어야 함
3. 테스트
- 소프트웨어의 기능적, 논리적 구현에서의 결함을 발견하기 위한 테스트 실시

1.3 소프트웨어공학의 과정
유지보수 과정: 변경에 초점
1. 수정
- 수정적 유지보수는 결함이 수정되도록 소프트웨어 변경
2. 적응
- 적응적 유지보수는 외부적인 환경변화(CPU, OS, 주변장치 변경 등)를 수용할
수 있도록 소프트웨어 변경
3. 기능향상
- 완전한 유지보수는 본래 요구된 기능을 충실히 수행하도록 소프트웨어 확장

1.4 소프트웨어 개발 단계: 정의
소프트웨어 개발단계는 소프트웨어 제품을 생산하기 위한 다양한 태스크(Task)와
이들 결함물의 집합으로, 대부분의 활동은 소프트웨어 엔지니어에 의해 수행

1.5 소프트웨어 개발 단계: 개발

1.6 소프트웨어 개발 단계: 유지보수

2.1 프로세스 모델: Waterfall 1/2
폭포수 모델: Waterfall Model

2.1 프로세스 모델: Waterfall 2/2
폭포수 모델: Waterfall Model

2.2 프로세스 모델: Prototype Model 1/2
프로토타입 모델: Prototype Model

2.2 프로세스 모델: Prototype Model 2/2
프로토타입 모델: Prototype Model

2.3 프로세스 모델: Spiral Model 1/2
나선형 모델: Spiral Model

2.3 프로세스 모델: Spiral Model 2/2
나선형 모델: Spiral Model

3.1 Agile Software Development : Concept
애자일 방법론은 소프트웨어 개발 방법에 있어서 아무런 계획이 없는 개발 방법과
계획이 지나치게 많은 개발 방법들 사이에서 타협점을 찾고자 하는 방법론이다. 계획이
없는 방법론의 경우, 앞으로의 일을 예측하기 힘들고 효율적이지 못하다는 점에서
취약점을 가지고 있으며, 계획에 너무 의존하는 경우는 그 형식적인 절차를 따르는데
필요한 시간과 비용을 무시할 수 없으며, 전체적인 개발의 흐름 자체를 느리게 하는
단점을 가지고 있다.
그렇기 때문에 애자일 방법론에서 택한, 그리고 다른 고전적인 방법론, 예를 들면 폭포수
모델 또는 나선 모형과 구별되는 가장 큰 차이점은 less document-oriented, 즉 문서를
통한 개발 방법이 아니라, code-oriented, 실질적인 코딩을 통한 방법론이라는 점이다.
그러므로 애자일 개발 방법론은 계획을 통해서 주도해 나갔던 과거의 방법론과는 다르게
앞을 예측하며 개발을 하지 않고, 일정한 주기를 가지고 끊임없이 프로토 타입을
만들어내며 그때 그때 필요한 요구를 더하고 수정하여 하나의 커다란 소프트웨어를
개발해 나가는 adaptive style 이라고 할 수 있다.
애자일 개발 프로세스란 어느 특정 개발 방법론을 가리키는 말은 아니고
"애자일(Agile=기민한, 좋은것을 빠르고 낭비없게 만드는 것) 개발을 가능하게 해 주는
다양한 방법론 전체를 일컫는 말이다. 예전에는 애자일 개발 프로세스는
"경량(Lightweight)" 프로세스로 불렸다. 익스트림 프로그래밍 (XP:eXtreme
Programming)이 애자일 개발 프로세스의 대표적인 방법이라 볼 수 있다

3.2 Agile : Background
애자일 프로세스의 배경에는 소프트웨어 개발 자체가 다른 공학적인 프로세스와는
큰 차이가 있음을 인지하는 데에서부터 시작되었다. 이는 소프트웨어 위기의
원인과 해결방안을 찾는 데에서 부터 시작되었다.
90년대 후반까지의 소프트웨어 공학과 개발방법론은 장기간에 걸쳐 많은 사람들을
투입하고 충분한 비용을 투입하여 진행하는 다른 공학의 프로세스와 비슷한
맥락에서 진행되었다.
그러나 소프트웨어는 유동적이고 개방적이다. 또한, 요구사항의 변경에 따른
작업량을 예측하기 힘들다. 그래서 이미 고전적인 소프트웨어 공학이나 관리
기법만으로는 대처할 수 없게 되었다.
이런 문제에 대한 기술적인 해결책으로 객체지향이 있다. 객체지향 기술은 그
동안의 개발 문제를 적절하게 대처해 주었다. 그리고 객체지향 개발을 하기
위해서는 그에 적합한 개발 프로세스가 필요했다. 그래서 수많은 애자일 개발
프로세스가 이러한 필요에 따라 만들어졌다. 따라서 애자일 개발 프로세스의
상당수는 객체지향 기술을 기반으로 한다.
애자일 개발 프로세스는 제한된 시간과 비용 안에서 정보는 불완전하고 예측은
불가능하다는 전제를 가진다. 그리고 그 전제 아래에서 합리적인 답을 내도록 하는
것이 애자일 개발 프로세스이다.

3.3 Agile : Manifesto
애자일 연합에서 추구하는 사상은 그들이 선언한 아래와 같은 글에서 잘 나타난다.
우리는 스스로 행하고 다른 이들도 이를 행할 수 있도록 도움을 줌으로써
소프트웨어 개발의 더 나은 방법을 전파한다. 이러한 작업을 통해 우리는 아래와
같은 가치에 도달하게 되었다.
절차와 도구를 넘어선 개성과 화합
종합적인 문서화를 넘어선 동작하는 소프트웨어
계약과 협상을 넘어선 고객과의 협력
계획 준수를 넘어서 변화에의 대응
이들의 앞선 가치들을 인정하면서도 뒤에 오는 가치들에 보다 큰 무게를 둔다.

3.4 Agile : Team Work
커뮤니케이션에 아무런 문제가 없는 팀의 경우 업계 평균보다 50배
이상 높은 성과를 얻을 수 있다고 한다. 애자일은 원활한
커뮤니케이션을 위해서 일일 스탠드업 미팅을 통해 주기적으로
직접적인 대화를 할 수 있는 기회를 제공한다. 하지만 피드백 및 대화
빈도를 높이는 것만으로 효과를 발휘하기는 어려우며 팀멤버가 아래와
같은 핵심적인 태도를 실천하지 않으면 안된다.
각자의 가치에 대한 존중
모든 커뮤니케이션에 있어서의 정직
모든 데이터, 작업 및 결정의 투명성
개개인이 모두 팀을 지원한다는 믿음
팀과 팀의 목표에 대한 헌신
이러한 태도를 촉진하기 위해 관리자는 협력적인 환경을 제공하고
팀코치는 보다 적극적인 참여를 유도해야 하며, 팀 멤버는 이러한
행동을 명확하게 실천해야 한다.

3.5 Agile : Principles
1. 우리의 최우선 순위는, 가치 있는 소프트웨어를 일찍 그리고 지속적으로
전달해서 고객을 만족시키는 것이다.
2. 비록 개발의 후반부일지라도 요구사항 변경을 환영하라. 애자일 프로세스들은
변화를 활용해 고객의 경쟁력에 도움이 되게 한다.
3. 작동하는 소프트웨어를 자주 전달하라. 2주 ~ 2개월 정도의 간격으로 하되 더
짧은 기간을 선호하라.
4. 비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체에 걸쳐 날마다 함께 일해야
한다.
5. 동기가 부여된 사람들을 중심으로 프로젝트를 구성하라. 그들이 필요로 하는
환경과 지원을 주고 그들이 일을 끝내리라고 신뢰하라.
6. 개발팀으로, 또 개발팀 내부에서 정보를 전하는 가장 효율적이고 효과적인
방법은 면대면 대화이다.
7. 작동하는 소프트웨어가 진척의 주된 척도이다.
8. 애자일 프로세스들은 지속 가능한 개발을 장려한다. 스폰서, 개발자, 사용자는
일정한 속도를 계속 유지할 수 있어야 한다.
9. 기술적 탁월성과 좋은 설계에 대한 지속적 관심이 기민함을 높인다.
10. 단순성이 -- 안 하는 일의 양을 최대화하는 기술이 -- 필수적이다.
11. 최고의 아키텍처, 요구사항, 설계는 자기 조직적인 팀에서 창발 한다.
12. 팀은 정기적으로 어떻게 더 효과적이 될지 숙고하고, 이에 따라 팀의 행동을
조율하고 조정한다.

4.1 Software Test
소프트웨어 테스트는 소프트웨어의 결함을 발견하는 행위로써, 현재 소프트웨어가
완전하다는 것을 증명하는 것이 아니라 소프트웨어의 결함을 발견해내는 데 있다
또한 이를 위해 소프트웨어 오류들을 체계적으로 찾아낼 수 있는 테스트 사례가
아주 중요하다
목적
- 테스트하는 것은 오류를 발견하려고 프로그램을 실행시키는 과정
- 좋은 테스트 사례는 아직까지 발견되지 않은 오류를 찾아내는 데 높은 확률을
가지고 있음
- 성공적인 테스트는 아직까지 발견되지 않은 오류를 발견해 냄
Snowball Effect 방지
- 초기단계에서 발생한 오류는 조치가 안될 경우, 후반부로 갈 수록 눈덩이가
점점 더 커지게 되어 전체 일정의 심각성 초래
- 소프트웨어 테스트가 중요한 이유는 초기 위험을 줄이고자 하는 활동이기 때문

4.2 Software Test: Black box test

4.3 Software Test: White box test

4.4 Software Test: 단위 테스트

4.5 Software Test: Principle
소프트웨어 테스트의 원칙
- 테스트는 개발 프로그래머나 해당 팀과는 무관한 그룹에 의해 수행
- 테스트 직업을 가장 능력이 뛰어난 사람에게 할당
- 오류가 발견되지 않을 것이란 가정 하에서 테스트 계획을 수립하지
않아야 함
- 타당한 경우뿐만 아니라 타당하지 않고 예상하지 못한 케이스로도
테스트를 수행
- 프로그램의 어떤 부분에 오류가 남아 있을 확률은 이미 발견된
오류의 수에 직접적으로 비례
- 테스트 케이스를 체계적으로 관리해야 함
- 각각의 테스트 결과를 철저하게 검증해야 함

Q&A
For further details, please contact us by e-mail
황태욱 : taewook.hwang@gmail.com
010.9576.5105
Kakao: Aldemaya

�ݺ�ߣ

컴퓨터개론12

Recommended

More Related Content

Similar to 컴퓨터개론12 (20)

More from Edward Hwang (20)

컴퓨터개론12