1-SoftwareEngineeringandBestPractices

1-SoftwareEngineeringandBestPractices - Software...

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: Software Engineering and Best Practices Sources: Various. Rational Software Corporation slides, OOSE textbook slides, Per Kroll talk, How to Fail with the RUP article, textbooks Most slides have been modified considerably 30 Fundamental Terms / Concepts Science and Engineering Discover Relationships that exist but are not found Formulas; chemical composition, d=r*t; calories in fats, Build carbohydrates, proteins; experimentation; Astrophysics origins of the universe Apply principles of science and mathematics to real Software Engineering; Software Development 30 2 needs, commodities, structures, products, etc. Fundamental Concepts / Terms (2) Software Engineering; Software Development Job positions: Software developer Programmer Software engineer Analyst / Programmer Senior ... what have you... 30 3 What is Software Engineering? The process of solving customers' problems by the systematic development and evolution of large, highquality software systems within cost, time and other constraints Note: 30 Process, systematic (not ad hoc), evolutionary... Constraints: high quality, cost, time, meets user requirements 4 Analysis of the Definition: Systematic development and evolution An engineering process involves applying well understood techniques in a organized and disciplined way Many wellaccepted practices have been formally standardized Most development work is evolutionary e.g. by the IEEE or ISO Large, high quality software systems Software engineering techniques are needed because large systems cannot be completely understood by one person Teamwork and coordination are required Key challenge: Dividing up the work and ensuring that the parts of the system work properly together The endproduct that is produced must be of sufficient quality Finite resources The benefit must outweigh the cost Others are competing to do the job cheaper and faster Inaccurate estimates of cost and time have caused many project failures Cost, time and other constraints 30 5 $250 billion annually in US. Over 175,000 projects! Complexity, size, distribution, importance push our limits. Business pushes these limits: Incredible pressure: develop systems that are: On time, Within budget, Meets the users' requirements Great demands for rapid development and deployment Comments: Figures in the late 90s indicated that at most 70% of projects completed Over 50% ran over twice the intended budget $81 billion dollars spent in cancelled projects!! 30 Getting better, but we need better tools and techniques! 6 What Happens in Practice Sequential activities: (Traditional `Waterfall' Process) Requirements Integration Design Code 100% Integration Test Begins Development Progress (% coded) Risk inadequately addressed Process not receptive to Change Problems not really `seen' until near delivery date! Until then, `all is well...' Big Bang approach full delivery Long development cycles... Little user involvement, etc. etc... Late Design Breakage Original Target Date 30 Project Schedule 7 30 Inaccurate understanding of enduser needs Inability to deal with changing requirements Symptoms of Software Development Problems Modules that don't fit together (integration) Software that's hard to maintain or extend (brittle) Late discovery of serious project flaws (integration) Poor software quality (architecture, risks unanticipated...) Process not responsive to Change (Gantt Charts...) Unacceptable software performance Team members in each other's way, unable to reconstruct who changed what, when, where, why (software architecture, ... ...and we could go on and on... 8 We need a process that Need a Better Hammer! Will serve as a framework for large scale and small projects Adaptive embraces `change!' Iterative (small, incremental `deliverables') Riskdriven (identify / resolve risks up front) Flexible, customizable process (not a burden; adaptive to projects) Architecturecentric (breaks components into `layers' or common areas of responsibility...) Heavy user involvement Opportunity for improvement not identification of failure! Identify best ways of doing things a better process acknowledged by world leaders... 30 9 Best Practices of Software Engineering Develop Iteratively Use Manage Component Requirements Architectures Model Visually Verify Quality Control Changes Know these! 30 10 Addressing Root Causes Eliminates the Symptoms Symptoms end-user needs changing requirements modules don't fit hard to maintain late discovery poor quality poor performance colliding developers Root Causes insufficient requirements ambiguous communications brittle architectures overwhelming complexity undetected inconsistencies poor testing subjective assessment Best Practices develop iteratively manage requirements use component architectures model the software visually verify quality control changes waterfall build-anddevelopment Symptoms of problems can be traced to having Root Causes. release uncontrolled Best Practices are `practices' designed to address the root causes of software problems. 30 11 change insufficient Practice 1: Develop Software Iteratively Develop Iteratively Manage Requirements Use Component Architectures Model Visually Verify Quality Control Changes Considered by many practitioners to be the most significant of the six 30 12 Practice 1: Develop Software Iteratively Until recently, developed under assumption most requirements can be identified up front. The research deconstructing this myth includes work by Capers Jones. (See next slide) In this very large study of 6,700 projects, creeping requirements -- those not anticipated near the start--are a very significant fact of software development life, ranging from around 25% on average projects up to 50% on larger ones. 13 30 Look up a definition of `Function Points.' 30 14 Interestingly, An initial design will likely be flawed with respect to its key requirements. Requirements rarely fully known up front! Latephase discovery of design defects results in costly overruns and/or project cancellation Oftentimes requirements change even during implementation! While large projects are more prone to cost overruns, mediumsize/small projects are vulnerable to cancellation. The key reasons continue to be poor project planning and management, shortage of technical and project management expertise, lack of technology infrastructure, disinterested senior management, and inappropriate project teams." 30 15 Waterfall Delays Risks Walker Royce, 1995 R I S K Requirements Design Code Integration System Test Waterfall risk 30 T I M E 16 Iterative Development Iteration 1 Iteration 2 Iteration 3 Earliest iterations address greatest risks Each iteration produces an executable release Each iteration includes integration, test, and assessment! 30 17 Objective Milestones: short-term focus; short term successes! Accelerate Risk Reduction Walker Royce, 1995 R I S K Risk reduction Iterative Waterfall risk Iteration 30 Iteration Iteration T I M E Iteration Iteration 18 Iterative Development Characteristics Critical risks are resolved before making large investments Initial iterations enable early user feedback Testing and integration are continuous assures successful integration (parts all fit) Objective milestones provide shortterm focus Progress measured by assessing implementations Partial implementations can be deployed Waterfall method no delivery Incremental development? May be some great values in delivering key parts of application. Critical components delivered first? 19 Easy to resolve problems early. Encourages user feedback in meaningful ways Continuous testing. 30 RUP Lifecycle Graph Showing Iterations STUDY THIS!!! In an iteration, you may walk through all disciplines C O N T E N T S T R U C T U R E 30 20 TIME Executable Releases RUP Iterations and Phases Elaboration Construction Transition Inception Preliminary Architect. Architect. Devel. Devel. Devel. Transition Transition Iteration Iteration Iteration Iteration Iteration Iteration Iteration Iteration An iteration is a distinct sequence of activities with an established plan and evaluation criteria, resulting in an `executable release.' (There is a lot of very important `key' terminology used here... (cycle, iteration, phase, milestones, core disciplines, content of iterations, etc....) 30 21 Problems Addressed by Iterative Development Root Causes Solutions Insufficient requirements Ambiguous communications Brittle architectures Overwhelming complexity Subjective assessment Undetected inconsistencies Poor testing Waterfall development Uncontrolled change Insufficient automation Enables and encourages user feedback Serious misunderstandings evident early in the life cycle Development focuses on critical issues break it down! Objective assessment thru testing and assessment Inconsistencies detected early Testing starts earlier continuous Risks identified and addressed early via planned iterations! 22 30 Major impacts on Project Managers, though.... No Free Lunch Traps Abound... Trap: When the initial risks are mitigated, new ones emerge Do not do just the easy stuff, to look good. Keep replanning based on all new information. Trap: Remember `some' Rework enables you to enhance your solution Accommodate change early in the project Trap: Iterative development does not mean never to commit to a solution Monitor `scrap and rework' Trap: Must Control "requirement creep, " however... Some clients will now naturally recognize many `musts...' 30 23 Many Traps in Iterative Development Here is another trap: Too long initial iteration Winning is fun. Winning teams work better than loosing teams Better to have a short initial iteration, than one too long Cut scope if necessary (much more later) Avoid `analysisparalysis' by timeboxing; you can enhance in later iterations (more later) Establish an even rhythm for project (at least w/i a phase) Not completing iterations makes you lose most of the benefit 30 Focus on results and deliverables, not activities 24 Iterations Are Timeboxed Work is undertaken within an iteration. The iteration plan defines the artifacts to be delivered, roles and activities. An iteration is clearly measurable. Iterations are riskdriven Generally, initial iterations based on high risk and core functionalities! 30 25 The Iteration Plan Defines.... The deliverables for that iteration. artifacts The to do list for the team members 30 26 Fixed Plans Produced Upfront Not Real Practical! Yet, senior management wants firm, fixed plans! Part of their culture / upbringing/ experience Necessary for `planning' budgeting, etc. of resources, projects.... BUT: Trap: Finegrained planning from start to end? Takes too much time Frustrating as change occurs (and it will), if plans too finegrained. Know that: Projects typically have some degree of uncertainty This makes detailed plans for the entire project meaningless Does not mean that we should not plan Establish milestones and track progress relative to milestones 30 Problem: 27 Plan With Evolving Levels of Detail Coarse-grained Plan: Software Development Plan One For Entire Project Fine-grained Plans: Iteration Plans Next Iteration Solution: Phases and major milestones What and when Iterations for each Current phase Iteration Number of iterations Iterative Objectives and Development does not mean less work and shorter schedule It is about greater predictability Duration 30 28 Progress is made against MILESTONES Each phase is defined by a milestone. Milestones measure success Phases NOT TIMEBOXED. Progress is made by passing milestones. Iterations ARE TIMEBOXED. Major Milestones 30 Inception Elaboration Construction Transition 29 Summary Much more about iteration and iteration planning later in the course... You will see some of these again and, more importantly, use this information in your own iteration planning. 30 30 ...
View Full Document

Ask a homework question - tutors are online