h(p://home.hit.no/~hansha/?page=so3ware_development So3ware Maintenance Hans- Pe(er Halvorsen, M.Sc.
Deployment Maintenance Planning TesIng ImplementaIon The So3ware Development Lifecycle Requirements Analysis Design
So3ware Releases Before the so3ware is released Alpha Release(s) Beta Release(s) RC - Release Candidate(s) RTM Release To Manufactoring Maintenance (a3er the so3ware is released) Patches (small fixes) SP - Service Packs (lots of small fixes and pathes bundle together) Start Planning next release 3
Example: Windows Timeline/Lifecycle 4
So3ware Development is a never ending story! MS- DOS (1981) Windows 1.0 (1985) Windows 3.0 (1990),, Windows NT (1993),, Windows XP (2001), Windows 7 (2009), Windows 8 Windows 8 (2012), Windows 8.1 (2013), Windows 8.1 Update (2014)
Example - Windows 8 Start planning and development of Windows 8, 2008/2009 (the planning started before Windows 7 was released) Internal Builds xxxx xxxx Internal Alpha versions, Alpha 1, 2, 3 Internal Builds xxxx xxxx Internal Milestone1 Release (build 7850), 2010.09.22 Internal Milestone2 (build 7955), Milestone3 (build 7989) Developer Preview (build 8102), 2011.09.13 Internal Builds xxxx xxxx Consumer Preview (build 8250), 2012.02.29 Internal Builds xxxx xxxx Release Preview (build 8400), 2012.05.28 Internal Builds xxxx xxxx major.minor.maintenance.build RTM Release (build 9200), 2012.08.01 It is normal to build the so3ware automaically every night, ready for internal tester the day a3er
Maintenace It makes it easier to maintain your hardware/so3ware when it looks like this J 7
So3ware Maintenance The process of modifying a so3ware system or component a3er delivery to correct faults, improve performance or other a(ributes, or adapt to a changed environment 40-90% of the so3ware life cycle cost Examples: Y2K problem New versions of the OS requires o3en adjustment to your so3ware New requirements and customer needs E. J. Braude and M. E.Bernstein, So1ware Engineering: Modern Approaches, 2 ed.: Wiley, 2011. 8
Maintenance Bugfixes, Patches, Service Packs, New Releases, etc. How to make the updated so3ware availible to the customers Support Start Planning new Releases etc. 9
Maintenace So3ware has bugs (Bug /Support incidents need to be tracked and followed up - > A good tool is needed). New features are required. Circumstances change. Therefore so3ware is changed. Who changes it? Development team broken up, maintenance may be done by different company! Repeated change leads to architectural degradaion. Old systems may have been degraded from the start! So3ware rots. Even with no code changes, the systems change, and eventually you can't compile the so3ware. 10
So3ware Maintenance Types of Maintenance: Repair Fixing defects/bugs Enhancement New Requirements Change in Design or ImplementaIon (No funcional change) E. J. Braude and M. E.Bernstein, So1ware Engineering: Modern Approaches, 2 ed.: Wiley, 2011. 11
So3ware Maintenance SoFware Maintenance CorrecBve AdapBve PerfecBve PrevenBve Bugfixing Enhancing exising funcionality Coping with a changing world Improving maintainability 12
PerfecBve PrevenBve So3ware Maintenance 4 Categories (according to So1ware Engineering: Modern Approaches): CorrecBve Repair of defects relaive to exising requirements. These defects are typically discovered by customers as they start using your so3ware. AdapBve Adapt your so3ware to changes in the operaiong environment, e.g., when a new OS is released or a new version of the hardware. As so3ware systems evolve, it is very likely that it will occure changes in the external environment (OS, hardware, etc.) your so3ware depends on. New features based on new user requests The so3ware must coninuously adapt new needs or your so3ware will become usesless. Changes in your so3ware to make it easier to maintain Changes from CorrecIve, AdapIve and PerfecIve makes your so3ware more complex, more difficult to maintain, etc. PrevenIve maintenance in form of Refactoring should be done on a regular basis E. J. Braude and M. E.Bernstein, So1ware Engineering: Modern Approaches, 2 ed.: Wiley, 2011.
So3ware Maintenance 3 Categories (according to I. Sommerville, So1ware Engineering): 1. Fault Repairs Fixing Errors a3er Sofware is released 2. Environmental AdapBon OS,Hardware, etc. changes 3. FuncBonality AddiBon The System Requirments change I. Sommerville, So1ware Engineering, 9 ed.: Pearson, 2010.
Exercise Maintenance Give some examples of typical Maintenance in the different categories CorrecIve AdapIve PerfecIve PrevenIve - Fault Repairs - Environmental AdapIon - FuncIonality AddiIon
Support B. Lund. (2013). Lunch. Available: h(p://www.lunchstriper.no, h(p://www.dagbladet.no/tegneserie/lunch/ To handle support requests from customers are criical Its important to keep the Customers happy, or they will not pay for it, buy new versions, etc. More bugs, more support 16
So3ware EvoluIon and Release Management Discipline in the evoluion of so3ware is (at least) as important as in its development. Gather change requirements: new features, adaping to system/business change, bug reports Evaluate each; produce proposed list of changes Go through normal development cycle to implement changes - ensuring that you understand the so3ware, which may be non- trivial. Issue new release Unfortunately, emergencies happen, and things have to be done with urgency. If at all possible, go through the normal process a3erwards. 17
Exercise Maintenance Create a List of Features that you want to include in your next release of your ApplicaIon
References I. Sommerville, So1ware Engineering, 9 ed.: Pearson, 2010. E. J. Braude and M. E.Bernstein, So1ware Engineering: Modern Approaches, 2 ed.: Wiley, 2011. Wikipedia. (2013). So1ware Deployment. Available: h(p://en.wikipedia.org/wiki/so3ware_deployment S. Adams. Dilbert. Available: h(p://dilbert.com O. Widder. (2013). geek&poke. Available: h(p://geek- and- poke.com B. Lund. (2013). Lunch. Available: h(p://www.lunchstriper.no, h(p://www.dagbladet.no/tegneserie/ lunch/ The University of Edinburgh, School of InformaIcs: h(p://www.inf.ed.ac.uk/teaching/courses/inf2c- se 19
Hans- PeNer Halvorsen, M.Sc. Telemark University College Faculty of Technology Department of Electrical Engineering, InformaBon Technology and CyberneBcs E- mail: hans.p.halvorsen@hit.no Blog: hnp://home.hit.no/~hansha/ 20