1 Martin Glinz Harald Gall Software Engineering Kapitel 12 Software Evolution und Reengineering! 2010, 2011 Harald Gall. Alle Rechte vorbehalten. Speicherung und Wiedergabe für den persönlichen, nicht kommerziellen Gebrauch gestattet; bei auszugsweiser Verwendung mit Quellenangabe. Verwendung für Unterrichtszwecke oder kommerziellen Gebrauch nur mit vorheriger schriftlicher Genehmigung des Autors.!
3 Objectives! To explain why change is inevitable if software systems are to remain useful! To discuss software maintenance and maintenance cost factors! To describe the processes involved in software evolution! To discuss an approach to assessing evolution strategies for legacy systems! 3!
4 Software change! Software change is inevitable! New requirements emerge when the software is used;! The business environment changes;! Errors must be repaired;! New computers and equipment is added to the system;! The performance or reliability of the system may have to be improved.! A key problem for organisations is implementing and managing change to their existing software systems.! 4!
5 12.1!Software Evolution! Organizations have huge investments in their software systems - they are critical business assets.! To maintain the value of these assets to the business, they must be changed and updated.! The majority of the software budget in large companies is devoted to evolving existing software rather than developing new software.! 5!
6 Spiral model of evolution! 6!
7 Program evolution dynamics! Program evolution dynamics is the study of the processes of system change.! After major empirical studies, 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.! 7!
8 Lehmanʼs laws! 8!
9 Lehmanʼs system types! [also see Chapter 13]! S-system: formally defined, derivable from a specification! P-system: requirements based on approximate solution to a problem, but real-world remains stable! E-system: embedded in the real world and changes as the world does! Software Engineering!Kapitel 12: Software Evolution und Reengineering! 2011 H. Gall! 9!
10 Applicability of Lehmanʼs laws! Lehmanʼs laws seem to be generally applicable to large, tailored systems developed by large organisations.! Confirmed in more recent work by Lehman on the FEAST project ( It is open how they should be modified for! Shrink-wrapped software products;! Systems that incorporate a significant number of COTS components;! Small organisations;! Medium sized systems.! 10!
11 12.2!Software Maintenance! Modifying a program after it has been put into use.! Maintenance does not normally involve major changes to the systemʼs architecture.! Changes are implemented by modifying existing components and adding new components to the system.! 11!
12 Maintenance is inevitable! The system requirements are likely to change while the system is being developed because the environment is changing. Therefore a delivered system won't meet its requirements!! Systems are tightly coupled with their environment. When a system is installed in an environment it changes that environment and therefore changes the system requirements.! Systems MUST be maintained therefore if they are to remain useful in an environment.! 12!
13 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 functionality! Modifying the system to satisfy new requirements.! 13!
14 ISO/IEC maintenance types! Corrective maintenance: Reactive modification of a software product performed after delivery to correct discovered problems.! Adaptive maintenance: Modification of a software product performed after delivery to keep a software product usable in a changed or changing environment.! Perfective maintenance: Modification of a software product after delivery to improve performance or maintainability.! Preventive maintenance: Modification of a software product after delivery to detect and correct latent faults in the software product before they become effective faults.! 14!
15 Maintenance effort! 15!
16 System evolution vs. decline! Is the cost of maintenance too high?! Is the system reliability unacceptable?! Can the system no longer adapt to further change, and within a reasonable amount of time?! Is system performance still beyond prescribed constraints?! Are system functions of limited usefulness?! Can other systems do the same job better, faster or cheaper?! Is the cost of maintaining the hardware great enough to justify replacing it with cheaper, newer hardware?! 16!
17 Maintenance team responsibilities! understanding the system! locating and correcting faults! locating information in system documentation! keeping system documentation up-to-date! extending existing functions to accommodate new or changing requirements! adding new functions to the system! finding the source of system failures or problems! answering questions about the way the system works! restructuring design and code components! rewriting design and code components! deleting design and code components that are no longer useful! managing changes to the system as they are made! 17!
19 Factors affecting maintenance effort! Application type! System novelty! Turnover and maintenance staff ability! System life span! Dependence on a changing environment! Hardware characteristics! Design quality! Code quality! Documentation quality! Testing quality! 19!
20 Measuring maintainability! Necessary data:! time at which problem is reported! time lost due to administrative delay! time required to analyze problem! time required to specify which changes are to be made! time needed to make the change! time needed to test the change! time needed to document the change! Desirable data:! ratio of total change implementation time to total number of changes implemented! number of unresolved problems! time spent on unresolved problems! percentage of changes that introduce new faults! number of components modified to implement a change! 20!
21 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.).! 21!
22 Development/maintenance costs! 22!
23 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.! Program age and structure! As programs age, their structure is degraded and they become harder to understand and change.! 23!
24 Modeling Maintenance Effort (1)! Belady and Lehman equation:! M = p + K c-d! M... total maintenance effort,! p... productive efforts,! c... complexity caused by lack of structured design and documentation,! d... c reduced by d, the degreee to which the maintenance team is familiar with the software! K... empirical constant determined by comparing this model with the effort relationships on actual projects! 24!
25 Modeling Maintenance Effort (2)! COCOMO II:! Size = ASLOC (AA + SU +0.4*DM +0.3*CM + 0.3*IM) /100! ASLOC... number of source lines to be adapted! DM... percentage of design to be modified! CM... percentage of code to be modified! IM... percentage of external code (e.g. reuse code) to be integrated! SU... rating scale representing the amount of software understanding required (Table 11.2)! AA... assessment and assimiliation effort to assess code and make changes (Table 11.3)! 25!
26 COCOMO II - Software Understanding! Structure Application clarity Very low Low Nominal High Very high Very low cohesion, high coupling, spaghetti code No match between program and application world views Moderately low cohesion, high coupling Some correlation between program and application Reasonably wellstructured; some weak areas Moderate correlation between program and application High cohesion, low coupling Good correlation between program and application Strong modularity, informationhiding in data and control structures Clear match between program and application world views Selfdescriptiveness Obscure code; documentation missing, obscure or obsolete Some code commentary and headers; some useful documentation Moderate level of code commentary, headers, documentation Good code commentary and headers; useful documentation; some weak areas SU increment Self-descriptive code; documentation up-to-date, well-organized, with design rationale Table COCOMO II rating for software understanding 26!
27 COCOMO II - Assessment & Assimilation! Table COCOMO II ratings for assessment and assimilation effort. Assessment and assimilation increment Level of assessment and assimilation effort 0 None 2 Basic component search and documentation 4 Some component test and evaluation documentation 6 Considerable component test and evaluation documentation 8 Extensive component test and evaluation documentation 27!
28 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.! 28!
29 Maintenance prediction! 29!
30 Change prediction! Predicting the number of changes requires an understanding of the relationships between a system and its environment.! Tightly coupled systems require changes whenever the environment is changed.! Factors influencing this relationship are! Number and complexity of system interfaces;! Number of inherently volatile system requirements;! The business processes where the system is used.! 30!
31 Complexity metrics! Predictions of maintainability can be made by assessing the complexity of system components.! Studies have shown that most maintenance effort is spent on a relatively small number of system components.! Complexity depends on! Complexity of control structures;! Complexity of data structures;! Object, method (procedure) and module size.! 31!
32 Process metrics! Process measurements may be used to assess maintainability! Number of requests for corrective maintenance;! Average time required for impact analysis;! Average time taken to implement a change request;! Number of outstanding (queued) change requests.! If any or all of these is increasing, this may indicate a decline in maintainability.! 32!
33 12.3!Software Evolution Processes! Evolution processes depend on! The type of software being maintained;! The development processes used;! The skills and experience of the people involved.! Proposals for change are the driver for system evolution! Change identification and evolution continue throughout the system lifetime.! 33!
34 Change identification and evolution! 34!
35 The system evolution process! 35!
36 Change implementation! 36!
37 Urgent change requests! Urgent changes may have to be implemented without going through all stages of the software engineering process! If a serious system fault has to be repaired;! If changes to the systemʼs environment (e.g. an OS upgrade) have unexpected effects;! If there are business changes that require a very rapid response (e.g. the release of a competing product).! 37!
38 Emergency repair! 38!
39 Configuration control process! Problem discovered by or change requested by user/ customer/developer, and recorded! Change reported to the Configuration Control Board (CCB)! CCB discusses problem: determines nature of change, who should pay! CCB discusses source of problem, scope of change, time to fix; they assign severity/priority and analyst to fix! Analyst makes change on test copy! Analyst works with librarian to control installation of change! Analyst files change report! 39!
40 Change control issues! Synchronization: When was the change made?! Identification: Who made the change?! Naming: What components of the system were changed?! Authentication: Was the change made correctly?! Authorization: Who authorized that the change be made?! Routing: Who was notified of the change?! Cancellation: Who can cancel the request for change?! Delegation: Who is responsible for the change?! Valuation: What is the priority of the change?! 40!
41 Impact analysis! Impact analysis is the evaluation of the many risks associated with the change, including estimates of effects on ressources, effort, and schedule.! Workproduct! any development artifact whose change is significant, e.g. requirements, design and code components, test cases, etc.! the quality of one can affect the quality of others! Horizontal traceability! relationships of components across collections of workproducts! Vertical traceability! relationships among parts of a workproduct! 41!
42 Interface change impact! Example: m components, we need to change k, we have to consider! k * (m - k) + k*( k - 1 ) / 2! interfaces!! 42!
48 Software Rejuvenation! Redocumentation: static analysis adds more information! Restructuring: transform to improve code structure! Reverse engineering: recreate design and specification information from the code! Reengineering: reverse engineer and then make changes to specification and design to complete the logical model; then generate new system from revised specification and design! 48!
49 Taxonomy of software rejuvenation! 49!
50 Reverse Engineering! 50!
51 Redocumentation! Output may include:! component calling relationships! data-interface tables! data-dictionary information! data flow tables or diagrams! control flow tables or diagrams! pseudocode! test paths! component and variable cross-references! 51!
52 Reengineering! Restructuring or re-writing part or all of a legacy system plus changing its functionality according to new requirements! Applicable where some but not all sub-systems of a larger system require frequent maintenance.! Reengineering involves adding effort to make them easier to maintain. The system may be re-structured and redocumented.! = Reverse Engineering + Delta + Forward Engineering! 52!
53 Reengineering! 53!
54 Advantages of Reengineering! Reduced risk! There is a high risk in new software development. There may be development problems, staffing problems and specification problems.! Reduced cost! The cost of re-engineering is often significantly less than the costs of developing new software.! e.g. Object-oriented Reengineering Patterns! 54!
55 Forward and Re-Engineering! 55!
56 The Reengineering process! 56!
57 Reengineering process activities! Source code translation! Convert code to a new language.! Reverse engineering! Analyze the program to understand it;! Program structure improvement! Restructure automatically for understandability;! Program modularization! Reorganize the program structure;! Data reengineering! Clean-up and restructure system data.! 57!
58 Reengineering approaches! 58!
59 Reengineering cost factors! The quality of the software to be reengineered.! The tool support available for reengineering.! The extent of the data conversion which is required.! The availability of expert staff for reengineering.! This can be a problem with old systems based on technology that is no longer widely used.! 59!
60 Legacy system evolution! Organisations that rely on legacy systems must choose a strategy for evolving these systems! Scrap the system completely and modify business processes so that it is no longer required;! Continue maintaining the system;! Transform the system by re-engineering to improve its maintainability;! Replace the system with a new system.! The strategy chosen should depend on the system quality and its business value.! 60!
61 System quality and business value! 61!
62 12.5!Legacy Systems! Low quality, low business value! These systems should be scrapped.! Low-quality, high-business value! These make an important business contribution but are expensive to maintain. Should be re-engineered or replaced if a suitable system is available.! High-quality, low-business value! Replace with COTS, scrap completely or maintain.! High-quality, high business value! Continue in operation using normal system maintenance.! 62!
63 Business value assessment! Assessment should take different viewpoints into account! System end-users;! Business customers;! Line managers;! IT managers;! Senior managers.! Interview different stakeholders and collate results.! 63!
64 System quality assessment! Business process assessment! How well does the business process support the current goals of the business?! Environment assessment! How effective is the systemʼs environment and how expensive is it to maintain?! Application assessment! What is the quality of the application software system?! 64!
65 Business process assessment! Use a viewpoint-oriented approach and seek answers from system stakeholders! Is there a defined process model and is it followed?! Do different parts of the organisation use different processes for the same function?! How has the process been adapted?! What are the relationships with other business processes and are these necessary?! Is the process effectively supported by the legacy application software?! Example - a travel ordering system may have a low business value because of the widespread use of web-based ordering.! 65!
66 Environment assessment 1! 66!
67 Environment assessment 2! 67!
68 Application assessment 1! 68!
69 Application assessment 2! 69!
70 System measurement! You may collect quantitative data to make an assessment of the quality of the application system! The number of system change requests;! The number of different user interfaces used by the system;! The volume of data used by the system.! 70!
71 12.6!Summary - Key points (1)! Software development and evolution should be a single iterative process.! Lehmanʼs Laws describe a number of insights into system evolution.! Three types of maintenance are bug fixing, modifying software for a new environment and implementing new requirements.! For custom systems, maintenance costs usually exceed development costs.! 71!
72 Summary - Key points (2)! The process of evolution is driven by requests for changes from system stakeholders.! Software re-engineering is concerned with re-structuring and re-documenting software to make it easier to change.! The business value of a legacy system and its quality should determine the evolution strategy that is used.! 72!
73 References! S.L. Pfleeger, J.M. Atlee. Software Engineering: Theory and Practice, 4th edition, Pearson Education, 2010.! I. Sommerville. Software Engineering, 9th edition, Pearson Education, 2011.! S. Demeyer, S. Ducasse, O. Nierstrasz. Object-Oriented Reengineering Patterns, Morgan-Kaufmann M. Cusomano, R. Selby, Microsoft Secrets: How the World's Most Powerful Software Company Creates Technology, Shapes Markets and Manages People, Free Press, 1998.! T. Mens, S. Demeyer (Eds.), Software Evolution, Springer, 2008.! International Conference on Software Maintenance, IEEE! International Conference on Program Comprehension, IEEE! Software Engineering!Kapitel 12: Software Evolution und Reengineering! 2011 H. Gall! 73!
Software Evolution, Reengineering and Reverse Engineering King Fahd University of Petroleum & Minerals SWE 316: Software Design & Architecture Semester: 072 Objectives To explain why change is inevitable
Software Engineering So(ware Evolu1on 1 Software change Software change is inevitable New requirements emerge when the software is used; The business environment changes; Errors must be repaired; New computers
CSC408H Lecture Notes These lecture notes are provided for the personal use of students taking Software Engineering course in the Summer term 2005 at the University of Toronto. Copying for purposes other
Software change 1 27. Software Change Objectives The objectives of this chapter are to introduce software change and to describe a number of ways of modifying software. When you have read this chapter,
SE-27-Software-Change-Management-HW.doc 1 CSCI 3321 Initials Written homework will be assigned regularly throughout the semester. Since there is little or no serious programming involved in the homework,
Software Processes Objectives To introduce software process models To describe three generic process models and when they may be used To describe outline process models for requirements engineering, software
Chapter 23 Software Cost Estimation Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 1 Software cost estimation Predicting the resources required for a software development process
Configuration management Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 1 Objectives To explain the importance of software configuration management (CM) To describe key CM activities
Legacy Systems Older software systems that remain vital to an organisation Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26 Slide 1 Objectives To explain what is meant by a legacy system
Software cost estimation Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 26 Slide 1 Objectives To introduce the fundamentals of software costing and pricing To describe three metrics for
Configuration Management Software Configuration Management New versions of software systems are created as they change: For different machines/os; Offering different functionality; Tailored for particular
1.1 The Nature of Software... Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering Software is intangible Hard to understand
Software cost estimation Predicting the resources required for a software development process Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 1 Objectives To introduce the fundamentals
How to realize software evolution of existing BOSS via ZTE SEEM Zhan Zhang Abstract Due to long-term construction and accumulation for different purposes, telecom carriers normally have very complex IT
CDC UNIFIED PROCESS JOB AID Independent Verification & Validation Activities Document Purpose This Job Aid is a brief document listing the items to be noted, checked, remembered, and delivered when completing
PART A Questions 1. Mention any two software process models. 2. Define risk management. 3. What is a module? 4. What do you mean by requirement process? 5. Define integration testing. 6. State the main
Chapter 25 Configuration Management 1 Topics covered Change management Version management System building Release management 2 Configuration management Because software changes frequently, systems, can
PESIT Bangalore South Campus Department of MCA SOFTWARE ENGINEERING 1. GENERAL INFORMATION Academic Year: JULY-NOV 2015 Semester(s):III Title Code Duration (hrs) SOFTWARE ENGINEERING 13MCA33 Lectures 52Hrs
Software Maintenance Software Maintenance (Chapter 14) Mark van den Brand Tom Verhoeff Main issues:! why maintenance is such an issue! reverse engineering and its limitations! how to organize maintenance
BCS HIGHER EDUCATION QUALIFICATIONS Level 6 Professional Graduate Diploma in IT March 2013 EXAMINERS REPORT Software Engineering 2 General Comments The pass rate this year was significantly better than
Software Engineering So#ware Processes 1 The software process A structured set of activities required to develop a software system. Many different software processes but all involve: Specification defining
0305203 0305280 0305301 0305302 Software Engineering/Courses Description Introduction to Software Engineering Prerequisite: 0306211(Computer Programming 2). This course introduces students to the problems
Software Processes cmsc435-1 Topics covered Systems vs. software engineering Software process models Process iteration Process activities Computer-aided software engineering cmsc435-2 What is a system?
What is a life cycle model? Framework under which a software product is going to be developed. Defines the phases that the product under development will go through. Identifies activities involved in each
Renaissance: A Method to Support Software System Evolution Ian Warren and Jane Ransom Computing Department Lancaster University Lancaster, LA1 4YR, UK Email iw email@example.com Abstract Legacy s are
Legacy systems 1 26. Legacy Systems Objectives The objectives of this chapter are to introduce legacy systems and to describe how many of these systems have been designed. When you have read this chapter,
Software cost estimation Sommerville Chapter 26 Objectives To introduce the fundamentals of software costing and pricing To describe three metrics for software productivity assessment To explain why different
Software Development Life Cycle (SDLC) Supriyo Bhattacharjee MOF Capability Maturity Model (CMM) A bench-mark for measuring the maturity of an organization s software process CMM defines 5 levels of process
Java Programming (10155) Rationale Statement: The world is full of problems that need to be solved or that need a program to solve them faster. In computer, programming students will learn how to solve
Software development life cycle Software life cycle: Software Engineering - II ITNP92 - Object Oriented Software Design Dr Andrea Bracciali Module Co-ordinator 4B86 firstname.lastname@example.org Spring 2014 (elicitation)
CHAPTER 27 CHANGE MANAGEMENT Overview Changes are inevitable when software is built. A primary goal of software engineering is to improve the ease with which changes can be made to software. Configuration
Software Reengineering 1 28. Software Re-engineering Objectives The objective of this chapter is to explain the process of software reengineering to improve the maintainability of a software system. When
Design with Reuse Building software from reusable components. Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14 Slide 1 Objectives To explain the benefits of software reuse and some reuse
Overview Hatha Systems Knowledge Refinery (KR) represents an advanced technology providing comprehensive analytical and decision support capabilities for the large-scale, complex, mission-critical applications
SOFTWARE DEVELOPMENT STANDARD FOR SPACECRAFT Mar 31, 2014 Japan Aerospace Exploration Agency This is an English translation of JERG-2-610. Whenever there is anything ambiguous in this document, the original
Peter Mileff PhD SOFTWARE ENGINEERING The Basics of Software Engineering University of Miskolc Department of Information Technology Introduction Péter Mileff - Department of Information Engineering Room
Rapid software development Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 17 Slide 1 Objectives To explain how an iterative, incremental development process leads to faster delivery of
Objective Software Project Measurements Slide 1 Fundamentals of Measurements Educational Objective: To review the fundamentals of software measurement, to illustrate that measurement plays a central role
Process Models and Metrics PROCESS MODELS AND METRICS These models and metrics capture information about the processes being performed We can model and measure the definition of the process process performers
Taming the complexity: The need for program understanding in software engineering Raghvinder S. Sangwan, Ph.D. Pennsylvania State University, Great Valley School of Graduate Professional Studies Robert
Software Engineering Socio-Technical Systems Based on Software Engineering, 7 th Edition by Ian Sommerville Objectives To explain what a socio-technical system is and the distinction between this and a
SOE managing change in system development projects: configuration management 2 3 understanding the problem of change change is one of the most fundamental characteristics in any software development process
Systems Engineering Designing, implementing, deploying and operating systems which include hardware, software and people Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 2 Slide 1 Objectives
2. Analysis, Design and Implementation Subject/Topic/Focus: Software Production Process Summary: Software Crisis Software as a Product: From Programs to Application Systems Products Software Development:
2012 Systems and Software Technology Conference Software Sustainability Challenges for Acquisition, Engineering, and Capability Delivery in the Face of the Growing Cyber Threat Paul R. Croll Fellow CSC
Process Methodology for Wegmans Deli Kiosk Version 1.0 Prepared by DELI-cious Developers Rochester Institute of Technology September 15, 2013 1 Table of Contents 1. Process... 3 1.1 Choice... 3 1.2 Description...
Software Engineering Prof. N. L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture - 2 Introduction to Software Engineering Challenges, Process Models etc (Part 2) This
Rapid software development 1 Objectives To explain how an iterative, incremental development process leads to faster delivery of more useful software To discuss the essence of agile development methods
IV. Software Lifecycles Software processes and lifecycles Relative costs of lifecycle phases Examples of lifecycles and processes Process maturity scale Information system development lifecycle Lifecycle
Software Processes Objectives To introduce software process models To describe three generic process models and when they may be used To describe outline process models for requirements engineering, software
Introduction Why Measure? What to Measure? It is often said that if something cannot be measured, it cannot be managed or improved. There is immense value in measurement, but you should always make sure
Project management: an SE Perspective Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 5 Slide 1 Objectives To explain the main tasks undertaken by project managers To introduce software
Systems Analysis and Design in a Changing World, Fourth Edition Learning Objectives Describe implementation and support activities Choose an appropriate approach to program development Describe various
Central Page 284 of 296 Application of software product quality international standards through software development life cycle Mladen Hosni, Valentina Kirinić Faculty of Organization and Informatics University
University of Dublin Trinity College ST3006 - Software Engineering Anthony Harrington Department of Computer Science Trinity College Dublin Anthony.Harrington@cs.tcd.ie Lifecycles A software project goes
CMP2101 Software Engineering Period per Week Contact Hour per Semester Total Mark Exam Mark Continuous Assessment Mark Credit Units LH PH TH CH WTM WEM WCM CU 45 00 30 60 100 40 100 4 Rationale Software
Software Development Life Cycle (SDLC) and Development Methods There are some enterprises in which a careful disorderliness is the true method. Herman Melville Capability Maturity Model (CMM) A Capability
Robust Object Oriented System Analysis Dr Jie Zhao, Dunstan Thomas Consulting Summary Uses cases are widely accepted as the best approach to capturing system requirements, in particular, functional requirements.
Processing Models Of SDLC Mrs. Nalkar Sanjivani Baban Asst. Professor, IT/CS Dept, JVM s Mehta College,Sector 19, Airoli, Navi Mumbai-400708 Nalkar_sanjivani@yahoo.co.in Abstract This paper presents an
Software Process Models Xin Feng Questions to Answer in Software Engineering? Questions to answer in software engineering What is the problem to be solved? Definition What are the characteristics of the
INTRODUCTION : Fundamentals of Software Engineering (Compulsory) This course is designed to provide the students with the basic competencies required to identify requirements, document the system design
Trends in Embedded Software Development in Europe Dr. Dirk Muthig email@example.com Problems A software project exceeds the budget by 90% and the project time by 120% in average Project Management
Empirical study of Software Quality Evaluation in Agile Methodology Using Traditional Metrics Kumi Jinzenji NTT Software Innovation Canter NTT Corporation Tokyo, Japan firstname.lastname@example.org Takashi
Project Planning COSC345 Lecture 3 Slides: Andrew Trotman Dramatic presentation: Richard O Keefe Software Engineering 2013 Overview Assignment: The assignment sheet specifies a minimum Think about what
White paper June 2009 Ten steps to better requirements management. Dominic Tavassoli, IBM Actionable enterprise architecture management Page 2 Contents 2 Introduction 2 Defining a good requirement 3 Ten
Office of Safety and Mission Assurance NASA-GB-9503 SOFTWARE CONFIGURATION MANAGEMENT GUIDEBOOK AUGUST 1995 National Aeronautics and Space Administration Washington, D.C. 20546 PREFACE The growth in cost
Service Oriented Architecture and the DBA Kathy Komer Aetna Inc. New England DB2 Users Group Tuesday June 12 1:00-2:15 Service Oriented Architecture and the DBA What is Service Oriented Architecture (SOA)
Software Management Cost Estimation Managing People Management Poor managment is the downfall of many software projects Ð Delivered software was late, unreliable, cost several times the original estimates
Object-Oriented Software Development What is Object-Oriented Development Object-Oriented vs. Traditional Development An Object-Oriented Development Framework Phases, Activities, and Work Products Phases,
Appendix M INFORMATION TECHNOLOGY (IT) YOUTH APPRENTICESHIP PROGRAMMING & SOFTWARE DEVELOPMENT AND INFORMATION SUPPORT & SERVICES PATHWAY SOFTWARE UNIT UNIT 5 Programming & and Support & s: (Unit 5) PAGE
F A C T S H E E T Change request and defect management for the application life cycle TrackRecord is an advanced change request and defect management tool that helps organizations establish a systematic
Towards Collaborative Requirements Engineering Tool for ERP product customization Boban Celebic, Ruth Breu, Michael Felderer, Florian Häser Institute of Computer Science, University of Innsbruck 6020 Innsbruck,
JOURNAL OF OBJECT TECHNOLOGY Online at http://www.jot.fm. Published by ETH Zurich, Chair of Software Engineering JOT, 2007 Vol. 6, No. 1, January-February 2007 CM Configuration Change Management John D.
The document in this file is adapted from the IEEE standards for Software Project Management Plans, 1058-1998, which conforms to the requirements of ISO standard 12207 Software Life Cycle Processes. Tailor
Software Engineering Objectives Designing, building and maintaining large software systems To define software engineering and explain its importance To discuss the concepts of software products and software