Slide 1

Slide 1 text

Dr. Javier Gonzalez-Sanchez [email protected] www.javiergs.info o ffi ce: 14 -227 CSC 307 Introduction to Software Engineering Lecture 02. Process Models

Slide 2

Slide 2 text

Previously

Slide 3

Slide 3 text

Homework

Slide 4

Slide 4 text

Homework

Slide 5

Slide 5 text

Homework

Slide 6

Slide 6 text

Software Process

Slide 7

Slide 7 text

Software Engineering “The a pplic a tion of a system a tic, disciplined, qu a nti f i a ble a ppro a ch (process) to the development, oper a tion, a nd m a inten a nce of softw a re.” – IEEE 7

Slide 8

Slide 8 text

Process 8

Slide 9

Slide 9 text

Activities 9 Deployment Softw Testing Coding, Progr Developing Softw Design Requirement Engineering [+]

Slide 10

Slide 10 text

Activities 10

Slide 11

Slide 11 text

Activities 11

Slide 12

Slide 12 text

Strategies 12 • Pl a n-driven, a ll process a ctivities a re pl a nned in a dv a nce, a nd progress is me a sured a g a inst a pl a n ( a contr a ct). • Agile pl a nning is increment a l, a nd it is e a sier to ch a nge the process to re f lect ch a nging customer requirements. •

Slide 13

Slide 13 text

Strategies 13

Slide 14

Slide 14 text

Plan-based Process

Slide 15

Slide 15 text

The Waterfall Model 15

Slide 16

Slide 16 text

The Waterfall Model • Key ide a : Sep a r a te a nd distinct ph a ses of speci f ic a tion a nd development. A ph a se h a s to be completed before moving on to the next ph a se. • Type: Line a r model. • Recommended for: Embedded systems a nd L a rge systems(developed by sever a l p a rtner comp a nies) • Dis a dv a nt a ge: the di ff iculty of a ccommod a ting ch a nge a fter the process is underw a y. 16

Slide 17

Slide 17 text

The V-Model 17 this arrows point at what we are testing

Slide 18

Slide 18 text

The V-Model • Key ide a : It is a n extension of W a terf a ll where inste a d of moving down in a line a r w a y, the process steps a re bent upw a rds a fter the coding ph a se. While the test is just one of f ive steps in W a terf a ll, it looks like pr a ctic a lly h a lf of the process in the V-model. • Type: Line a r model. • Recommended for: well-suited for projects th a t must m a int a in a strict de a dline a nd meet key milestone d a tes throughout the process. Ex a mple: medic a l device industry • Dis a dv a nt a ge: s a me a s w a terf a ll 18

Slide 19

Slide 19 text

The Spiral Model 19

Slide 20

Slide 20 text

The Spiral Model • Key ide a : High a mount of risk a n a lysis hence, a void a nce of Risk is enh a nced. • Evolution a ry model • Recommended for: (1) Good for l a rge a nd mission-critic a l projects. (2) Strong a pprov a l a nd document a tion control. (3) Signi f ic a nt ch a nges a re expected (rese a rch a nd explor a tion). • Doesn’t work well for sm a ller projects. • Doesn’t work well when users a re unsure of their needs • Doesn’t work well when requirements a re complex 20

Slide 21

Slide 21 text

Prototyping 21 Constructi communicat Qui Modeling Constructi Deploym ent

Slide 22

Slide 22 text

Prototyping • De f inition: A prototype is a n initi a l version of a system used to demonstr a te concepts a nd test design options. • Evolution a ry model • Recommended for: a prototype c a n be used to help with requirements elicit a tion a nd v a lid a tion; or in design processes to explore options a nd develop a UI design. 22

Slide 23

Slide 23 text

The Incremental Model 23 Option A: Linear Increments (not all colors (activities) are repeated)

Slide 24

Slide 24 text

The Incremental Model 24 Option B: Parallel Increments (most than 1 activity at the same time)

Slide 25

Slide 25 text

The Incremental Model ▪ Key ide a : split e a ch a ctivity into pieces. ▪ Type: Iter a tive model (it could include p a r a llel). ▪ Recommended for: F a cilit a te getting customer feedb a ck on the development work th a t h a s been done. ▪ Dis a dv a nt a ges: (1) it could be not cost-e ff ective to produce documents th a t re f lect every version of the system; (2) System structure tends to degr a de a s new increments a re a dded. Unless time a nd money a re spent on ref a ctoring to improve the softw a re, regul a r ch a nge tends to corrupt its structure. 25

Slide 26

Slide 26 text

Agile Methods

Slide 27

Slide 27 text

Agile in a Nutshell 27

Slide 28

Slide 28 text

Agile in Action 28

Slide 29

Slide 29 text

Agile Manifesto 29 Our highest priority is to satisfy the customer Working software is the primary Agile Manifesto The 12 Principles of Agile We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: n Individuals and interactions n Working software n Customer collaboration n Responding to change over processes and tools over comprehensive documentation over contract negotiation over following a plan While there is value in the items on the right, we value the items on the left more.

Slide 30

Slide 30 text

Agile Manifesto 30 Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a devel- opment team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity – the art of maximizing the amount of work not done – is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. The 12 Principles of Agile n Responding to change over following a plan While there is value in the items on the right, we value the items on the left more.

Slide 31

Slide 31 text

Agile Manifesto 31 Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a devel- opment team is face-to-face conversation. Simplicity – the art of maximizing the amount of work not done – is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler Robert C. Martin Steve Mellor Dave Thomas James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Ken Schwaber Jeff Sutherland ©2001-2019 The Agile Manifesto Authors. This declaration may be freely copied in any form, but only in its entirety through this notice. THE MANIFESTO AUTHORS Advancing the principles of Agile Learn more at AgileAlliance.org

Slide 32

Slide 32 text

Applicability • Product development is where a softw a re comp a ny develops a sm a ll or medium-sized product for s a le. • Now a d a ys, sever a l softw a re products a nd a pps a re sm a ll or medium-sized; therefore, they a re developed using a n a gile a ppro a ch. • Custom system development within a n org a niz a tion where the customer cle a rly commits to becoming involved in the development process a nd where there a re few extern a l rules a nd regul a tions th a t aff ect the softw a re. 32

Slide 33

Slide 33 text

Pros • The product is broken down into a set of m a n a ge a ble a nd underst a nd a ble chunks. • Unst a ble requirements do not hold up progress. • The whole te a m h a s visibility of everything, a nd consequently, te a m communic a tion is improved. • Customers see on-time delivery of increments a nd g a in feedb a ck on how the product works. 33

Slide 34

Slide 34 text

Cons • The inform a lity of a gile development is incomp a tible with the leg a l a ppro a ch to contr a ct de f inition (requirement speci f ic a tion) th a t is commonly used in l a rge comp a nies. • Agile methods a re most a ppropri a te for new softw a re development r a ther th a n softw a re m a inten a nce (document a tion). Yet the m a jority of softw a re costs in l a rge comp a nies come from m a int a ining their existing softw a re systems. • Agile methods a re designed for sm a ll co-loc a ted te a ms, yet much softw a re development now involves worldwide distributed te a ms. 34

Slide 35

Slide 35 text

Questions 35

Slide 36

Slide 36 text

Lab 02. Getting Started with Java Swing (Part II)

Slide 37

Slide 37 text

Previously

Slide 38

Slide 38 text

Paint App 38

Slide 39

Slide 39 text

No content

Slide 40

Slide 40 text

No content

Slide 41

Slide 41 text

No content

Slide 42

Slide 42 text

No content

Slide 43

Slide 43 text

Next

Slide 44

Slide 44 text

Paint App 44

Slide 45

Slide 45 text

class TheNanny implements ActionListener { public void actionPerformed (ActionEvent e) { } }

Slide 46

Slide 46 text

Paint App 46

Slide 47

Slide 47 text

class MyVeryOwnCenterPanel extends JPanel { public void paintComponent (Graphics g) { } }

Slide 48

Slide 48 text

class TheMouseNanny implements MouseListener { public void mousePressed (MouseEvent e) { } public void mouseClicked(MouseEvent e) { } public void mouseReleased(MouseEvent e) { } public void mouseEntered(MouseEvent e) { } public void mouseExited(MouseEvent e) { } public void mouseDragged(MouseEvent me) { } public void mouseMoved(MouseEvent e) { } }

Slide 49

Slide 49 text

// MouseListener public void mousePressed (MouseEvent e) {} public void mouseClicked(MouseEvent e) { } public void mouseReleased(MouseEvent e) { } public void mouseEntered(MouseEvent e) { } public void mouseExited(MouseEvent e) { } public void mouseDragged(MouseEvent me) { } public void mouseMoved(MouseEvent e) { } // MouseMotionListener public void mouseDragged(MouseEvent me) { } public void mouseMoved(MouseEvent e) { }

Slide 50

Slide 50 text

Paint App 50

Slide 51

Slide 51 text

Homework How to pass information from a class (object) to another?

Slide 52

Slide 52 text

To be continued…

Slide 53

Slide 53 text

CSC 307 Introduction to Software Engineering Javier Gonzalez-Sanchez, Ph.D. [email protected] Summer 2024 Copyright. These slides can only be used as study material for the class CSC307 at Cal Poly. They cannot be distributed or used for another purpose.