소프트웨어 공학 이론 정리 -3강- <소프트웨어 엔지니어링 2부>

Essence of Software Engineering practice

-      Polya Suggests

• Understand the problem
• Plan a Solution
• Carry out the plan
• Examine result for accuracy

Understand the Problem

-      4가지 확인 요소

• 문제를 갖고 있는 사람이 누구인가?
  • 즉, 이 문제에 대해 이해관계가 얽힌 사람이 누군가?
• 알려지지 않은게 무엇인가?
  • 문제를 해결하기 위해 알아야만 하는 데이터와 함수, 기능이 무엇이 있는가?
• 큰 문제를 작은 문제로 나눌 수 있는가? (Compartmentalize)
  • 문제를 풀기 위해 이해하기 쉽도록 문제를 작은 문제 단위로 해결할 수 있는가?
• 문제에 대해 시각화 할 수 있는가?
  • 분석 모델을 만들어 낼 수 있는가?

Plan a Solution

-      4가지

• 기존에 비슷한 문제를 본 적 있는가?
  • 문제를 해결가능한 솔루션 패턴이 있는가? 비슷한 데이터와 함수, 기능을 제공하는 소프트웨어가 이미 있는가?
• 이와 비슷한 문제들이 잘 해결된 적 있는가?
  • 만약 그렇다면 그 솔루션의 요소들을 재활용할 수 있는가?
• 비슷한 문제가 있고 해당 문제에 대한 솔루션이 있다면, 그 문제의 부분 문제를 정의할 수 있는가?
  • 만약 그렇다면, 솔루션들은 누가 봐도 부분문제를 해결하기 위한 것인가?
• 효과적으로 구현하기 위해 해당 솔루션을 잘 표현해낼 수 있는가?
  • 디자인 모델(설계도면)을 잘 만들 수 있는가?

Carryout the Plan

-      2가지

• 솔루션이 계획에 부합하는가?
  (설계도면에 맞게 소스코드가 만들어졌는가?)
• 솔루션의 각 Component가 원하는 대로 잘 작동하는가?
  (코드와 디자인을 리뷰하고 우리가 적용해야 하는 알고리즘에 알맞게 증명되었는가?)

Examine the Result

-      2가지

• 솔루션의 컴포넌트들을 각자 테스트하는게 가능하냐? (Unit Test 가능?)
  (테스트를 위한 전략이 구현되어 있는가? (블라인드, 직접 보는 테스트))
• 솔루션이 우리가 원했던 결과를 잘 만들어 냈는가?
  (소프트웨어가 모든 stakeholder의 요구사항을 해결할 수 있게 검증되었는가?)

 

 

<Chapter2>

Generic Process Model

1. Work를 쪼개 => Task => Product가 나옴
 => Work에 대한 Product가 나옴

2. 해당 Product에 대해 Quality Assurance를 받아

3. 프로젝트의 리스크 관리와 같은 것을 함 (Project Milestones)

위 과정을 반복적으로 수행한다. (Software Engineering Action과 Framework Activity 모두 반복 수행한다.)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

-      단계는 5단계 Flow는 다양

-      단계 : Communication, Planning, Modeling, Construction, Deployment

-      Flow

• Linear process flow : 각 단계를 한 번씩만 순차적으로 수행
• Iterative Process Flow : 단계를 묶어서 반복 => 문제가 생긴 부분을 계속해서 검토
• Evolutionary process flow : 모든 단계를 크게 한 번 진행, 산출물이 부족하면 다시 모든 단계를 진행 => 반복 하다가 만족스러운 결과물이 계속 나와
• Parallel process flow : 그래프화해 다양한 모습을 만들어 나가지만, 그래도 각 단계는 순차적으로 진행되어야 함. 그림에서 Communication -> Modeling 이 부분은 순차성을 무시함으로 잘 못 된 그림이다. 올바른 그림은 원래 Communication <- Modeling 이다.

 

 

-      Identifying a Task Set

• 테스크 셋은 실질적으로 해야 하는 일이기에 추상적이지 않다.
  • 작업 목록이 구체적으로 작성되어 있어야 한다.
  • 각 작업으로 인해 생기는 work products 리스트를 작성해야 한다.
  • QA 필터 리스트가 작성되야 한다.

-      Process Assessment(평가) and Improvement

• 현재 존재하는 소프트웨어 프로세스가 현재 만들려고 하는 소프트웨어에 맞지 않을 수 있다. (출시 기한에 맞지 않거나, 소비자의 요구에 맞지 않거나,) => 변형해서 사용
• 모든 소프트웨어 프로세스는 평가받아서, 프로세스가 갖고 있는 기준에 맞춰 기능을 다해야 한다. 이렇게 하면 성공한 소프트웨어 엔지니어링을 했다 볼 수 있다.
• 소프트웨어 프로세스나 activities는 numeric measure나 software analytics(metrics)를 통해 검증 받아야만 한다.