CSC310 Lecture 04

Process Models
(20260904)

Transcript

1. CSC 3100 Software Engineering Lecture 04. Process Models Dr. Javier Gonzalez-Sanchez javiergs@calpoly.edu www.javiergs.info ffi o ce: 14 -227
2. Software Engineering “The pplic tion of system tic, disciplined, qu nti i ble ppro ch (process) to the development, oper tion, nd m inten nce of softw re.” a a a a a a f a a a a a a 2 a – IEEE
3. Process Process Activity Task Step 3
4. Activities Deployment Softw Testing a a 4 a Coding, Progr Developing [+] Requirement Engineering Softw Design
5. Activities 5
6. Activities How to connect the activities? 6
7. • Pl n-driven, ll process ctivities re pl nned in dv nce, nd progress is me sured g inst pl n ( contr ct). a a a a a a a a a f a a a a a a a 7 a • Agile pl nning is increment l, nd it is e sier to ch nge the process to re lect ch nging customer requirements. • a a a a Strategies
8. Strategies 8
9. Agile Methods
10. Agile (SCRUM) in a Nutshell 10
11. Agile in a Nutshell 11
12. Agile in Action 12
13. Team • Te m makes decisions • Motiv ted Individu ls. • With Self-Org nizing C p bilities. • Technic lly competent • Te m is measured constantly. a a a a a a a a 13
14. Agile Manifesto Agile Manifesto 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 n Working software 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. 14 The 12 Principles of Agile
15. The 12 Principles of Agile Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Working software is the primary measure of progress. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Continuous attention to technical excellence and good design enhances agility. Business people and developers must work together daily throughout the project. Simplicity – the art of maximizing the amount of work not done – is essential. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The best architectures, requirements, and designs emerge from self-organizing teams. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
16. Business people and developers must work together daily throughout the project. Simplicity – the art of maximizing the amount of work not done – is essential. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The best architectures, requirements, and designs emerge from self-organizing teams. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Agile Manifesto Advancing the principles of Agile Learn more at AgileAlliance.org THE MANIFESTO AUTHORS 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. 16
17. Applicability • Product development is where product for s le. softw re comp ny develops sm ll or medium-sized • Now d ys, sever l softw re products nd pps re sm ll or medium-sized; therefore, they re developed using n gile ppro ch. a a a a a a a a a a a a a a a ff a a a a a a a a a a a a a a a 17 a • Custom system development within n org niz tion where the customer cle rly commits to becoming involved in the development process nd where there re few extern l rules nd regul tions th t ect the softw re.
18. Pros • The product is broken down into set of m n ge ble nd underst nd ble chunks. • Unst ble requirements do not hold up progress. • The whole te m h s visibility of everything, nd consequently, te m communic tion is improved. a a a a a a a a a a a a a a a 18 a • Customers see on-time delivery of increments nd g in feedb ck on how the product works.
19. Cons • The inform lity of gile development is incomp tible with the leg l ppro ch to contr ct de inition (requirement speci ic tion) th t is commonly used in l rge comp nies. • Agile methods re most ppropri te for new softw re development r ther th n softw re m inten nce (document tion). Yet the m jority of softw re costs in l rge comp nies come from m int ining their existing softw re systems. a a a a a a a a a a a a a a a a a a f a a a a a a a a a a f a a a a a 19 a • Agile methods re designed for sm ll co-loc ted te ms, yet much softw re development now involves worldwide distributed te ms.
20. The 12 Principles of Agile Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Working software is the primary measure of progress. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Continuous attention to technical excellence and good design enhances agility. Business people and developers must work together daily throughout the project. Simplicity – the art of maximizing the amount of work not done – is essential. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The best architectures, requirements, and designs emerge from self-organizing teams. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
21. Business people and developers must work together daily throughout the project. Simplicity – the art of maximizing the amount of work not done – is essential. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The best architectures, requirements, and designs emerge from self-organizing teams. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Agile Manifesto Advancing the principles of Agile Learn more at AgileAlliance.org THE MANIFESTO AUTHORS 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. 21
22. Plan-based Process
23. The Waterfall Model 23
24. The Waterfall Model • Key ide : Sep r te nd distinct ph ses of speci ic tion nd development. A ph se h s to be completed before moving on to the next ph se. • Type: Line r model. • Recommended for: Embedded systems nd L rge systems(developed by sever l p rtner comp nies) a a a a a a a a a f a a a a a ff a a a a a a a a a 24 a • Dis dv nt ge: the di iculty of ccommod ting ch nge fter the process is underw y.
25. The V-Model this arrows point at what we are testing 25
26. • Key ide : It is n extension of W terf ll where inste d of moving down in line r w y, the process steps re bent upw rds fter the coding ph se. While the test is just one of ive steps in W terf ll, it looks like pr ctic lly h lf of the process in the V-model. • Type: Line r model. • Recommended for: well-suited for projects th t must m int in strict de dline nd meet key milestone d tes throughout the process. Ex mple: medic l device industry a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a 26 a • Dis dv nt ge: s me s w terf ll a f The V-Model
27. The Spiral Model 27
28. • Key ide : High mount of risk n lysis hence, void nce of Risk is enh nced. • Evolution ry model • Recommended for: (1) Good for l rge nd mission-critic l projects. (2) Strong pprov l nd document tion control. (3) Signi ic nt ch nges re expected (rese rch nd explor tion). • Doesn’t work well for sm ller projects. • Doesn’t work well when users re unsure of their needs a a a a a a a a f a a a a a a a a a a a a 28 a • Doesn’t work well when requirements re complex a a a The Spiral Model
29. Prototyping Quick plan communication Modeling Quick design Deployment delivery & feedback 29 Constructio Construction n of prototype
30. • De inition: A prototype is n initi l version of nd test design options. system used to demonstr te concepts • Evolution ry model a a a a a a a a a a a a 30 f • Recommended for: prototype c n be used to help with requirements elicit tion nd v lid tion; or in design processes to explore options nd develop UI design. a a Prototyping
31. The Incremental Model Option A: Linear Increments (not all colors (activities) are repeated) 31
32. The Incremental Model Option B: Parallel Increments (most than 1 activity at the same time) 32
33. The Incremental Model ▪ Key ide : split e ch ctivity into pieces. ▪ Type: Iter tive model (it could include p r llel). ▪ Recommended for: F cilit te getting customer feedb ck on the development work th t h s been done. a a a f a a a a a a a a a a a ff a a a a a a a a a a 33 a ▪ Dis dv nt ges: (1) it could be not cost-e ective to produce documents th t re lect every version of the system; (2) System structure tends to degr de s new increments re dded. Unless time nd money re spent on ref ctoring to improve the softw re, regul r ch nge tends to corrupt its structure.
34. Questions 34
35. CSC 3100 Software Engineering Javier Gonzalez-Sanchez, Ph.D. javiergs@calpoly.edu Fall 2026 Copyright. These slides may be used only as study material for CSC 5100 within the California State University system. They may not be distributed or used for any other purpose.