[소프트웨어 공학] 02. Software Process

Software Process

---

Introduction

The software process

• 소프트웨어 과정(Software Process)은 소프트웨어 시스템을 개발하기 위해 필요한 일련의 구조화된 활동들로 구성됩니다.
• 다양한 소프트웨어 과정이 존재하지만 모든 과정은 다음과 같은 공통적인 단계를 포함합니다
  • Specification (명세, Requirements): 시스템이 무엇을 해야 하는지 정의합니다.
  • 설계 및 구현(Design and implementation): 시스템의 구조를 정의하고 시스템을 구현합니다.
  • 검증 (Validation): 시스템이 고객의 요구사항을 충족하는지 확인합니다.
  • 진화 (Evolution): 고객의 변화하는 요구에 따라 시스템을 변경합니다.
  • 시험 문제!
• 소프트웨어 프로세스 모델은 프로세스의 추상적 표현입니다. 이는 특정 관점에서 프로세스의 설명을 제시합니다

Software process descriptions(소프트웨어 개발 활동 계획서)

• 개발 활동 계획서 : Activities + Orders
• 다음 요소들 또한 포함해야 함
  • Products : 개발 활동의 결과
  • Roles : 프로세스에 참여하는 각 개인이나 팀의 역할
  • Pre- and post-conditions(사전 조건과 사후 조건) : 구현 전 후로 만족해야 할 조건

Plan-driven and agile process

• Plan-driven processes
  • 프로세스에 필요한 모든 활동을 계획하고, 진행 정도는 현재 진행 정도와 계획을 대비하여 측정한다
• Agile processes
  • 점진적으로 계획을 추가해 나가고, 변화하는 고객의 요구사항을 반영하여 개발 프로세스를 변경하기 쉽다
• 실무에선, 두 가지 요소가 혼재된 프로세스를 구성하여 실행한다
• 어떤 process가 옳고 그르다고 할 수 없음

Software process models

• The waterfall model(폭포수형 모델)
  • Plan-driven model.
  • 명세와 개발이 명확히 분리 되있다.
  • (개발 중에 명세 수정이 안되며, 개발을 한다는 것은 명세가 확정된 것을 의미한다.)
• Incremental development(점진적 모형)
  • 명세, 개발 및 검증(Validation)이 모두 함께 반복되어 일어난다.
• Integration and configuration - plan-driven or agile
  • 계획 주도 방식 또는 애자일 방식으로 진행할 수 있으며, 이 모델은 기존에 구성 가능한 컴포넌트들로 시스템을 조립합니다
  • 접근법은 주로 재사용 가능한 컴포넌트가 많을 때 유용하며, 빠르게 시스템을 구축할 수 있습니다.
    • ex) 외부 api를 가져와서 develop를 하는 경우
• 실무에서는 이러한 모델들의 요소를 조합하여 사용하는 경우가 많습니다

The waterfall model

• 이 모델의 기본 원칙 : 하나의 단계가 완전히 끝나야 다음 단계로 넘어갈 수 있다
• 각 단계는 특정 산출물을 생성합니다. 이 산출물은 문서 형태일 수 있으며, 생성된 문서는 다음 단계의 입력 자료로 사용됩니다

Waterfall model의 문제점

• 워터폴 모델에서 프로젝트를 구분된 명확한 단계로 나누는 것은 유연성이 부족하여 고객의 요구사항 변화에 대응하기 어렵다는 단점이 있다
  • 그러므로 요구사항이 아주 명확한 경우와 변화가 거의 일어나지 않는 경우에 적합한 모델이다.
  • 그러나 현실에는 요구사항이 fix되는 일이 드물다.
• waterfall model은 시스템이 여러 사이트에서 개발되는 대규모 시스템 엔지니어링 프로젝트에 주로 사용된다.
  
  • 이러한 상황에서는 폭포수 모델의 계획 중심 특성(plan-driven nature)이 작업을 조정하는데 도움이 된다.

 

Incremental development

 

Incremental development benefits

고객 요구사항 변경을 수용하는 비용이 절감된다.

• 다시 분석하고, 작성해야 하는 문서의 양이 waterfall model보다 훨씬 적다.
• (waterfall model은 최종산출물이 나온 다음에야 요구사항 및 변경사항 수정이 가능하며 그동안 자원 소모가 크다.)

이미 진행된 개발 작업에 대한 고객 피드백을 더 쉽게 얻는다.

• 고객은 소프트웨어 시연에 의견을 줄 수 있고, 얼마나 많이 구현되었는지 확인이 가능하다.
• (초기버전~중간버전을 고객이 계속 접할 수 있고 그에 따라 피드백이 빠르게 들어올 수 있다.)

고객에게 유용한 소프트웨어를 빠르게 전달하고 배포하는 것이 가능하다.

• 고객은 waterfall model보다 더 빨리 소프트웨어가 제공하는 가치를 경험하고 실제로 사용해 볼 수 있다.
• (핵심적인 것을 먼저 구현한 후 세부적인 것은 이후 수정할 수 있다.)

 

Incremental development problems

프로세스가 가시적이지 않다.

• 관리자는 진척도를 확인하기 위한 정기적인 중간산출물이 필요하다. 그러나 시스템이 빨리 개발되어야 한다면, 시스템의 모든 버전을 반영한 문서를 작성하는 것은 비용 측면에서 비효율적이다.
• cf) specification list를 가지고 개발하는 plan-driven 방식

새로운 증가분이 반영되면서 시스템 구조를 훼손시키는 경향이 있다.

• 소프트웨어 개선을 위해 리팩토링하는데 시간과 돈을 들이지 않으면, 정기적인 변경으로 인해 구조가 손상되는 경향이 있다. 시스템에 새로운 기능을 추가하는 작업은 하면 할수록 더 어렵고 많은 비용이 들어간다.

 

Integration and configuration

• 소프트웨어 재사용을 바탕으로 한 통합 및 구성은 기존의 컴포넌트나 애플리케이션 시스템들로부터 시스템을 통합하는 방식입니다
  • 이런 기존 컴포넌트들은 종종 COTS(Commercial-off-the-shelf, 기존에 있는 것을 그대로 가져다 쓰는) 시스템이라고 불립니다.
• 재사용된 요소들은 사용자의 요구사항에 맞게 그들의 행동과 기능을 조정하기 위해 구성될 수 있습니다
• 현재 많은 유형의 비즈니스 시스템을 구축하는 표준 접근법으로 ReUse가 널리 사용되고 있습니다

Types of reusable software

• Stand-alone application systems (COTS)
  • 특정 환경에서 사용하기 위해 구성된 독립 실행형 애플리케이션입니다. 예를 들어, 사무용 소프트웨어나 그래픽 디자인 툴 등이 이에 해당됩니다.
• Collections of objects
  • 컴포넌트 프레임워크(예: PyGame)와 통합되어 개발된 객체들의 집합입니다. 이러한 패키지는 특정 애플리케이션에 쉽게 통합되어 기능을 확장할 수 있습니다.
• Web services
  • 서비스 표준에 따라 개발되며 원격 호출이 가능한 웹 서비스입니다. 이를 통해 다양한 애플리케이션에서 공통의 기능을 웹 기반으로 이용할 수 있습니다.
  • ex) kakao map api
• 심지어 entire systems 자체도 reusable software로 간주될 수 있다
  • AWS와 같은 클라우드 서비스, Docker나 같은 컨테이지원 기술

 

Reuse-oriented software engineering model

 

장점

• 개발해야하는 소프트웨어의 양을 줄인다.
• 비용과 risk가 감소한다.
• 소프트웨어를 고객에게 더 빨리 전달하여 배포할 수 있다

단점

• 요구사항의 타협이 불가피: 재사용된 요소들은 때때로 특정 사용자의 실제 필요를 완벽히 만족시키지 못할 수 있으며, 이로 인해 시스템이 사용자의 진정한 요구를 충족시키지 못할 수 있습니다
• 재사용된 시스템 요소의 진화에 대한 통제력 상실: 재사용된 요소들은 그 소유권이나 제어가 외부에 있을 수 있기 때문에, 이 요소들의 업데이트나 변화를 직접 관리하는 것이 어려워질 수 있습니다.
  • ex) GPT 토큰 당 가격 인상

Process activities

실제 소프트웨어 개발 과정은 기술적, 협업적, 관리적 활동들이 서로 얽혀 있는 일련의 순서로 이루어집니다. 이러한 활동들의 전반적인 목표는 소프트웨어 시스템을 명세화하고, 설계하며, 구현하고, 테스트하는 것입니다.

소프트웨어 개발의 네 가지 기본적인 프로세스 활동은 명세(specification), 설계 및 구현(design and implementation), 검증(validation), 그리고 진화(evolution)입니다. 이 활동들은 각기 다른 개발 프로세스에서 다르게 조직됩니다.

예를 들어, 워터폴 모델에서는 이러한 활동들이 순차적으로 조직되어 각 단계가 완료된 후 다음 단계로 진행됩니다. 반면에, 증분 개발(incremental development)에서는 이 활동들이 서로 교차하며 진행됩니다. 즉, 명세, 설계, 구현 및 테스트 단계가 반복적으로 이루어지며 서로 얽혀 있어 프로젝트의 유연성을 높이고, 신속한 피드백에 기반하여 개선을 진행할 수 있습니다.

 

Software specification

시스템을 개발하기 위해 어떤 서비스가 필요한지를 이해하고 정의하며, 시스템의 운영과 개발에 대한 제약사항을 찾아내는 프로세스

Requirements engineering process

1. 요구사항 도출 및 분석(Requirements elicitation and analysis):
   시스템에 대한 설명을 바탕으로, 시스템 이해관계자들이 시스템에 대해 요구하거나 기대하는 바를 파악합니다. 이 단계에서는 다양한 이해관계자의 요구사항과 기대를 수집하고 분석합니다.

2. 요구사항 명세(Requirements specification):
   사용자 요구사항과 시스템 요구사항을 구체적으로 정의합니다. 이 명세 과정을 통해 요구사항이 문서화되며, 이 문서는 개발 과정에서 중요한 참고 자료로 사용됩니다.

3. 요구사항 검증(Requirements validation):
   요구사항 문서의 타당성을 검토합니다. 이 단계는 수집된 요구사항이 실제 사용자의 필요를 정확히 반영하고 있는지 확인하며, 요구사항이 명확하고 실행 가능한지 점검합니다.

Software design and implementation

system specifiation을 실행가능한 시스템으로 전환하는 과정

Software design

• specification을 실현하는 소프트웨어 구조를 설계하는 것이다.

Implementation

• 소프트웨어 구조를 실행 가능한 프로그램으로 변환하는 것이다.

설계와 구현은 밀접하게 연관되어 있으며 중첩될 수 있다.

 

A general model of the design process

 

Design activities

Architectual design:

시스템의 전체 구조, 주요 구성 요소(subsystems나 modules), 이들의 관계 및 배포 방법을 식별하는 단계이다.

Interface design:

시스템 컴포넌트들 사이의 인터페이스 정의를 디자인하는 단계이다.

Component slection and design:

재사용할 수 있는 컴포넌트를 찾고, 재사용할 수 없다면 각 시스템 구성 요소의 작동 방식을 설계하는 단계이다.

Database design:

시스템의 데이터 구조를 설계하고 데이터베이스에서 어떻게 표현할 지 결정하는 단계이다.

 

System implementation

시스템 구현은 소프트웨어를 개발하거나 애플리케이션 시스템을 구성함으로써 이루어집니다. 다음은 시스템 구현 과정의 주요 측면들입니다:

1. Design and implementation : 대부분의 소프트웨어 시스템 유형에서 설계와 구현은 교차하는 활동입니다. 즉, 설계가 진행되는 동안 구현도 병행하여 이루어지며, 설계 변경사항이 구현에 신속하게 반영될 수 있습니다.

2. 프로그래밍: 프로그래밍은 주로 개인적인 활동으로, 표준화된 과정이 없습니다. 각 개발자가 주어진 문제를 해결하기 위해 자신만의 방법과 스타일로 코드를 작성합니다. 알잘딱

3. 디버깅: 디버깅은 프로그램의 결함을 찾고 이를 수정하는 활동입니다. 개발 과정에서 발생할 수 있는 오류나 버그를 식별하고, 그 원인을 분석하여 적절한 수정을 통해 문제를 해결합니다. 개발비용의 50-70% 정도를 투자할 정도로 중요!

Software verification & validation

검증(verification) 및 확인(validation)은 시스템이 주어진 명세를 잘 따르고 있다는 것과 시스템 고객의 요구사항을 만족시키고 있다는 것을 보이기 위한 것이다.

verification:

제대로 작동하는지? 버그 없이 잘 돌아가는지?

validation:

고객을 만족시키는지?

 

• 소프트웨어 검증은 체크와 리뷰 과정, 그리고 시스템 테스팅을 포함합니다
• 시스템 테스팅은 시스템을 실행하고, 시스템에 의해 처리될 실제 데이터의 사양에서 파생된 테스트 케이스를 사용하여 테스트하는 과정입니다.
• 소프트웨어 테스팅은 검증 및 검사(V & V) 활동에서 가장 일반적으로 사용되는 방법입니다. (나중에 다룸)
  
  

Testing stages

1. 컴포넌트 테스팅(Component testing)
   개별 컴포넌트를 독립적으로 테스트합니다. 이 컴포넌트들은 함수, 객체 또는 이러한 요소들의 일관된 그룹일 수 있습니다. 컴포넌트 테스팅의 목적은 각 부품이 정상적으로 기능하는지 확인하고, 초기 결함을 발견하여 수정하는 것입니다.

2. 시스템 테스팅(System testing)
   시스템 전체를 테스트합니다. 이 단계에서는 시스템의 모든 컴포넌트가 통합된 상태에서의 작동을 검사하며, 특히 시스템의 출현 특성(emergent properties)을 테스팅하는 것이 중요합니다. 출현 특성이란 개별 컴포넌트에서는 볼 수 없는, 시스템 전체로서만 나타나는 특성을 의미합니다.

3. 사용자 테스팅(User testing, 또는 수용 테스팅 Acceptance testing)
   고객의 데이터를 사용하여 테스트를 진행합니다. 이 단계의 목적은 시스템이 고객의 요구사항을 충족하는지 확인하는 것입니다. 고객이 실제 사용 조건에서 시스템을 평가하게 함으로써, 시스템이 시장에 출시되기 전에 최종 사용자의 요구를 만족시킬 수 있는지 검증합니다. (ex. Beta test)

Software evolution

• 소프트웨어는 본질적으로 유연하며 변경될 수 있다.
• 변화하는 비즈니스 환경으로 요구사항이 변경됨에 따라, 비즈니스를 지원하는 소프트웨어도 진화하고 변경되어야 한다.
• 개발과 유지보수 사이에 구분이 있었지만,
  - 이는 점점 덜 중요해지고 있습니다. 왜냐하면 시스템이 완전히 새로워지고 있기 때문입니다.
  - ex) DevOps
  
  (이 슬라이드는 소프트웨어 개발과 유지보수의 전통적인 구분이 더 이상 중요하지 않다고 주장하면서, DevOps와 같은 새로운 방법론이 소프트웨어 개발 생태계에서 중요해지고 있음을 강조합니다.)

 

Coping with change

• 모든 큰 소프트웨어 프로젝트에서 변화는 불가피합니다.
  • 비즈니스 변화는 새로운 및 변경된 시스템 요구사항을 가져옵니다.
  • 새로운 기술은 구현을 개선할 수 있는 새로운 가능성을 열어줍니다.
  • 플랫폼 변경은 애플리케이션 변경을 요구합니다 
• 변화는 재작업을 초래하므로, 변화의 비용은 재분석 요구사항(예: 요구사항 재분석)뿐만 아니라
  - 새로운 기능을 구현하는 비용도 포함합니다.
  • rework의 Cost는 측정하기 어려운 경향이 있음(maintability가 낮을 수록 cost는 증가함)
    
    (이 슬라이드는 소프트웨어 개발에서 변화가 일상적이며, 이에 따라 비용과 요구사항 분석을 재검토하는 등의 재작업이 필요함을 설명하고 있습니다.)

 

Reducing the costs of rework

변화 예측(Change anticipation): 소프트웨어 프로세스가 중요한 재작업이 필요하기 전에 가능한 변화를 예측할 수 있는 활동을 포함합니다.
  - 예를 들어, 시스템의 핵심 기능을 고객에게 보여주기 위한 프로토타입 시스템이 개발될 수 있습니다.

변화 수용(Change tolerance): 프로세스가 상대적으로 낮은 비용으로 변화를 수용할 수 있도록 설계됩니다.
  - 이는 보통 점진적 개발의 어떤 형태를 포함합니다.
      - 제안된 변화는 아직 개발되지 않은 증분(Increment)에서 구현될 수 있습니다.
  - 만약 이것이 불가능하다면, 시스템의 작은 부분만이 변화를 통합하기 위해 변경될 수 있습니다.

이 슬라이드는 소프트웨어 개발 과정에서 변화에 대비하고 이를 수용하는 방법에 초점을 맞추고 있으며, 재작업이 필요할 때 발생하는 비용을 줄이는 전략에 대해 설명하고 있습니다.

 

Coping with changing requirements

- 시스템 프로토타이핑(System prototyping)
  - 프로토타입은 고객의 요구사항과 디자인 결정의 실행 가능성을 빠르게 확인하기 위해 개발됩니다.
  - 이 접근법은 변화 예측을 지원합니다.

- 증분적 배포(Incremental delivery)
  - 시스템 증분은 고객에게 의견과 실험을 위해 전달됩니다.
  - 이는 변화 수용을 지원합니다.

이 슬라이드는 소프트웨어 개발에서 변화를 예측하고 수용하는 두 가지 전략인 프로토타이핑과 증분적 배포에 대해 설명하고 있습니다. 프로토타이핑은 초기 단계에서 고객의 요구사항을 이해하고 디자인의 실행 가능성을 탐색하는 데 도움을 줍니다. 증분적 배포는 개발 과정에서 지속적으로 고객의 피드백을 받아 개선할 수 있게 하여, 변화에 대한 유연성을 높이고 비용을 절감할 수 있도록 합니다.

 

Software prototyping

프로토타입은 제품의 아이디어를 시연하고, 디자인 선택 사항들을 시도해볼 수 있는 시스템의 초기 버전이다.

 프로토타입은 다음과 같이 사용될 수 있다:

• requirements engineering process에서 시스템 요구사항 도출과 검증에 도움을 준다.
• design process에서 소프트웨어에서 선택 가능한 옵션을 탐색하거나 UI 개발을 위해 사용한다
• 연속 테스트를 실행하기 위한 테스트 프로세스에서
  • 두 가지 버전의 시스템이 동일한 사양으로 비교됩니다.

Benefits of Prototyping

사용자의 실제 요구사항에 가까워질 수 있다.

maintablility가 향상됨

 사용성이 향상된다.

디자인 품질이 향상된다.

개발 노력이 감소한다.(프로토 타입 개발에 effort 많이 투자하면 이 의미가 없어짐)

 

Prototype development

• 신속한 프로토타이핑 언어 또는 도구를 기반으로 할 수 있다.
• 기능을 생략하는 것을 포함할 수 있다
  •  프로토타입은 잘 이해되지 않는 제품 영역에 초점을 맞춰야 한다.
  • 오류 검사 및 복구는 프로토타입에 포함되지 않을 수 있다.
  •  비기능 요구사항보다 기능 요구사항에 중점을 두어야 한다.

 

Throw-away protytypes

프로토타입은 생산 시스템의 좋은 기반이 아니므로 개발 후 폐기해야 한다. (프로토타입을 base로 개발하지 말고 따로 개발해야 한다)

• 비기능 요구사항을 충족하도록 시스템을 조정하는 것은 불가능할 수 있다.
• 프로토타입은 일반적으로 문서화되지 않는다.
• 프로토타입 구조는 일반적으로 급격한 변경으로 인해 저하된다.
• 프로토타입은 일반적인 조직의 품질 표준을 충족하지 못할 수 있다.

 

Incremental delivery

• 시스템을 한 번에 제공하는 대신, 개발과 인도를 증분으로 나누고, 개발을 마친 증가분 일부를 고객에게 전달한다.
• 사용자 요구 사항에 우선 순위를 정하고 가장 높은 우선 순위 요구 사항이 초기 증분에 포함된다.
  • 우선 순위에 따라 개발 후 update 한다
• 일단 증분에 대한 개발이 시작되면, 추가적으로 요구 사항을 분석할 수 있지만, 현재 증분에 대해서는 요구 사항이 동결된다.

 

Incremental development and delivery

- 증분 개발(Incremental development)
  - 시스템을 단계적으로 개발하며, 각 단계를 평가한 후에야 다음 단계의 개발로 넘어갑니다.
  - 이 방식은 애자일 방법론에서 자주 사용되며,
  - 사용자나 고객의 대리인이 진행하는 평가를 통해 이루어집니다.

- 증분 배포(Incremental delivery)
  - 개발된 증분을 실 사용자에게 배포하여 사용하게 합니다.
  - 이를 통해 소프트웨어의 실제 사용에 대한 더 현실적인 평가가 가능해집니다.
  - 증분이 기존 시스템의 기능을 덜 포함하고 있을 때, 기존 시스템을 대체하기 어려울 수 있습니다.

즉, 증분 개발과 배포는 소프트웨어를 조금씩 개발하고, 각 부분이 완성될 때마다 실제 환경에서 테스트하고 평가함으로써 전체 소프트웨어의 개발을 효과적으로 관리하고 위험을 줄이는 방법입니다.

 

 

Incremental delivery advantages

• 각 증분으로 고객 가치를 제공할 수 있어서 시스템 기능성을 더 일찍 사용할 수 있습니다.
• 초기 증분들이 후속 증분들에 대한 요구사항을 도출하는 데 도움이 되는 프로토타입 역할을 합니다.
• 전체 프로젝트 실패의 위험을 낮춥니다.
• 가장 높은 우선순위를 가진 시스템 서비스들이 대개 가장 많은 테스트를 받습니다.
  • 이는 보통 더 일찍 배송되고, 이후 증분과 함께 다시 테스트되기 때문입니다.

 

 

Incremental delivery problems

- 대부분의 시스템은 시스템의 다양한 부분에서 사용되는 기본 기능들을 필요로 합니다.

- 요구사항이 증분이 구현될 때까지 상세하게 정의되지 않기 때문에,
  - 모든 증분에 필요한 공통 기능을 식별하기 어려울 수 있습니다.

- 반복적인 프로세스의 본질은 소프트웨어와 함께 명세가 개발된다는 것입니다. (develop -> feedback 에 따라 명세가 change)
  - 그러나 이것은 많은 조직의 구매 모델과 충돌할 수 있습니다.
  - 완전한 시스템 명세는 시스템 개발 계약의 일부입니다. (보통 계약을 맺어 진행하는 방식이 다수라, incremental 개발 방식이 부적합한 경우가 있다)

 

Software Development and LLMS

- 대규모 언어 모델(Large Language Model, LLM)은 방대한 양의 데이터와 매개변수로 훈련된 머신러닝 모델입니다.

- 이러한 모델을 사용하여, 코드 생성 기능을 제공하는 서비스들이 개발되었습니다.
  - 예를 들어, Copilot, ChatGPT, Bing, Gemini 등이 있습니다.

- 이러한 서비스들은 자연어 설명을 작동 코드로 변환할 수 있습니다.
  - 이들이 기존 코드와 설명으로부터 훈련되었기 때문에, 넓은 관점에서 코드 재사용으로 간주될 수 있습니다.

- 또한, 이러한 서비스들은 요구사항 공학, 설계, 테스팅 등 다른 개발 활동을 지원하고 있습니다.

 

Advantages of using LLM

- 다른 소프트웨어 재사용 방법들과 달리, 대규모 언어 모델(LLMs)은 직접 사용자의 목적에 맞는 작동 코드를 생성할 수 있습니다.
  - 이러한 재사용 방식은 소프트웨어 발견과 평가 시간뿐만 아니라 요구사항을 정교하게 다듬는 시간을 절약할 수 있습니다.

- 요구사항 명세와 컴포넌트 적응, 검증을 포함하는 재사용 지향적 개발이 가능합니다.

- 우리는 소프트웨어 개발에 있어서 "어떻게"보다는 "무엇을"에 집중할 수 있습니다.

    - 무엇을 해야 하는지 알고 있다면, 특히 많은 표준 코드와 컴포넌트를 작성하는데 드는 시간을 크게 절약할 수 있습니다.

 

Issues on using LLM

• LM은 확률에 기반하여 내용(텍스트, 코드, 심지어 이미지)을 단순히 생성합니다.
  • 생성된 내용이 매우 잘 작성되었을지라도, 그것이 논리적 근거를 가지고 있지는 않습니다.
  • 사람과 달리 실제로 '생각'할 수 없습니다.
• 따라서, 제공된 내용이 잘못되었을 가능성을 항상 고려해야 합니다.
  • 적절한 검사 없이 사용하고 싶지 않을 것입니다.
• 또한, 프롬프트에 입력하는 모든 데이터가 공개될 수 있고 철회되지 않을 수 있다는 것을 이해해야 합니다.
  • 결코 특정하거나 민감한 데이터나 코드를 입력하지 마세요.

Two approaches

• 소프트웨어 개발에서 LLM을 사용하는 두 가지 주요 접근법을 고려할 수 있습니다.
  • 예제에서 배우기: 요구사항을 충족시키기 위해 예제를 요청합니다. 그 예제들로부터 배우고, 필요한 구성요소들을 직접 작성합니다.
    • 코드를 보고 프로그래머가 이해해서, 직접 작성하는 것
  • 설명하고 검증하기: 설명에 맞는 코드를 생성하도록 요청합니다. 생성된 코드를 검증하고 직접 사용합니다.
    • 생성한 코드가 원하는 기능을 하는지만 확인해서 사용한다

Involved Software Activities

• LLM은 구현을 위해서만 사용되는 것일까요? - 아니오, 그렇지 않습니다.
• 거의 모든 소프트웨어 개발 활동에서 LLM을 활용할 수 있습니다.
  • 예: 요구사항 공학, 아키텍처 설계, 코드 검사, 테스팅, 디버깅 등.
• 물론 LLM을 사용하는 것이 효과적이고 효율적인지 여부는 다른 문제입니다.
  • 그러므로 LLM을 사용하여 생산성을 어떻게 높일 수 있는지 이해해야 합니다.
  • 단순히 책임을 회피하기 위해 사용해서는 안 됩니다!

Summary

• 소프트웨어 프로세스 모델은 일반적으로 네 가지 소프트웨어 활동과 관련이 있습니다.
  • Specification, Design and Implementation, Validation and Evolution
• 모델 간의 차이점은 활동이 프로세스 모델 내에서 어떻게 배치되는지에 기반합니다.
• 소프트웨어 변화는 불가피합니다.
  • 따라서 우리는 이러한 변화에 어떻게 대처할지 알아야 합니다.
    • 변화 예측, 변화 수용, 프로토타이핑, 증분 배송.