CSC307 Lecture 02

Introduction to Software Engineering
Process Models
(202406)

In today's class, we explored various software process models, starting with plan-based approaches: the waterfall model (linear and sequential), the V-model (emphasizing testing stages), the prototyping model (iterative with early user feedback), and the spiral model (iterative with risk management). We then introduced the global ideas behind Agile methodologies and contrasted them with plan-based models, highlighting flexibility, iterative progress, and customer collaboration.

Transcript

1. Dr. Javier Gonzalez-Sanchez javiergs@calpoly.edu www.javiergs.info o ffi ce: 14 -227 CSC 307 Introduction to Software Engineering Lecture 02. Process Models
2. Previously
3. Homework
4. Homework
5. Homework
6. Software Process
7. 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
8. Process 8
9. Activities 9 Deployment Softw Testing Coding, Progr Developing Softw Design Requirement Engineering [+]
10. Activities 10
11. Activities 11
12. 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. •
13. Strategies 13
14. Plan-based Process
15. The Waterfall Model 15
16. 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
17. The V-Model 17 this arrows point at what we are testing
18. 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
19. The Spiral Model 19
20. 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
21. Prototyping 21 Constructi communicat Qui Modeling Constructi Deploym ent
22. 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
23. The Incremental Model 23 Option A: Linear Increments (not all colors (activities) are repeated)
24. The Incremental Model 24 Option B: Parallel Increments (most than 1 activity at the same time)
25. 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
26. Agile Methods
27. Agile in a Nutshell 27
28. Agile in Action 28
29. 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.
30. 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.
31. 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
32. 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
33. 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
34. 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
35. Questions 35
36. Lab 02. Getting Started with Java Swing (Part II)
37. Previously
38. Paint App 38
43. Next
44. Paint App 44
45. class TheNanny implements ActionListener { public void actionPerformed (ActionEvent e) { } }
46. Paint App 46
47. class MyVeryOwnCenterPanel extends JPanel { public void paintComponent (Graphics g) { } }
48. 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) { } }
49. // 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) { }
50. Paint App 50
51. Homework How to pass information from a class (object) to another?
52. To be continued…
53. CSC 307 Introduction to Software Engineering Javier Gonzalez-Sanchez, Ph.D. javiergs@calpoly.edu 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.