[소프트웨어 엔지니어링] 중간고사 기록용

소프트웨어공학개론 [중간고사]

연습문제

1장 대규모 소프트웨어 개발 과제

1. Stake Holder 란? Stake Holder가 증가할 경우에 발생되는 문제점은?

• Stake Holder란 이해관계자로 해석되며, 소프트웨어 개발에 관련된 모든 사람을 이야기한다. 소프트웨어 개발에있어서 Stake Holder들은 대표적으로 기획담당자, 프로젝트 관리자, 설계 담당자, 개발담당자, 운용담당자, 유지봇수담당자 , 고객, 이용자 , 판매담당자가 있다. Stake Holder들은 서로 다른 관점에서 소프트웨어 개발을 바라보기때문에 Stake Holder가 증가할수록 의사소통에 어려움이 생기고, 담당자들간의 연계업무에 문제가 생길 수 있다. 이처럼 발생한 문제점들은 소프트웨어 개발에 재작업량을 증가시키며, 이는 소프트웨어 개발 비용과 시간을 증가시킨다.
  

2. Stake Holder가 증가할 경우에 발생하는 문제점에 대해서 추상화와 모델링에 어떤 효과가 있는가?

• 위에서 이야기한바와 같이 Stake Holder들의 관점은 다양하다. 그렇기 때문에 추상화및 모델링 작업에 있어서, 서로다른 관점으로 현상을 파악하고 이해한다. 하지만 추상화를 통해 본질적으로 공통된 특징들을 추출하고, 모델링을하여 획일화된 모델을 만들면, Stake Holder들간에 충돌을 최소화할 수 있다.
  

3. 소프트웨어 개발기간과 이용기간의 장기화에 의해 발생되는 문제점은?

• 소프트웨어 개발기간과 이용기간이 장기화되면 개발 기간 및 비용이 증가한다. 하지만 만약에 코딩 과정에 들어가기 전에 요구 사항 분석을 정확히 하고 이를 설계사 양서와 요구사양 서로 문서화해두었다면, 개발 기간과 비용의 증가 수치를 대폭 감소시킬 수 있다. 왜냐하면 위 두가지를 확인하여 프로그램상의 정확한 문제점을 파악하고, 시스템의 구조를 확인하며, 설계자의 의도를 파악하여 훨씬 빠른 시간 안에 해결할 수 있기 때문이다. 단 위와 같이 신속 정확하게 해결하기 위해서는 설계사양서, 요구사양서에 “왜 A와 같은 방식을 선택했는지” , “왜 B라는 판단을 내렸는지”등 세부 한 내용을 모두 기술해서 문서화해야 한다.
  

4. 소프트웨어 개발 초기단계에서 요구사항을 명확하게 규정해야하는 이유는?

• 소프트웨어 개발 시 초기 단계에 요구 사항을 명확하게 규정하지 않으면 프로그래밍 과정에서 대참사가 일어난다. 왜냐하면 소프트웨어를 개발하는 목적인 고객의 요구 사항(무엇을 만드는지, 어떤 구조로 제작되는지,어떻게 사용되는지)이 파악되지 않으면 노동력 낭비만 이루어지기 때문이다. 만약 수강신청 소프트웨어를 제작하는데, 고객은 스마트폰에서만 사용할 애플리케이션을 만들 고싶어한다 하지만 이 점을 초기에 파악하지 않은 개발회사는 데스크탑 버전으로 만들어버렸다. 만약 이런상황이 발생되면 처음부터 다시 애플리케이션으로 제작해야하는 참사가 발생한다. 즉 요구 사항을 명확하게 규정하지 않은 체 소프트웨어를 만든다는 것은 기초공사 없이 대교를 만든다는 것과 같은 소리이다.또한 요구 사항들을 토대로 요구사 항서를 작성하게 되고, 또 이를 바탕으로 설계사 양서를 작성하기 때문에 소프트웨어 개발 초기 단계에서 요구사 항서를 명확하게 규정해야 합니다.
  

5. 무엇을 만들것인가 뿐만아닌 어떤 구조로 할 것인가 , 어떻게 사용할 것인가에 대해서 조기에 규정해두어야 하는 이유는?

• 위에서 언급했듯이, 소프트웨어를 개발함에 있어서 고객의 요구 사항 충분히 파악하고 이를 요구 사항 서로 문서화해야 한다. 이 과정에서 “무엇을 만들 것인가” 뿐만 아니라 구조와 사용방법에 대해서까지 조기에 규정해야 하는 이유는, 이를 확인하지 않은 채 프로그램을 만들었다가는 고객의 요구와 맞지 않아 개발 시간이 증가되고, 개발비용이 증가되는 현상이 발생하기 때문이다. 그렇기 때문에 우리는 소프트웨어를 개발하기 위해서 고객의 요구 사항 즉 무엇을 만드는지(고객이 원하는 프로그램이 무엇인지 파악) , 어떤 구조로 할 것인지 (인터넷을 경유해서 웹브라우저에서 동작 시킬지, 개발 언어는 어떤 언어로 만들지 등), 어떻게 사용하는지(스마트폰 전용인지, 데스크톱 버전인 지 등)를 조기에 규정하고 문서화해야 한다.
  

2장 소프트웨어 개발공정

1. 소프트웨어 개발에 있어서 재작업이란 무엇이며, 재작업을 줄이기위한 방법은?

• 소프트웨어 개발에 있어서 재작업이란, 개발비용의 증가와 개발기간의 장기화를 의미하며 시간과 금전적 가치는 소프트웨어 개발에있어서 가장 중요한 자원입니다. 소프트웨어 재작업을 줄이기 위해서 우리는 적합한 프로세스를 선택하여 개발을 진행해야하며, 프로젝트를 관리하고, 여러 성과물들을 관리해야하며, 요구사항을 정확하게 파악하여 요구사양서를 작성해야합니다. 위 과정들은 소프트웨어개발에 재작업량을 줄여주는 중요한 요소입니다.
  

2. 폭포수 모델의 작업공정은 무엇이며 그 문제점은?

• waterfall모델은 사용사례가 가장 많고, 전통적인 SW 개발 공정 과정입니다. 폭포수 모델의 작업 공정은 요구분석 -> 기본설계 -> 상세설계 -> 구현 -> 테스트 / 검증 -> 운용/보수 이며, 각 공정과정마다 요구사양서 -> 기본설계사양서(외부사양서 , 시스템 사양서) -> 상세설계 사양서(내부사양서, 프로그램사양서) -> 프로그램 리스트 -> 테스트 사양서 가 결과물로 도출됩니다.
  

장점

• 폭포수 모델은 각 공정들이 명확하게 구분되어있고, 각 공정마다 리뷰작업을 통해 후속공정에 문제가 영향을 미치지 않도록 노력합니다. 그렇기떄문에 진행상황 파악이 용이하고, 프로젝트 관리가 수월합니다. 또한 각 공정마다 테스트 공정을 거치며, 테스트과정은 아래와 같습니다.구현공정을 테스트하는 단위테스트(모듈 동작상태 확인) , 상세설계 과정을 테스트하는 통합테스트(다양한 모듈을 통합해 동작상태 확인) , 기본설계 과정을 테스트하는 시스템테스트(완성된 프로그램 동작상태 확인) , 요구분석단계를 테스트하는 인수테스트(고객의 요구사양에 적합한지 확인).

단점

• 후속공정과정에서 문제점이 발생되면 waterfall 모델 특성상 앞 공정으로 되돌아가서 다시 재작업을 해야함.

3. 시험형 프로토타이핑의 잇점은 무엇이며 나선형 모델의 위험요소 분석의 관점에서 시험형 프로토타이핑을 폭포수모델에 적용하는 경우의 문제점은?

• 프로토타이핑은 크게 시험형 프로토타이핑과 진화형 프로토타이핑으로 나뉜다. 그중 시험형 프로토타이핑은 말그대로 Test를 하기위한 프로그램을 만드는데, 이는 요구사양을 작성한 후에 폐기한다. 시험형 프로토타이핑은 문제점을 보다 쉽게 추출하게 하며, 요구사항의 중요한부분들을 가시화하여 바로 이용자, 고객에게 평가받을 수 있다. 위 프로토타이핑 고정을 거쳐 계획대로 개발해도 아무런 문제가 발생하지 않음을 확인했다면, 추후에 문제 발생으로 인한 재작업량을 대폭으로 감소시킬 수 있다.
  
• 나선형 모델은 지속적으로 위험요소들을 분석하고, 프로토타입에 적용시켜 위험요소를 경감한다. 그리고 그 위험요소의 가능성이 정말 작아질때 다음 공정을 진행한다. 하지만 폭포수모델은 프로토타입에서 확인하지 못한 부분의 기능에서 문제가 발생할시 다시 재작업을 해야한다.
  

4. 반복형 개발 프로세스모델과 점증형 개발 프로세스 모델의 차이점은 무엇인가?

• 반복형 개발 프로세스모델과 점증형 개발 프로세스모델을 나누는 기준은 프로토타입의 개선방법에 따라서 나뉘며, 반복형 개발 프로세스는 프로토타입의 개발과 평가를 반복해서 만줄할 수 있는 시스템이 구축되면 완료하는 모델로, 요구분석과 설계, 구현과 테스트 를통해 프로토타입을 완성하면 그 프로토타입을 고객 혹은 이용자에게 평가받고 문제점이 발생하면 수정하는 형식으로 진행되고, 점증형 개발 프로세스는 시스템 전체를 여러 시스템들로 분할하여 개발하고, 분할된 시스템들을 검증받아가며 그것들을 조립해가면서 완성해간다.즉 반복형 개발은 전체적인 프로토타입을 제작하여 검증받는다면, 점증형 개발은 큰 시스템을 분할하여 분할된 시스템들을 검증받아가면서 제작하는 과정이다.
  

3장 프로젝트관리

1. 프로젝트 관리에 있어서 , 왜 개발계획을 세워야 하는가?

• 프로젝트란 제품이나 서비스를 만들기 위햏 수행되어야 할 일시적인 행동을 의미하며, 우리는 소프트웨어 개발 프로젝트를 관리함으로써 프로젝트의 성공률을 높일 수 있다. 왜냐하면 우리는 프로젝트 관리를 통해 SW개발에서 누가 어떤 단계에서 무엇을 하면 좋을지를 계획핳고 확인함혀 대책을 마련하는 작업을 하기 때문이다.

2. 표준업무기법을 사용한 개발공수 산정 절차는?

• 공수란 일정한 작업에 요하는 인원수를 노동시간 또는 노동 일 / 월로 나타내는 단위로써, man-hour / man - day / man-month로 나타낸다.각 단위는 인원수 대비 시간(시간 / 일 / 월)을 기준으로 표현한다. 우리는 개발공수를 개바일정과 체제를 확정하기 위해 산출해야하며, 공수가 산출되면 고객에게 SW개발비용과 기간을 설명할 수 있게된다. 공수의 산출 방법엔 크게 OOSW , 표준업무기법 , Cocomo , 기능점수법이 있으며 표준업무기법을 사용한 개발공수 산정절차는 아래와같다.
  
  먼저 개발하려는 소프트웨어의 작업을 여러개의 표준 업무들로 분해한다. 그 후 각 표준업무들의 규모와 복잡도를 결정하고, 그렇게 정한 표준업무의 작업공수와 건수를 곱한다음 모두 더한다. 표준업무 기법의 가장 큰 특징은 SW개발에 필요한 표준업무들마다 개발공수를 미리 정한다는 것 인데, 이 과정에서 각 개발업체 및 개발프로젝트의 실적 과 멤버들의 경험들을 토대로 독자적으로 설정한다는 점 이다. 그리고 이를 토대로 실제 SW 개발에 필요한 작업을 예측해서 공수를 산정한다.

3. 기능점수법의 적용순서를 설명하고, 사용시 주의사항은?

• COCOMO , COCOMOII , 표준업무기법 은 소스코드의 라인수 (Line of SourceCode)로 개발 공수를 산정한다. 하지만 기능점수법은 SW에 포함된 기능의 개수를 기준으로 공수를 산정한다. 기능점수법은 소프트웨어의 다양한 기능들을 외부입력, 외부출력 , 외부조회 , 내부논리파일 , 외부인터페이스파일로 소프트웨어 내부의 기능을 분류한 후 , 이 5가지 기능들의 복잡도를 구하고 복잡도 별 기능수 와 가중치 계수를 선정하여 두 수를 곱해 미조정된 기능점수를 산출한다.그 후 기능의 기준이 되는 14개의 항목에 영향도 점수를 부여하여 0.65 + (0.01 * 영향도 합계점수 N)을 하여 조정용 계수를 만든다. 조정용 계수는 미 조정된 기능점수를 조정할 때 사용되고, 그 범위는 0.65 이상 1.35 이하 이다. 그 이유는 영향도 합계점수의 범위가 0 ~ 70이기 때문이다. 위 과정을 통해 조정용 계수와 미조정기능점수가 구해졌다면, 그 두 수를 곱해 조정된 점수 FP를 구한다. 소프트웨어 프로젝트의 생산성은 FP / MM 이다.
  다시 정리해보면 소프트웨어의 기능점수 측정유형을 결정하고 계산범위 및 어플릭케이션 경계를 식별한 후 데이터 와 트랜잭션의 기능과 복잡도를 계산한후 곱하여 미조정 기능점수를 산출하고, 소프트웨어 기능의 긱준이 되는 14개의 항목에 영향도 점수를 부여하여 조정용 계수를 만든후 그 둘을 곱하면 조정 기능 점수각 산출이된다.

4. CMM이 어떻게 프로세스 개선에 도움을 주는가? 그리고 CMM을 사용할 때의 주의사항은 무엇인가?

• 우리는 측정하지 못하는 것을 절대 조정할 수 없다. 그렇기 때문에 우리는 프로젝트 관리에 있어서 소프트웨어 개발 성과물고가 개발 공정의 품질을 반드시 평가해야 한다. CMM은 Capability Maturity Modedel의 약자로써 현재는 CMMI (CMM Integration)으로 체계화 되었으며 소프트웨어 프로세스 품질을 인증하는 제도이다. CMM은 소프트웨어 프로세스에 있어서 서비스의 개발, 획득 , 유지보수를 하기위한 조직의 공정 및 관리능력을 향상시키기위한 가이드 제공을 목적으로 한다. 그리고 소프트웨어 개발관련 CMM을 우리는 SW-CMM이라고 한다.
  SW-CMM은 총 5가지의 단계와 4개의 핵심 프로세스를 갖고있다. 그리고 그 내용은 아래와 같다.
• 레벨 1- 초기
  이 수준의 프로세스는 (일반적으로) 문서화되지 않고 프로세스의 성과를 예측할 수 없는 상태입니다.
  

• 레벨 2- 반복 가능 ( 요구관리 , 프로젝트계획 , 프로젝트 추적, 감시 , 외주/형상 관리 , 품질보증)
  이 성숙도 수준의 특징은 성공했던 프로젝트 프로세스를 반복사용 , 반복적 실행으로 통계적 관리가 가능합니다.
  

• 레벨 3- 정의(조직 프로세스 정의 교육훈련 프로그램통합 소프트웨어 관리 , 소프트웨어 생산 공학 , 그룹간 조정 및 중간 심사)
  프로세스 작업을 정의하며, 이해가 가능합니다.
  프로세스 데이터로 프로젝트 관리를 합니다.
  프로세스 기초 정립이후 계속 발전하는 상태입니다.
  

• 레벨 4- 관리 (정량적 프로세스 관리 , 소프트웨어 품질 관리)
  프로세스의 성과를 측정할 수 있고, 분석할 수 있으며, 개선하고 관리가 가능한 상태입니다.
  
  레벨 5- 최적화 (효율적, 결함예방 , 기술변화 관리 , 프로세스 변경 관리)
  질적 , 양적으로 개선이 지속적으로 진행되는 상태입니다.
  

5. 소프트웨어의 6가지 품질 특성은 무엇인가?

소프트웨어 품질에 관한 국제표준 ISO / IEC 9126에 의거하여 소프트웨어는 6가지 품질 특성을 갖고 이는 기능성 , 신뢰성, 사용성 , 효율성 ,유지보수성 , 이식성으로 정의됩니다. 대학교 수강신청 소프트웨어를 예로 아래의 특성을 설명하면, 기능성은 수강신청기능이 제대로 구현되었는가에 관한것이고, 신뢰성은 수강신청 기능이 정상적으로 문제없이 동작하는가에 관한것 입니다. 사용성은 이용자가 수강신청을 이용하기 수월한가에 대한것이고, 효율성은 얼마나 효율적으로 동작하는까이며, 유지보수성은 수강신청 기능에 개정작업에 필요한 노력이 적은가에 대한것입니다. 이식성은 호환성이 얼마나 좋은가, 즉 다른환경으로 이식하기 수월한가에대한것 입니다. 우리는 소프트웨어 품질을 향상시키기위해 각 소프트웨어에 품질특성에 대해 높은 수준을 유지해야합니다.

4장 요구사항 분석

1. 요구사항과 요구사양의 관계는 무엇인가?

요구사항은 이용자 혹은 고객이 소프트웨어에 대해 명시적 , 잠재적으로 생각하고있는 것들이며 소프트웨어를 이용하는 목이며 기능적 요구사항(개발하려는 시스템이 무엇을 수행하는지 표현) 과 비기능적 요구사항 (성능 , 사용편의성 , 안전성, 유지보수성, 이식성 등을 표현) 한것으로 나뉜다.. 우리는 요구사항을 만족시키기 위해 소프트웨어가 구현해야 하는 요건들을 모아서 사양화 하고 이를 요구사양서라 칭한다. 요구사양서는 추후에 많은 공정에 큰 영향을 주고, 정확한 요구사항 분석을 통해 도출된 요구사양서는 개발과정의 재작업량을 대폭감소시키기 때문에 우리는 최대한 정확한 요구사항을 고객 혹인 이용자로부터 도출해야한다.

2. 요구사항분석이 어렵다고 여겨지는 이유는 무엇인가?

먼저 고객과 이용자는 개발전문가가 아니기 때문에 원하고자 하는 기능이 현재 기술력으로 구현이 가능한지에대해 정확히 알지 못한다. 즉, 서로의 전문 분야에대한 지식이 부족하기때문에 의사소통이 원활하게 이루어지기 힘들다. 또한 고객과 이요자들의 요구사항이 정확한것이 아니라 애매모호하기 때문이다. 그리고 고객과 이용자들의 요구사항은 한번에 획일화 되지 않고, 비일비재하게 변경되기 때문이다. 우리는 이러한 문제점을 보완하기위해 다양한 요구사항 추출기법(자료수집, 인터뷰, 설문조사 , 브레인스토밍, 현장관찰, 프로토타이핑, 시나리오, 유즈케이스 , 목표지향분석 , 문제프레임)을 통하여 고객, 이용자로부터 요구사항을 도출해내야한다.

3. 목표지향분석의 절차는 무엇인가?

목표지향문석이란 달성해야하는 목표를 설정하고 여러개의 부문목표들로 그것을 분해하여 계층화 한다. 그리고 그것을 goal Tree라는 구조로 작성한다. 목표를 분해하는 방법으로는 And분해와 OR 분해가 있다. 최종 달성 목표를 And 혹은 OR 구조를 통해 분해한 후 모순을 도출해내는 과정이다.

4. 요구사항의 사양화에 형식언어를 사용할 경우의 장점은 무엇인가?

요굿사항을 사양화하방법은 크게 도면으로 작성하는 방법과 형식언어로 작성하는 방법 두가지가있다. 형식언어로 작성하는 방법의 장점은 오류 포함 가능성이 감소한다.

5. 요구사양에 대한 품질특성을 만족하지 않는 요구사항의 예는 무엇인가?

요구사양의 품질특성은 타당성 - 요구사양에 포함된 요구사항들이 개발하려는 시스템이 필수적으로 만족해야하는 사항인가? , 비애매모호성 - 모든 요구사항들이 누구에게나 한가지 의미로 해석이 가능한가? , 완전성 - 필요한 정보가 모두 기술되어있는가? , 무결점성 - 요구사항들이 서로 모순되는 부분이 없는가? , 중요도 와 안전성에대한 우선순위부여 - 모든 요구사항들은 같은 수준의 중요도와 안정도를 갖지 않음으로 이들에대해 우선순위를 적합하게 부여했는가? ,검증가능성 - 완성된 시스템이 요구사양의 기술내용을 만족하는지 검사가 가능한가? (“verification - 만들어진 소프트웨어가 요구사양대로 만들어졌는가? , validation - 소프트웨어를 만들었는데 고객과 이용자가 요구한 데로 만들어졌는가? ), 변경가능성 - 요구사항의 일부분을 모순없이 완전하게 수정가능한가? (git ,github가 대표적) , 추적가능성 - 요구사항들에 대해서 그 배경 , 이유, 의도가 명확하고 수월하게 참조가 가능하며 요구사양을 토대로 작성된 다양한 결과물로부터 수월하게 참조가 가한가? 총 8가지이다.

5장 구조화 분석

1. 데이터흐름도를 구성하는 4가지 요소들을 설명하시오.

데이터 흐름도는 DD [Data Dictionary] / ERD [Entity Relationship Diagram] / DFD [ Data Flow Diagram] / STD[State Transition Diagram] 로 구성되어있으며 , DFD 는 데이터의 흐름을 , STD 는 상태천이도로써 데이터의 흐름을 표현하며 특정 이벤트에 의한 상태 / 동적 변화를 중심으로 요구사항을 파악합니다.(ATM기계처럼) , DD는 데이터 딕셔너리로써 DFD에 나타나는 모든데이터에 대해서 데이 항목을 찾아내서 그 구조를 정의한 것 이다.

2. 구조화분석기법에 있어서, 단계적 상세화란 무엇인지 설명하시오.

단계적 상세화란 한번에 모든 DFD를 그리는것이아닌 간단한 DFD를 토대로 계층화하여 세부적인 DFD를 그리는것을 의미하며 우리는 더이상 간결해질 수 없을 때 까지 게속 계층화 하여야합니다. 프로세스를 상세화 할 때 상위으 프로세스 여러 개의 하위 프로세스들로 분할 되며, 분할 전 후의 입출력 데이터흐름은 반드시 보존되어야합니다. 또한 프로세스 세분화시 프로세스의 분할과 동시에 데이터의 분할을 수행하는 경우도 있습니다.

3. 데이터흐름도의 상세화에 있어서 엄수해야하는 중요한 규칙에 대해서 설명하시오.

1 - 1 . 데이터흐름은 데이터의 흐름을 표현하며, 제어의 흐름을 표현하면 안됩니다. (제어의 흐름은 FLowChart를 사용합니다.) 즉 데이터의 이동만을 표현하는 것 입니다.
1 - 2 . 프로세스에는 반드시 1개이상의 입력흐름과 출력흐름이 존재합니다. 프로세스에 입력되는 데이터가 항상 1개 이상이어야하며, 출력은 반드시 1개 이상이 있어야합니다.
1 - 3 . 1개 프로세스에 여러 개의 입력흐름들과 출력흐름들이 존재하는경우 , 입출력 데이터의 대응관계는 규정되 않는다. 즉 데이터간의 관계는 표현하지 않으며, 데이터 흐름이 교차해서 표현하면 안됩니다.
1 - 4 . 데이터의 입출력에 관한 순서 및 타이밍은 표현하지 못한다. 언제 데이터를 사용하는지, 어떤순서로 사용되는지는 표현하지 않고 오로지 데이터의 이동 흐름에대해서만 표기합니다. 1 - 5 . 발생할 수 있는 모든 데이터 흐름을 기술해야한다. 특정한 조건에서 실제로 출력되는 데이터를 구별하여 기술하지 못하고, 일어나는 모든 데이터의 흐름을 전부 기술해야한다.

4. ERD란 무엇을 나타낸 것인지 설명하시오.

Entity Relationship Diagram으로 시스템 내부의 데이터구조 관계를 DD로 표현한것이며, 세스템의 기능을 데이터 흐름으로 파악할 수 있게합니다.

5. 상태천이도에 있어서 상태, 이벤트 , 액션의 관계를 설명하시오.

데이터흐름을 중심으로 요구사항을 파악하며 DFD를 사용합니다. 이벤트에 의한 상태 / 동작 변화에 중심으로 요구사항을 파악하며 (REAL TIME 서비스처럼) 언제 에빈트가 활성화되고 비활성화되는지를 가시화 합니다. 이벤특가 A에서 B로 변경될때 이루어지는 상태 / 동작ㄱ의 변화를 액션이라고 합니다.