4/30/2015CPSC-4360-01, CPSC-5360-01, Lecture 21 Software Engineering, CPSC-4360-01, CPSC-5360-01,...

54
11/01/22 CPSC-4360-01, CPSC-5360-01, Lecture 2 1 Software Engineering, CPSC-4360-01, CPSC-5360- 01, Lecture 2

Transcript of 4/30/2015CPSC-4360-01, CPSC-5360-01, Lecture 21 Software Engineering, CPSC-4360-01, CPSC-5360-01,...

Page 1: 4/30/2015CPSC-4360-01, CPSC-5360-01, Lecture 21 Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2.

04/18/23CPSC-4360-01, CPSC-5360-01,

Lecture 2 1

Software Engineering, CPSC-4360-01, CPSC-5360-01,Lecture 2 

Page 2: 4/30/2015CPSC-4360-01, CPSC-5360-01, Lecture 21 Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2.

04/18/23CPSC-4360-01, CPSC-5360-01,

Lecture 2 2

Overview of the Last Lecture

Overview of Software Engineering SE definitions Quality of Good Software

Overview of Software Process Activities and associated stages

Overview of Software Engineering Method Structured Analysis Object-Oriented Method

Page 3: 4/30/2015CPSC-4360-01, CPSC-5360-01, Lecture 21 Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2.

04/18/23CPSC-4360-01, CPSC-5360-01,

Lecture 2 3

Overview of This Lecture Software Development Models

Waterfall Model Evolutionary Models Incremental Model Spiral Model Unified Process

Overview of UML History 4 + 1 View models Using UML in UP

Page 4: 4/30/2015CPSC-4360-01, CPSC-5360-01, Lecture 21 Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2.

04/18/23CPSC-4360-01, CPSC-5360-01,

Lecture 2 4

Software Development Models High level, abstract representation of software

development (software process): Specification. Development. Validation. Evolution.

Theoretical framework that is usually extended and adapted in real world application.

Two Generic Models: Waterfall Model. Evolutionary Model.

Page 5: 4/30/2015CPSC-4360-01, CPSC-5360-01, Lecture 21 Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2.

04/18/23CPSC-4360-01, CPSC-5360-01,

Lecture 2 5

Waterfall Model

The earliest software development model (Royce, 1970).

Requirementsdefinition

System andsoftware design

Implementationand unit testing

Integration andsystem testing

Operation andmaintenance

Page 6: 4/30/2015CPSC-4360-01, CPSC-5360-01, Lecture 21 Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2.

04/18/23CPSC-4360-01, CPSC-5360-01,

Lecture 2 6

Waterfall Model

Defined a number of phases, e.g., “requirement phase”, “design phase”, etc.

The phases correspond to the four stages of the fundamental software process activities (lecture 1).

Assumption behind the model: a phase takes place in sequence to another. each activity is completed before the next starts.

Page 7: 4/30/2015CPSC-4360-01, CPSC-5360-01, Lecture 21 Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2.

04/18/23CPSC-4360-01, CPSC-5360-01,

Lecture 2 7

Waterfall Model

In theory: Each phase produces documents that are:

Verified and validated. Assumed to be complete.

Each phase depends on the documents of the previous stage to proceed → it has to wait for the completion of previous stage.

In practice: The phases overlap and feedback to each other

(see the feedback arrow in the diagram).

Page 8: 4/30/2015CPSC-4360-01, CPSC-5360-01, Lecture 21 Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2.

04/18/23CPSC-4360-01, CPSC-5360-01,

Lecture 2 8

Waterfall Model: Advantages

Tangible products (the various documents) at the end of every phases → good to measure progress.

Intuitive, sensible and general purpose: Emphasize planning before action. Recommend a top-down perspective. See the big

picture before zooming down.

Page 9: 4/30/2015CPSC-4360-01, CPSC-5360-01, Lecture 21 Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2.

04/18/23CPSC-4360-01, CPSC-5360-01,

Lecture 2 9

Waterfall Model: Problems

Specification is frozen early, because: It is costly and time consuming. Later stages can be carried out.

Cannot adapt to changing or incorrect specification: Ignore or code around. Does not meet user requirement.

Testing at the very end of development: Work or die situation.

Page 10: 4/30/2015CPSC-4360-01, CPSC-5360-01, Lecture 21 Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2.

04/18/23CPSC-4360-01, CPSC-5360-01,

Lecture 2 10

Waterfall Model: Observations Process stages can be iterative. Flexibility in coping with changing specification. Early and frequent validation of software system. The later models are designed in response to these

observations.

Page 11: 4/30/2015CPSC-4360-01, CPSC-5360-01, Lecture 21 Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2.

04/18/23CPSC-4360-01, CPSC-5360-01,

Lecture 2 11

Evolutionary Model

Evolves an initial implementation with user feedback → multiple versions until the final version.

ValidationFinal

version

DevelopmentIntermediate

versions

SpecificationInitial

version

Outlinedescription

Concurrentactivities

Page 12: 4/30/2015CPSC-4360-01, CPSC-5360-01, Lecture 21 Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2.

04/18/23CPSC-4360-01, CPSC-5360-01,

Lecture 2 12

Evolutionary Model

Two fundamental types: Exploratory Development:

Explores the requirement and delivers a final system. Starts with something that is understood and evolves by adding

new features proposed by customers. Throwaway prototyping:

Understands the requirement and develop a better requirement definition.

Experimenting with poorly understood requirement. Usually develops User Interface (UI) with minor or no functionality.

Page 13: 4/30/2015CPSC-4360-01, CPSC-5360-01, Lecture 21 Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2.

04/18/23CPSC-4360-01, CPSC-5360-01,

Lecture 2 13

Evolutionary Model: Advantages Customer involvement in the process:

More likely to meet the user requirement. Early and frequent testing:

More likely to identify problems. Lower risk.

Suitable for small to medium sized system.

Page 14: 4/30/2015CPSC-4360-01, CPSC-5360-01, Lecture 21 Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2.

04/18/23CPSC-4360-01, CPSC-5360-01,

Lecture 2 14

Evolutionary Model: Problems The process is intangible:

No regular, well-defined deliverables. The process is unpredictable:

Hard to manage, e.g., scheduling, workforce allocation, etc. Systems are poorly structured:

Continual, unpredictable change tends to corrupt the software structure.

Can cause major problems during software evolution. Systems may not even converge to a final version.

No strategy to gauge or solve this problem.

Page 15: 4/30/2015CPSC-4360-01, CPSC-5360-01, Lecture 21 Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2.

04/18/23CPSC-4360-01, CPSC-5360-01,

Lecture 2 15

Incremental Model

Combine the advantages of Waterfall and Evolutionary Model.

Requirements Outline

Split into increments

Design System

Architecture

Develop Increment

Validate Increment

Integrate Increment

Validate System

Final System

Page 16: 4/30/2015CPSC-4360-01, CPSC-5360-01, Lecture 21 Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2.

04/18/23CPSC-4360-01, CPSC-5360-01,

Lecture 2 16

Incremental Model

Each increment is a mini-waterfall.

Page 17: 4/30/2015CPSC-4360-01, CPSC-5360-01, Lecture 21 Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2.

04/18/23CPSC-4360-01, CPSC-5360-01,

Lecture 2 17

Incremental Model Prioritizes the services to be provided by the

system. Maps these requirements to Increment based

on priority. Freezes requirement for the current Increment.

Requirements for the later increments can evolve concurrently.

Each Increment release is a working system: Allows user to experiment. Can be put into service right away.

Page 18: 4/30/2015CPSC-4360-01, CPSC-5360-01, Lecture 21 Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2.

04/18/23CPSC-4360-01, CPSC-5360-01,

Lecture 2 18

Incremental Model: Advantages Early utilization:

the 1st increment satisfies the most critical requirement.

Early increments can serves as prototypes. Lower risk of overall project failure. Most crucial and basic services are

implemented first → receives multiple testing throughout development.

Page 19: 4/30/2015CPSC-4360-01, CPSC-5360-01, Lecture 21 Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2.

04/18/23CPSC-4360-01, CPSC-5360-01,

Lecture 2 19

Incremental Model: Problems

Hard to map requirement into small increments (< 20,000 lines of code).

Hard to define the basic services that are shared by all subsequent increments.

Popular variant: AGILE method:

eXtreme Programming (XP) Not covered here.

Page 20: 4/30/2015CPSC-4360-01, CPSC-5360-01, Lecture 21 Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2.

04/18/23CPSC-4360-01, CPSC-5360-01,

Lecture 2 20

Spiral Model Formalize the Evolutionary Model and avoid the

management shortcomings.

Page 21: 4/30/2015CPSC-4360-01, CPSC-5360-01, Lecture 21 Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2.

04/18/23CPSC-4360-01, CPSC-5360-01,

Lecture 2 21

Spiral Model

Process is represented as a spiral rather than as a sequence of activities with backtracking.

Each loop = One Iteration = A process phase. Each Loop passes through 4 quadrants (90°):

Objective Setting. Risk Assessment and Reduction. Development and Validation. Planning.

As loops move away from center → Time and Cost increase.

Page 22: 4/30/2015CPSC-4360-01, CPSC-5360-01, Lecture 21 Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2.

04/18/23CPSC-4360-01, CPSC-5360-01,

Lecture 2 22

Spiral Model

Risk Driven: Explicitly identify risks for each iteration. Address the highest perceived risk.

Does not prescribe a fix process: Project Manager chooses the appropriate activity

for each iteration base on progress and perceived risk.

Flexible: May resemble other process model depends on

needs.

Page 23: 4/30/2015CPSC-4360-01, CPSC-5360-01, Lecture 21 Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2.

04/18/23CPSC-4360-01, CPSC-5360-01,

Lecture 2 23

Unified Process State of the art process, by learning from the history

of previous software development processes.

Page 24: 4/30/2015CPSC-4360-01, CPSC-5360-01, Lecture 21 Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2.

04/18/23CPSC-4360-01, CPSC-5360-01,

Lecture 2 24

Unified Process Integrating two seemingly contradicting

insights: Definitive activities and deliverables as in the

Waterfall Model. Iterative and incremental processes.

A project is split into several phases: Each phase is split into several iterations. Each iteration consists of the traditional process

activities, known as workflow. Each workflow places different emphasis on the

activities depending on the current iteration.

Page 25: 4/30/2015CPSC-4360-01, CPSC-5360-01, Lecture 21 Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2.

04/18/23CPSC-4360-01, CPSC-5360-01,

Lecture 2 25

Unified Process: 4 Phases Inception:

Plan the project. Evaluate risk.

Elaboration: Understand problem domain. Design system architecture. Plan development.

Construction: Design, programming and test.

Transition: Moving system from developer to user environment. Acceptance testing, release of full system.

Page 26: 4/30/2015CPSC-4360-01, CPSC-5360-01, Lecture 21 Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2.

04/18/23CPSC-4360-01, CPSC-5360-01,

Lecture 2 26

Other Process Models Formal System Development:

Transforms a mathematical based specification through different representation → executable program.

Program correctness is easy to demonstrate, as the transformations preserve the correctness.

Reuse-Oriented Development: Concentrates on integrating new system with existing

components/systems. Growing rapidly as development cost increase.

Aspect-Oriented Development. Agent-Oriented Software Development.

Page 27: 4/30/2015CPSC-4360-01, CPSC-5360-01, Lecture 21 Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2.

04/18/23CPSC-4360-01, CPSC-5360-01,

Lecture 2 27

Unified Modeling Language (UML) A visual language to

Visualize, construct, document software system. Similar to all other languages, UML has:

Grammar: Rules to follow when drawing diagrams. Semantics: The meaning behind each diagram.

Used with the Object-Oriented Method. Separates the language from the software

process → can be used with other software development model.

Currently, this is an industry standard.

Page 28: 4/30/2015CPSC-4360-01, CPSC-5360-01, Lecture 21 Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2.

04/18/23CPSC-4360-01, CPSC-5360-01,

Lecture 2 28

What UML is NOT

Not a programming language. Not executable. Exist tools to translate into code (skeleton), but the

programmer still need to do the bulk of work. Not a software modeling tool.

There are tools that implement the UML standard, e.g., ArgoUML, Visual Paradigm, RationalRose.

Not a SE method or software development process.

Page 29: 4/30/2015CPSC-4360-01, CPSC-5360-01, Lecture 21 Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2.

04/18/23CPSC-4360-01, CPSC-5360-01,

Lecture 2 29

UML: Brief History OO Modeling approach with different strengths and

weaknesses grows rapidly. In 1995,

There were more than 50 named techniques in the industry. The Object Management Group (OMG) calls for a common

modeling approach. Rumbaugh, Booch, and Jacobson (The three amigos)

with input from others, formalized the UML standard (UML 1.1) in 1997.

Revised in 2003 (UML 1.5): Currently most widely used. Reorganized in 2005 (UML 2.0): A new standard.

Page 30: 4/30/2015CPSC-4360-01, CPSC-5360-01, Lecture 21 Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2.

04/18/23CPSC-4360-01, CPSC-5360-01,

Lecture 2 30

UML: 4 + 1 View Models A system can be viewed in different ways,

usually depends on the role of the viewer. UML supports this by providing the 4 + 1 View

Models [Kruchten, 1995]:

System

Design View

Implementation View

Deployment View

Process View

Use Case View

Page 31: 4/30/2015CPSC-4360-01, CPSC-5360-01, Lecture 21 Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2.

04/18/23CPSC-4360-01, CPSC-5360-01,

Lecture 2 31

Use Case View

Audience: System Analyst, End Users and Testers.

Usage: Describes the system’s external behaviour. Defines the requirements of the system, so it

constraints all the other views. Has the central role in driving the development

process.

Page 32: 4/30/2015CPSC-4360-01, CPSC-5360-01, Lecture 21 Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2.

04/18/23CPSC-4360-01, CPSC-5360-01,

Lecture 2 32

Example of Use Case Elevator System

Use case 1: ‘Call Elevator’ is this possible written story: Basic course of events: If the userOutside wants to call lift to

go up/down, then he/she presses UpButton/DownButton; Exception 1: If the lift is at the ground floor, then there is no

DownButton; Exception 2: If the lift is at the top floor, then there is no

UpButton; Use case 2: ‘Move From Inside’ is this written story:

The userFromInside can select a floor number (from 1 to the number of floors of the building), or can press “Open”, “Close”.

Page 33: 4/30/2015CPSC-4360-01, CPSC-5360-01, Lecture 21 Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2.

04/18/23CPSC-4360-01, CPSC-5360-01,

Lecture 2 33

Design View

Audience: System Analyst and Programmers.

Usage: Describes the logical structures that support the

functional requirements expressed in the use case view.

Consists of definitions of program components (classes, data), their behaviour and interactions.

Useful as basis for coding.

Page 34: 4/30/2015CPSC-4360-01, CPSC-5360-01, Lecture 21 Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2.

04/18/23CPSC-4360-01, CPSC-5360-01,

Lecture 2 34

Implementation View

Audience: System Engineer and Tester.

Usage: Describes the physical components out of which

the system is to be constructed: executable files, libraries of code, databases.

Useful for configuration management and system integration.

Page 35: 4/30/2015CPSC-4360-01, CPSC-5360-01, Lecture 21 Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2.

04/18/23CPSC-4360-01, CPSC-5360-01,

Lecture 2 35

Process View

Audience: System Analyst, Programmer and Tester.

Usage: Non-Functional requirements. Defines concurrency within the system.

Relatively undeveloped.

Page 36: 4/30/2015CPSC-4360-01, CPSC-5360-01, Lecture 21 Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2.

04/18/23CPSC-4360-01, CPSC-5360-01,

Lecture 2 36

Deployment View

Audience: System Integrator (setup the system at client side).

Usage: Non-Functional. Describes physical components that are deployed

in the physical environment: Network of computers, connection protocol. Computer specification.

Relatively Undeveloped.

Page 37: 4/30/2015CPSC-4360-01, CPSC-5360-01, Lecture 21 Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2.

04/18/23CPSC-4360-01, CPSC-5360-01,

Lecture 2 37

UML Terminology

Model: Refers to the information in a single view, e.g., Use Case

Model. OR Refers to all the information about the system, i.e., System

Model. Model element:

Independent graphical notation element, e.g., a box, an arrow, etc, that has a well defined meaning.

Diagram: Graphical presentation of a collection of model elements.

Page 38: 4/30/2015CPSC-4360-01, CPSC-5360-01, Lecture 21 Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2.

04/18/23CPSC-4360-01, CPSC-5360-01,

Lecture 2 38

UML Diagrams by Views

1. Use case diagram (use case view)

2. Object diagram (use case and design views)

3. Sequence diagram (use case and design views)

4. Collaboration diagram (use case and design views)

5. Class diagram (design view)

6. Statechart diagram (design and process views)

7. Activity diagram (design and process views)

8. Component diagram (implementation view)

9. Deployment diagram (deployment view)

Page 39: 4/30/2015CPSC-4360-01, CPSC-5360-01, Lecture 21 Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2.

04/18/23CPSC-4360-01, CPSC-5360-01,

Lecture 2 39

UML Diagrams by Characteristic Software system exhibits two characteristics:

Static: Logical Structure, e.g., relationship between classes, attributes of a class, etc.

Dynamic: Behavior of the system, e.g., how to respond to a certain event, how to initiate an action, etc.

In addition, knowledge about setting up and running the system: Implementation.

Page 40: 4/30/2015CPSC-4360-01, CPSC-5360-01, Lecture 21 Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2.

04/18/23CPSC-4360-01, CPSC-5360-01,

Lecture 2 40

UML Diagrams by Characteristic Static:

Use case diagram Class diagram

Dynamic: Object diagram State diagram Activity diagram Sequence diagram Collaboration diagram

Implementation: Component diagram Deployment diagram

Page 41: 4/30/2015CPSC-4360-01, CPSC-5360-01, Lecture 21 Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2.

04/18/23CPSC-4360-01, CPSC-5360-01,

Lecture 2 41

Design Model and Code Models present an abstract view of system. Implementation adds enough detail to make these

models executable.

UML model Object structures

Source code Executing program

UML

Java

Abstract view of Abstract view of

specifies

specifies

Compile time Run time

Page 42: 4/30/2015CPSC-4360-01, CPSC-5360-01, Lecture 21 Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2.

04/18/23CPSC-4360-01, CPSC-5360-01,

Lecture 2 42

UML Models Both documentation (‘UML model’) and ‘Source code’ can

be described as compile-time artifacts. ‘Object structures’: Programmers in object-oriented

languages (e.g., Java, C++) tend to use abstract models of program execution which talk in terms of objects being created and destroyed as a program runs.

‘Executing program’: describes the effect the program has on computer’s processor and memory when the program is running.

The upper and below parts refer to design and programming.

The left and right parts refer to compile-time and run-time.

Page 43: 4/30/2015CPSC-4360-01, CPSC-5360-01, Lecture 21 Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2.

04/18/23CPSC-4360-01, CPSC-5360-01,

Lecture 2 43

Unified Process and UML

UP is Use Case Driven: A systematic utilization of Use Case.

UML diagrams are used in the Requirement, Analysis and Design activities in the UP workflow.

Because of their history, there is a close fit between UML and the UP.

Page 44: 4/30/2015CPSC-4360-01, CPSC-5360-01, Lecture 21 Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2.

04/18/23CPSC-4360-01, CPSC-5360-01,

Lecture 2 44

UP: Requirement and Analysis UP starts with use

cases describing how users interact with the system: A domain model records

facts about real world entities.

UML use case and class diagrams document these.

Page 45: 4/30/2015CPSC-4360-01, CPSC-5360-01, Lecture 21 Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2.

04/18/23CPSC-4360-01, CPSC-5360-01,

Lecture 2 45

UP: Analysis and Design Analysis and Design usually overlap in UP as the

same diagrams are used. Proceed by Realization and Refinement.

Page 46: 4/30/2015CPSC-4360-01, CPSC-5360-01, Lecture 21 Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2.

04/18/23CPSC-4360-01, CPSC-5360-01,

Lecture 2 46

UP: Realization and Refinement Use case realizations indicate how the

functionality will be supported by the system. Documented in UML interaction diagrams, e.g.,

Sequence Diagram, Collaboration Diagram. This causes the domain model to be refined

into a more implementation-oriented class diagram.

Page 47: 4/30/2015CPSC-4360-01, CPSC-5360-01, Lecture 21 Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2.

04/18/23CPSC-4360-01, CPSC-5360-01,

Lecture 2 47

UP: Specifying Behavior

UML provides State Chart to document the behavior of classes.

Page 48: 4/30/2015CPSC-4360-01, CPSC-5360-01, Lecture 21 Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2.

04/18/23CPSC-4360-01, CPSC-5360-01,

Lecture 2 48

Summary (1)

Waterfall Process Model: Development activities in a linear fashion. Requirements to freeze very early in

development. Testing very late in the process.

Evolutionary Process Model in response to iterative nature of development: Use of prototyping. Requirements evolve with users’ feedback.

Page 49: 4/30/2015CPSC-4360-01, CPSC-5360-01, Lecture 21 Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2.

04/18/23CPSC-4360-01, CPSC-5360-01,

Lecture 2 49

Summary (2)

Incremental Process Model in response to incremental nature of development: Delivery in increments. Allows prioritizing risks in development. Allows different process models for different

increments.

Page 50: 4/30/2015CPSC-4360-01, CPSC-5360-01, Lecture 21 Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2.

04/18/23CPSC-4360-01, CPSC-5360-01,

Lecture 2 50

Summary (3)

Spiral Model: Addresses incremental and iterative nature of

development. Allows risk evaluation at every phase. Expensive process. Allows use of multiple process models.

Unified Process: Incorporates best industry practices. Extensive use of UML models. Allows iteration of workflows.

Page 51: 4/30/2015CPSC-4360-01, CPSC-5360-01, Lecture 21 Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2.

04/18/23CPSC-4360-01, CPSC-5360-01,

Lecture 2 51

Summary Software Development Models

Waterfall Model Evolutionary Models Incremental Model Spiral Model Unified Process

Overview of UML History 4 + 1 View models Using UML in UP

Page 52: 4/30/2015CPSC-4360-01, CPSC-5360-01, Lecture 21 Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2.

04/18/23CPSC-4360-01, CPSC-5360-01,

Lecture 2 52

Reading Suggestions

[Wadhwa, Andrei, Soo; 2007], Chapter 2 [Sommerville; 2008], Chapters 1 and 4 [Priestley; 2004], Chapter 3

Page 53: 4/30/2015CPSC-4360-01, CPSC-5360-01, Lecture 21 Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2.

04/18/23CPSC-4360-01, CPSC-5360-01,

Lecture 2 53

Coming up next

Use Case Modeling, Domain Modeling: [Wadhwa, Andrei, Soo; 2007], Chapters 2 and 3 [Priestley; 2004], Chapter 4

Page 54: 4/30/2015CPSC-4360-01, CPSC-5360-01, Lecture 21 Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 2.

04/18/23CPSC-4360-01, CPSC-5360-01,

Lecture 2 54

Thank you for your attention!

Questions?