Transcription
Dr. Michael EichbergSoftware EngineeringDepartment of Computer ScienceTechnische Universität DarmstadtIntroduction to Software EngineeringSoftware Process Models
The Software (Engineering) Process is the set ofactivities and associated results that produce a softwareproduct.Software Process (Models) Requirements specification Software specificationDefinition of the software to be produced and the constraints of itsoperation. Software developmentDesign and implementation of the software. Software validationTo ensure that the software does what the customer requires. Software evolutionAdaptation and modification of the software to cope with changingcustomer and market requirements.Fundamental Process Activities2
Software (Engineering) Process Models aresimplified and abstract description of a software processthat presents one view of that process.Software Process (Models) Process models may include activities that are part of thesoftware process, software products, e.g. architecturaldescriptions, source code, user documentation, and theroles of people involved in software engineering. Examples: The waterfall model The spiral model “V-Modell (XT)” (dt.) eXtreme Programming 3
Process Models Large(r) projects may use different (multiple) softwareprocess models to develop different parts of the software.4
The Waterfall Model
The Waterfall Model can be considered as a genericprocess model.Software Process Models - The Waterfall Model 1.Requirementsanalysis anddefinitionThe requirementsare established byconsultation withsystem users.After that they aredefined in detailand serve as thesystemspecification.Requirementsdefinition6
The Waterfall Model can be considered as a genericprocess model.Software Process Models - The Waterfall Model 2.System andSoftware designThe overall systemarchitecture isdefined. Thefundamentalsoftware systemabstractions andtheir abstractionsare identified.RequirementsdefinitionSystem andsoftware design7
The Waterfall Model can be considered as a genericprocess model.Software Process Models - The Waterfall Model 3.Implementation andunit testingThe software designis realized as a setof program units;testing verifies thateach unit meets itsspecification.RequirementsdefinitionSystem andsoftware designImplementationand unit testing8
The Waterfall Model can be considered as a genericprocess model.Software Process Models - The Waterfall Model 4.Integration andsystem testingProgram units areintegrated andtested as acomplete system.RequirementsdefinitionSystem andsoftware designImplementationand unit testingIntegration andsystem testing9
The Waterfall Model can be considered as a genericprocess model.Software Process Models - The Waterfall Model 10RequirementsdefinitionSystem andsoftware designImplementationand unit testingIntegration andsystem testingOperation andmaintenance
Key Properties of the Waterfall ModelSoftware Process Models - The Waterfall Model 11 The result of each phase is aset of artifacts that isapproved. The following phase startsafter the previous phase hasfinished.(In practice there might be someoverlapping.) In case of errors previousprocess stages have to berepeated. Fits with other (hardware)engineering process models.RequirementsdefinitionSystem andsoftware designImplementationand unit testingIntegration andsystem testingOperation andmaintenance
The Marshmallow Challenge 12
Agile Development Agile Software Development - Principles,Patterns, and Practices; Robert C. Martin; 2003Im Deutschen wird gelegentlich von “schnellerSoftwareentwicklung” gesprochen wenn iterativeEntwicklung gemeint ist - agile Methoden bauenauf iterativen Ansätzen auf.
Agile Development - Key PointsAgile Software Engineering Process Models - Agile Development 14 The goal is to develop software quickly, in the face ofrapidly changing requirements Originally conceived for small to mid-sized teams To achieve agility we need to . employ practices that provide the necessary discipline andfeedback employ design principles that keep “our” software flexibleand maintainable know the design patterns that have shown to balance thoseprinciples for specific problems
Agile Software Engineering Process Models - Agile Development 15Using an agile method does not mean that thestakeholders will always get what they want.It simply means that they’ll be able to controlthe team to get the most business value forthe least cost.
Agile Development Manifesto
Manifesto for Agile Software DevelopmentAgile Software Engineering Process Models - Agile Development 17Individuals and interactions over process and tools.The best tools will not help if the team doesn’twork together. Start small and grow if needed.
Manifesto for Agile Software DevelopmentAgile Software Engineering Process Models - Agile Development 18Working software over comprehensive documentation.The structure of the system and the rationales forthe design should be documented.
Manifesto for Agile Software DevelopmentAgile Software Engineering Process Models - Agile Development 19Customer collaboration over contract negotiation.The contract should specify how the collaborationbetween the development team and the customerlooks like.A contract which specifies a fixed amount of money that will be paid ata fixed date will likely fail.
Manifesto for Agile Software DevelopmentAgile Software Engineering Process Models - Agile Development 20Responding to change over following a plan.today24681012time(weeks)Plan: preciseroughbig picture
Agile Development Principles
Principles of Agile DevelopmentAgile Software Engineering Process Models - Agile Development 22 Our highest priority is to satisfy the customer throughearly and continuous delivery of valuable software Deliver working software frequently (e.g. every twoweeks), from a couple of weeks to a couple of months,with a strong preference to the shorter timescale Working software is the primary measure of progress Continuous attention to technical excellence and gooddesign enhances agility Simplicity - the art of maximizing the amount of worknot done - is essential .If 30% of the functionality is implemented, 30% of the project is done.
Principles of Agile DevelopmentAgile Software Engineering Process Models - Agile Development 23 . At regular intervals, the team reflects on how tobecome more effective, then tunes and adjusts itsbehavior accordinglyWelcome changing requirements, even late indevelopment; agile processes harness change for thecustomer’s competitive advantageProcess Improvement The best architectures, requirements, and designsemerge from self-organizing teams
Principles of Agile DevelopmentAgile Software Engineering Process Models - Agile Development 24 Business people and developers must work togetherdaily throughout the project Build projects around motivated individuals; give themthe environment and support they need, and trustthem to get the job done Agile processes promote sustainable development;the sponsors, developers, and users should be able tomaintain a constant pace indefinitelyWorkloadM1M2Releasenot sustainablesustainabletypicalidealTime
Agile Processes Agile Software Engineering Process Models - Agile Development 25SCRUM( Project Management Method)(Agile) Unified ProcessCrystalFeature Driven DevelopmentAdaptive Software DevelopmentExtreme Programming.
Unified ProcessA Very First Glimpse
Unified Process - PhasesSoftware Engineering Processes - Unified Process 271. Inception ( dt. Konzeption)Feasibility phase, where just enough investigation isdone to support a decision to continue or stop2. Elaboration ( dt. Entwurf)The core architecture is iteratively implemented; highrisks are mitigated(mitigate dt. mildern / abschwächen)3. Construction ( dt. Konstruktion)Iterative implementation of remaining lower risk andeasier elements, and preparation for deployment4. Transition ( dt. Übergabe)Beta tests, deployment
Unified Process 281234520iterations
Unified Process ssoftware20%2%30%5%50%8%85%10%90%20%Iteration 1Iteration 2Iteration 3Iteration 4Iteration 5iterations
Unified Process 0%8%85%10%90%20%Iteration 1Iteration 2Iteration 3Iteration 4Iteration 5
Unified Process 0%8%85%10%90%20%Iteration 1Iteration 2Iteration 3Iteration 4Iteration 53 weeksMTWThFMTWThFMstart coding & testingTWThFnext iteration planningde-scope iteration goals if too much workagile modeling & designkickoff meetingclarifying iteration goalsdemo and 2-day requirements workshop
General PracticesSoftware Engineering Processes - Unified Process 32 Tackle high-risk and high-value issues in earlyiterations Continuously engage users for evaluation, feedback,and requirements Build a cohesive core architecture in early iterations Continuously verify quality; test early, often, andrealistically Apply use cases where appropriateDo some visual modelingCarefully manage requirementsPractice change request and configurationmanagement
OOA/D - Case Studies - Setup 33In the following, we assume that we are on a project thatuses the unified process (UP) as the process model fordeveloping our POS application.
Current Development StateStart of the Elaboration PhaseOOA/D - Case Studies - Setup 34 The inception phase is over; we are entering iteration 1 ofthe elaboration phase Most actors, goals and use cases were named Most use cases were written in brief format 10-20% of the use cases are written in fully dressedformat Version one of the vision is available Technical proof of concept prototypes were developed(E.g., can Java Swing be used with touch screen?) Candidate tools have been identified
Artifacts That May Be Started In the Elaboration Phase}OOA/D - Case Studies - Setup 35(System Models) Domain ModelVisualization of the domain concepts Design ModelDescription of the logical design usingclass diagrams, object interactiondiagrams, package diagrams. Software Architecture DocumentSummary of key architectural issuesand their resolution in the design Data ModelE.g., database schemas, mappingstrategies between object and nonobject representations
Planning the First Iteration Of the Elaboration PhaseOOA/D - Case Studies - Setup 36 Apply the following criteria to rank work across iterations: RiskTackle high risk issues related to technical complexity,usability,. CoverageTry to touch all major parts of the system in early iterations CriticalityImplement functionality of high business value
Ranked Requirements for the POS applicationOOA/D - Case Studies - Setup 37RankRequirement(Use Case orFeature)CommentHighProcess SaleLoggingPervasive; hard toadd lateMediumMaintain UsersAffects securitysubdomainLow.
Requirements Forthe First Iteration Of the POS ApplicationOOA/D - Case Studies - Setup 38 Implement a basic, key scenario of the Process Sale usecase: entering items and receiving a cash payment Implement a start up use case as necessary to support theinitialization needs of the iteration No collaboration with external services, such as taxcalculator or product database No complex pricing rules are applied
Extreme Programming
Software Engineering Process Models 40Practices dt. Verfahren / VerfahrensregelnExtreme programmingis made up of a set ofsimple, interdependent practices.
Extreme Programming - PracticesSoftware Engineering Process Models 41Customer Team MemberCustomer is the person (or group) who defines andprioritizes features. The customers are members andavailable to the team.
Extreme Programming - PracticesSoftware Engineering Process Models 42User StoriesRequirements are talked over with the customer but only afew words that reminds everybody of the conversation arewritten on an index card along with an estimate.
Extreme Programming - PracticesSoftware Engineering Process Models 43Short CyclesWorking software is delivered every, e.g., two weeks (aniteration); the delivered software may or may not be putinto production.Iterations are timeboxed - date slippage is illegal; if youcannot complete all tasks scheduled for the iterationremove some.It. 1It. 4ndaysnndays days
Extreme Programming - PracticesSoftware Engineering Process Models 44Short CyclesIteration PlanDuring each iteration the user stories and their prioritiesare fixed.The customer selects the user stories they want to haveimplemented. The number of stories is limited by theIt. 1It. 4budget, which is set by the developers.nnndaysdays days
Extreme Programming - PracticesSoftware Engineering Process Models 45Short CyclesRelease PlanMaps out approx. six iterations. Can always be changed.It. 1nndays daysndaysnIt. 6ndays days
Extreme Programming - PracticesSoftware Engineering Process Models 46The Planning GameDivision of responsibility between business anddevelopment. Business people decide how important afeature is and the developers decide how much thatfeature will cost to implement.FeatureFeatureX,Y,.It. 1nZ,.ndays daysndaysnIt. 6ndays days
Extreme Programming - PracticesSoftware Engineering Process Models 47Acceptance TestsDetails of the user stories are captured in theform of acceptance tests.Acceptance tests are written before orconcurrent with the implementation of a userstory.Once an acceptance test passes, it is added tothe set of passing acceptance tests and is neverallowed to fail again.Acceptancetests are(ideally)black-boxtestsdevelopedby thecustomer.
Extreme Programming - PracticesSoftware Engineering Process Models 48Pair ProgrammingThe code is written by pairs of programmers; one typesthe code and the other member watches the code beingtyped - the keyboard is moved between the developers.The pairs change after half a day to make sure that theknowledge is spread.Collective OwnershipThe team owns the code. A pair has the right to check outany module.
Extreme Programming - PracticesSoftware Engineering Process Models 49RefactoringDo frequent refactorings to avoid that the code “rots”due to adding feature after feature.Refactoring meansimproving thestructure withoutchanging behavior.
Extreme Programming - PracticesSoftware Engineering Process Models 50Test-Driven DevelopmentAll code is written to make failing (unit)tests pass! Having a (very) complete bodyof test cases facilitates refactorings andoften (implicitly) leads to less coupledcode.These testsare whitebox unittestsdevelopedby the“developers”.
Extreme Programming - PracticesSoftware Engineering Process Models 51Continuous IntegrationProgrammers check in their code and integrate severaltimes per day; non-blocking source control is used. Aftercheck-in the system is build and every test (includingrunning acceptance tests) is run.
Extreme Programming - PracticesSoftware Engineering Process Models 52Sustainable PaceNo overtime; except in the very last week before a release.Open WorkspaceThe team works together in an open room.
Extreme Programming - PracticesSoftware Engineering Process Models 53Simple DesignMake the design as simple and expressive as possible.Focus on the current set of user stories; don’t worryabout future user stories.E.g. only add the infrastructure when a story forces it.
Extreme Programming - PracticesSoftware Engineering Process Models 54Consider the simplest thing that could possibly workFind the simplest design option for the current set of user stories.You aren’t going to need itAdd infrastructure only if there is proof or at least compelling evidence.Once and only onceDon’t tolerate code duplication;eliminate code redundancies by creatingabstractions. Employ patterns to removeredundancies.SimpleDesign
Extreme Programming - PlanningSoftware Engineering Process Models - Extreme Programming 55 Initial Exploration (Start of the Project) Developers and customers try to identify allsignificant user stories; i.e., they do not tryto identify all storiesThe developers estimate - relative to eachother - the stories by assigning storypoints; a story with twice as much points asanother story is expected to take twice aslong to implementTo know the true size we need the velocity(velocity time required per story point)The velocity will get more accurate as theproject proceeds; initially it is just guessedbased on “experience”A prototypedevelopedto measurethe velocityis called aspike.
Extreme Programming - PlanningSoftware Engineering Process Models - Extreme Programming 56 Release Planning Developers and customers agree on a date for the firstrelease (2-4 months)The customers pick the stories and the rough order; acustomer cannot choose more stories than the currentvelocity enablesAs the velocity becomes more accurate the release plan(i.e. the number of user stories) will be adjusted
An Example Release Plan For aTravel Booking ProjectExtreme Programming eFind lowest fare.321Show available flights.211Sort available flights by convenience.4Purchase ticket.2Do customer profile.4Review itineraries.211121 .
Extreme Programming - PlanningSoftware Engineering Process Models - Extreme Programming 58 Iteration Planning The customer picks the stories for the iterationThe order of the stories within the iteration is atechnical decisionThe iteration ends on the specified date (timeboxed),even if all stories aren’t doneThe estimates for all the stories are totaled and thevelocity for that iteration is calculatedThe planned velocity for each iteration is the measuredvelocity of the previous iteration
Extreme Programming - PlanningSoftware Engineering Process Models - Extreme Programming 59 Task Planning At the start of each iteration the developer andcustomers get together to planThe stories are broken down into tasks which requirebetween 4 and 16 hours to implementEach developer signs up for tasksA developer can choose an arbitrary task - even if he is not an expert
“Software Engineering Process Models - Extreme Programming 60Example: User Stories for a Web ApplicationMy storyis.James Newkirk and Robert C. MartinExtreme Programming in Practice; Addison Wesley, 2001
Example: User Stories for a Web ApplicationSoftware Engineering Process Models - Extreme Programming 61Estimates (righuppt coerrngiveer)n inareideal dain thysis caseone daySome pages trigger the login mechanism and somedon't.The list of pages that do/don't is dynamic.And the mechanism is triggered once per session.
Example: User Stories for a Web ApplicationSoftware Engineering Process Models - Extreme Programming 62ConstraintThe system will not pop up a window that couldbe interpreted as a pop-up ad.Nonimplementabus eler stories
Example: User Stories for a Web ApplicationSoftware Engineering Process Models - Extreme Programming 63Login Story - two daysWhen the login is triggered, and the site cannotdetect that the user is a member, the user istransferred to a login page, which asks for theirusername and password and explains the loginprocess & philosophy of the site.The story is broken up into tasks.Login StartRead cookie.If presentLogin StartDisplay login ack. with user e-mail address andoption to login as someone else.elseBring up login page.Login TaskLogin TaskTakes data from HTML input. Checks the databasefor e-mail and password. Stores cookie ifselection has been made. Routes to URL fromwhere you came from if successful. Createssession. If not su
Software Process (Models) Fundamental Process Activities The Software (Engineering) Process is the set of activities and associated results that produce a software product. Requirements specification Software specification Definition of the so
