본문 바로가기

Developer/Theory

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

26) Formal transformation(정형적 변환)

명세서를 S/W로 변환시키는 것으로

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

가 되어 공식에 맞춰서 변환하므로 명세서와 일치하는지에 대한 증명과정이 필요한데,

                     와 같은 변환에 대한 정확성을 증명하는 과정을 통해 변환을 한다.

 


27) CASE

Computer-Aided Software Engineering 의 약자로서 S/W 개발에 필요한 도구들을 일컫는 말. CASE 에는 두가지 종류가 있는데 Upper-CASE (Life cycle의 앞부분, real world의 관점에서 필요한 도구를 말하고, 설계 분석 같은 초기 프로세스 활동을 지원)

Lower-CASE (Life cycle의 뒷부분, computer world의 관점에서 필요한 도구, 디버깅, 테스트 같은 후반기 프로세스 활동을 지원하는 도구)가 있다.


28) Maintainability(유지보수성)

요구되는 사항들에 맞춰 진화할 수 있는가? 이를 맞추려면 모듈화가 잘 되어 있어야 한다.

 

29) Dependability(신빙성)

믿을 만한 S/W 인가 ?


30) Efficiency(효율성)

쓸데없이 많은 시스템 자원들을 낭비하지 않는가?

 

31) Usability(유용성)

용도가 사용자들에게 적절한가?

 

32) Confidentiality(신임)

기밀에 속하는 정보나 중요한 정보에 대하여 허가 없이 접근하는 것을 금지하는 보조 장치의 믿을 만한 정도.

 

33) Competence(적임성)

역량이라도 일컫는데, 소프트웨어를 개발하고 유지보수하는데에 능률적인 활동을 일컫는다

개발자는 요구,에로사항에대해 복합적으로 연결된 체인시스템에서 유기적으로 연결시켜

추가적인 트렌드에대해 효율적이게 추가적으로 구축됨을 일 컫는다.

 

34) Understandability(이해도)

요구사항이 응용 시스템의 도메인에 대해 언어로서 표현된다. 이는 종종 시스템을 개발하는 소프트웨어 공학자들에게는 이해하지 못하는 것이다.

35) Implicitness(묵시성)

도메인 전문가들은 해당 영역을 매우 잘 이해하고 있기 때문에, 그들은 도메인 요구사항을 명백하게 표현할 생각을 하지 않는다.

 

36) DFD

시스템의 분석 과정이나 설계 과정에서 사용되는 그래픽을 이용한 도표로서 시스템에서의 자료의 흐름을 나타내기 위해 사용된다. 이는 구조적인 분석 및 설계(SA/SD) 기법에서 가장 기본적인 설계 도구로 자료가 각 부분에서 어떻게 처리되어 흐르는가를 나타낸다.

                                                 <DFD 예시 >

37) ERD

데이터 모델링 분야에서 개체-관계 모델이라는 구조화된 데이터에 대한 일련의 표현으로 구조화된 데이터를 저장하기 위해 데이터베이스를 사용하는데, 이 데이터의 구조 및 그에 수반한 제약 조건들을 다양한 기법에 의해 설계될 수 있습니다. 기 기법 중 하나가 개체-관계 모델링(ERM)이라고 하는데, ERM 프로세스의 산출물을 가리켜서 개체-관계 다이어그램 (Entity-Realationship Modeling) 줄여서 ERD 라 일컫는다.

                                                          <ERD 예시 그림>

 


38) Validity

(요구사항 검사) 시스템이 고객의 요구사항을 가장 잘 지원하는 기능을 제공하는가?

 

39) Consistency

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

 

40) Completeness

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

 

41) Realism

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

 

42) Stakeholder

최종 사용자, 관리자, 유리보수에 관계된 공학자, 도메인 전문가, 마케팅 관계자 등이 관련 되어 있는데, 이들을 Stakeholder 라고 부른다.

 

43) Specification(명세화)

어떤 서비스가 필요한지, 시스템의 동작과 개발에 대한 제한사항을 설립하는 과정









지식을 공유합시다 ! 

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

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