Software lifecycle

CS351 - Software Engineering (AY2007)Slide 2 Reading Chapters 1 – 4 of Pressman. Chapter 1 covers some background regarding the nature of software. Chapter 2 covers some generic process methods Chapter 3 is the primary focus of this lecture discussion. Chapter 4 looks at Agile Programming – the latest approach to software process/development.

CS351 - Software Engineering (AY2007)Slide 3 Nature of Software Software is a complex component within a complex system. Often constraints (cost, performance, hardware, time, legacy systems) dictate how the software is to be developed. As software engineers we are relied upon to: –Analyze a clients needs. –Design an appropriate solution within cost and time constraints. –Build a safe, reliable, efficient, extensible solution. –Test and fine-tune the software prior to delivery. –Maintain the software after it goes into production. In many cases the software we develop may need to interact with other (third-party) software or legacy systems.

CS351 - Software Engineering (AY2007)Slide 4 Software lifecycle Requirements Analysis Design & Specification Coding & Module Testing Integration & System Testing Delivery & Maintenance 50-70% 10-20% 10% 10-20%

CS351 - Software Engineering (AY2007)Slide 5 Software lifecycle “student view” Design & Specification Coding Testing (optional) Hand it in >90% <10%

CS351 - Software Engineering (AY2007)Slide 6 Comments The “student lifecycle model” clearly has many limitations: –It doesn’t always earn you the grades you want. –It doesn’t scale. –You have little assurance of quality – somewhat of an issue for paying customers! –It isn’t consistent. We need a better model, a better process to follow, to give us a chance of delivering quality code in a timely manner.

CS351 - Software Engineering (AY2007)Slide 7 Software production process models Ad–hoc approach: “Code and Fix” –intuitive “model” –undesirable even for small tasks –impossible for large tasks Many formal process models exist –Waterfall Model –Spiral Model –Prototyping/Evolutionary Model Build first version Modify until Client is satisfied Operations mode Retirement Development Maintenance

CS351 - Software Engineering (AY2007)Slide 8 Waterfall model – overview A process model addresses these questions: –What shall we do next? –How long shall we continue to do it? A framework for software development methodology Clearly identifies –Deliverables –Standards Waterfall model provides a sequential, linear flow between phases

CS351 - Software Engineering (AY2007)Slide 9 Minimal waterfall model Analysis Design Code Testing Maintenance

CS351 - Software Engineering (AY2007)Slide 10 Waterfall model – requirements stages Feasibility study –Cost/benefit analysis –Needs understanding of problem –Deliverable - a feasibility study document Costs alternative solutions Requirements –Analysis Functionality etc of software –Specification document “Contract” between customer and software engineers Complete, precise, modifiable Specifies –Functional requirements –Non-functional requirements –Development and maintenance procedures

CS351 - Software Engineering (AY2007)Slide 11 Waterfall model – final stages Design and specification –Modules Preliminary and detailed design –Deliverable - design specification document –Standards Coding and module testing –Deliverable - tested modules –Standards for coding and testing, quality control Integration and system testing –Delivers running application - alpha tested within organization

CS351 - Software Engineering (AY2007)Slide 12 Waterfall model – final stages Delivery and maintenance –Beta testing then product delivery –Maintenance Problems –Time between requirements and maintenance phases –Integrating changes into correct phases

CS351 - Software Engineering (AY2007)Slide 13 Detailed waterfall model Requirements Verify Specification Verify Planning Verify Design Verify Implementation Test Integration Test Operations Mode Retirement Changed Requirements Verify Development Maintenance

CS351 - Software Engineering (AY2007)Slide 14 Waterfall model – example/analysis Documentation, verification and management –“Document driven" –Quality control: reviews, walk-throughs and inspections –Management: methodology, configuration and personnel Analysis –Linear, rigid, monolithic –Disciplined –Disadvantages Commitments too early Rigidity and linearity make feedback difficult Change often achieved as a "fix": distorts maintenance phase Somewhat bureaucratic

CS351 - Software Engineering (AY2007)Slide 15 Waterfall model - reality Requirements analysis System design Program design Program implementation Unit testing Integration testing System testing Delivery Maintenance

CS351 - Software Engineering (AY2007)Slide 16 Rapid prototyping model Rapid Prototyping Verify Specification Verify Planning Verify Design Verify Implementation Test Integration Test Operations Mode Retirement Changed Requirements Verify Development Maintenance

CS351 - Software Engineering (AY2007)Slide 17 Evolutionary model Requirements Verify Specification Verify Planning Verify Architectural design Verify For each build: perform detailed design, implementation and integration. Test. Deliver to client Operations Mode Retirement Development Maintenance

CS351 - Software Engineering (AY2007)Slide 18 Evolutionary model Incremental development to –Deliver partial functionality early (non-monolithic) –Provide feedback on requirements May be associated with incremental delivery –Delivered increment is a product –User provides feedback for design of next increment Approach may be combined with waterfall model –During implementation phases Requirements document identifies subsets Allowance for later change –At all stages Finer grained application of waterfall model to each increment

CS351 - Software Engineering (AY2007)Slide 19 Evolutionary model – prototyping Prototyping –“Throw-away” Build system once - as basis for understanding requirements Discard and rebuild –Build-upon Iterative process –Decide objectives of prototype –Plan, build and document prototype –Evaluate prototype Eventually refine into a completed system Provides feedback on requirements and functionality Facilitates understanding of requirements and interfaces Flexible Inherently less disciplined - needs careful management

CS351 - Software Engineering (AY2007)Slide 20 Evolutionary model – prototyping SpecificationDesign Implementation & Integration Deliver to client SpecificationDesign Implementation & Integration Deliver to client SpecificationDesign Implementation & Integration Deliver to client Build 1 Build n Build 3 Build 2 Specification team Design team Implementation/integration team SpecificationDesign Implementation & Integration Deliver to client

CS351 - Software Engineering (AY2007)Slide 21 Spiral model Verify Risk analysis Risk analysis Risk analysis Risk analysis Risk analysis R.A. Rapid prototype Specification Implementation Design Planning Integration

CS351 - Software Engineering (AY2007)Slide 22 Spiral model A meta–model really –Any of the other process models can be used with it Cyclic, not linear Attempts to identify risks Usually coupled with prototyping Each “turn” around the spiral resolves more risks and (possibly) yields a prototype

CS351 - Software Engineering (AY2007)Slide 23 Spiral model – prototyping

CS351 - Software Engineering (AY2007)Slide 24 Agile Development Agile software development (i.e., Extreme Programming) combines a philosophy and a set of development guidelines. Encourages customer satisfaction and involvement through active and continuous involvement. Early incremental delivery of software to solicit customer feedback. Small, highly motivated project teams using informal methods and minimal software engineering work products. Strive for overall development simplicity. Stress delivery over analysis and design Agile development has its supporters and its detractors.

CS351 - Software Engineering (AY2007)Slide 25 Agile Development Agile team members should have the following characteristics: –Competence –Common focus –Collaboration –Decision-making ability –Fuzzy problem-solving ability (ability to deal with ambiguity) –Mutual trust and respect –Self-organization Examples of agile development include: –Extreme Programming (XP) –Adaptive Software Development (ASD) –Dynamic Systems Development Method (DSDM) –Scrum –Crystal –Feature Driven Development (FDD) –Agile Modeling (AM)

CS351 - Software Engineering (AY2007)Slide 26 Is it worth it? Estimates for a 200,000 line data processing product: CMMDurationEffortFaults detectedFaults deliveredTotal cost Level(months)(personduring to clientof months)developmentand installeddevelopment Level $5,440,000 Level $1,311,000 Level $728,000 Level $392,000 Level $146,000 CMM = Capability Maturity Model CMM is a measure of an organizations ability to follow a process and refine it to suit that organization’s activities. It is covered in more detail in CS451.

CS351 - Software Engineering (AY2007)Slide 27 Observations We need to understand the software development lifecycle and have a process in place to help us deliver software on-time and within budget. Error rates and cost of development decrease the more we understand the software process. While discussion on requirements gathering etc is deferred until CS451, we can certainly do a great deal to improve our own software by understanding what we do when we build software systems. As individuals, we most likely follow one of the lifecycle models described earlier – or a hybrid of one or more of the models. We may skip some steps, we may not pay sufficient attention to some aspects.

CS351 - Software Engineering (AY2007)Slide 28 Our behavior A better understanding of our personal behavior will help us fit into a team environment better, and will help us deliver higher quality code. To understand what we do, we must objectively assess what we do. –This is difficult as we first have to overcome our belief that we are doing everything correctly. –We have to examine what we do and constantly ask “how can I improve?” –We have to measure what we do in order to know if the changes we make are working, and to identify those aspects of our behavior that require change.

CS351 - Software Engineering (AY2007)Slide 29 Journal In this course, we require you to keep a journal. A journal is where you record all of your thoughts, design your algorithms, plan the testing strategy for these algorithms, make notes on the performance of your code, make notes on the kinds of errors you make, record how you intend to rectify these deficiencies, … You record everything related to software development. You should throw nothing away. Ideally, the journal is a bound book with numbered pages. At regular intervals (every month), you should read through your journal and look for trends, look for errors you regularly make, look for things you don’t understand. Once identified, plan a strategy to deal with these issues – record the plan in the journal and stick to it.

CS351 - Software Engineering (AY2007)Slide 30 Summary This course focuses on your personal ability to produce high quality software. You should make observations in your journal of errors you make including: –Not fully understanding the requirements –Poor testing –Typical coding errors –Poorly designed interfaces –Integration issues These are all aspects of the software lifecycle If we can get things right as an individual, we have a better chance of getting things right in a team.