Presentation Transcript

1. Software Engineering Management Course # CISH-6050 Lecture 6: Software Process Definition and Modeling Convener: Houman Younessi 06/18/2012 1
2. AGENDA SE Processes Rational Unified Process (RUP) Object-oriented Process Environments and Notation (OPEN) Key Process Areas for SW-CMM Level 3: Defined Peer Reviews Education and Training 2
3. AGENDA … Software Process Definition Software Process Models: Waterfall V-Model Spiral Evolutionary, Incremental, Concurrent Prototype, OO RAD Others … 3
4. SW-CMM Level 3 KPAs: Defined Organizational Process Focus Establish organizational responsibility for software process activities that improve org’s overall software process capability Organizational Process Definition: Develop & maintain a usable set of software process assets that improve process performance across projects 4
5. SW-CMM Level 3 KPAs: Defined … Training Program Develop skills and knowledge of individuals so they can perform their roles effectively and efficiently Integrated Software Management: Integrate software engineering and management activities into a coherent, defined software process, tailored from org’s standard software process 5
6. SW-CMM Level 3 KPAs: Defined … Software Product Engineering: Consistently perform a well defined engineering process, integrating all software engineering activities to produce correct products consistently Intergroup Coordination: Means for software engineering group to actively participate with other engineering groups 6
7. SW-CMM Level 3 KPAs: Defined … Peer Reviews: Review defects from the software work products early and efficiently 7
8. Education and Training Fallacies about Education and Training from R. L. Glass Facts and Fallacies of Software Engineering You teach people how to program by showing them how to write programs Shown the “rules” of a programming language & then asked to write code In learning other languages, you learn to read it first; read examples of what skilled writers have written 8
9. Education and Training … Should take a ‘read before writing’ approach to learn how write code To teach code reading, select examples of code to be read – top notch code or flawed code Need text books to support code reading Standard curricula for software academic disciplines updated to teach code reading 9
10. Education and Training … Organizations are likely to expect project members to acquire new knowledge in ad-hoc manner, vs. personal development program Training has cost attached to it, which can be offset with expected benefits Training is investment in org’s major asset: its employees 10
11. Education and Training … Lack of training jeopardizes schedules and product quality Sufficient evidence from failed IS projects to suggest many new & inexperienced project managers struggle to cope with project Orgs stand by & watch project managers (and projects) suffer Net result not good – failed projects and departed resource 11
12. Education and Training … To correct this: Organizations place focus on education and training Support training by providing funding & time for education Offer mentoring or coaching schemes to project managers – both new and inexperienced 12
13. Education and Training … Software Engineering Process Group (SEPG) should serve as focal point for organizational education & training 13
14. Education and Training … Education & training generally needs to be done for a development organization on: Project Management Methods Software Design Methods Quality Management Design and Code Inspections 14
15. Education and Training … SEPG can consult on: Process data to be collected Analysis & interpretation of data Tuning standard process to unique project needs Assisting with quality plans Advising on priority areas for technology insertion Serve as experienced inspection moderators 15
16. Peer Reviews Facts & Fallacies about Reviews & Inspections from R. L. Glass Facts and Fallacies of Software Engineering Fact: Rigorous inspections can remove up to 90% of errors from software before 1st test case is executed Same study shows cost of inspection less than cost of testing to find same error Effective process that is cost effective 16
17. Peer Reviews … So why aren’t given same recognition as other break through methods, such as CASE tools? Few major vendors make money from inspections Nothing new & marketable about inspections Seen as part of back end of the software life cycle Require a lot of mind-intensive hard work 17
18. Peer Reviews … Fact: Despite benefits of rigorous inspections, they can’t/shouldn’t replace testing Inspections can’t remove all errors Error removal is complex task Software construction is complex and error prone No silver bullet with software inspections, so testing is still needed to remove errors in code 18
19. Peer Reviews … Fact: Postdelivery reviews are important for process improvement and determining customer sat, but most orgs don’t do them After project is complete, lessons learned (postdelivery review) should be done to understand problems, root causes, and what can be done to prevent them from happening again Lessons learned tend to be discarded as developers move on to next project 19
20. Peer Reviews … Fact: Peer reviews are both technical and sociological – have to pay attention to both Need to focus on the technical aspect of the review, while being sensitive to the sociological side as well Egoless programming and no personal attacks on the developer Don’t let managers or unprepared participants attend Have roles and responsibilities identified 20
21. Peer Reviews … Fallacy: If enough people look at your code, all bugs are found Research shows that there is a maximum number of useful inspection participants – 2 to 4 No evidence to suggest that this fallacy is true 21
22. Peer Reviews … Software Inspections provide powerful method to improve quality & productivity of software: Find/correct errors earlier in software development cycle 13:1 ROI by some orgs by correcting bugs and reducing rework costs later in cycle Cost factor for fixing bug increases through development cycle: 1x to 200x 22
23. Peer Reviews … Inspection : Find errors at earliest possible point Uncover errors in function, logic, etc. Ensure technically agree on work Verify software meets requirements Ensure software developed per standards Achieve software that is developed in uniform manner Make projects more manageable Provide data on product & inspection process 23
24. Peer Reviews … Not just code inspection, but also inspect: Estimates & sizings Project plans & schedules Requirements document Design documents Unit Test Cases System Test Cases User Acceptance Test Cases 24
25. Peer Reviews … Inspection Principles: Structured, formal process w/ defined roles Generic checklists used for all inspections Tailored checklists for project specific items 3 to 5 people Advance prep needed; no more than 2 hours Duration less than 2 hours Data about inspection recorded & reported Identify problems, not resolve them 25
26. Software Process Definition The software process is documented by a process engineering work product Software Process Definition: Identifies a set of activities needed to develop software and supporting products Identifies activity relationship to each other Typically performed at 2 levels: Generic organization process Project specific process 26
27. Software Process Definition … Each defined activity provides: A description When to start and stop Required inputs What it accomplishes or produces Personnel, methods, practices & tools to be used Cost & schedule estimating mechanisms 27
28. Software Process Definition … Four fundamental process activities common to all software processes: Software Specification – functionality & constraints Software Development – producing software to meet specification Software Validation – verification & validation Software Evolution – evolves to meet changing customer needs 28
29. Software Process Definition … Process Driver Constraints: Organizational Process Drivers Investments (equipment, methods, etc.) Technology & business strategies Infrastructure & culture Government rules & regulations Polices, procedures, & standards 29
30. Software Process Definition … Process Driver Constraints … Project Process Drivers Organizational process definition (or drivers) Project objectives (follow-on work, zero defects, etc.) Project constraints (i.e. customer requirements) Project risks & problem areas 30
31. Software Process Definition … There’s no right or wrong software process for an org to follow Different software processes decompose activities differently Timing of activities may vary as does results Different orgs may use different processes to produce same type of product 31
32. Software Process Definition … There’s no right or wrong software process for an org to follow … Different types of products may be produced by organization using different processes Some processes more suitable than others for some types of application development Chosen process model based on nature of software dev. project & application 32
33. Software Process Models Waterfall Model First presented by Royce in 1970 Simple, transformation-based life cycle model Depicts a sequential execution of principle stages in the development process Also called Linear Sequential or Classic Life Cycle model 33
34. Waterfall Model Operations / Maintenance 34
35. Software Process Models … V-Model Variation of the Waterfall model – Waterfall is “pulled” to a ‘V’ at implementation phase Viewed as several horizontal process layers Each phase, except for implementation, has process checking mechanism Detailed design validated by Unit Test High level design validated by Component Integration Test 35
36. Software Process Models … V-Model … Each layer depicts a level of abstraction and three process partitions, each depicting a class of project activity: Creation Evaluation Operation 36
37. V-Model Operation Evaluation Creation System Req. Analysis Operation & Maintenance 37
38. Software Process Models … Spiral Model First introduced by Boehm in 1988 Views the software process as a series of risk management cycles Based on notion or prototyping As you move away from origin of spiral, levels of expended funding increase Specific activities as you go through each quadrant 38
39. Software Process Models … Spiral Model … Goal: after sufficient number of cycles, product will be accepted Win Win Spiral Set of negotiation activities at the beginning of each pass around spiral Following activities defined: Identification of system stakeholders Determine stakeholder’s win criteria Negotiation of win criteria 39
40. Software Process Models … Evolutionary, Incremental Models Evolutionary Models are iterative: Planned development of multiple releases of product Incremental Models Combines elements of Waterfall model with iterative philosophy of prototyping Each linear sequence delivers increment of the software Activities repeated at each increment 40
41. Software Process Models … Concurrent Model Many activities in progress concurrently for any phase of cycle Uses state charts to represent concurrent relationships existing among activities Driven by user needs, management decisions & review results Can be represented schematically as a series of major technical activities, tasks, & their associated states 41
42. Software Process Models … Prototype Model Customer identifies set of general objectives Detailed requirements not known Create a prototype, which is evaluated by customer Iterations occur as prototype is tuned Focuses on high risk function, performance, and user requirements 42
43. Software Process Models … Object Oriented/Component Based Models Creation of classes that encapsulates both data & algorithms to manipulate data Prescribes software development in terms of synergy between abstraction, modularity, encapsulation, hierarchy, typing, concurrency & persistence Incorporates characteristics of Spiral Model Evolutionary in nature; software reuse 43
44. Software Process Models … Rapid Application Development (RAD) Incremental software development model emphasizing extremely short cycle (60-90 days) High speed adaptation of Waterfall, using component based design If requirements fully understood & project scope constrained, RAD enables dev team to create fully functional system in short period of time 44
45. Software Process Models … Phases encompassed by RAD: Business Modeling – info flow between fctns Data Modeling – business data refined into set of data objects Process Modeling – data objects transformed to information flow Application generation – assumes 4GL used Testing/Turnover – with reuse, many components already tested 45
46. Software Process Models … Embedded Systems: US DoD system life cycle model DoD-Std-2167 describes how embedded systems should be developed Embedded System: electromechanical system governed by one or more computers (i.e. rocket guidance system) Computers in embedded systems perform some of requirements of that system 46
47. Software Process Models … Formal Methods: Encompasses activities leading to formal mathematical specifications of software Enables software engineer to specify, develop, & verify software through rigorous mathematical notation Ambiguity & inconsistency discovered & corrected more easily than ad hoc reviews Concerns: time consuming, extensive training, may be difficult to use w/ customers 47
48. Software Process Models … Cleanroom: Variation of Formal Methods Cleanroom Engineering starts during software process management Each cleanroom has ETVXM: Entry – conditions to satisfy Feedback – input to tasks Task – what, who, how, & when Verification – checking work products Exit – termination requirements Measurement – required task measures 48
49. Software Process Models … 4GT - Fourth Generation Techniques: Encompasses software tools allowing engineer to specify software characteristics at high level Tool automatically generates source code Focuses on ability specify software using specialized language forms or graphics 4GT development environments use non- procedural languages for DB query, report generation, code; high level graphics, spread sheets, automated HTML, etc. 49
50. Software Process Models … 4GT Current State: Using 4GT is viable approach for many application areas Coupled with computer-aided software & code generators, 4GT offers credible sol’n Based on data from companies using 4GT: Reduced time in producing small apps Reduced time for design/analysis for small apps Using 4GT for larger effort requires more analysis, design, & testing to save time 50
51. Lecture 6 Recap: Key Process Areas for SW-CMM Level 3: Defined Peer Reviews Education and Training Software Process Definition Software Process Models 51
52. P. Jalote, Software Project Management in Practice, Addison-Wesley, Boston, MA, 2002 R. L. Glass, Facts and Fallacies of Software Engineering, Addison-Wesley, Boston, MA, 2003 D. Yardley, Successful IT Project Delivery: Learning the Lessons of Project Failure, Addison-Wesley, Boston, MA, 2002 R. S. Pressman, Software Engineering: A Practitioner's Approach, 5th ed., McGraw-Hill, New York, 2001 W. S. Humphrey, Managing the Software Process, Addison-Wesley, Reading, MA, 1989 I. Sommerville, Software Engineering, 5th ed., Addison-Wesley, Reading, MA, 1995 M. Paulk, C. V. Weber, B. Curtis, M. B. Chrissis, The Capability Maturity Model: Guidelines for Improving the Software Process, Addison-Wesley, Boston, MA, 1995 J. Peters, W. Pedrycz, Software Engineering: An Engineering Approach, John Wiley & Sons, Inc., NY, NY, 2000 References 52