소프트웨어 테스트 정말 중요한 테스트 단계다. 요즘 트렌드인 테스트 주도 개발(TDD)은 다들 한 번씩 들어봤으리라 생각된다. 우리가 만든 SW가 정상적으로 잘 작동하는지 어떻게 확신할 수 있을까? SW 오류로 인한 사고 사례 몇 가지만 살펴보자. 걸프전 당시 페트리어트 미사일 실패 미사일이 1km를 날아갈 때마다
소프트웨어 구현 이전 단계인 설계 명세에 따라 직접적으로 코딩하는 단계. 이 단계에선 크게 2가지 이슈가 있다. 코딩 스타일 ( Coding Convention ) 리팩토링 ( Refactoring ) 코딩 스타일은 정말 많지만 간단히 몇 개만 적어보면 명칭 ( 필드, 메서드, 클래스 등의 이름을 어떻게 지을 것인가? ) 주석 ( 주석 표시 맞추기 ) 자료형 상수 수식 문장 등등 여러가지 규칙이 있다. 리팩토링은 기능을 변경시키는게아니라 만들어논 코드를 좀 더 깔끔하게 개선하는 작업.
소프트웨어 설계 이전 요구사항 분석∙정의 단계가 What(무엇)에 대한 관점이었다면, 그 다음인 설계 단계는 How(어떻게)에 대한 관점이다. 요구사항 분석∙정의 단계에서 생각한 걸 구체적으로 어떻게 만들건지 ! ( OS, 미들웨어, 프레임워크 등의 플랫폼을 디테일하게 결정하는 단계 ) 좋은 설계의 조건은 다음과 같다. 요구분석 명세서의 내용을 설계서에 모두 포함해야 한다. 유지보수가 용이하고, 변화에 쉽게 대응하기 위해 모듈을 기능에 따라 독립적으로 작성해야한다. (디자인 패턴) 설계서는 읽기 쉽고, 이해하기 쉽게 작성되어야 한다. 즉, 좋은 설계가 될려면 모듈이 서로 독립적이어야 하고, 모듈 내 요소들 간의 응집력은 높게, 모듈 간의 결합력은 낮게 ! (이러한 고민을 해결하기 위해 디자인 패턴이 나온..
요구사항 정의 이전 포스팅에 이어서 작성하겠다. 요구사항 정의 단계에선 총 4가지를 해야한다고 했다. Use-Case 모델 작성하기 Use-Case 모델 작성한걸 토대로 상세화하기 작성한 Use-Case 모델을 구조화하기 구조화한 Use-Case 모델을 조직화하기 1번 Use-Case 모델 작성하기까지 이전 포스팅에 작성했고, 이어서 나머지를 정리해보자. 2. Use-Case 모델 작성한걸 토대로 상세화하기 1단계에서 Use-Case Diagram을 만들었다면, 이제 이를 토대로 Use-Case 명세서를 작성하는 단계다. 자산 관리라는 임의의 기능으로 간단한 명세서를 만들어보자. 위의 요구사항 명세서는 정말 예제 수준으로 간단히 표현해본건데, 더 자세히 알고싶다면 따로 검색 ㄱㄱ ! 3. 작성한 Use-..
요구사항 정의 고객이 SW에 기대하는 기능 및 특징에 대한 요구를 도출해 명세(Specification)∙검증(Verification)∙확인(Validation)하는 활동 고객의 SW에 대한 요구에 따라 Use-Case 모델링을 한다. (건축에서도 건축짓기 전에 모델링하듯이 IT는 고객의 요구에 따라 모델링 함) 그러면 Use-Case 모델링을 어떤 식으로 표현할거냐에 대한 표준이 있어야 되겠지? 그게 바로 Use-Case Diagram !! 요구사항은 크게 2가지로 나뉜다. 기능적 요구사항 : 사용자 관점에서 사용될 직접적인 기능에 대한 정의 비기능적 요구사항 : 품질(성능, 신뢰성, 보안성, 안전성, 가용성)과 제약(개발 방법, 플랫폼 등)에 관해 정의 결론적으로 요구사항 정의 단계에서 해야할 사항과..
UML ( Unified Model Language) UML은 설계도를 그리기 위한 언어다. 건축 도면과 비슷하게 정해진 기호로 구조를 설명할 수 있도록 하는 언어다. 2005년에 UML 2.0이 발표되었고, 2011년에 발표된 UML 2.4.1이 최신 표준 버전이다. 여러 가지 모델링 언어가 있지만 UML이 가장 대중적으로 사용된다. 겉핡기로 배워서는 간단한 다이어그램을 그리는 것이라면 모를까, 대규모 프로젝트에 그런 식으로 접근하면 안됨 ! 대규모 팀을 이루는 원전 건설사, 항공기 개발사에서는 UML에 통달한 언어학자/기호학자/수학자를 채용한다. UML에 포함된 많은 다이어그램이 있는데, 다 필요없고 딱 2개만 익히자 ! 유스케이스 다이어그램 (use-case diagram) 클래스 다이어그램 (cl..
인력 계획 (=조직 계획) 인력 계획은 말 그대로 사람에 대한 계획이다. S/W 개발은 다른 어떤 분야보다도 사람이 차지하는 비중이 크기 때문에 엄청 중요함 ! 인력에 대한 계획을 잘 세우기 위해서는 아래와 같은 특성을 알아둬야 한다. 기간이 긴 프로젝트에서는 사기를 높이고 이직을 줄이기 위하여 개개인의 일에 대한 만족도를 높여줘야 한다. 문제의 특성에 맞게 팀의 규모를 맞추고, 팀원들을 구성해야 한다. (큰 규모의 팀보다 작은 규모의 팀은 보다 단결력이 강하고 사기가 높으며, 생산성이 높다.) 팀 구성 권한을 가지는 관리자는 일정, 예산, 품질 등의 요소들을 고려하여 팀을 구성해야 한다. 그렇다면 팀을 어떤 식으로 구성해야 좋을까? 정답은 아니겠지만 이 질문에 대한 가이드라인이 있다. 가이드라인에서 제..
일정 계획 S/W를 개발하기 위해 어떤 작업이 필요한지 정의하고, 소작업의 개발 기간 및 소작업들의 우선순위를 정하는 것과 같은 프로젝트 일정에 대한 계획을 세우는 것. 예를 들어 대학의 학사관리 시스템에 대한 간략한 일정 계획은 다음과 같다. 일정 계획을 세우기 위해 해야할 것들이 많은데 어떤 걸 먼저 해야할까? 일반적인 일정 계획 수립 순서는 다음과 같다. S/W 개발 모형 선택 + WBS(Work Breakdown Structure) 작성 각 작업들간 의존 관계를 CPM 네트워크로 나타낸다. CPM 네트워크에 각 작업 소요 기간을 정하고, 프로젝트 완료에 필요한 최소 소요기간을 산출한다. 비용 산정 방법(COCOMO 등)을 통해 구한 노력을 기반으로 프로젝트 소요 기간을 산출하고, 이..
대부분의 일이 계획을 잘 세워야 성공하듯, S/W 개발 또한 사전에 계획을 잘 세워야 성공할 수 있다. S/W 개발 계획에는 크게 3가지가 있다. 비용 계획 일정 계획 인력 계획 만약 계획없이 S/W 개발을 한다면? 일정은 지연될 것이고, 비용은 초과할 것이고, 품질은 저하될 것이다. 그로 인해 유지보수의 비용 또한 증가할 것. 비용 계획 비용 계획을 잘 세우기 위해선 당연히 S/W 개발에 대한 비용을 어떻게 산정할 것인가에 대한 이해가 필요하다. S/W 개발은 전자 제품 생산이나 건축 공사와는 달리 사람(개발자)이 중심이 되고 사람에 매우 의존적이다. 그렇다보니 명확한 개발비 산출이 어렵다. S/W 개발 비용에 영향을 주는 요소는 다음과 같은 것들이 있다. 개발자의 역량 SW의 복잡도 (단순 응용 앱인..
4) 나선형 모델 이 모델은 프로토타입 모델에서 위험 분석을 추가한 모델이다. (프로토타입 모델 + 위험 분석) 어떤 프로젝트에 나선형 모델을 적용하는게 적합할까? (위험 요소들로 인해 확신이 안서는 프로젝트) 해당 프로젝트가 위험 부담(재정적 또는 기술적으로 불안불안할때)이 큰 경우 요구사항이나 아키텍처를 이해하기 어려운 경우 해당 프로젝트에 필요한 핵심 기술에 문제가 있는 경우
SW개발 프로세스 SW개발에서의 프로세스 : 작업(task) 순서의 집합 + 제약 조건(일정, 예산, 자원)을 포함하는 일련의 활동 작업(task) : SW를 개발할 때 일을 수행하는 작은 단위 SW개발 프로세스의 목적은 전체적인 개발에 대한 가이드다. 이전에 얻은 노하우를 전달 -> 시행착오 감소 -> 빠르게 적응 SW개발 프로세스 모델 SW개발 프로세스 모델은 SW개발 생명주기(SDLC, Software Development Life Cycle)를 기반으로 설명된다. SW개발 생명주기 : 요구사항 정의 및 분석 -> 설계 -> 코딩 -> 테스트 -> 유지보수 프로세스 모델은 핵심은 위의 5가지 과정 중에서 어디에 포커스를 맞추느냐이다. SW개발을 시작하기 전 어떤 프로세스 모델을 적용할지 미리 정함으..
1. 소프트웨어의 당면 과제 1) 새로운 소프트웨어에 대한 사용자 요구의 증가 S/W의 발전 속도가 사용자 요구에 따라가질 못한다. 해결방안으로 CBD개발 방법론이 제기되었지만 범용화되지 못했다는 걸로 봐서 큰 효과는 없는 듯 하다. 2) SW 개발 관리 SW 개발에도 관리가 필요하다. 비용 관리 주어진 예산 내에서 개발을 해야함 일정 관리 정해진 기간 내에 프로젝트를 완료해야함 개발자 관리 개발 중에 개발자가 이직을 하거나, 팀원 간의 감정적인 문제가 없어야함 2. 소프트웨어 개발의 어려움 1) 개발 과정이 복잡하다. 무엇이든지 복잡하면 문제가 많이 발생할 수 있는데 SW 개발도 마찬가지. 그래서 소프트웨어 공학에서는 개발의 복잡함을 줄이기 위한 방법과 기술을 제시한다. 2) 참여 인력이 많다. 인력이..