PROC-1 3. Software Process

PROC-2 What’s a process? Set of activities in creating software It involves creativity –hard to automate –Requires human judgment No one approach to create software –Different organizations and groups within organization do different things

PROC-3 Activities Requirements specification Analysis Design Implementation Testing Maintenance and evolution

PROC-4 Different Approaches Waterfall Spiral Iterative & Incremental Development Agile

PROC-5 Waterfall Model Requirements Analysis Design Implementation &Testing Integration Maintenance

PROC-6 What’s good about Waterfall Easy to plan –(but hard to execute) Easy to explain the progression of the project –(but may not be the reality, however) Help with budgeting and estimating time upfront –(often overrun though)

PROC-7 Problems with Waterfall Sequential steps Not easy to work with Each stage expected to be complete and well done Assumes requirements are well understood –(Are they ever?) Hard to keep up with change –(change is the only constant) Hard to meet users needs

PROC-8 Spiral Model Analysis Requirements Specification Integration Design Implementation & Unit Testing

PROC-9 What’s good about Spiral Recognizes that software applications need to evolve Each version may be one loop though the spiral You have a chance to revisit and modify things that may not be correct or adequate

PROC-10 Problems with Spiral Each cycle may be long – waterfall If each cycle is large, hard to modify system –change may be prohibitive May be expensive If cycles are short, planning may be hard –Project management and reporting will be an issue

PROC-11 Iterative & Incremental Dev. Consider waterfall as a guiding framework, but not execution model Consider spiral as execution model within that guiding framework Planned with versions in mind –incremental Each increment involves many cycles of all the activities, ending with executable application

PROC-12 Iterative & Incremental Dev. Waterfall Spiral Iterative & Incremental Development

PROC-13 Advantages & Disadvantages of IID Provides good opportunity to analyze risk System evolves Coding starts early Integration start sooner May still be ceremonial Iteration may be too long Some companies that claim to be doing IID actually are doing waterfall

PROC-14 Agile Development Process Iterative and evolutionary development Adaptive planning Incremental delivery Agility More focused on success than sticking with a plan Working software is valued and considered measure of progress

PROC-15 Advantages Closely matches user expectations You may modify and evolve as understanding as requirements evolve Functionality stabilizes overtime

PROC-16 Disadvantage Hard to document each step Project management is not easy System may be poorly structure –You may hack your way though Works effectively only for small teams

PROC-17 Where does it work? For small teams Small to medium size projects Not effective on large projects –(large projects are not effective any ways!!) Requires competent team

PROC-18 The Agile Manifesto Individuals and interactions –over process and tools Working Software –over comprehensive documentation Customer collaboration –over contract negotiations Responding to change –over following a plan

PROC-19 The Agile Principles Satisfy Customer through early and continuous delivery of valuable software Welcome changing requirements any time Deliver working software frequently Business people and developers work closely Motivated individuals trusted to do job Face-to-face conversation Working software measure of progress Processes that promote sustainable development Sponsors, developers, users should maintain constant pace indefinitely Attention to technical excellence and good design enhances agility Simplicity is essential Reflect on how to become more effective, and tunes and adjusts behavior accordingly

PROC-20 Agile Modeling UML is for understanding/communication not for documentation Agile modeling is not avoiding modeling Do not apply UML to all or most of software Defer simpler design till programming Use UML for smaller percentage of system where it is required Choose lightweight simpler tools Don’t model alone Look for good enough solution Use design as guidelines – it will be inaccurate when you start Do not expect (or be expected) to design and hand off for coding – developer must be part of designing

PROC-21 Agile Processes Scrum –Self-organizing teams –Daily team measurement –Avoid following predefined steps –Standup meetings, 30 day iteration, demo to stake holders at end of iteration XP –Collaboration –Quick and early software creation –Communication, simplicity, feedback, courage –Constant feedback, test driven development