소프트웨어공학 (SE) - 용어정리

 

1) waterfall 모델

소프트웨어 프로세스는 소프트웨어 시스템을 명세화- 설계 - 구현 - 시험 하기 위한 활동들의 집합을 말하는데, waterfall은 소프트웨어 프로세스의 여러 가지 모델중의 하나이다. 개발의 흐름이 마치 폭포수처럼 지속적으로 아랫방향을 향하는 것처럼 보인다는데서 붙여진 이름이다. (아래와 같은 과정으로 개발되는 프로세스)

2) extreme 프로그래밍

소프트웨어 개발 방법 중하나로서, 비즈니스 상의 요구가 시시각각 변동이 심한 경우에 적합한 개발 방법이다. 애자일 개발 프로세스라 불리는 개발 방법 중의 대표적인 하나로 꼽히며, 약칭으로 ‘XP’로 잘 알려져 있다. 이 방법은 10~12개 정도의 구체적인 실천 방법을 정의하고 있어, 비교적 적은 규모의 인원의 개발 프로젝트에 적용하기가 좋고, 개발 문서보다는 소스코드를, 조직적인 개발의 움직임 보다는 개개인의 책임과 용기에 중점을 두는 경향이 크다. XP의 목적은 고객이 원하는 양질의 소프트웨어를 빠른 시간안에 전달하는 것이고, 수시로 발생하는 고객의 요구사항에 대처, 고객이 원하는 SW를 인도하기 위해서는 고객과 팀원간의 대화를 통해 해결한다.

 

3) 정형적(Formal) 개발

수학적 명세서를 바탕으로 다양한 표현방식으로 실행가능한 프로그램으로 변환하는 개발 방법. 변환할 때 명세서와 변환한 결과물이 정확한지에 초점을 맞추므로 프로그램이 명세서에 적합하다는 것을 보여주는 것이 쉽다. Cleanroom 접근법 (만들 때부터 버그가 없도록 개발하는 것)에 포함된다. 문제점으로는 난이도가 높아서 전문 기술, 기술 적용 교육이 필요하고, 시스템에 속한 부분들을 명세화 시키는 것 자체가 어렵다는 것이다. 하지만 보안이 확실하게 이루어져야 하는 시스템에서는 용이하게 사용된다.

요구사항 정의    -    공식적인 명세화   -     공식적인 변환 -       통합 및 시스템 테스트

 

 

4) 재사용 기반 개발

재사용 기반 개발은 기존의 컴포넌트, COTS(Commerical-Off-The-Shelf) 시스템으로부터 통합되는 것처럼 체계적인 재사용에 기초를 둔 개발 방법이다. 즉, 기존에 있는 것을 가져다가 쓰는 개발 방법 (오픈소스, API 등을 재사용)

1. 요구사항 정의 2. 컴포넌트 분석 3. 요구사항 수정 4. 재사용을 고려한 시스템 설계 5. 개발과 통합 6. 테스트

 

5) incremental 개발

시스템을 한번에 인도하지 않고, 중요도 순서에 따라 개발과 인도를 반복하는 것이다. 각각 증가분에서는 요구되는 기능들을 인도한다. 사용자의 요구사항을 우선순위 메겨서 그 우선순위를 토대로 중요도를 메겨서 중요한 것부터 먼저 넘겨준다. 개발이 시작되면 요구사항은 변경이 불가능하다. 이점은 고객이 중요하고 필요한 부분부터 요구하고 인도 받기 때문에 시스템 초기에 이용할 수 있고, 고객과 함께 소통하여 개발 과정을 반복하므로 실패확률도 적다. 초기에 인도해준 증가분이 후에 인도되는 증가분의 프로토 타입 역할을 하는데, 이를 토대로 요구사항들을 이끌어 낼 수 있다. 또한 많은 테스트를 통해 안정성이 높아진다.

 

6) spiral 모델

나선형 모델은 프로세스 반복 방법론 중하나 인데, 프로세스 과정을 순서도가 아닌 나선형으로 표현한 것이다. S/W의 위험을 명백히 측정하는 데 좋은 모델이다. 사분면이라고 생각하면, 2 - 1 - 4 - 3 순서로 루프가 진행되고, 2- 계획 수립, 목표 설정 : 프로젝트 단계를 위한 특정한 목적을 식별 1- 위험 측정과 해결 : 가장 중요시 여기는 리스크를 측정하고, 감소시킬 활동들이 위치 4- 개발과 확인 : 시스템에 대한 개발 모델을 선택 3- 다음 단계 계획 : 프로젝트 검토, 다음 단계에 대한 계획 나선을 돌며 반복적으로 수행하는 것이 나선형 모델이다.

 

7) use case

시스템 사이에서 교환되는 메시지의 중요도에 의해 클래스나 시스템에 제공되는 고유 기능 단위로서, 상호 행위자 밖의 하나 혹은 그 이상의 것이 시스템에 의해서 실행되는 행위를 함께 하는 것. 사용의 사례, 시스템 사용의 사례들을 그려놓은 것 , 의사소통수단, 구현과 독립적이다. 외부에서 시스템을 바라보아 그 기능을 나타낸다. 그러므로 내부적 수행 과정은 블랙박스. 유스케이스 다이어 그램을 그릴 때 시스템 내부적인 수행과정은 포함시키지 말아야 한다.

 

8) actor

사람, 컴퓨터시스템, 조직 등과 같이 행위를 하는 어떤 것으로 목표나 필요를 가진다. 행동을 하는 어떤것. 논의 대상 시스템(SUD) 자체도 다른 시스템의 서비스를 요청한다면 액터에 속한다. 사람, 조직, 소프트웨어, 기꼐도 액터가 될수있다. - 주요액터 : SUD 의 서비스를 이용함으로써 사용자 목표를 이룬다. - 보조액터 : SUD 에 서비스를 제공한다. - 숨은액터 : 사용사례에서 다룰 관심사가 있지만 주요액터나 보조액터가 아닌것.

 

9) scenario

시나리오는 시스템이 실제로 사용되는 방식에 대한 설명이고, 요구사항 유도에 많은 도움을 준다. 이유는 사람들이 시스템으로부터 무엇을 필요로하는지에 대해 추상적인 문장들보다 시나리오에 좀 더 쉽게 접근할 수 있기 때문이다. 그리고 개략적인 요구사항 설명에 상세한 것을 추가하는데 매우 유용하다.

 

10) requirements document

요구사항은 시스템의 기능 또는 제약 조건에 대한 고수준의 추상적 문장으로부터 상세한 수학적인 기능 명세서까지를 포함하고, 두 가지 용도로 사용되는 것이 필연적이다. 요구사항의 종류 - 사용자 요구사항(요구사항 정의) :시스템이 제공하는 기능과 제약 조건에 대해 자연 언어 +다이어그램으로 작성됨. (고객을 위함) - 시스템 요구사항 (요구 사항 명세서) : 시스템의 기능을 상세히 설명한 구조화된 문서, 고객과 계약자간에 계약을 위해 작성 - 소프트웨어 명세서 :설계 또는 구현의 기초로 사용되는 소프트웨어에 대한 상세한 기술, 개발자를 위해 작성.

 

11) correctness

소프트웨어 요구 사항이나 사용자의 기대에 만족되는 정도 또는 설계·코딩상의 결함이 없는 것.

 

12) consistency

(요구사항 검사) 요구사항들간에 불일치는 없는가?

 

13) completeness

(요구사항 검사) 고객이 필요로 하는 모든 기능이 포함되었는가?

 

14) realism

(요구사항 검사) 요구사항이 주어진 가용한 예산과 기술로서 구현될 수 있는가?

15) adaptability

(검토회의의 점검사항) 순응도는 요구사항이 다른 요구사항에 커다란 영향 없이 변경될 수 있는가?

 

16) maintainability(유지보수성) 

소프트웨어 개발 활동 중 유지보수 비용을 줄이기 위해 유지보수성의 서브-특성을 정의, 검토, 통제해야 합니다. 이러한 활동이 성공적으로 이루어진다면, 소프트웨어의 유지보수성은 개선될 수 있습니다. 흔히 유지보수성의 서브-특성들은 소프트웨어 개발 프로세스의 주안점이 아니기 때문에 유지보수성의 개선이 이루어지기는 어렵습니다. 개발자는 다른 많은 것들에 몰두하고 있어 가끔씩 유지보수 담당자의 요구사항을 무시하기도 합니다. 이것은 곧 시스템 문서화의 부족을 초래하며, 또 프로그램 이해와 영향도 분석에 어려움을 주는 주된 원인이 됩니다. 또한 체계적이고 성숙한 프로세스, 기법, 도구가 존재하면 시스템의 유지보수성을 향상하는데 도움이 됩니다. 17) dependability   믿을 만한 S/W 인가 ? (신빙성)   18) efficiency 쓸데없이 많은 시스템 자원들을 낭비하지 않는가? (효율성)   19) usability 용도가 사용자들에게 적절한가? (유용성)   20) Feasibility studies(가능성 분석) 제안된 시스템이 수행할 만한 가치가 있는 것인지를 판단하고 다음과 같은 것을 검사 - 시스템이 조직의 목적에 기여할 수 있는가 - 시스템이 현재의 기술과 가능한 예산 범위 내에서 개발될 수 있는가 - 시스템이 현재 사용되고 있는 다른 시스템들과 통합될 수 있는가 정보 수집과 정보에 대한 평가, 보고서 작성 등의 작업을 수행 조직내의 인원들에게 묻는 질문 - 시스템이 개발되지 않으면 어떻게 되는가? - 현재의 프로세스의 문제점들은 무엇인가? - 제안된 시스템은 어떻게 도움을 줄 수 있는가? - 통합에 관계된 문제점들은 무엇이 있을 수 있는가? - 새로운 기술 또는 기법들이 필요한가? - 제안된 시스템은 어떤 기능들을 지원하는가?   21) Specification(명세화) 어떤 서비스가 필요한지, 시스템의 동작과 개발에 대한 제한사항을 설립하는 과정 22) Validation(확인) 요구사항이 고객이 정말로 원하는 시스템을 정의했는지를 확인하는 것 요구사항 에러에 따른 비용은 매우 크기 때문에 확인은 매우 중요한 역할 (인도 후에 요구사항 에러를 고치는 비용은 구현 에러를 고치는 비용의 거의 100배) 23) Evolution(진화) 변화하는 비즈니스 환경을 통해 요구사항이 변경됨에 따라, 해당 비즈니스를 지원하는 소프트웨어도 마찬가지로 진화하고 변경되어야 함. 소프트웨어는 본질적으로 융통성이 있고 변경 가능하고 비록 개발과 진화 (유지보수)사이에 개념적인 경계선이 존재하더라도, 완전하게 새로운 시스템이 점점 드물어짐에 따라 연속적인 프로세스로 둘 사이에 구분이 없어지고 있다.

25) Evolutionary development(진화적 개발)

Lehman은 1969년에 소프트웨어 유지보수와 시스템 진화에 대해 처음으로 언급하였습니다. 20여 년에 걸쳐, 그의 연구는 여덟 가지 “진화 법칙”을 공식화하였는데 주요한 발견은 유지보수는 진화론적인 개발이며, 시간이 지남에 따라 시스템(과 소프트웨어)에 어떤 일이 일어나는지 이해하는 것이 유지보수 의사결정에 도움을 준다는 사실입니다. 어떤 이들은 하나의 추가입력(Extra Input) 또는 제약사항 (Constraint)-현존하는 대형 소프트웨어는 절대 완전하지 않으며 계속 진화한다는-을 제외한다면 유지보수는 지속적인 개발이라고 말하기도 합니다. 소프트웨어(또는 시스템)가 진화함에 따라 복잡성을 줄이기 위한 특정 조치가 일어나지 않는다면, 소프트웨어(또는 시스템) 점점 더 복잡해지게 됩니다. 소프트웨어는 규칙적인 수행결과와 추이을 보여주기 때문에, 이러한 것들은 측정이 가능합니다. 유지보수 공수을 산정하기 위해 예측 모델(Predictive Models)을 개발하려는 시도는 계속 되어왔고, 결과적으로, 유용한 관리 도구가 개발되었습니다. 진화에 초점을 맞춘 개발 프로세스로 명세화 - 개발 - 검증 과정을 반복하면서 초기, 중간, 최종 버전을 내놓는 것이다. 2가지 분류법이 있는데, 탐험적 개발과 Throw-away 프로토타이핑 두가지 방법이있다. - 탐험적 개발 : 개략적인 명세서를 작성하고 고객과 함께 의논하여 좀 더 자세히 명세화 시키는 개발 방법으로 요구사항이 잘 정의되어 있고, 상세한 명세서를 작성할 수 없을 때 적당한 방법이다. - Throw-away 프로토타이핑 : 시험 제품을 만들어 보는 방법으로 시스템의 요구사항을 잘 이해하지 못했을 때 일단 만들어보고 요구사항에 대한 이해를 초점으로 하는 개발 방법이다. <문제점> - 프로세스 가시성의 부족 :얼마나 개발했는지, 개발단계가 어디까지 와있는지 알 길이 없다. - 종종 시스템의 구조가 바람직하지 않게 망가진다. - 특별한 기술이 필요할 수도 있다. : 빠른 프로토타이핑을 위해 개발 언어를 선택해야 한다. <적용점> - 중소 규모의 대화식 시스템에 적용 - 대형 시스템의 일부분 - 수명이 짧은 시스템 - 요즘 강조되는 UX기반의 S/W에 적합할 수 있다.

지식을 공유합시다 ! 

다른 방법, 비슷한 방법, 본문 내에 의문점/문제점 댓글로

달아주시고 함께 성장합시다 ^^