SOFTWARE ENGINEERING IT 0301 Semester V B.Nithya,G.Lakshmi Priya Asst Prof SRM University, Kattankulathur School of Computing, Department of IT 1
School of Computing, Department 2 SOFTWARE CHANGE Software change is inevitable Adaptive Preventive Perfective Corrective A key problem for organisations is implementing and managing change to their legacy systems
Program evolution dynamics Program evolution dynamics is the study of the processes of system change After major empirical study, Lehman and Belady proposed that there were a number of laws which applied to all systems as they evolved There are sensible observations rather than laws. They are applicable to large systems developed by large organisations. Perhaps less applicable in other cases School of Computing, Department 3
School of Computing, Department 4 Lehman s laws Law Description Continuing change A program that is used in a real-world environme necessarily must change or become progressively le useful in that environment. Increasing complexity As an evolving program changes, its structure tend to become more complex. Extra resources must be devoted to preserving and simplifying the struct Large program evolutionprogram evolution is a self-regulating process. System attributes such as size, time between relea and the number of reported errors are approxima invariant for each system release. Organisational stabilityover a program s lifetime, its rate of developme approximately constant and independent of the resources devoted to system development. Conservation of Over the lifetime of system, a the incremental chan familiarity in each release is approximately constant.
School of Computing, Department 5 Applicability of lehman s laws This has not yet been established They are generally applicable to large, tailored systems developed by large organisations It is not clear how they should be modified for Shrink wrapped software products Systems that incorporate a significant number of COTS components Small organisations Medium sized systems
School of Computing, Department 6 Types of maintenance Maintenance to repair software faults Changing a system to correct deficiencies in the way meets its requirements Maintenance to adapt software to a different operating environment Changing a system so that it operates in a different environment (computer, OS, etc.) from its initial implementation Maintenance to add to or modify the system s
Distribution of effort School of Computing, Department 7
Spiral maintenance model School of Computing, Department 8
School of Computing, Department 9 Maintenance costs Usually greater than development costs (2* to 100* depending on the application) Affected by both technical and non technical factors Increases as software is maintained. Maintenance corrupts the software structure so makes further maintenance more difficult. Ageing software can have high support costs (e.g. old languages, compilers etc.)
Development/maintenance costs School of Computing, Department 10
Maintenance cost factors Team stability Maintenance costs are reduced if the same staff are involved with them for some time Contractual responsibility The developers of a system may have no contractual responsibility for maintenance so there is no incentive to design for future change Staff skills Maintenance staff are often inexperienced and have limited domain knowledge School of Computing, Department 11
Maintenance process School of Computing, Department 12
Change implementation School of Computing, Department 13
Emergency repair School of Computing, Department 14
Maintenance prediction Maintenance prediction is concerned with assessing which parts of the system may cause problems and have high maintenance costs Change acceptance depends on the maintainability of the components affected by the change Implementing changes degrades the system and reduces its maintainability Maintenance costs depend on the number of changes and costs of change depend on maintainability School of Computing, Department 15
Maintenance prediction School of Computing, Department 16
School of Computing, Department 17 Legacy system structure Ideally, for distribution, there should be a clear separation between the user interface, the system services and the system data management In practice, these are usually intermingled in older legacy systems
School of Computing, Department 18 Documentation Requirements General requirements of all software documentation Should provide for communication among team members Should act as an information repository to be used by maintenance engineers Should provide enough information to management to allow them to perform all program management related activities Should describe to users how to operate and administer the system
School of Computing, Department 19 Documentation Requirements In all software projects some amount of documentation should be created prior to any code being written Design docs, etc. Documentation should continue after the code has been completed User s manuals, etc. The two main types of documentation created are Processand Product documents
School of Computing, Department 20 Process Documentation Used to record and track the development process Planning documentation Cost, Schedule, Funding tracking Schedules Standards Etc. This documentation is created to allow for successful management of a software product
School of Computing, Department 21 Process Documentation Has a relatively short lifespan Only important to internal development process Except in cases where the customer requires a view into this data Some items, such as papers that describe design decisions should be extracted and moved into the product documentation category when they become implemented
Product Documentation Describes the delivered product Must evolve with the development of the software product Two main categories: System Documentation User Documentation School of Computing, Department 22
Product Documentation System Documentation Describes how the system works, but not how to operate it Examples: Requirements Spec Architectural Design Detailed Design Commented Source Code Including output such as JavaDoc Test Plans Including test cases V&V plan and results List of Known Bugs School of Computing, Department 23
School of Computing, Department 24 Product Documentation User Documentation has two main types End User System Administrator In some cases these are the same people The target audience must be well understood!
School of Computing, Department 25 Product Documentation There are five important areas that should be documented for a formal release of a software application These do not necessarily each have to have their own document, but the topics should be covered thoroughly 1. Functional Description of the Software 2. Installation Instructions 3. Introductory Manual 4. Reference Manual 5. System Administrator s Guide
School of Computing, Department 26 Document Quality Providing thorough and professional documentation is important for any size product development team The problem is that many software professionals lack the writing skills to create professional level documents
School of Computing, Department 27 Document Structure All documents for a given product should have a similar structure A good reason for product standards The IEEE Standard for User Documentation lists such a structure It is a superset of what most documents need The authors best practices are: 1. Put a cover page on all documents 2. Divide documents into chapters with sections and subsections 3. Add an index if there is lots of reference information 4. Add a glossary to define ambiguous terms
School of Computing, Department 28 Standards Standards play an important role in the development, maintenance and usefulness of documentation Standards can act as a basis for quality documentation But are not good enough on their own Usually define high level content and organization Three types Process, Product & Interchange
School of Computing, Department 29 Document Preparation Covers the entire process of creating and formatting a document for publication Author recommends using specialized (and separate) tools for creating and preparing documents This is only important for user documentation It is often important to have a professional writer or document publisher evaluate documents before publication to ensure they look good and will carry over to paper well
School of Computing, Department 30 Document Storage Earlier File System to store the actual documents Database to store references to the files with metadata to allow searching and referencing Today it is probably better to use a content management systems CVS or Subversion Free and Open Source Easy to setup and maintain
School of Computing, Department 31 bibliography Software Engineering, Roger Pressman, Fifth Edition Software Engineering, Ian Sommerville, Sixth Edition
School of Computing, Department 32 Review questions Different types of maintenance? Why do you think maintenance is inevitable? Three phases of maintenance prediction? What are the two types of software documentation? Why do you think we should document a software?