1. Software Engineering Process

류지현·2024년 11월 2일

소프트웨어공학

목록 보기
1/1

전체적 개요

1. Software Engineering Process

  • 1.1 Definition and Importance
    • Process Models
    • Learn from Well-Established Industry
    • The process Framework
    • A Generic Process Model
  • 1.2 Process Flows
    • Simple Process Flows
      • 1.2.1 Linear Process Flow
      • 1.2.2 Iterative Process Flow
    • 1.2.3 Evolutionary Process Flow
    • 1.2.4 Parallel Process Flow
  • 1.3 Task Sets in Software Engineering
    • 1.3.1 Identifying a Task Set
  • 1.4 Process Assessment and Improvement
  • 1.5 Prescriptive Process Models
    • 1.5.1 Waterfall Model
    • 1.5.2 Prototyping Model
    • 1.5.3 Spiral Model
    • 1.5.4 Unified Process Model (01-02 - Software Engine…)

전체적 요약

소프트웨어 공학 프로세스 개요

  • 소프트웨어 공학 프로세스는 프레임워크 활동(의사소통, 계획, 모델링, 개발, 배포)과 우산 활동(프로젝트 관리, 위험 관리, 품질 보증 등)을 포함한다
  • 프로세스 모델은 이 기본 프레임워크를 바탕으로 만들어지며, 활동들의 적용 방식과 순서에 따라 다양한 모델이 존재한다

프로세스 흐름과 모델

  • 프로세스 흐름에는 선형, 반복, 진화, 병렬 등 다양한 유형이 있으며, 각각의 특성에 따라 적용된다
  • 처방적 프로세스 모델(Prescriptive Process Models)은 구조와 질서를 중시하지만, 변화가 잦은 소프트웨어 개발 환경에서는 유연성이 필요할 수 있다

주요 프로세스 모델

  • 폭포수(Waterfall) 모델은 순차적 프로세스로, 각 단계가 고정된 순서로 진행된다
  • 프로토타이핑 모델은 사용자 피드백을 기반으로 반복적으로 소프트웨어를 개선하는 방식이다
  • 나선형(Spiral) 모델은 위험 관리에 중점을 두고 각 반복에서 위험을 분석하며 소프트웨어를 개발한다
  • 통합 프로세스(Unified Process) 모델은 객체지향 설계를 기반으로 한 반복적이고 점진적인 개발 방법론이다

내용정리!!!

1. Software Engineering Process

  • 1.1 Definition and Importance

    • Process Models

    • Learn from Well-Established Industry

      !

      공통점

      이미지에서 보여주는 요소들은 모두 품질 관리효율적인 프로세스를 강조. 소프트웨어 개발에서도 산업 표준측정 가능한 품질을 유지하면서, 체계적으로 작업을 진행하는 것이 중요하다는 점을 시사함.

      • ISO 9001:2015: 국제 품질 관리 표준. 일관된 품질 보장을 위해 필요.
      • 압력계: 데이터 기반의 정확한 측정이 중요하다는 점을 상징.
      • Ford Q1: 높은 품질 기준을 의미하며 지속적 관리 필요.
      • 작업자들: 팀워크와 기술 도구 활용의 중요성을 보여줌
    • The process Framework

      • process models(프로세스 모델)은 이 framework를 바탕으로 만들짐. 기본적으로 소프트웨어 개발 프로세스는 framework activities(의사소통, 계획, 모델링, 개발, 배포)와 umbrella activities(위험 관리, 품질 보증 등)를 포함. 이 활동들이 각기 다른 방식으로 적용되면서 다양한 프로세스 모델들이 만들어지는것. 예를 들어:
        • Waterfall 모델은 프레임워크 활동들을 순차적으로 진행하는 방식이고, 모든 활동이 완료된 후에 다음 단계로 넘어감.

        • Agile 모델은 각 프레임워크 활동을 반복적으로 수행하면서, 소프트웨어를 점진적으로 완성.

          즉, process models는 이 기본 프레임워크의 활동들이 어떻게 적용되고 순서가 어떻게 구성되는지에 따라 달라짐.

    • A Generic Process Model

      • Generic Process Model은 소프트웨어 개발의 기본 틀을 제공하는 모델로, 프레임워크 활동(의사소통, 계획, 모델링, 개발, 배포)과 우산 활동(프로젝트 관리, 위험 관리, 품질 보증 등)을 포함. 이 모델은 각 활동을 단계별로 반복하거나 병렬로 수행해 소프트웨어 개발을 체계적으로 관리하는 방식. 다양한 프로세스 모델(예: 워터폴, 애자일)들이 이 기본 구조를 기반으로 만들어짐.

2. Process Flows

  • Simple Process Flows
    - 1.2.1 Linear Process Flow
    - 1.2.2 Iterative Process Flow
  • 1.2.3 Evolutionary Process Flow

    Iterative Process Flow특정 단계를 여러 번 반복해서 점차 개선해 나가는 방식. 예를 들어, 설계 단계에서 잘못된 부분을 찾아 수정한 다음, 다시 개발을 진행하는 식으로 작업을 반복.
    Evolutionary Process Flow소프트웨어 전체를 점차 완성해 나가는 방식. 즉, 한 번의 반복을 통해 부분적으로 완성된 소프트웨어가 나옴. 그리고 그 소프트웨어는 계속 진화하면서 더 완벽해짐. 각 사이클마다 새로운 기능이나 개선된 버전이 나오고, 사용 가능한 부분적인 제품을 제공함.
    따라서, Iterative특정 단계를 개선하는 데 초점이 있고, Evolutionary전체 소프트웨어를 점차 발전시키는 데 초점이 있다는 차이가 있음.

    1.2.4 Parallel Process Flow

3. Task Sets in Software Engineering

  • 3.1 Identifying a Task Set
    - 진짜 해야되는 일 sw engineering action의 목표 달성을 위해
    - A task set lists로 구성
    - A list of tasks to be accomplished
    - A list of work products to be produced
    - A list of quality assurance filters to be applied

4. Process Assessment and Improvement

  • 존재 ≠ 소프트웨어의 질, 고객 만족 보장
  • process criteria 만족 시키는지 평가되어야됨
  • numeric measures로 평가 돼야됨!!!!! software analytics(metrics)나

✅ 질문에 대한 답 with GPT
Q. process assessment and improvement가 umbrella activity에 포함이 되는건가요?
차이점 요약:
- Process Assessment전체 프로세스의 성과 평가에 중점을 두고, 개선할 부분을 찾기 위한 평가에 가까워요.
- Umbrella Activities개발 전 과정에 걸쳐 발생하는 지속적인 관리 활동으로, 프로세스를 원활하게 진행되도록 돕는 역할이에요.
따라서, Process Assessment는 주로 평가와 개선을 위한 것이고, Umbrella Activities개발 과정의 전반적인 관리에 초점을 맞춘다고 볼 수 있어요.

5. Prescriptive Process Models

orderly

  • If prescriptive process models strive for structure and order, are they appropriate for a software world that thrives on change?

    • 구조와 질서를 중시하므로, 변화가 잦은 소프트웨어 세계에서는 적합하지 않을 수 있음
  • If we reject traditional process models and replace them with something less structured, do we make it impossible to achieve coordination and coherence in software work?

    • 전통적인 모델을 버리고 덜 구조화된 모델을 채택해도, Agile이나 Evolutionary 모델 같은 방식으로 유연성을 유지하면서도 필수적인 조정과 일관성을 유지할 수 있음

1.5.1 Waterfall Model

  • 순차적 프로세스 모델. 각 단계가 고정된 순서대로 진행되며, 한 번 완료된 단계는 다시 돌아가지 않는 것이 특징.
    - linear process flow 기반
    1.5.2 Prototyping Model
  • Prototyping 모델Evolutionary Process Flow에서 나온 모델
  • 프로토타입 개발: 소프트웨어의 일부 기능이나 UI를 빠르게 개발하여 시제품을 만든다.
  • 사용자 피드백: 사용자가 프로토타입을 직접 사용해보고 피드백을 제공한다.
  • 반복적 개선: 사용자 피드백을 반영하여 소프트웨어를 반복적으로 개선하고 발전시킨다.
  • 최종 소프트웨어: 최종적으로 완성된 소프트웨어는 여러 차례의 반복적 개선 과정을 거쳐 사용자 요구를 정확히 반영한다.

장점

  • 사용자 참여가 활발하여 요구사항이 명확해지고, 소프트웨어의 최종 품질이 향상됨.
  • 변화에 유연하여, 프로젝트 진행 중에 요구사항이 변경되더라도 빠르게 반영할 수 있음.
  • 제품이 초기부터 시각화되기 때문에, 사용자가 실제로 어떻게 작동할지 미리 경험할 수 있음.

단점

  • 프로토타입에 의존할 위험 (temptation to ship a prototype)
  • 시간과 비용 초과 (프로토타입 버려지는거에 대해서..)
  • 요구사항 완벽 정의 X
  • 설계의 품질 저하

1.5.3 Spiral Model

✅질문에 대한 답 with GPT
Spiral 모델Prototyping 모델은 둘 다 반복적이고 점진적인 개발을 통해 소프트웨어를 완성하는 점에서는 비슷하지만, 중요한 차이점이 있어:

1. 목적과 초점

Spiral 모델:
- Spiral 모델은 위험 관리에 중점을 두고, 각 반복에서 위험을 분석하고 그에 따른 결정을 내려가면서 소프트웨어를 개발해.
- 각 반복 주기마다 위험을 줄이기 위해 위험 평가가 필수적으로 포함되며, 점진적으로 더 완성도 높은 소프트웨어를 목표로 해.
- Spiral 모델은 대규모 프로젝트고위험 프로젝트에 적합하며, 여러 단계를 거쳐 계속해서 발전하는 방식이야.
Prototyping 모델:
- Prototyping 모델은 사용자 요구사항을 명확히 하기 위한 것이 목적이야. 초기 프로토타입을 만들어 사용자가 직접 테스트해보고 피드백을 제공받아, 요구사항을 구체화하는 데 중점을 둬.
- 위험 관리보다는 사용자와의 피드백을 통해 요구사항을 점진적으로 개선하는 것이 핵심이야.
- 빠른 피드백사용자 요구사항 반영을 위해 프로토타입을 반복적으로 개발하고 수정해.

2. 프로토타입 사용 여부

Spiral 모델: 프로토타입을 필요에 따라 만들 수 있지만, 필수 요소는 아니야. 중요한 것은 위험 분석과 이를 기반으로 한 반복적 개발이야.
Prototyping 모델: 프로토타입을 필수적으로 사용하며, 이를 기반으로 사용자 피드백을 받아 개발을 진행해.

3. 위험 관리

Spiral 모델: Spiral 모델은 각 반복에서 위험을 평가하고, 그 위험을 줄이기 위한 결정을 내리는 것이 핵심이야. 이는 고위험 프로젝트에서 매우 중요해.
Prototyping 모델: 위험 관리에 대한 명확한 단계는 없고, 주로 사용자 요구사항에 초점을 맞춰서 개발이 이루어져.

결론:

Spiral 모델위험 관리를 중심으로 점진적으로 발전하는 방식이고, Prototyping 모델사용자 요구사항을 구체화하기 위해 프로토타입을 반복적으로 개선하는 방식이야. 둘 다 반복적 개발을 하지만, 목표와 초점이 다르기 때문에 동일한 모델은 아니야

1.5.4 Unified Process Model


Unified Process Model은 소프트웨어 개발에서 객체지향 설계와 분석을 기반으로 한 반복적이고 점진적인 개발 방법론. 이 모델은 소프트웨어를 여러 반복 주기(iteration)로 나눠서 개발하고, 각 주기마다 소프트웨어의 완성도를 높여가는 방식으로, 유스케이스(Use Case)를 중심으로 시스템을 개발하는 것이 특징.
주요 단계:

  • Inception(개념 단계): 프로젝트의 범위를 정의하고, 주요 요구사항을 파악.
  • Elaboration(정교화 단계): 시스템의 구조와 설계를 구체화하며, 핵심 위험을 해결.
  • Construction(구축 단계): 실제 소프트웨어를 개발하고, 반복적으로 기능을 추가.
  • Transition(전환 단계): 소프트웨어를 사용자에게 배포하고, 피드백을 반영하여 수정.
  • 객체지향 설계: 객체지향 기법을 사용해 소프트웨어를 설계하며, 유지보수와 확장성을 고려.

✅질문에 대한 답 with GPT
Linear Process Flow vs Waterfall Model 차이가 뭐얌 구체적으로

요약:

  • Linear Process Flow는 단순히 단계가 순차적으로 진행되는 흐름을 설명하는 것이고,
  • Waterfall 모델Linear Process Flow를 기반으로 한 구체적인 소프트웨어 개발 방법론이에요.

0개의 댓글