Modern practices 2.3.2015 1
Today s lecture Learn what some modern SW engineering topics are about A peek to some research topic of our department 2
3
4
5
6
How the lectures continue? 02.03 Modern practices Continuous Integration, Continuous Deployment, DevOps,.. 9.03 No lectures - exam week 17.3 Improving Quality: review practices, testing and quality assurance Quality in general; Quality management systems 23.3 Dependable and safety-critical systems 30.3 Other methods; RUP, XP, Lean; Kanban. 6.4 Easter - no lectures 13.4 Role of software architecture; software maintenance; software evolution 20.4 Software business, software start-ups 27.4 Guest lecture 1 4.5 Guest lecture 2 7
General matters About the tools All information should be on the Web page (if something is missing, please report me) Canvas is a collaboration tools Emails (POP-messages) are for quick updates and reminders Sprint reviews Evaluation is based on several factors (overall management, scrum process, implemented user stories) Weekly exercises We had some technical problems that delayed finalization of Jenkins exercise => postponed to 16.3 This week we look at Traditional, Agile and Lean through a scientific article 8
Agenda for today Recap of the effort estimation Global SW development And related research Optimized pipeline from requirements to use feedback And related research 9
10 STILL ABOUT EFFORT ESTIMATION
Estimates improve as the project progresses Picture 12.8 in Haikala&Mikkonen, 23.9 in Sommerville 11 Prestudy Early prototyping Early design Requirement specification Architecture design Post architecture Detailed design Implementation Real value
Effort estimation in Scrum 12 24 hours Planning Initial estimation Sprint planning Sprint backlog Sprint 2-4 weeks Go / no-go decision Resource allocation
Effort estimation 13 Necessary for planning: timetable and budget Factors Complexity of the software often hard to know in advance Productivity of the team Skills Experience Spirit Required quality Timetable (recall previous slides)
14 GSD - GLOBAL SOFTWARE DEVELOPMENT
Reasons for distributed development 15 Size of the project One team cannot finish in time Not enough resources available otherwise Need for additional competences HW, databases, UI Domain knowledge Business In some places development is cheaper Presence close to customer needed for the business
Global SW development 16 SW developed by a geographically distributed organization Reasons like above Often main reason is lower salary costs Also called off-shore development Real savings debated
Business set-ups 17 Scale own development By resources from foreign company Buy a project Handle management
GSD problems 18 Communication distance: (timezone, language cultural..). Serious issue since communication is major challenge in SW Spirit, motivation, committment They and us attitude No feeling of ownership
Guidelines for planning distributed projects 19 Design for partitioning Or it will happen anyways Conway s law: organizations which design systems... are constrained to produce designs which are copies of the communication structures of these organizations Facilitate communication Add extra effort for Communication Solving problems due to bad communication in your plan
How to use Genetic Algorithm to propose planning of a global SW project Work packages & their relations Teams & their relations GA Work distribution Scheduling 20 12/09/2014
For our algorithm we need a GSD Work Distribution Model Skill -area -level * * Available resources Team -cost -capacity -performance 0..* Communication distance * Slot Component -estimated effort 1..* * * System requirements 21 System information -skill Responsibility 12/09/2014
Genetic Algorithms Genetic Algorithms (GA) are adaptive heuristic search algorithms inspired by the natural selection and genetics. The system runs through several generations A solution is encoded as genes and altered through mutations New solutions found also by combining parts of two existing solutions (parents) The best individuals survive from each generation. For a more detailed description see the paper and its references. 22 12/09/2014
12/09/2014 Genetic algorithm simplified! 23 A B C D A B C D A B C D A B C D A I C D A B E D A H C D O B C D A I C D A B E D A H C D O B C D A I C D A H C D A I E D A H C D A I C D A B E D A H C D O B C D Mutations Selection 5 10 8 1 12 7 8 3
Applying genetic algorithm to work distribution and scheduling in GSD (1/3) Team and WP characteristics encoded in genes Initial work distribution and schedule Genetic Algorithm Result Set of optimal work distributions and schedules - Change team - Change development order Mutations Cost Duration Fitness function 24 12/09/2014
Applying genetic algorithm to work distribution and scheduling in GSD (3/3) Crossover exchanges genes between two parent chromosomes The fitness function evaluates the goodness of the solution (individual in a generation). Two factors: cost and lead-time determine the fitness Pareto optimality approach is used for selecting the survivors In practice we seek points where improvement of one criteria (e.g. cost) can only be optimized by compromising another (e.g. time). Cost Time 25 12/09/2014
Results London is faster but Bangalore is cheaper. Using the Pareto fronts, the project manager can analyze different work distributions for a given project based on available cost and time. 26 12/09/2014
Time vs Cost 27 Cost Time is expensive! Minimum cost Time Minimum time
Partitioning of the project 28 Impossible to partition Easy to partition Cost/people
29 CONTINUOUS INTEGRATION, DELIVERY, DEPLOYMENT
Continuous integration (http://www.martinfowler.com/articles/continuousintegration.html) 30 Suggested by many agile methods, for example XP. The team integrates latest changes to complete system frequently even several times a day. Often combined with test-driven development Benefits Reduced risk (and earlier discovery) Helps in getting rid of bugs Avoid chaos at the end (integration hell) Changes behavior of programmers, more carefully written and simpler code
Practices of continuous integration 31 Maintain a Single Source Repository. Automate the Build Make Your Build Self-Testing Everyone Commits To the Mainline Every Day Every Commit Should Build the Mainline on an Integration Machine Keep the Build Fast Test in a Clone of the Production Environment Make it Easy for Anyone to Get the Latest Executable Everyone can see what's happening Automate Deployment
Continuous integration, when not practical 32 Target platform is too different for example embedded SW System is big, and building takes long (e.g. hours) => Daily builds (often nightly builds) By agreed time of the day every developer needs to deliver a functional version of his/her component Build server compiles and links the system Automated tests are run and/or system is sent to test team
Continuous integration 33 Version mgmt 1. Check in 4. Check out Build servers App Developes 2. Signal change 3. Init build 5. Report results Other stakeholders 6. Feedback CI server
Figure 25.12 in Sommerville Version Management Private Workspace fail Checkout Mainline Build and Test System Make Changes Build and Test System Check-in to Build Server Build and Test System Commit changes Build Server Version Management 34
Practices of continuous integration 35 Maintain a Single Source Repository. Automate the Build Make Your Build Self-Testing Everyone Commits To the Mainline Every Day Every Commit Should Build the Mainline on an Integration Machine Keep the Build Fast Test in a Clone of the Production Environment Make it Easy for Anyone to Get the Latest Executable Everyone can see what's happening Automate Deployment Limit number of branches
Practices of continuous integration 36 Maintain a Single Source Repository. Automate the Build Make Your Build Self-Testing Everyone Commits To the Mainline Every Day Every Commit Should Build the Mainline on an Integration Machine Keep the Build Fast Test in a Clone of the Production Environment Make it Easy for Anyone to Get the Latest Executable Everyone can see what's happening Automate Deployment Manage the dependencies for the source code Builds are based on a schedule or triggered by source code changes Possibly run the build as distributed processes Generating build notes and other documentation Reporting the build status.
Practices of continuous integration 37 Maintain a Single Source Repository. Automate the Build Make Your Build Self-Testing Everyone Commits To the Mainline Every Day Every Commit Should Build the Mainline on an Integration Machine Keep the Build Fast Test in a Clone of the Production Environment Make it Easy for Anyone to Get the Latest Executable Everyone can see what's happening Automate Deployment Challenges: increased work effort needed to create the automated tests need to test user interaction or external interfaces that are difficult to automate the amount of processing power needed to run the tests repeatedly.
Practices of continuous integration 38 Maintain a Single Source Repository. Automate the Build Make Your Build Self-Testing Everyone Commits To the Mainline Every Day Every Commit Should Build the Mainline on an Integration Machine Keep the Build Fast Test in a Clone of the Production Environment Make it Easy for Anyone to Get the Latest Executable Everyone can see what's happening Automate Deployment NOTE: this is not always possible Prevents potential problems or conflicts to be hidden in the local copies of the software. The rule of thumb in CI is to commit software changes every day. In practice it is often beneficial to commit even more frequently.
Practices of continuous integration 39 Maintain a Single Source Repository. Automate the Build Make Your Build Self-Testing Potential solutions to the problem: Staged build or build pipeline Everyone Commits To the Mainline Staged Every testing Day Distributed build and testing Raw processing power. Every Commit Should Build the Mainline on an Integration Machine Keep the Build Fast Test in a Clone of the Production Environment Make it Easy for Anyone to Get the Latest Executable Everyone can see what's happening Automate Deployment
Practices of continuous integration 40 Maintain a Single Source Repository. Automate the Build Make Your Build Self-Testing Everyone Commits To the Mainline Every Day Every Commit Should Build the Mainline on an Integration Machine Keep the Build Fast Test in a Clone of the Production Environment Make it Easy for Anyone to Get the Latest Executable Everyone can see what's happening Automate Deployment Do the best you can
Practices of continuous integration 41 Maintain a Single Source Repository. Automate the Build Make Your Build Self-Testing Everyone Commits To the Mainline Every Day Every Commit Should Build Even the Mainline managers! on an Integration Machine Keep the Build Fast Test in a Clone of the Production Environment Make it Easy for Anyone to Get the Latest Executable Everyone can see what's happening Automate Deployment
Practices of continuous integration 42 Maintain a Single Source Repository. Automate the Build Make Your Build Self-Testing Everyone Commits To the Mainline Every Day Every Commit Should Build the Mainline on an Integration Machine Keep the Build Fast Test in a Clone of the Production Environment Make it Easy for Anyone to Get the Latest Executable Everyone can see what's happening Automate Deployment Status displays in separete and public screens (but maybe not in cafeteria)
Practices of continuous integration 43 Maintain a Single Source Repository. Automate the Build Make Your Build Self-Testing Everyone Commits To the Mainline Every Day Every Commit Should Build Discussed the Mainline later today on an Integration Machine Keep the Build Fast Test in a Clone of the Production Environment Make it Easy for Anyone to Get the Latest Executable Everyone can see what's happening Automate Deployment
An example tool for CI: Jenkins 44 Very commonly used open source tool Run build (e.g. Ant) and automatic test (e.g. Junit) scripts Integrates with very many version management systems Can be triggered automatically by version management Can be triggered by sending email Build running in batch mode users can see the status Let look at tutorial at: http://www.vogella.com/tutorials/jenkins/article.html There will be a weekly exercise (16.3)!
Continuous delivery and deployment (http://blog.crisp.se/2013/02/05/yassalsundman/continuous-delivery-vscontinuous-deployment) 45
A/B Testing 46 Should our project have A or B? Implement a way to collect statistics Usage statistics Compare Usage statistics Implement B Implement A Deploy B Deploy A
Background info what is DevOps 47 DevOps is about faster deployment of new innovations by combining technology, culture, practices and processes Some factors (sources: wikipedia, http://dev2ops.org) Use agile methodologies Demand for an increased rate of production releases Cloud infrastructure from internal and external providers Unified tools / unified processes Business need Development Operation Agile DevOps See: http://dev2ops.org Marketing video: www.youtube.com/watch?v=v6drgbg-w40 (Nicole Forsgren - DevOps and the Bottom Line)
Summary of the demo Integrated pipeline from coding to deployment and operation Edit Build Test Deploy 48 Operate The developer just needs a browser. No SW installation needed. Deployment to brokered cloud: system finds the most suitable provider and deploys there
App Developer Architecture that delivers from the developers to users 49 Develop code (using web-based IDE) App users Commit Source code repository Build Test Public or Private PaaS runtimes Package Project configuration Reporting Cloud-based Continuous Integration COAP S Deploy App
50
Concrete example Need-For-Speed How to ensure fast pipeline for continuous deployment? We have worked on real data/projects/companies Does the agile process work as it should? Nature of changes, changing role of developers? Project mgmt, Issue tracking Codin g Version mgmt Build Testing Deployment Use Are there particular reasons for problems (delays) Are right tests done in right place to maximize speed? 51
Example visualization 52
Material 53 Martin Fowler: Continuous Integration http://martinfowler.com/articles/continuousintegration.html Ashish Kumar: Development at the Speed and Scale of Google (Presentation + Video) http://www.infoq.com/presentations/development-at- Google#.TuYqU_kvSuI.email Tero Piirainen: Continuous Delivery or: How I Learned to Stop Worrying about Releasing and started to Love my Customers Keynote by prof Jan Bosch, http://www.tut.fi/fi/tietoayliopistosta/laitokset/tietotekniikka/laitoksenesittely/tapahtumia/viksut-vekottimet/index.htm Web page of need for speed project http://www.n4s.fi/en/