1. 소프트웨어 테스팅의 방법들이 품질 보증에서 어떻게 응용되며, 품질보증과 품질관리가 어떻게 적용되는지를 설명해 보시오.
품질 보증(Software Quality Assurance)란 소프트웨어 개발의 전 과정에 대한 Audit활동을 가리킨다. 이 가운데 소프트웨어 테스팅은 각 단계별 산출물들에 대한 확인(Verification) 작업과 최종 Product에 대한 검증(Validation)작업을 가리킨다. 때문에 품질 검증의 요소 가운데 Verification과 Validation에 대한 영역에 대해서 소프트웨어 테스팅의 방법을 적용할 수가 있을 것이다. 구체적인 적용 방안은 다음과 같다.
- 품질 측정 방안
기능적 또는 비기능적 소프트웨어 품질을 테스팅에 의해 발견된 결함(데이터)에 근거하여 측정
- 결함 검출 방안
: 산출 문서에 대한 Static Analysis 수행
(Requirement 및 Design Spec., Source Code)
: 개발 소프트웨어에 대한 Dynamic Analysis 수행
(Unit Testing, Integration Testing, System Testing, Acceptance Testing)
- 결함 해결 방안
: 결함 관리 시스템 사용(ex. IBM Rational Clear Quest..)
: Defect 상태 등록 및 공유
ref.)
http://en.wikipedia.org/wiki/Software_quality_assurance
2. 소프트웨어 개발 방법론에 대하여 비교 평가하시오.
(구조적 방법론, 정보공학, 객체지향 개발, CBD)
- 객체지향 개발 방법론
객체(object) 중심: 상태, 행동, 유일한 식별성을 가진 캡슐화된 개체로 모델링
화이트박스 재사용: 소스 코드 중심의 재사용. 수정 및 개작 가능
- CBD 방법론
컴포넌트 중심: 객체 지향 기반 개발보다 재사용성이 높은 소프트웨어 빌딩 블록을 구축
블랙박스 재사용: 바이너리 코드 중심의 재사용. 수정 및 개작이 불가함
객체 자체에 초점을 두기보다는 존재하는 객체들을 효율적으로 결함하는 것에 초점을 둔다.
특정 컴포넌트 개발 표준(EJB, COM+, CCM)을 준수하여야 한다.
- 구조적 방법론
폭포수 모델을 기본으로 하는 프로세스 위주의 분석과 설계방식
모듈의 분할과 정복에 의한 top-down 방식으로 진행
알고리즘은 순차, 선택, 반복 구조면 충분
단일입구/단일출구의 처리구조를 가짐
철저한 모듈화로 추상화와 정보은닉을 이루어 프로그램의 구조를 읽이 쉽게 단순화함
데이터 구성에 대한 설계 방안이 부족
프로젝트 관리 및 조직, 역할 등 방법론적 다른 요소의 정의가 없다는 단점이 있음
- 정보공학 방법론
구조적 방법론의 기본적 사상인 하양식, 모듈화, 분할과 정복, 폭포수 등의 개념은 동일
개별 소프트웨어가 아닌 기업에서 사용되는 정보 시스템을 목표로 한다는 것이 구조적 방법론과 다름
기업 경영 전략을 창출하는 정보전략계획(ISP) 작업을 포함하고 기업의 업무처리에는 안정된 데이터베이스가 중요하므로 데이터 중심의 분석과 설계를 진행
구조적 방봅론과 정보공학 방법론에서는 프로세스와 데이터를 분리하여 처리하기 때문에 실제 설계와 개발이 어려움이 있고 복잡한 기법들이 활용되어야 했다. 또한 완성된 시스템에 대한 요구사항의 결과를 너무 늦게 확인할 수 있고 산출물의 양이 많고 복잡도가 크다. 객체지향 방법론에서는 프로세스와 데이터를 통합하여 모델링함으로써 이러한 단점을 해결하였다. 객체지향 방법로은 재사용을 강조하며 반복적, 점증적인 개발방식을 사용한다. 또한 UML이라는 쉽고 표준화된 표기법을 사용하기 때문에 산출물의 복잡도를 감소시킨다. CBD 방법론은 대부부니 객체지향 언어를 사용하고 있으므로, 객체지향 방법론의 연장선상에 있다고 볼 수 있다. 시스템에 대한 요구사항을 확립하고 구조 설계가 진행될 때, CBD는 보다 상세한 설계 작업들로 바로 진행하는 것이 아니라 시스템의 어떠한 부분들이 합성에 적합한가를 판단하기 위해 요구사항들을 조사하고 컴포넌트와 인터페이스를 도출하는 것이다. 또한 생성된 컴포넌트들은 컴포넌트 라이브러리에 등록되어 이후 소프트웨어 개발시에 재사용할 수 있다. 재상용이 쉽고 인터페이스가 맞으면 언제든지 컴포넌트를 수정할 수 있는, 교체가 용이하다는 장점이 있다.
3. RUP에서 주장하는 Best Practice란 무엇이며, RUP를 구성하는 4가지 요소에 대하여 간략히 설명하시요.
Best Practice
- 반복적인 개발(Iterative Development): 하나의 커다란 시스템을 작게 쪼개고, 그 쪼갠 것을 개발해서 점진적으로 완성
- 요구사항 관리(Manage Requirement): 사용자의 요구사항을 초기부터 관리하여 변경에 대한 이력을 관리하여 추적성 및 무결성을 높일 수 있게 함
- 컴포넌트 기반의 구조 사용(Use Component Architectures): 유연한(Resilient) 구조의 소프트웨어 컴포넌트를 사용한다. 이를 통해 확장성과 재사용성을 높일 수 있다. 또한 모듈간의 의존성을 낮추고 구현 언어의 독립성을 높일 수 있다.
- 비주얼 모델링(Model Visually-UML)
- 개발주기 전반에 걸친 품질 검증(Continuously Verify Quality): 소프트웨어 결함을 개발 단계에서 발견하고 수정하여 테스트 비용을 절약
- S/W 변화 제어 관리(Manage Change): 모든 산출물들과 이에 대한 변경 내역들을 일괄 관리
RUP를 구성하는 4가지 요소
- Inception: 프로젝트의 목표 설정, 중요 업무 및 요구사항 수집, 프로젝트 위험 요소 파악, 프로젝트 계획 및 소요비용 산정
- Elaboration: Construction 단계에서 설계 및 구현의 기초가 될 시스템 기초 아키텍처를 결정 및 구축. 중요 요구사항 처리
- Construction: 나머지 요구사항들을 분명하게 하고, 기초 아키텍처를 기반으로 개발을 완성해 나감. 어떤 의미에서는 제품화하는 단계임.
- Transition: 개발 시스템을 최종사용자가 사요할 수 있게함. 즉, Release를 준비하기 위하여 테스트 한다거나, 사용자의 의견을 수렴하여 수정을 한다는 등의 작업 수행.
위의 4개 구성 요소는 필요에 따라 반복됨
4. Agile 방법론이란 무엇이며, XP개발방법에 대하여 간략히 기술하시오.
Agile Methodology
(http://en.wikipedia.org/wiki/Agile_process)
Agile software development is a conceptual framework for software engineering that promotes development iterations throughout the life-cycle of the project.
Customer satisfaction by rapid, continuous delivery of useful software
Working software is delivered frequently(weeks rather than months)
Even late changes in requirements are welcomed
Close, daily cooperation between business people and developers
Face-to-face conversation is the best form of communication
Projects are built around motivated individuals, who should be trusted
Simplicity
Regular adaptation to changing circumstances
Agile 방법론의 장점은 문서에 대한 부담을 줄일 수 있고, 변화에 쉽게 대응하며 고객의 입장에 초점을 맞춰 개발할 수 있다는 것이다. 하지만 방법론 그 자체로서 적용하기에는 프로세스 정립이 부족하고 대형 프로젝트 적용에는 부적합하다. 또한 감리 대응이 미흡하고 관리 방법에 대한 가이드라인이 부족하다는 단점을 가진다.
XP
(http://en.wikipedia.org/wiki/Extreme_programming#XP_values)
Principles
- Feedback
- Assuming simplicity
(ex. incremental changes
Assuming simplicity is about treating every problem as if its solution were "extremely simple". Traditional system development methods say to plan for the future and to code for reusability. Extreme programming rejects these ideas.)
XP values
Extreme Programming (or XP) is a software engineering methodology (and a form of agile software development) prescribing a set of daily stakeholder practices that embody and encourage
particular XP values
The five values are:
Communication
Simplicity
Feedback
Courage
Respect
5. SWEBOK와 PMBOK의 목적과 그 구조에 대하여 설명하시요.
SWEBOK
ACM과 IEEE Computer Society에서 관리하는 전문소프트웨어 엔지니어가 반드시 갖추어야할 능력을 구성하는 지식영역들을 식별하였다.
10가지의 지식영역의 구조를 가지며 54가지 지식 하위 영역을 포함한다.
- Software Requirements
- Software Design
- Software Construction
- Software Testing
- Software Maintenance
- Software Configuration
- Software Quality
- Software Engineering Management
- Software Engineering Tools and Methods
PMBOK
PMI에서 만든 단일 프로젝트관리를 위해서 광범위한 프로젝트관리 지식체계를 요약한 지침서
The five process groups are:
1. Initiating
2. Planning
3. Executing
4. Controlling and Monitoring
5. Closing
The nine knowledge areas are:
1. Project Integration Management
2. Project Scope Management
3. Project Time Management
4. Project Cost Management
5. Project Quality Magement
6. Project Human Resource Management
7. Project Communications Management
8. Project Risk Management
9. Project Procurement Management
6. 개선된 Win-Win 나선형 모델을 간단하게 설명하시오.
(http://agile.csc.ncsu.edu/winwinspiral.html)
- While maintaining many of the traditional elements of the spiral model, the Win-Win version strives to involve all
stakeholders in the development process.
- It involves a collaborative engine that establishes "win" conditions set by users, customers, developers, and system
engineers in order to evolve and reprioritize requirements throughtout the process.
- Boehm의 win-win spiral model은 기존이 spiral model 타원 진행의 시작 점에 다음 작업들을 정의해 놓는다.
Identify next-level stakeholders
Identify stakeholders' win conditions
Reconcile win conditions
7. 소프트웨어 Reengineering 프로세스를 간단히 설명하고 그 필요성과 효용서에 대하여 약술하시오.
(http://en.wikipedia.org/wiki/Reengineering_%28software%29)
The reengineering of software was described as "the examination and alteration of a system to reconstitute it in a new form".
Less formally, reengineering is the modification of a software system that takes places after it has been reverse engineered,
generally to add new functionally, or to correct errors.
대부분의 레거시 시스템들은 S/W공학 기법이 널리 사용되기 전에 개발되었다. 따라서 빈약하게 구조화 되었고 문서화 되었다. 또한 기존 시스템도 명세서가 존재하지 않는 경우가 많다. 이러한 상황에서 레거시 시스템은 주기적으로 유지 및 보스를 해야하고 그 비용은 증가되고 있다. 리엔지니어링을 통해서 S/W의 재개발을 보다 저렴한 비용으로 막을 수 있다면 이는 매우 효과적일 것이다.
8. UML Diagram과 4+1 View에 대하여 설명하시오.
(http://en.wikipedia.org/wiki/UML_diagram)
UML is a standardized visual specification language for object modeling. UML은 모델의 기본 요소를 구성하는 사물(Thing)과 사물들 간의 관계(Relationship) 그리고 관련있는 사물들 간의 관계를 도형으로 표현한 Diagram의 3가지로 구성된다.
4+1 View
- the use case view(Scenario)
- the logical view, which is the object model of the design(when an object-oriented design method is used)
- the process view, which captures the concurrency and synchronization aspects of the design
- the physical view, which describes the mapping(s) of the software onto the hardware and refelcts its distributed aspect
- the development view, which describes the static organization of the software in its develoopment environment
9. 소프트웨어 아키텍쳐의 유형과 각 유형별로 개발(구현)단계에서 어떻게 활용되는지를 간단히 설명하시오.
(http://blog.daum.net/jhmoon77/6956904)
1) Model-View-Controller(MVC) architecture pattern
2) The publish-subscribe architecture pattern
- a publisher publishes data on a bus
- subscribers subscribe to portions of the data that are published by publishers on the bus.
3) pipes and filters
filter: small program
a filter has an input and an output the filters are assembled into a chain in which each filter gets data from the
previous filter in the chain, processes the data, and passes the data to the next filter in the chain.
4) Layers
In a closed layer system, a layer may only access adjacent layers.
In an open layer system, layers may access any other layer in the system, not just the ones to which they are adjacent.
'잡담' 카테고리의 다른 글
임베디드 가상화 플랫폼 (0) | 2008.03.20 |
---|---|
컴퓨터 구조론 (0) | 2008.03.15 |
Computer Network (0) | 2008.03.08 |
MIS(Management Information System) (0) | 2008.03.08 |
KAIST 산학 (0) | 2008.02.21 |