Downloaded 22 times
Uploaded by3Quill Softwares
Best Practices - Software Engineering
The document discusses the principles and practices of software engineering, emphasizing systematic development, the need for high-quality software systems, and managing constraints such as cost and time. It highlights the importance of iterative development for addressing risks early, fostering user feedback, and maintaining flexibility to adapt to changing requirements. Additionally, it identifies common issues found in traditional methods like the waterfall model and promotes better practices to enhance project outcomes.
More Related Content
![[CVPR2022, LongVersion] Online Continual Learning on a Contaminated Data Stre...](https://cdn.slidesharecdn.com/ss_thumbnails/cvpr2022puridiverlongversion-220412040601-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to Best Practices - Software Engineering
Best Practices - Software Engineering
- 1. 3030 Software EngineeringSoftware Engineering andand BestPracticesBest Practices Sources: Various.Sources: Various. Rational Software Corporation slides,Rational Software Corporation slides, OOSE textbook slides, Per Kroll talk, How to Fail withOOSE textbook slides, Per Kroll talk, How to Fail with the RUP article, textbooksthe RUP article, textbooks Most slides have been modified considerablyMost slides have been modified considerably
- 2. 30 2 Fundamental Terms/ ConceptsFundamental Terms / Concepts ►Science and EngineeringScience and Engineering DiscoverDiscover ►Relationships that exist but are not foundRelationships that exist but are not found ►Formulas; chemical composition, d=r*t; calories in fats,Formulas; chemical composition, d=r*t; calories in fats, carbohydrates, proteins; experimentation;carbohydrates, proteins; experimentation; ►Astrophysics – origins of the universeAstrophysics – origins of the universe BuildBuild ►Apply principles of science and mathematics to realApply principles of science and mathematics to real needs, commodities, structures, products, etc.needs, commodities, structures, products, etc. ►Software Engineering; Software DevelopmentSoftware Engineering; Software Development
- 3. 30 3 Fundamental Concepts/ Terms (2)Fundamental Concepts / Terms (2) ►Software Engineering; Software DevelopmentSoftware Engineering; Software Development ►Job positions:Job positions: Software developerSoftware developer ProgrammerProgrammer Software engineerSoftware engineer Analyst / ProgrammerAnalyst / Programmer Senior … what have you…Senior … what have you…
- 4. 30 4 What isSoftware Engineering?What is Software Engineering? ►The process of solving customers’ problemsThe process of solving customers’ problems by the systematic development and evolutionby the systematic development and evolution of large, high-quality software systems withinof large, high-quality software systems within cost, time and other constraintscost, time and other constraints ►Note:Note: Process, systematic (not ad hoc), evolutionary…Process, systematic (not ad hoc), evolutionary… Constraints: high quality, cost, time, meets userConstraints: high quality, cost, time, meets user requirementsrequirements
- 5. 30 5 Analysis ofthe Definition:Analysis of the Definition: ► Systematic development and evolutionSystematic development and evolution An engineering process involves applyingAn engineering process involves applying well understood techniqueswell understood techniques in ain a organizedorganized andand disciplineddisciplined wayway ManyMany well-accepted practices have been formally standardizedwell-accepted practices have been formally standardized ► e.g. by the IEEE or ISOe.g. by the IEEE or ISO Most development work isMost development work is evolutionaryevolutionary ► Large, high quality software systemsLarge, high quality software systems Software engineering techniques are needed because large systemsSoftware engineering techniques are needed because large systems cannot becannot be completely understoodcompletely understood by one personby one person TeamworkTeamwork and co-ordination are requiredand co-ordination are required Key challenge: Dividing up the work and ensuring that the parts of the systemKey challenge: Dividing up the work and ensuring that the parts of the system work properly togetherwork properly together The end-product that is produced must be of sufficient qualityThe end-product that is produced must be of sufficient quality ► Cost, time and other constraintsCost, time and other constraints Finite resourcesFinite resources The benefit must outweigh the costThe benefit must outweigh the cost Others are competing to do the job cheaper and fasterOthers are competing to do the job cheaper and faster Inaccurate estimates of cost and time have caused many project failuresInaccurate estimates of cost and time have caused many project failures
- 6. 30 6 Comments:Comments: ► $250billion annually in US.$250 billion annually in US. ► Over 175,000 projects!Over 175,000 projects! ► Complexity, size, distribution, importance push ourComplexity, size, distribution, importance push our limits.limits. ► Business pushes these limits:Business pushes these limits: Great demands forGreat demands for rapid development and deploymentrapid development and deployment ► Incredible pressure: develop systems that are:Incredible pressure: develop systems that are: On time,On time, Within budget,Within budget, Meets the users’ requirementsMeets the users’ requirements ► Figures in the late 90s indicated that at mostFigures in the late 90s indicated that at most 70% of projects completed70% of projects completed Over 50% ran over twice the intended budgetOver 50% ran over twice the intended budget $81 billion dollars spent in cancelled projects!!$81 billion dollars spent in cancelled projects!! ► Getting better, but we need better tools andGetting better, but we need better tools and techniques!techniques!
- 7. 30 7 What Happensin PracticeWhat Happens in Practice Sequential activities: (Traditional ‘Waterfall’ Process) Requirements Design Code Integration Test Late Design Breakage 100% Project Schedule DevelopmentProgress (%coded) Original Target Date Integration Begins 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…
- 8. 30 8 Symptoms ofSoftwareSymptoms of Software Development ProblemsDevelopment Problems ► Inaccurate understandingInaccurate understanding of end-user needsof end-user needs ► Inability to deal withInability to deal with changing requirementschanging requirements ► Modules that don’t fit together (integration)Modules that don’t fit together (integration) ► Software that’s hard to maintain or extend (brittle)Software that’s hard to maintain or extend (brittle) ► Late discovery ofLate discovery of serious project flawsserious project flaws (integration)(integration) ► Poor software qualityPoor software quality (architecture, risks unanticipated…)(architecture, risks unanticipated…) ► ProcessProcess not responsive to Change (Gantt Charts…)not responsive to Change (Gantt Charts…) ► Unacceptable software performanceUnacceptable software performance ► Team members in each other’s way, unable to reconstruct whoTeam members in each other’s way, unable to reconstruct who changed what, when, where, why (software architecture, …changed what, when, where, why (software architecture, … ► ……and we could go on and on…and we could go on and on…
- 9. 30 9 ► Weneed aWe need a processprocess thatthat Will serve as a framework for large scale and smallWill serve as a framework for large scale and small projectsprojects Adaptive – embraces ‘change!’Adaptive – embraces ‘change!’ ► Opportunity forOpportunity for improvementimprovement not identification ofnot identification of failurefailure!! Iterative (small, incremental ‘deliverables’)Iterative (small, incremental ‘deliverables’) Risk-driven (identify / resolve risks up front)Risk-driven (identify / resolve risks up front) Flexible, customizable process (not a burden; adaptive toFlexible, customizable process (not a burden; adaptive to projects)projects) Architecture-centric (breaks components into ‘layers’ orArchitecture-centric (breaks components into ‘layers’ or common areas of responsibility…)common areas of responsibility…) HeavyHeavy user involvementuser involvement ► Identify best ways of doing things – a better processIdentify best ways of doing things – a better process – acknowledged by world leaders…– acknowledged by world leaders… Need a Better Hammer!
- 10. 30 10 Develop IterativelyDevelopIteratively Control ChangesControl Changes UseUse ComponentComponent ArchitecturesArchitectures ManageManage RequirementsRequirements ModelModel VisuallyVisually VerifyVerify QualityQuality Best Practices of SoftwareBest Practices of Software EngineeringEngineering Know these!
- 11. 30 11 Symptoms end-user needs changing requirements modulesdon’t fit hard to maintain late discovery poor quality poor performance colliding developers build-and-release Root Causes insufficient requirements ambiguous communications brittle architectures overwhelming complexity undetected inconsistencies poor testing subjective assessment waterfall development uncontrolled change insufficient automation Best Practices develop iteratively manage requirements use component architectures model the software visually verify quality control changes Addressing Root CausesAddressing Root Causes Eliminates the SymptomsEliminates the Symptoms Symptoms of problems can be traced to having Root Causes. Best Practices are ‘practices’ designed to address the root causes of software problems.
- 12. 30 12 Practice 1:Develop SoftwarePractice 1: Develop Software IterativelyIteratively Develop IterativelyDevelop Iteratively Control Changes Use Component Architectures Manage Requirements Model Visually Verify Quality Considered by many practitioners to be the most significant of the six
- 13. 30 13 Practice 1:Develop Software IterativelyPractice 1: Develop Software Iteratively ►Until recently, developed under assumption -Until recently, developed under assumption - most requirements can be identified up front.most requirements can be identified up front. ►The research deconstructing this myth includesThe research deconstructing this myth includes work by Capers Jones. (See next slide) In thiswork by Capers Jones. (See next slide) In this very large study of 6,700 projects,very large study of 6,700 projects, creepingcreeping requirementsrequirements — those not anticipated near the— those not anticipated near the start—are astart—are a very significant fact of softwarevery significant fact of software development lifedevelopment life, ranging from around 25% on, ranging from around 25% on average projects up to 50% on larger ones.average projects up to 50% on larger ones.
- 14. 30 14 Lookup a definition of ‘Function Points.’
- 15. 30 15 Interestingly,Interestingly, ► Aninitial design willAn initial design will likely be flawedlikely be flawed with respect to its keywith respect to its key requirements. Requirements rarelyrequirements. Requirements rarely fully knownfully known up front!up front! ► Late-phase discovery of design defectsLate-phase discovery of design defects results in costlyresults in costly over-runs and/or project cancellationover-runs and/or project cancellation Oftentimes requirements change – even during implementation!Oftentimes requirements change – even during implementation! ► While large projects are more prone to cost overruns,While large projects are more prone to cost overruns, medium-size/small projects are vulnerable to cancellation.medium-size/small projects are vulnerable to cancellation. ► The key reasons continue to beThe key reasons continue to be poor project planning and management,poor project planning and management, shortage of technical and project management expertise,shortage of technical and project management expertise, lack of technology infrastructure,lack of technology infrastructure, disinterested senior management, anddisinterested senior management, and inappropriate project teams.”inappropriate project teams.”
- 16. 30 16 Waterfall DelaysRisksWaterfall Delays Risks R I S K T I M E Integration System Test Code Design Requirements Waterfall risk Walker Royce, 1995
- 17. 30 17 Iterative DevelopmentIterativeDevelopment Earliest iterations address greatest risks • Each iteration produces an executable release • Each iteration includes integration, test, and assessment! • Objective Milestones: short-term focus; short term successes! Iteration 1 Iteration 2 Iteration 3
- 18. 30 18 Accelerate RiskReductionAccelerate Risk Reduction Iterative T I M E Iteration Iteration Iteration Iteration Iteration Risk reductionRisk reduction R I S K Waterfall risk Walker Royce, 1995
- 19. 30 19 Iterative DevelopmentCharacteristicsIterative Development Characteristics ► Critical risks are resolved before makingCritical risks are resolved before making large investmentslarge investments ► Initial iterations enable early userInitial iterations enable early user feedbackfeedback Easy to resolve problems early.Easy to resolve problems early. Encourages user feedback in meaningful waysEncourages user feedback in meaningful ways ► Testing and integration are continuousTesting and integration are continuous –– assures successful integration (parts all fit)assures successful integration (parts all fit) Continuous testing.Continuous testing. ► Objective milestones provide short-term focusObjective milestones provide short-term focus ► Progress measured by assessingProgress measured by assessing implementationsimplementations ► Partial implementations can be deployedPartial implementations can be deployed Waterfall method – no deliveryWaterfall method – no delivery Incremental development? May be some greatIncremental development? May be some great values in delivering key parts of application.values in delivering key parts of application.
- 20. 30 20 UP LifecycleGraph – Showing IterationsUP Lifecycle Graph – Showing Iterations In anIn an iteration,, you may walkyou may walk through allthrough all disciplinesdisciplines C O N T E N T S T R U C T U R E T I M E STUDY THIS!!!
- 21. 30 21 Executable Releases UnifiedProcess Iterations andUnified Process Iterations and PhasesPhases 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….) Preliminary Iteration Architect. Iteration Architect. Iteration Devel. Iteration Devel. Iteration Devel. Iteration Transition Iteration Transition Iteration Elaboration Construction TransitionInception
- 22. 30 22 Enables andencouragesEnables and encourages useruser feedbackfeedback SeriousSerious misunderstandingsmisunderstandings evident early in the life cycleevident early in the life cycle Development focuses onDevelopment focuses on criticacritica issues – break it down!issues – break it down! Objective assessment thruObjective assessment thru testing and assessmenttesting and assessment Inconsistencies detected earlyInconsistencies detected early Testing starts earlier –Testing starts earlier – continuous!continuous! Risks identified and addressedRisks identified and addressed early - viaearly - via plannedplanned iterations!iterations! Problems Addressed by Iterative DevelopmentProblems Addressed by Iterative Development Root CausesRoot Causes SolutionsSolutions Insufficient requirementsInsufficient requirements AmbiguousAmbiguous communicationscommunications Brittle architecturesBrittle architectures OverwhelmingOverwhelming complexitycomplexity Subjective assessmentSubjective assessment UndetectedUndetected inconsistenciesinconsistencies Poor testingPoor testing Waterfall developmentWaterfall development Uncontrolled changeUncontrolled change Insufficient automationInsufficient automation
- 23. 30 23 No FreeLunchNo Free Lunch - Traps- Traps Abound…Abound… ► Major impacts on Project Managers, though….Major impacts on Project Managers, though…. ► Trap: When the initial risks are mitigated, new ones emergeTrap: When the initial risks are mitigated, new ones emerge Do not do just the easy stuff, to look good.Do not do just the easy stuff, to look good. Keep re-planning based on all new information.Keep re-planning based on all new information. ► Trap: Remember ‘some’Trap: Remember ‘some’ ReworkRework enables you to enhance your solutionenables you to enhance your solution Accommodate changeAccommodate change earlyearly in the projectin the project ► Trap: Iterative developmentTrap: Iterative development doesdoes notnot meanmean never to commit to a solutionnever to commit to a solution ► Monitor ‘scrap and rework’Monitor ‘scrap and rework’ ► Trap: Must Control “requirement creep, ” however… SomeTrap: Must Control “requirement creep, ” however… Some clients will now naturally recognize many ‘musts…’clients will now naturally recognize many ‘musts…’
- 24. 30 24 Many Trapsin Iterative DevelopmentMany Traps in Iterative Development Here is another trap: Too long initial iterationHere is another trap: Too long initial iteration ► Winning is fun. Winning teams work better than loosing teamsWinning is fun. Winning teams work better than loosing teams ► BetterBetter to have a short initial iteration, than one too longto have a short initial iteration, than one too long Cut scope if necessary (much more later)Cut scope if necessary (much more later) ► Avoid ‘analysis-paralysis’ byAvoid ‘analysis-paralysis’ by time-boxing;time-boxing; you can enhanceyou can enhance in later iterations (more later)in later iterations (more later) ► Establish anEstablish an even rhythmeven rhythm for project (at least w/i a phase)for project (at least w/i a phase) ► Focus onFocus on resultsresults andand deliverablesdeliverables, not activities, not activities
- 25. 30 25 Iterations AreTime-boxedIterations Are Time-boxed ►Work is undertaken within anWork is undertaken within an iterationiteration.. ►The iteration planThe iteration plan definesdefines thethe artifactsartifacts toto be delivered,be delivered, rolesroles andand activitiesactivities.. ►An iteration is clearlyAn iteration is clearly measurablemeasurable.. ►Iterations areIterations are risk-drivenrisk-driven ►Iterations areIterations are plannedplanned.. ►Iterations areIterations are assessedassessed!! ►Generally,Generally, initialinitial iterations (in Construction)iterations (in Construction) based onbased on high risk and core functionalities!high risk and core functionalities!
- 26. 30 26 The IterationPlan Defines….The Iteration Plan Defines…. TheThe deliverablesdeliverables forfor that iteration.that iteration. TheThe to do listto do list for thefor the team membersteam members artifacts
- 27. 30 27 Problem:Problem: FixedFixed PlansProduced Upfront – NotPlans Produced Upfront – Not Real Practical!Real Practical! ►Yet, senior management wants firm, fixed plans!Yet, senior management wants firm, fixed plans! Part of their culture / upbringing/ experiencePart of their culture / upbringing/ experience Necessary for ‘planning’ budgeting, etc. of resources, projects…. BUT:Necessary for ‘planning’ budgeting, etc. of resources, projects…. BUT: ►TrapTrap: Fine-grained planning: Fine-grained planning from start to end?from start to end? Takes too much timeTakes too much time Frustrating as change occurs (and itFrustrating as change occurs (and it will)will) , if plans too fine-grained., if plans too fine-grained. ►Know that:Know that: Projects typically have some degree ofProjects typically have some degree of uncertaintyuncertainty ►This makesThis makes detaileddetailed plans for theplans for the entireentire project meaninglessproject meaningless ►Does not mean that we should not planDoes not mean that we should not plan
- 28. 30 28 Solution:Solution: Plan WithEvolving Levels of DetailPlan With Evolving Levels of Detail Current Iteration Next Iteration Phases and major milestones What and when Iterations for each phase Number of iterations Objectives and Duration One For Entire Project Fine-grained Plans: Iteration Plans Coarse-grained Plan: Software Development Plan Iterative Development does not mean less work and shorter schedule It is about greater predictability
- 29. 30 29 Progress ismade againstProgress is made against MILESTONESMILESTONES ►In the Unified Process:In the Unified Process: Each phase is defined by aEach phase is defined by a milestonemilestone.. Progress is made by passingProgress is made by passing milestonesmilestones.. Milestones measureMilestones measure successsuccess ►PhasesPhases - NOT TIMEBOXED.- NOT TIMEBOXED. ►IterationsIterations ARE TIMEBOXED.ARE TIMEBOXED. Inception Elaboration Construction Transition Major Milestones
- 30. 30 30 SummarySummary ►Much moreabout iteration and iterationMuch more about iteration and iteration planning later in the course…planning later in the course… ►You will see some of these again – and,You will see some of these again – and, more importantly,more importantly, useuse this information inthis information in your own iteration planning.your own iteration planning.
Editor's Notes
- #26 This presentation does not attempt to describe in detail the iterative software development process. Good references on iterative development are contained within the Rational Unified Process itself. Suffice it to say that RUP is an incremental process whereby the overall project is broken down into phases and iterations. The important aspects of iterative development from a plan perspective are: The iteration plan provides a detailed description of the upcoming phase of work. It defines the roles, activities and artifacts delivered in that iteration. It has a very clear set of measurement criteria which can be assessed at the end (and during) the iteration. An iteration should deliver an executable piece of software that is demonstratable and testable against the project’s requirements and use cases. An iteration should be time boxed-meaning that it should have a definite duration; Beginning and end. Iterations are the mechanism that the project manager uses to mitigate risk. Therefore, each iteration should reduce the overall risk to the project.
- #27 Once you have defined your coarse grained project plan, then an iteration plan is developed at a more detailed level prior to each and every iteration. In short, iteration plans are the roadmap for each iteration. Each phase has a series of milestones associated with it. Each iteration in a phase moves the project towards these milestones. An iteration has a clear objective defined and associated with that objective are the activities and deliverables required to accomplish that objective.
- #30 Secondly, RUP projects measure progress against defined milestones. Each phase is defined by a milestone; These milestones are defined by the project plan (as opposed to the iteration plan). Progress on you project is made by passing these milestones. Not passing your defined milestones is also a problem. Unlike your iterations, phases are not time boxed; There are not defined constraints on time for your four phases. In the end, milestones measure success! The milestones for a phase provide a focus for the iterations. The milestone helps to plan the objective of the iteration. For example during the inception phase, one of the phase milestones is the need to understand scope. An iteration within that phase would be structured around the need to understand the scope of the system. The iteration(s) would provide the management framework for the team to explore the system boundary, implications of a possible solution and the size of that solution. The number of iterations would depend on how difficult it will be to define the scope of the project. If the scope was very hard to understand, or it could be grouped into easily defined pieces, then you may need more than one iteration. One iteration for each piece. If, as is normally the case, there is one clear piece of work to understand the scope, then one iteration would be appropriate. Judging the size and number of iterations for a project is described later in this presentation.