CPT203-Software Engineering 笔记

这篇具有很好参考价值的文章主要介绍了CPT203-Software Engineering 笔记。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

Week 1 -- Introduction

failure reason 

professional software development***

maintain, security, efficiency, acceptability

two kinds***: generic, customized

software deterioration 软件退化

reduce changes/ side effects after changes

software engineering approaches 软件工程方法***

4 fundamental activities:s,d,v,e(迭代优化) Lec1 p24

•软件规范(Software specification)(需求明确)

•软件开发(Software development)

•软件验证(Software validation)

•软件进化(Software evolution)(软件迭代)

开发方法

• 顺序开发(Sequential)
• 迭代开发(Iterative)

ethics***

软件开发的风险(SOFTWARE DEVELOPMENT RISK) 风险***

minimize risks -- communicate

Week 2 --software process

a set of related activities

•软件规范(Software specification)
•软件设计和实现(Software design and implementation)
•软件验证(Software validation)
•软件进化(Software evolution)

classification***

plan driven/ agile process

process models 软件过程模型 p12

瀑布模型(The waterfall model)

This takes the fundamental process activities of specification, development, validation, and evolution and represents them as separate process phases such as requirements specification, software design, implementation, testing, and so on.

*document produced in each stage

* free parts 

CPT203-Software Engineering 笔记,课程笔记,软件工程

 原则上,瀑布模型应该只在需求被很好地理解并且在系统开发期间不太可能发生根本变化的情况下使用

增量开发(Incremental development)

This approach interleaves the activities of specification, development, and validation. The system is developed as a series of versions (increments), with each version adding functionality to the previous version.

CPT203-Software Engineering 笔记,课程笔记,软件工程

优点:

成本低,快速,客户及时反馈

缺点:

进程不可见。

随着新增量的增加,系统结构趋于退化(错误越来越多)

面向重用的软件工程(Reuse-oriented software engineering)

This approach is based on the existence of a significant number of reusable components. The system development process focuses on integrating these components into a system rather than developing them from scratch.

注意:这些模型不是相互排斥(mutually exclusive)的,并且经常一起使用,特别是对于大型系统开发。

e.g web服务, 包,standalone software

CPT203-Software Engineering 笔记,课程笔记,软件工程

优点:

less work/cost/risks

faster

缺点

· 然而,需求妥协(requirements compromises)是不可避免的,这可能导致系统不能满足用户的真正需求。

此外,由于可重用组件的新版本不在使用它们的组织的控制之下,因此失去了对系统演化的一些控制(新版本上线,有些东西不能用了)

SOFTWARE PROCESS ACTIVITIES 软件过程活动

定义***现实的软件过程是技术、协作和管理活动的交错序列,其总体目标是指定、设计、实现和测试软件系统(specifying, designing, implementing, and testing a software system)

在瀑布模型中,它们按顺序组织(in sequence)

在增量开发中,它们是交错的(interleaved)

CPT203-Software Engineering 笔记,课程笔记,软件工程

SOFTWARE SPECIFICATION

requirement engineering

- 2level high level/ detailed level 

-4 activities p35 

需求工程过程的目的是产生一个商定的需求文档,该文档指定了一个满足涉众需求的系统

SOFTWARE DESIGN AND IMPLEMENTATION 软件设计和实现

软件开发的实现阶段是将系统规范转换为可执行系统的过程

它总是涉及软件设计和编程过程,但是,如果使用增量开发方法,也可能涉及软件规范的细化(refinement of the software specification)

软件设计是对要实现的软件结构、系统使用的数据模型和结构、系统组件之间的接口,有时还包括所使用的算法的描述
*迭代设计

CPT203-Software Engineering 笔记,课程笔记,软件工程

输入:平台信息。需求规范说明,数据描述

输出:软件结构,数据库规范描述,接口规范描述,组件规范描述

design activity 设计活动

体系结构设计(Architectural design)

接口设计(Interface design)

组件设计(Component design)

数据库设计(Database design)

Software Validation 软件验证

•    a system both conforms to its specification
•    it meets the expectations of the system customer

Validation techniques 验证技术

CPT203-Software Engineering 笔记,课程笔记,软件工程

三个阶段的测试过程包括对系统组件的测试(testing for system component),然后是对集成系统的测试( testing for an integrated system),最后是使用客户数据对系统进行测试(testing of the system with the customer’s data)

开发测试(Development testing)

组件测试,独立

系统测试(System testing)

组件交互

验收测试(Acceptance testing)

用户数据

Week 3 -- Agile methods

Rapid Software Development 快速软件开发

The software is not developed as a single unit but as a series of increments, with each increment including new system functionality.

fundamental characteristics: interleaved, Minimum documentation,series of version with system stakeholders involvement, interactive development system

Principle

•    Individuals and interactions over processes and tools
•    Working software over comprehensive documentation
•    Customer collaboration over contract negotiation
•    Responding to change over following a plan

CPT203-Software Engineering 笔记,课程笔记,软件工程

Challenge

- require: a customer who is willing and able to spend time with the development team and who can represent all system stakeholders

- Individual team members may not have suitable personalities for the intense involvement

- Prioritizing changes difficult

- contract difficult - time paid

- responsibility 

-maintain continuity

Maintenance 维护

正式的文档应该能简化系统的演化和维护。然而,在实践中,正式文档通常是不更新的,在系统可维护性方面也是如此(对文档的不重视性可能导致维护性差)

system requirements document **

Plan-driven and Agile development 计划驱动和敏捷开发

10个问题

•    Detail specification and design needed?
•    Is incremental strategy realistic?
•    How large is the system?
•    What type of system being developed?
•    System life span?

•    Available technologies and tools?
•    Organization of the team?
•    Cultural issues?
•    Available skillsets?
•    External regulation?

Week 4 -- Requirement Engineering

是software specification这个阶段的任务哦!

高层描述(high-level description)User requirements;
细节描述(detail description)System requirements

Functional  requirement

· 功能需求

These are statements of services the system should provide. How the services should react and behave in certain condition. In some cases, the functional requirements may also explicitly state what the system should not do.

完整性(Completeness),一致性(Consistency)

类型:

通用性需求;状态驱动的需求;事件驱动的需求;可选功能需求;异常行为需求;复杂需求

Non-functional requirement*****

· 非功能需求

These are constraints on the services or functions offered by the system. Non-functional requirements often apply to the system as a whole, rather than individual system features or services. 

系统属性(System properties)

重要:如可靠性、安全性和机密性需求(reliability, safety, and confidentiality)

1. failing the unfunctional requirement means the whole system is unuseable

2. affect overall architecture

3 may generate a number of related functional requirements

非功能分类↓

•    Product requirements - These requirements specify or constrain the behavior of the software.
•    Organizational requirements - These requirements are broad system requirements derived from policies and procedures in the customer’s and developer’s organization.
•    External requirements - This broad heading covers all requirements that are derived from factors external to the system and its development process

CPT203-Software Engineering 笔记,课程笔记,软件工程

定量地(quantitatively)

软件需求文档(The Software Requirements Document)

软件需求文档(有时称为软件需求说明书(software requirements specification)或SRS)是系统开发人员应该实现的正式文档。应该包括系统的用户需求系统需求详细规格说明

需求稳定的

CPT203-Software Engineering 笔记,课程笔记,软件工程

质量特性:correct,complete,unambiguous,verificable, consistent, ranked for importance/stability, modifiable, traceable

需求工程过程(Requirements Engineering Processes)

CPT203-Software Engineering 笔记,课程笔记,软件工程

和软件过程活动是一张图居然

4 high-level activities

-(可行性研究,feasibility study)

需求发现(获取和分析,elicitation and analysis),

转换成某种标准形式(规范,specification),

(验证,validation)

CPT203-Software Engineering 笔记,课程笔记,软件工程

需求获取与分析(Requirements Elicitation and Analysis)

CPT203-Software Engineering 笔记,课程笔记,软件工程

需求规范(Requirements specification):需求被记录下来,并输入到螺旋的下一轮中。如第4.3节所述,可能会产生正式或非正式的需求文件

挑战 p39

1. unreachable

2. customer use their own terms

需求发现(Requirements discovery/elicitation)

This is the process of interacting with stakeholders of the system to discover their requirements

stakeholders--

interviews (close/open)a springboard question, a requirements proposal, a prototype system 来自访谈的信息补充了来自描述业务流程或现有系统的文档、用户观察等有关系统的其他信息。

observation

scenarios

prototypes

1.采访(Requirements Discovery - Interview)

2.场景(Requirements Discovery - Scenarios)

示例交互会话(example interaction sessions),标识了系统与其用户或其他系统之间的单独交互

一般情况下,一个场景可能包括1.2.3.4.5

3.用例(Requirements Discovery - Use case)

4.人类学(Requirements Discovery – Ethnography)

站在需求方考虑,不是完整的启发(elicitation)的方法,用来填补其他方法

需求规范(Requirements Specification) p60

清晰的、无歧义的、容易理解的、完整的和一致的

在写用户的需求规范时,应1.2.3.4

1. 需求规范—自然语言规范(Natural Language Specification)

2. 结构化规范(Structured Specification)

结构化自然语言是一种使用自然语言在预定义的结构或模板中编写系统需求的方法

需求验证(Requirements Validation)

•Requirements validation is the process of checking that requirements correctly define the system that the customer really wants

types of checks

有效性检查(Validity checks)

一致性检查(Consistency checks)

完整性检查(Completeness checks)

真实性检查(Realism checks)

可验证性(Verifiability)

techniques

需求评审(Requirements reviews)

原型设计(Prototyping)

测试用例生成(Test-case generation)

重要性:不适当的 validation 可能导致rework

Week5 -- System Modeling

构成元素 elements

系统建模是开发系统抽象模型的过程,每个模型表示该系统的不同视图或视角

建模通过将复杂系统抽象成适当层次的细节来简化复杂系统

使用某种图形符号来表示系统,现在几乎总是基于统一建模语言(UML)中的符号

系统视角(System perspectives)

external/interaction/structural/behavioral  models

UML 图

这玩意我单独写一篇博客

活动图(Activity diagrams)显示流程或数据处理涉及的活动

用例图(Use case diagrams),显示系统与其环境之间的交互

序列图(Sequence diagrams),显示参与者和系统之间以及系统组件之间的交互

类图(Class diagrams),显示系统中的对象类和这些类之间的关联

状态机图(State machine diagrams),显示系统如何对内部和外部事件作出反应。 

上下文建模(Context models)

illustrate the operational context of a system - they show what lies outside the system boundaries. 

social & organisational may affect System boundaries

1.生成一个简单的体系结构模型(a simple architectural model)

交互模型(Interaction models)

Modeling user interaction/system-to-system interaction/component interaction

用例图和顺序图(Use case diagrams and sequence diagrams用于描述系统中用户和系统之间的交互(交互模型(Interaction models))

用例图描述系统和外部参与者之间的交互;

序列图通过显示系统内部的对象之间的交互向这些图添加了更多的信息。

结构模型(Structural models)

static -- the structure of the system design

dynamic -- the organization of the system when it is executing

类图(class diagrams用于定义系统中类的静态结构及其关联

generalization 底层类是继承父类的属性和操作的子类,泛化显示为指向更通用类的箭头(三角箭头)

aggregation一个对象(整体)由其他对象(部分)组成,整体的类旁边使用一个菱形(菱形箭头)

行为模型(Behavioral models)

系统对来自环境的刺激(data/events)作出反应时发生了什么或应该发生什么

数据驱动模型(Data-driven modeling)

关于事件驱动的建模(Event-driven modeling)

活动图(Activity diagrams)和序列图可用于对数据处理建模(data-driven models),其中在活动图,每个活动表示一个过程步骤。

状态图(State diagrams)用于对系统响应内部或外部事件的行为进行建模(event-driven models)。

Week 8--Design Concepts

analysis 做什么

design 怎么做

analysis:  

CPT203-Software Engineering 笔记,课程笔记,软件工程

goal

•    Firmness (no bugs)
•    Commodity (useful or valuable)
•    Delight (pleasurable experience)

Design in the SE context

CPT203-Software Engineering 笔记,课程笔记,软件工程

四个层次,由总到细,由高到低

Component level design

 transforms structural elements of the software architecture into a procedural description of software components.

Interface design

describes how the software communicates with systems that interoperate with it, and with humans who use it

Architectural design

defines the relationship between major structural elements of the software, the architectural styles and patterns that can be used to achieve the requirements defined for the system, and the constraints that affect the way in which architecture can be implemented.

data design/class design

transforms class models into design class realizations and the requisite data structure required to implement it.

Quality control in the design progress*

3 goals : satisfy implicit/explicit requirement/readable/complete picture

8 technical criteria p9 - architecture, modular, distinct representation, appropriate data structures, independent, repeatable, notation

Quality -- FURPS***

Functionality, Usability, Reliability, Performance, Supportability

Design concepts***

idea: foundation, partition, technical quality

Abstraction

Abstraction simply means to hide the details to reduce complexity and increases efficiency or quality.
procedural abstraction: a sequence of instructions that have a specific and limited function. The name of a procedural abstraction implies these functions, but specific details are suppressed.

data abstraction: a named collection of data that describes a data object.

Modularity

better organize complex system

CPT203-Software Engineering 笔记,课程笔记,软件工程

Functional independence: coupling &cohesion

coupling: refers to the degree of interdependence between software modules

sol: interface--, cohesion++

cohesion: the degree of how closely the elements of a module are related to each other

object-oriented design

designing object classes

objects are created dynamically from these class definitions.

Elements in design model

Data

abstract → refined

Program-component level

Application level

Business level

Architectural

floor to the house

resources:

application domain

model elements

availability

Interface

doors and windows

UI, external, internal

Component-Level

detailed

UML-diagram

Deployment-Level

physical

Week 9--Architecture, Component-Level and Interface

Architecture Design

Architectural design is concerned with understanding how a system should be organized and designing the overall structure of that system. It identifies the main structural components in a system and the relationships between them. The output of this design process is a description of the software architecture.

affects: performance, robustness, distributability, and  maintainability

    Individual component – implement functional requirements
    System architecture – fulfill non-functional requirement

advance: stakehoder communication, system analysis, reuse

Architecture View

· Logical

shows the key abstractions in the system as objects or object classes.

· process

shows how, at run-time, the system is composed of interacting processes.

· development (模块)

shows how the software is decomposed for development.

· physical

shows the system hardware and how software components are distributed across the processors in the system.

scenarios:

用用例将另外几个视图串联

Aechitectural Patterns************

 Patterns are means of representing, sharing and reusing knowledge. A stylized description of good design practice,

· MVC (Model-View-Controller)

    Model: central component of the pattern that directly manages the data, logic and rules of the application
    View:can be any output representation of information, such as a chart or a diagram.
    Controller: accepts input and converts it to commands for the model or view, enables the interconnection between the views and the model

CPT203-Software Engineering 笔记,课程笔记,软件工程

CPT203-Software Engineering 笔记,课程笔记,软件工程

·  Layered Patterns

the system functionality is organized into separate layers, and each layer only relies on the facilities and services offered by the layer immediately beneath it.

supports the incremental development , not efficient 

CPT203-Software Engineering 笔记,课程笔记,软件工程

CPT203-Software Engineering 笔记,课程笔记,软件工程

· Repository Patterns

CPT203-Software Engineering 笔记,课程笔记,软件工程

· Client-Server Patterns

CPT203-Software Engineering 笔记,课程笔记,软件工程

· Pip and filter Patterns

CPT203-Software Engineering 笔记,课程笔记,软件工程

Component-level Design

Component-level design occurs after the first iteration of architectural design has been completed.
 A complete set of software components is defined during architectural design.

define  data structures, algorithms, interface characteristics, and communication mechanisms

intermediate representations

➢    A software component is a modular building block for computer software.
➢    It can be used to review for correctness and consistency with other components.
 

Views of Component

·面向对象视角(object-oriented view)

Centers on objects as the fundamental building blocks of software. An object encapsulates both data and behavior, representing entities or concepts.

面向对象视图侧重于将系统建模为一组相互作用的对象,每个对象都封装了与在线购物相关的数据和行为。

CPT203-Software Engineering 笔记,课程笔记,软件工程

· 传统视角(conventional view)

传统观点将系统构建为一系列执行特定任务的过程或功能,如添加产品、下订单和处理付款。

CPT203-Software Engineering 笔记,课程笔记,软件工程

· 流程视角(process view)

流程视图根据系统的运行时行为来查看系统,特别是它如何处理订单和支付流,以及如何管理并发性和系统资源

CPT203-Software Engineering 笔记,课程笔记,软件工程

User Interface Design

golden rules

1. Place the User in control

 does not force

flexible interaction

interruptible and undoable

 direct interaction on screen

 visibility

2. Reduce the Users' Memory Load

Reduce demand on short-term memory.

default

realworld

3. make the interface consistant 

processCPT203-Software Engineering 笔记,课程笔记,软件工程

iterative

issues

Response time: length, variability

Help facilities

Error handling

Application accessibility

Internationalization

evaluation

CPT203-Software Engineering 笔记,课程笔记,软件工程

Week 10--Software Testing

Testing basics

validation vs defect

validation testing 验证:

You expect the system to perform correctly using a given set oftest cases that reflect the system's expected use.

A successful test shows that the system operates as intended

defect testing 缺陷:

The test cases are designed to expose defects. The test cases indefect testing can be deliberately obscure and need not reflecthow the system is normally used

A successful test is a test that makes the system performincorrectly and so exposes a defect in the system.

verification vs validation

meeks specification and delivers functionality

verification: functional and non-functional requirements

validation: meets the customer's expectations

software inspections vs software testing

inspection : Concerned with analysis of the static system representation to discover problems(static V&V)

adavantage: ignore error interaction, no additional cost, border quality

testing : Concerned with exercising and observing product behavior (dynamic V&V)

stages of testing

Development testing

the system is tested during development to discover bugs and defects

Unit testing

where individual program units or object classes are tested. Unit testing should focus on testing the functionality of objects or methods.

unit : Object classes with several attributes and methods

automated test: setup, call, assertion

testing strategies

partition testing(类似的组合测试); single value, different size, boundaries, midpoint, zero length

guideline-based testing(容易出错地方的测试)

Component testing

several individual units are integrated to create composite components. Component testing should focus on testing component interfaces. * not individual components

interface testing 

interface misuse: A calling component calls another component and makes an error in its use of its interface e.g. parameters in the wrong order

interface misunderstanding: A calling component embeds assumptions about the behavior of the called component which are incorrect

timing errors: The called and the calling component operate at different speed sand out-of-date information is accessed

extreme ends, null pointers, component failure 

System testing

where some or all of the components in a system are integrated and the system is tested as a whole System testing should focus on testing component interactions

use-case testing

testing policies

Release testing

a separate testing team test a complete version of the system before it is released to users

system: bugs / release: check requirements

requirement based testing

scenario testing

performance testing - operational profile/ Stress testing

User testing

users or potential users of a system test the system in their own environment 

alpha - user and team at developer's site

beta - user experiment

acceptance-Customers 

CPT203-Software Engineering 笔记,课程笔记,软件工程

Week 11--Junit Testing

JUnit

AssertTrue/AssertFalse

AssertSame/AssertNotSame

AssertEquals/AssertNotEquals

AssertArrayEquals

AssertThrows

CPT203-Software Engineering 笔记,课程笔记,软件工程

life circle

@BeforeAll

@BeforeEach

@AfterAll

@AfterEach

CPT203-Software Engineering 笔记,课程笔记,软件工程

@DisplayName

@Timeout

@RepeatedTest

Week12 Project Management

Challenges

intangible, one-off, variable and organization-specific

Risk management

•    Project risks: Risks that affect the project schedule or resources (e.g., loss of an experienced designer). 
•    Product risks: Risks that affect the quality or performance of the software being developed (e.g., failure of a purchased component to perform as expected). 

•    Business risks: Risks that affect the organization developing or procuring the software (e.g., a new product from competitors). 

CPT203-Software Engineering 笔记,课程笔记,软件工程

阶段

CPT203-Software Engineering 笔记,课程笔记,软件工程

•    Risk identification: identify possible project, product, and business risks

CPT203-Software Engineering 笔记,课程笔记,软件工程
•    Risk analysis: assess the likelihood and consequences of these risks

probability

seriousness


•    Risk planning: plans to address the risk, either by avoiding it or minimizing its effects on the project

Avoidance strategies, Minimization strategies, Contingency plans


•    Risk monitoring: regularly assess the risk and your plans for risk mitigation and revise these when you learn more about the risk

managing people

CPT203-Software Engineering 笔记,课程笔记,软件工程

4 critical factors: Consistency, Respect, Inclusion, Honesty

people type: Task/Self/Interaction-oriented people

Software team

a closed/random/open/synchronous paradigm

CPT203-Software Engineering 笔记,课程笔记,软件工程

efficiency influence by: Group size/Group structure/Group composition/The physical work environment/ The available communication channels 文章来源地址https://www.toymoban.com/news/detail-796157.html

到了这里,关于CPT203-Software Engineering 笔记的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 【读书笔记】《软件工程导论》

    目录 一、软件工程概述 二、启动阶段 三、计划阶段 四、实施阶段 五、收尾阶段 软件危机: 在计算机软件的开发和维护过程中遇到的一系列严重问题。 软件危机的产生与自身的特点有关,还与软件开发、管理的方法不正确有关。 软件危机的典型表现: 对软件开发的进度和

    2024年02月11日
    浏览(43)
  • 软考笔记——9.软件工程

    软件工程的基本原理: 用分阶段的生命周期计划严格管理、坚持进行阶段评审、实现严格的产品控制、采用现代程序设计技术、结果应能清除的审查、开发小组的人员应少而精、承认不断改进软件工程事件的必要性。 软件工程的基本要素: 方法、工具、过程 软件生存周期:

    2024年02月12日
    浏览(36)
  • Crafting User-Centric Experiences: The Confluence of UX and UI in Software Engineering

                  In the realm of software engineering, the realms of User Experience (UX) and User Interface (UI) design have emerged as pivotal disciplines, shaping the way users interact with and perceive software applications. UX and UI design are instrumental in creating intuitive, engaging, and aesthetically pleasing interfaces that resonate wit

    2024年01月22日
    浏览(48)
  • 《面向对象软件工程》笔记——1-2章

    “学习不仅是一种必要,而且是一种愉快的活动。” - 尼尔·阿姆斯特朗 软件工程是一门以生产出没有错误、按时并且在预算内交付的满足客户需求的软件为目的的学科。这个定义非常广泛,所以能使用到从数学、计算机科学到管理学、心理学等诸多专业的学科。开发软件的

    2024年02月06日
    浏览(37)
  • 【软考程序员学习笔记】——软件工程

      目录 🍊一、软件存周期 🍊二、软件生存周期模型 🍊三、软件开发方法 🍊四、需求分析 🍊五、内聚和耦合 🍉模块内的独立性--内聚性 🍉模块间的独立性--耦合性 🍊六、软件测试 🍉黑盒测试 🍉白盒测试 🍊七、V模型 🍊八、软件维护 🍊九、软件质量模型 问题定义

    2024年02月12日
    浏览(52)
  • 软考高级架构师笔记-8软件工程

    前文回顾:

    2024年02月11日
    浏览(40)
  • STM32学习笔记(一):简介、软件安装及新建工程

    本文内容参考自以下内容: B站UP主江科大自化协:STM32入门教程,链接:https://www.bilibili.com/video/BV1th411z7sn?spm_id_from=333.337.search-card.all.click 《零死角玩转stm32—f103指南者》、《普中STM32F1xx开发攻略v1.0》 链接:https://pan.baidu.com/s/1DfVTBpOT_JXgvK_AVQCouA?pwd=1024 提取码:1024 1. STM32的基

    2024年01月23日
    浏览(43)
  • 【通义千问】大模型Qwen GitHub开源工程学习笔记(1)-- 使用指南、依赖库和软件

    9月25日,阿里云开源通义千问140亿参数模型Qwen-14B及其对话模型Qwen-14B-Chat,免费可商用。 立马就到了GitHub去fork。 GitHub: GitHub - QwenLM/Qwen: The official repo of Qwen (通义千问) chat pretrained large language model proposed by Alibaba Cloud. 官方的技术资料也下载了,看这里==https://qianwen-res.oss-cn-b

    2024年02月03日
    浏览(63)
  • 《ChatGPT Prompt Engineering for Developers》课程-提示词原则

    本章的主要内容为编写 Prompt 的原则,在本章中,我们将给出两个编写 Prompt 的原则与一些相关的策略,你将练习基于这两个原则来编写有效的 Prompt,从而便捷而有效地使用 LLM。 本教程使用 OpenAI 所开放的 ChatGPT API,因此你需要首先拥有一个 ChatGPT 的 API_KEY(也可以直接访问

    2024年02月03日
    浏览(40)
  • 《ChatGPT Prompt Engineering for Developers》课程中文版系列

    课程简介 吴恩达《ChatGPT Prompt Engineering for Developers》课程中文版,主要内容为指导开发者如何构建 Prompt 并基于 OpenAI API 构建新的、基于 LLM 的应用,包括: 书写 Prompt 的原则; 文本总结(如总结用户评论); 文本推断(如情感分类、主题提取); 文本转换(如翻译、自动纠

    2024年02月03日
    浏览(44)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包