If Given No Direction on Process

1. If Given No Direction on Process • We start where many of us are “most comfortable” - programming and low level design • Most small establishments also focus on programming and low level design first Low Level Design & Code Requirements & Architecture Testing & Integration past class inputs : “many people are entering the software environment via contacts with IS/IT or other support groups; thus the support processmay also be a starting point.”

2. Coding Low level Design Code Compile Unit Test Debug works ? “done!” For most of us --- this is what we are “most used to”

3. Software Development Process • What is a Process ?: • a set oforderedtasksaimed at achieving some end goals • What is a Software Development Process: • a set of ordered tasks aimed at producing software solutions ---- the tasks include: • requirements understanding, specification, and agreement of problem • architecture and design of the solution • construction and programming of the solution • testing of the solution • integration of the solution • installation and deployment of the solution • supporting, fixing, and evolving the solution • Note: Each of these tasks may itself be a Sub-Process containing orderedsubtasks

4. Why Have a Process at all? • Large Software development requires a group of people - coordination of activities is key • Process imposes a set of structure and consistency: • forms a common understanding of the ordered tasks, constraints, and needed resources • allows the detection of any omission and of problems in the development of solution • clarifies the goals of the software solutions via emphasizing and modifying the process (e.g. introducing review for quality) • allows the tailoring and improvement for development of different types of software. • Defined process allows us to capture our experiencesand then reuse, improve, and/or pass it on to others

5. Some Key Process Models • Major models: • Waterfall • V-model • Prototyping • Phased Model (Incremental and Iterative) • Spiral • Agile (e.g. X-treme programming) • Minor ones (rarely talked about in industry, now) : • Operational : (nail down the requirements and combine with design/code - almost like prototyping) • Transformational : (“formal” evaluation of the actual transformations from one phase to another phase)

6. Waterfall Process • The most familiar and modeled after hardware and manufacturing process • This process with each stage not starting until the previous one is completed was attractive: • easy to track for management • deliverables are well defined • There are some serious drawbacks: • the actual “testing” of the code comes very late in the process • customer interaction did not happen except at the requirements phase • “real” development stages are not that crisp in that more interaction and iteration is required because software development is not manufacturing except at the packaging and copying stage Requirements Design Program & Unit Test (Spec.) Test Integrate & System Test (Spec.) (Code) Package & Release (Spec.& test result) (System) (System)

7. V-Model • This is similar to the Waterfall Model except the association of different testing (test case design) phases are aligned with the requirements, design, and code phases for error corrections. Test Case Design System Test & Packaging Requirements Design Test Case Design Integration & Functional Test Code Unit Test

8. Prototyping Model • Allows better understanding and revisions of the users’ requirements, especially UI. • Allows better explorations of feasibility of unknown areas. • Usually coupled with waterfall or any other processes. Requirements Design Integrate System changes changes Prototype Prototype Prototype

9. Phased Development Model • Many reasons to develop the solution in phases: • Delivering some partfast and early • Getting reactions earlyand being able to adjust • Some early trainingand familiarization of users • Allows the staggering of & reuse of skills and technology • There are 2 major approaches: • Incremental : breaking the requirements into separate vertical application parts ; develop and deliver the parts as fully functional application subsystems. • Iterative:break the system into separately designed horizontal cross application parts (applications with simple screens with little error recovery, enhanced error messages and context sensitive help, enhanced performance and speed, etc..); develop and deliver the various parts as complete, cross application components Things are never very clean

10. How would we develop Incrementally & Iteratively? “Vertical” App Component Design F1 F2 Fn . . . . User Int / levels of GUI “Horizontal” Common Function Design Help/Error Messages “Reprocess” Mechanism Import/Export data sharing mechanism installation mechanism

11. Spiral Model • Introduced by Barry Boehm at TRW to combine development process with “enhanced” risk management. • There are four major aspects : • planning • setting goals and looking at alternatives • evaluate the alternatives and the risks • develop and test (perform the task) • Each of development phases such as requirements, design, etc. goes through the four aspects. Setting goal & alternatives Prototype alternatives & analyze risks Design Develop & Test (perform the task) Plan

12. Agile Processes • There are several “agile” processes: • Extreme Programming –XP • Crystal • SCRUM • Adaptive Software Development • Some commonalitiesamong theAgile processes: • Develop in small increments • Frequent “delivery” of the increments • Small teams of people • Focus on customer collaboration, rather than legal contracts • Value human and human interaction more than documentation and process/tools • Accommodate changes, rather than excessive front end planning and follow the plan rigidly --- believe in “changes” A lot like the earlier “phased incremental & iterative process”

13. Extreme Programming (XP) • A Programmingpractice or set of principles originated by Kent Beck in the mid-90’s. • Based on the concept of quick and constant“Feedback Mechanism”involving: • Planning Game (Small Units of Requirements) • Onsite Customer (Immediate and better feedback) • Metaphor (Use one set of metaphor for design/architecture) • Simple Design (Just enough to cover what’s needed) • Collective Code Ownership (Peer pressure to improve code) • Pair Programming (Feedback and shared improvements) • Coding Standard (Facilitates better communication) • Refactoring (Continuous examination for code improvement) • Continuous Functional and Unit Testing (100% completion of test) • Continuous Integration (integrating small functional “releases”) • 40 hour work (high morale and energy level) some recognition of “human” aspects

14. Extreme Programming “Process” Onsite Customers Coding standards Simple Design Planning Game (requirements) Pair Programming Functional &Unit Test Small Releases System Metaphors Continuous Integration Refactoring Collective Code Ownership Larger Release Adhere to 40 hour work week as much as possible !

15. A Note for Your Project Assignment • Reminder: 2nd part of your semester project WILL be a “team project” • So ---- think about agreeing on a process modeled after one of these “macro-processes” --- see earlier slide #4 on why process is needed. Do you need to think about process this early in the game? ---- What do you say?

16. Process Plays an Important Role in Software Engineering • Process Modeling and Studying • building static models to depict understand the process model • building dynamic models to run and predict outcomes of process model • Process improvements and enforcement • ISO 9000 • CMM and CMMI Process “modeling,” although a good idea, is very difficult due to the great variability in human behavior ---- so far it has not been done very successful.

17. Studying Process or Sub-Process Pre- conditions Post- conditions Process or Sub-process Description Outputs Inputs Measurements of Success: - schedule reduction - cost reduction - improved quality - etc. Difficult to show

18. How Do We Describe the Process • Pre and Post conditions : how much do we specify (people skills, tools readiness, previous process completion status, etc.) • Input : all the inputs and to what degree • Outputs : all the outputs and to what degree • Process Description : how detailed ; how should it be represented (graphical, textual, etc.) • Should all these descriptions be static descriptions or dynamic and possibly “executable ?” (Leon Osterweil’s proposal in late 1980’s) • Don’t Worry about the Lai notation (Static model) & other process modeling discussions towards the end of Chapter 2

19. Some “Desirable Properties” of Process Descriptions • Facilitates the communication of and the understanding of the process. (check your book and my lecture notes --- communicated “deep” enough?) • Allows reuse of all or parts of the process • allows improvements and adjustments • Allows the managementof process • provides metrics and measurements on the process • Provides more than just description • give some guidance on how to execute the process • deep enough to automate parts of or all of the process

20. Top 2 Industry Process “standards” • ISO 9000 • Very Document Oriented • Popular in Europe and among Manufacturing industry • Popular in the early 90’s • CMM/CMMI • CMM Has 5 levels of maturity, each level addresses a set of “Key” processes - except for level 1 • For continuous improvements • Start to gain popularity among service companies Agile’s --- SCRUM is the currently “popular” process