시스템 공학은 소프트웨어가 중요한 역할을 하는 복잡한 시스템의 개발과 진화의 모든 관점을 다룹니다. 그러므로 시스템 공학은 소프트웨어 공학과 마찬가지로 하드웨어 개발, 정책, 프로세스 설계, 시스템 설치 등을 다룹니다. 시스템 엔지니어는 시스템을 분석하고 전체 구조를 정의하며 최종 시스템을 만들기 위해서 서로 다른 부분을 통합하는 것을 포함합니다. 그것은 하드웨어, 소프트웨어 등의 시스템 컴포넌트 공학과는 다소 거리가 있습니다.
시스템 공학은 소프트웨어 공학보다 더 오래된 학문입니다. 비행기와 화학 공장 설비와 같은 복잡한 산업 시스템은 백 년 전부터 만들어져 왔습니다. 그러나 시스템에서 소프트웨어의 비율이 증가함에 따라 유스케이스 모델링, 형상 관리와 같은 소프트웨어 공학 기술이 시스템 공학에서도 사용되고 있습니다.
기본적으로 컴퓨터 과학은 컴퓨터와 소프트웨어 시스템이 가지고 있는 이론과 방법을 다루지만, 소프트웨어 공학은 소프트웨어를 생산하는 실제적인 문제를 다룹니다. 물리학이 전자 공학자에게 기본적인 것 처럼, 컴퓨터 과학의 지식은 소프트웨어 엔지니어에게도 기본이 됩니다.
이상적으로 소프트웨어 공학의 모든 것이 컴퓨터 과학의 이론에 의해 토대가 마련되어야 하지만 실제로는 그렇지 않습니다. 소프트웨어 엔지니어는 소프트웨어를 개발하는데 임시방편을 자주 사용합니다. 컴퓨터 과학의 정연한 이론이 소프트웨어 제품에 필요한 복잡하고 실제적인 문제를 늘 적용될 수는 없다는 것입니다.
소프트웨어 공학은 시스템 명세화의 초기 단계부터 시작하여 시스템을 사용하기 시작한 후부터 시스템을 유지보수하기까지 소프트웨어 생산의 모든 관점을 다루는 공학적인 학문입니다.
1. 공학적 원리
엔지니어는 일이 되도록 합니다. 그들은 적당하다고 생각돠는 이론, 방법, 도구 등을 적용합니다. 그러나 이것들을 선택적으로 적용하고 문제에 적합한 방법과 이론이 없을지라도 문제에 대한 해결을 찾으려고 노력합니다. 엔지니어는 조직상의 제약 조건과 재정적인 측면의 제약 조건에 따라서 일해야 한다는 것을 인식하고 있기 때문에 이러한 제약 조건 내에서 해결책을 찾습니다.
2. 소프트웨어 생산의 모든 측면
소프트웨어 공학은 단지 소프트우어 개발의 기술적 프로세스뿐만 아니라 소프트웨어 프로젝트 관리와 같은 활동 그리고 소프트웨어 생산 지원에 필요한 도구, 방법, 이론의 개발과 같은 활동을 포함합니다.
일반적으로 소프트웨어 엔지니어는 자신의 작업에 체계적이고 조직적인 방법을 선택하는데, 대게 이것은 고품질의 소프트웨어를 생산하는 가장 효과적인 방법입니다. 그러나 공학은 주어진 환경 내에서 가장 적절하고 더욱 독창적인 비형식적 개발 방법이 어떤 환경에 효과적인지를 찾아내는 것이 전부입니다. 비정형적인 개발은 소프트웨어와 그래픽 설계 기술의 혼합을 요구하는 웹 기반 시스템의 개발에 대하여 특히 적합합니다.
많은 사람들은 컴퓨터 프로그램을 소프트웨어와 같은 것이라고 생각합니다. 그러나 조금 더 넓은 의미의 정의를 하자면 소프트웨어는 단순한 프로그램일 뿐만 아니라 프로그램이 올바르게 작동하도록 하는 데 필요한 그와 관련된 모든 문서 및 설치 데이터를 의미합니다.
소프트웨어 시스템은 여러 개의 프로그램과 그 프로그램을 설치하는 데 필요한 설치 파일, 시스템의 구조를 기술한 시스템 문서, 시스템 사용방법과 사용자가 제품의 최근 정보를 내려받기 위한 웹사이트를 기술하는 사용자 문서 등을 포함합니다.
소프트웨어에는 2가지 유형이 있습니다.
1. 일반적인 제품
개발 조직에 의해서 생산된 독립형의 제품으로서 그것을 사고 싶어 하는 어떤 고객에게든지 판매할 수 있습니다. 이러한 유형의 제품은 데이터베이스, 문서 편집기, 프로젝트 관리 도구, 그래픽 패키지 등과 같은 PC용 소프트웨어를 포함합니다.
2. 맞춤형 제품
특정한 고객을 위한 시스템으로서 소프트웨어 개발자는 특정 고객에 대한 소프트웨어를 개발합니다. 이러한 유형의 소프트웨어는 전자 장치에 대한 제어 시스템이나 특정 비즈니스 프로세스를 지원하기 위한 시스템, 항공관제 시스템 등을 포함합니다.
이 2가지의 소프트웨어의 중요한 차이점은, 일반적인 제품은 그 소프트웨어를 개발하는 조직이 소프트웨어 명세화를 제어하지만, 고객용 제품은 그 소프트웨어를 구입하는 조직에 의해서 소프트웨어의 명세서가 개발되고 제어됩니다. 소프트웨어 개발자는 그 명세서에 따라 일을 진행합니다.
그러나 이러한 제품의 차이에 대한 장벽이 점점 허물어져 가고 있습니다. 더 많은 소프트웨어 회사가 일반적인 시스템으로 시작해서 특정 고객에 적합한 것으로 맞추어 가고 있습니다. SAP 시스템과 같은 전사적자원 관리(ERP: EnterpriseResource Planning)시스템이 이러한 기법의 가장 좋은 예입니다. 복잡한 대규모 시스템을 비즈니스 규칙과 프로세스, 필요한 보고서에 관한 정보를 통합한 한 회사에 적용하는 것입니다.
모두 완성하지 않아도 완성된 업무 프로세스부터 순차적으로 현장에서 데모를 하고 실제로 조작하면서 사용의 편리성을 확인할 수 있습니다. 문자나 그림으로 그린 종이 사양서를 가지고 상상하는 것이 아니라 좋고 나쁨을 직관적으로 판단할 수 있으므로 개선을 위한 피드백을 정확하고 신속하게 처리할 수 있습니다.
비즈니스 상 중요한 업무 프로세스부터 완성시켜 1 ~ 2주 단위로 계속해서 사용자에게 릴리즈를 검증 받습니다. 릴리즈 때마다 이전 릴리즈의 수정과 테스트를 반복하므로 중요한 부분일수록 빠른 단계에서 반복 검증할 수 있어 버그를 철저히 수정할 수 있습니다. 개발 후반부가 되면 업무 프로세스의 중요도가 낮아지므로 문제가 발생해도 전체에 대한 영향을 최소한으로 줄일 수 있고 전체적으로 고품질의 시스템을 만들 수 있습니다.
애자일 개발에서의 업무 프로세스 단위화
업무 프로세스 단위로 만들기 때문에 사양 동결은 1 ~ 2 주가 걸리므로 도중에 사양이나 우선순위가 바뀌어도 아직 착수하지 않은 업무 프로세스라면 쉽게 바꿀 수 있고 변경 요구도 유연하게 대처할 수 있습니다.
결과적으로 단기간에 고품질의 변경이 용이한 개발을 실현할 수 있습니다. 애자일 개발의 목적을 정리하면 다음 3가지로 압축할 수 있습니다.
1) 예측할 수 없는 미래를 추측으로 정하지 않고 정말로 사용할 시스템만 만듦으로써 쓸데 없는 개발 투자를 막습니다.
2) 실제로 움직이는 '현물'을 확인하면서 현장이 납득하여 사용할 수 있는 시스템을 실현합니다.
3) 납득할 수 있는 예산과 기간 안에서 최선의 기능과 최고의 품질을 실현합니다.
'IT와 하나 된 비즈니스'에 대한 비중이 높아지는 지금 IT 비즈니스 요구에 대한 즉각적인 대응력은 지금보다 중요해질 것입니다. 그런 의미에서도 애자일 개발이 주목받고 있습니다.
※ 오늘은 소프트웨어 공학의 기초인 '애자일 개발의 장점'에 대하여 알아보았습니다.
이 포스트는 학부에서 제공하는 기본적인 컴퓨터, 소프트웨어 공학 강의와 책들을 토대로 알기 쉽게 내용을 작성하였습니다. 하지만 계속 더 유익하고 논문 및 전문 서적을 읽어가며 더 추가돼야 할 내용이 있으면 컴퓨터, 소프트웨어 공학,프로그래밍 포스트와 콘텐츠들을 계속 고도화하는 방식으로 진행하려고 합니다.
기존에는 만들어야 할 시스템의 요건을 모두 정한 후에 개발을 시작하는 '워터풀형 개발'이 주류였지만, 이 방법으로는 대응할 수 없는 사태가 늘고 있습니다. 그래서 주목을 받고 있는 것이 애자일 개발입니다.
워터풀형 개발에서는 '전부 만드는 것'을 전제로 하여, 사용자의 요건이 모두 정해지지 않으면 개발에 착수할 수 없습니다. '반드시 사용한다', '사용할 것 같다', '장래에 사용할지도 모른다' 등을 고려하여 사양을 굳혀 갑니다. 개발은 기능 단위로 진행하는데, 기능이란 입력 화면, 장표 인쇄, 집계 등 일련의 업무처리를 구현하는 부품입니다. 이러한 것을 나눠서 만든 후 나중에 모두 연결하여 처리의 흐름을 만듭니다.
따라서 모든 기능을 완성시키고 연결하기 전까지는 현장 사용자에게 사용해 보라고 할 수가 없습니다. 또한, 만들기 시작하면 도중에 변경하는 것이 어려우며, 일단 전부를 다 만드는 것이 우선시됩니다. 변경이나 품질 보증은 코드를 전부 다 쓴 마지막에 확인하고 대처해야 합니다.
애자일 개발 방법론
한편 애자일 개발은 '전부 만들지 않는다'는 것을 전제로 합니다. 이 점이 워터풀 개발과 본질적으로 다른 점으로, 애자일 개발은 '업무상 필요성이 높은 프로세스를 선별하여 우선순위를 정하고, 정말로 사용할 업무 프로세스만 만들자'라는 개념입니다.
여기서 말하는 업무 프로세스는 '출하 지시 버튼을 누르면 창고 출하 전표가 인쇄되어 출력된다', '경비 전산 장표에 데이터를 입력하면 경리 부서에 데이터가 전달된다'와 같이 하나로 연결된 업무의 흐름입니다. 이를 '업무 수행하는 데 있어서 중요도가 높은 순서'로 우선순위를 정해 순차적으로 개발해 갑니다. '필요한지 아닌지 모르겠다', '있으면 좋을지 모르겠다'라는 만들지 않는 것이 좋습니다.
반복형 개발 (Iterative development)
지속적 통합 과정 (Continuous integration)
하나의 업무 프로세스는 1~2주일 정도에 개발할 수 있는 규모로 하여 대략의 개발 기간과 필요한 인원을 계획하여 개발을 시작합니다. 그리고 '반복형 개발(Iterative Development)'나 '지속적인 통합(Continuous Integration)이라는 기법을 사용하여 비즈니스 요구에 즉시 대응하고 있습니다.
※ 오늘은 소프트웨어 공학의 기초인 '애자일 개발'에 대하여 알아보았습니다.
이 포스트는 학부에서 제공하는 기본적인 컴퓨터, 소프트웨어 공학 강의와 책들을 토대로 알기 쉽게 내용을 작성하였습니다. 하지만 계속 더 유익하고 논문 및 전문 서적을 읽어가며 더 추가돼야 할 내용이 있으면 컴퓨터, 소프트웨어 공학,프로그래밍 포스트와 콘텐츠들을 계속 고도화하는 방식으로 진행하려고 합니다.
XP(eXtreme Programming) 창시자 중 한명이자, TDD를 주도한 켄트 백은 TDD를 소개한 자신의 책에서 "프로그램을 작성하기 전에 테스트를 먼저 작성하는 것"이라고 테스트 주도개발을 정의하였습니다. 프로그램을 작성하지도 않았는데, 테스트를 먼저 하라는 것은 무슨 의미인지 어리둥절했습니다.
"프로그램을 작성하기 전에 테스트를 먼저 하라! Test the program before you write it! " by 켄트 백
"업무 코드를 작성하기 전에 테스트 코드를 먼저 만드는 것"
코드를 검증하는 테스트 코드를 먼저 만든 다음에 실제 작성해야 하는 프로그램 코드작성에 들어가라는 뜻입니다. 최초에는 테스트 우선 개발 (Test First Development)이라고 불렸으나 지금은 테스트 주도 개발 (Test-Driven Development, TDD)이라 불립니다. 테스트 코드를 작성한다는 TDD의 정의가 다소 과격하게 들릴 수도 있지만, 메소드나 함수 같은 프로그램 모듈을 작성할 때 '작성 종료조건을 먼저 정해놓고 코딩을 시작한다'는 의미로 받아들이면 편합니다.
예를 들어, 2개의 숫자 합을 구해서 반환하는 SUM이라는 메소드를 작성한다고 가정해봅시다.
위의 표는 만들고자 하는 메소드를 일종의 설계문서(Spec)처럼 간단히 적어본 모습입니다. 사실 이러한 형식은 굳이 TDD라는 용어를 꺼내지 않더라도, 우리가 프로그램을 작성할 때 머릿속으로 생각하는 내용과 별반 다르지 않습니다.
다만'문서로 만들어 머리로 생각하고 눈으로 확인할 것인가?'아니면'예상결과를 코드로 표현해놓고 해당 코드가 자동으로 판단하게 할 것인가?'의 차이가 있습니다. 예를 들면 위의 설계 문서에 따라 sum 메소드를 작성할 때, 코드를 정상적으로 구현됐는지를 판단하는 방법을 선택한다면 아래와 같은 코드로도 작업할 수 있습니다.
위의 예제는 main 메소드를 테스트 메소드 처럼 사용했습니다. sum 메소드는 컴파일 에러만 나지 않도록 해놓고, 내부는 비어 있는 상태입니다. sum 메소드를 먼저 구현한 다음에 테스트를 할 수도 있지만,그렇게 하지 않고 검증코드를 먼저 만들어놓았습니다. 그 검증코드에 해당되는 테스트 케이스를 모두 만족하면, 즉 main 메소드의 실행 결과가 모두 true로 나오면 sum 메소드가 정상적으로 작성됐다고 판단하기로 한 것입니다.
명시적인 코드로 개발 종료조건을 정해놓은 것입니다. 이런 식의 개발 접근 방식이 바로 TDD입니다. 무언가 특별한 테크닉이나 테스트 프레임워크를 써야 TDD일 것 같지만 그렇지 않습니다. 테스트 케이스 작성으로 구현을 시작하는 것, 그게 바로 TDD방식입니다.
이 포스트는 학부에서 제공하는 기본적인 컴퓨터, 소프트웨어 공학 강의와 책들을 토대로 알기 쉽게 내용을 작성하였습니다. 하지만 계속 더 유익하고 논문 및 전문 서적을 읽어가며 더 추가돼야 할 내용이 있으면 컴퓨터, 소프트웨어 공학, 프로그래밍 포스트와 콘텐츠들을 계속 고도화하는 방식으로 진행하려고 합니다.
