Divide & Conquer를 이용한 하향식, 구조적 방법론의 개요 구조적 방법론(Structured Development Methodology) 개념 - 전체 시스템을 기능에 따라 분할하여 개발하고, 이를 통합하는 분할과 정복(Divide & Conquer) 방식의 방법론, 프로세스 중심의 하향식 방법론(Top-Down) - 정형화된 분석 절차에 따라 사용자 요구사항을 파악하여 문서화하는 체계적인 방법으로 비즈니스 프로세스 자동화를 목표로 하고 있으며, 프로세스 중심의 개발 방법 특징데이터 흐름 지향으로 프로세스 위주의 분석과 설계 방식모듈의 분할과 정복에 의한 하향식(Top-Down) 설계 방식다른 프로세스로 순차적 진행하는 폭포수 모델이 기본소프트웨어의 개발이 목표인 프로세스와 산출물의 구성연속(..
EAI(Enterprise Application Integration)의 개요 EAI의 개념 EAI(Enterprise Application Integration)은 약어의 의미 그대로 전사 어플리케이션 통합을 위한 솔루션이다. 처음부터 모든 어플리케이션을 연결하기 위해서 설계되어지고 만들어졌다면 EAI가 필요하지 않겠지만, 그렇지 않은 기업들은 산재되어 각자 만들어진 수많은 어플리케이션이 있을 것인데 이것을 통합하기 위해서 솔루션이 필요했으며, 그 솔루션의 명칭을 EAI라고 한다. 표준화되거나 솔루션 기반의 통합을 사용하지 않고 직접 모든 어플리케이션을 연결할 경우 이와같이 스파게티 현상이 발생한다 참고로 가트너 그룹에서는 EAI를 아래와 같이 정의한다.- 엔터프라이즈 미들웨어를 인프라로 하여 다양한 ..
TDD(Test-Driven Development)는 매우 짧은 개발 사이클을 반복하는 소프트웨어 개발 프로세스 중 하나로 애자일 방법론중 하나이다. 일반적으로 개발을 먼저 수행하고, 테스트 단계를 거치는 방식을 관점을 뒤집은 것으로 테스트를 수행할 방법(ex: Test Case)을 먼저 만들고, 이 요건을 충족할 코드를 뒤에 짜는 것이다. TDD는 이런 방식을 채용하였기 때문에, 더 고품질의 프로그램이 실현 가능해진다. 그리고 이어지는 리팩토링 단계는 테스트의 문제 뿐만 아니라, 코드의 단단함까지 더해질 수 있다. 결과적으로 TDD를 수행하게 되면 TC를 충족하는 코드와 군더더기 없는 코드(simple code 혹은 clean code)가 생산된다는 말이 된다. 일반적으로 개발을 진행하였을 때, 들어가..
설치 테스트는 프로그램이 제대로 설치되며 동작하는지 확인하고, 레지스트리의 변경 사항과 제거(Uninstallation)이 제대로 수행되는지까지 확인하는 테스트다. 윈도우(Windows) 운영체제에 설치하지 않는 리눅스계열의 프로그램이라면, 특정 폴더안에서 설치가 되는지 확인하고 sh(쉘파일) 등으로 쉽게 삭제할 수 있겠지만, 윈도우에 설치하는 프로그램이라면 설치, 삭제 시 영향도까지 확인하는 작업이 필요하다. 참고로, 설치 테스트에 관련된 정보는 STEN 혹은 개발자도 알아야 할 소프트웨어 테스팅 실무 도서에 포함이 되어 있지 않는데 아무래도 인수 테스트 단계에서 설치 테스트 관련 내용을 포함하는 것이 아닐까 싶다 사용자 환경의 End-User 최종 테스트, 설치 테스트 설치 테스트(Installati..
인수 테스트(Acceptance Testing)은 정보 시스템의 검사 중 하나로서, 해당 시스템이 실제 운영 환경에서 사용될 준비가 되었는지 최종적으로 확인하는 테스팅 단계이다. 개발자가 중심이 되어 수행하는 단위 테스트와 개발자 테스터가 같이 수행하는 통합 테스트 그리고 전문적인 테스터가 주축이 되어 수행하는 시스템 테스트와 달리 인수 테스트의 주축이 되는 테스터는 고객이나 실제 사용하는 사용자가 참여하며, 다른 이해관계자(Stakeholder)도 참여할 수는 있다. 앞에서 수행하는 테스트들은 결함을 찾고, 요구사항의 조건에 충족하는지를 보는 것이 목적이라면 인수 테스트의 목적은 이제 사용을 해도 되는 것인지 확신(Confidence)를 얻는 것이다. 시스템의 인수결정을 위한 확인 과정, 인수테스트인수..
시스템 테스트는 통합한 모듈들이 요구사항에 잘 맞게 작동이 되는지를 판단하게 되며 작동 시간, 처리 능력, 부하, 복구 등과 같은 비기능적인 요소들도 점검한다. 시스템 테스트는 White Box 레벨이 아닌 Black Box 레벨에서 주로 수행하게 되어서 블랙박스 테스트 분류에 속하며, 해당 시스템에 대한 지식이 없어도 테스트를 수행할 수 있다. 단위 테스트와 통합 테스트는 동일한 환경을 맞춰서 수행을 하지 않는다. 단위 테스트야 개발자가 만든 Dummy 객체 등을 이용해서 테스트를 수행할 수 있으며 컴포넌트 혹은 모듈이 정상적으로 돌아가는지 개별적으로 테스트하는 것에 목적을 두고 있으며, 통합 테스트는 각 모듈들이 잘 연결되는지 테스트하며 이를 위해 Test Driver나 Test Stub과 같은 마찬..
통합테스트는 모듈을 통합(Integrate)하는 단계에서 수행하는 테스트이다. 단위 테스트를 우선 수행하여 모듈들이 각각 정상적으로 작동이 되는 것을 확인했다면 이제 이 모듈들을 연동하여 테스트를 수행하게 되는데 이것이 통합 테스트이다. 단위 테스트에서 찾지 못하는 연동시 발생하는 버그 등을 찾을 수 있으며, 다른 모듈들과 동시 다발적으로 테스트를 수행해야 하기 때문에 단위 테스트와 다르게 일반적으로 테스트를 교육 받은 전문적인 테스터와 함께 수행하게 된다. 테스트 시 컴포넌트간의 I/F(인터페이스)를 테스트 하는 것은 물론이고, 운영체제, 파일 시스템, 하드웨어, 시스템간 인터페이스와 같은 시스템의 각기 다른 부부과 상호 연동하는 동작을 테스트하게 된다. 소프트웨어 상호작용 테스트, 통합 테스트통합 테..
단위 테스트(Unit Test)는 다른 말로, 컴포넌트 테스팅(Component Testing)이라고도 불리는 테스트가 가능한 최소 단위로 나눠서 테스트를 수행하는 테스트를 일컫는다. 개발 수명주기(Development LifeCycle)의 정황과 시스템에 의존적이면서도 시스템의 다른 부분에서 격리하여 독립적으로 수행해야 하는 테스트이다. 단위 테스트를 하기 위해서, 가짜 프로그램, 객체(Mock Object)을 만들어서 활용할 수 있으며, 정교하게 테스트를 하기 위해서 테스트 케이스(Test Case) 작성은 필수라 할 수 있다. 개발 기반 모듈 테스트 단위테스트단위 테스트(Unit Test)의 개념 - 소프트웨어 개발 후 테스트 가능한 최소단위 기준으로 결함을 찾고, 기능을 검증하는 테스트 활동 - ..
개발을 한참 하던 시기, 국내에 ISTQB(International Software Testing Qualification Board)라는 자격증이 들어오면서 한 때 테스터에 대해서 진심으로 고민을 했던적이 있었다. 국내에 관련 자격을 취득한 사람이 매우 전무하던 시기이다 보니 왠지 모르게 선구자가 될 수 있다는 생각과 꽤 성장을 할 수 있는 분야로 느꼈으며, 내가 테스트를 꽤 잘하기도 했었기 때문이다. 개발을 1990년부터(Basic) 시작하다보니 남들보다 당연히 개발을 잘하기도 했었고, 추리 소설을 즐겨 읽는 성격이 가미되어 어느 부분에 문제가 발생할 지 등을 남들보다 잘 예측하기도 했다. 그리고, 반년 정도 테스팅 업무를 지원하기도 했는데(스크립트 만드는 것과 테스트 도구를 개발하는 것) 이때 테스..
AOP(관점지향프로그래밍, Aspect Oriented Programming)는 스프링 프레임워크(Spring Framework)을 써야만 되는 이유중 하나로, 대규모 프로그래밍을 매우 강력하게 만들어 줍니다. 관점지향 프로그램을 이해하기에 앞서 우리는 OOP(객체지향 프로그래밍, Object Oriented Programming)에 대해서 먼저 선 이해를 해야 합니다. 프로그램은 소프트웨어 위기를 겪게 되면서, 패러다임이 유지보수를 편하게 할 수 있는 쪽으로 전환을 시작하게 됩니다. 그러면서 객체지향 프로그램이 나오게 됩니다. 즉 소스가 소스끼리 얽히고 설키는 것이 아니라 소스 하나하나를 재활용할 수 있게 만들어서 조립하는 방식으로 만드는 것이죠. 대표적인 언어가 자바(Java) 입니다. 하지만 일반적..
린 개발 방법론은 토요타 생산 시스템(Toyota Production System)에서 사용한 기법을 Mary and Tom Poppendieck 부부가 2003년에 재정립한 기법이다. 즉 생산 시스템에서 영감을 얻어 프로그램 개발 방법론에 적용한 기법인데 IT 프로젝트 뿐만 아니라 다양한 분야에서 사용할 수 있는 기법이다. 린 방법론은 무다(無駄)라는 "낭비"에 포커스를 두고 프로젝트를 수행할 때 발생할 수 있는 모든 낭비를 제거하는 기법이다. 예전에 TPS에 관련된 교육 이수를 받은 적이 있었는데 동료에게 물건을 전달할 때에도 낭비 요소가 없는지 전화 통화를 할 때 낭비요소가 없는지 모두 체크하는 것이 인상적이었다. 낭비요소 제거를 통한 프로세스 향상, 린 개발방법론 의 개요 린(Lean) 개발 방법..
XP는 스크럼(Scrum)과 쌍두마차격인 애자일(Agile) 방법론이다. 비즈니스 상의 요구가 시시각각 변동이 워낙 심하다보니 기존의 개발방법론으로는 현재의 흐름을 제대로 대응하기 힘들었고, 그래서 나온 것이 XP 방법론이다. XP는 켄트 백이 1999년에 "Extreme Programming Explained - Embrace Change" 라는 저서로 발표하였고 이후 XP라는 약칭으로 알려지게 된다. XP는 구체적인 실천 방법들을 정리해 놨고, 이 방법론은 적은 규모의 개발 프로젝트에 적용하기 좋다. 기존의 일반적인 산출물보다 소스코드를 조직적인 행동보다는 개개인의 행동과 책임 등을 중점을 둔다. 초창기에는 4가지의 가치를 추구했던 것으로 사료된다. "What Is Xp" 문서를 보면 단순성, 소통,..
