We think you have liked this presentation. If you wish to download it, please recommend it to your friends in any social system. Share buttons are a little bit lower. Thank you!
Presentation is loading. Please wait.
Published byJulian Bowen
Modified over 3 years ago
Slide 1.1 © The McGraw-Hill Companies, 2007 Object-Oriented and Classical Software Engineering Seventh Edition, WCB/McGraw-Hill, 2007 Stephen R. Schach
Slide 1.2 © The McGraw-Hill Companies, 2007 CHAPTER 1 THE SCOPE OF SOFTWARE ENGINEERING
Slide 1.3 © The McGraw-Hill Companies, 2007 Outline Historical aspects Economic aspects Maintenance aspects Requirements, analysis, and design aspects Team development aspects Why there is no planning phase
Slide 1.4 © The McGraw-Hill Companies, 2007 Outline (contd) Why there is no testing phase Why there is no documentation phase The object-oriented paradigm The object-oriented paradigm in perspective Terminology Ethical issues
Slide 1.5 © The McGraw-Hill Companies, Historical Aspects 1968 NATO Conference, Garmisch, Germany Aim: To solve the software crisis Software is delivered Late Over budget With residual faults
Slide 1.6 © The McGraw-Hill Companies, 2007 Standish Group Data Data on 9236 projects completed in 2004 Figure 1.1
Slide 1.7 © The McGraw-Hill Companies, 2007 Cutter Consortium Data 2002 survey of information technology organizations 78% have been involved in disputes ending in litigation For the organizations that entered into litigation: In 67% of the disputes, the functionality of the information system as delivered did not meet up to the claims of the developers In 56% of the disputes, the promised delivery date slipped several times In 45% of the disputes, the defects were so severe that the information system was unusable
Slide 1.8 © The McGraw-Hill Companies, 2007 Conclusion The software crisis has not been solved Perhaps it should be called the software depression Long duration Poor prognosis
Slide 1.9 © The McGraw-Hill Companies, Economic Aspects Coding method CM new is 10% faster than currently used method CM old. Should it be used? Common sense answer Of course! Software Engineering answer Consider the cost of training Consider the impact of introducing a new technology Consider the effect of CM new on maintenance
Slide 1.10 © The McGraw-Hill Companies, Maintenance Aspects Life-cycle model The steps (phases) to follow when building software A theoretical description of what should be done Life cycle The actual steps performed on a specific product
Slide 1.11 © The McGraw-Hill Companies, 2007 Waterfall Life-Cycle Model Classical model (1970) Figure 1.2
Slide 1.12 © The McGraw-Hill Companies, 2007 Typical Classical Phases Requirements phase Explore the concept Elicit the clients requirements Analysis (specification) phase Analyze the clients requirements Draw up the specification document Draw up the software project management plan What the product is supposed to do
Slide 1.13 © The McGraw-Hill Companies, 2007 Typical Classical Phases (contd) Design phase Architectural design, followed by Detailed design How the product does it Implementation phase Coding Unit testing Integration Acceptance testing
Slide 1.14 © The McGraw-Hill Companies, 2007 Typical Classical Phases (contd) Postdelivery maintenance Corrective maintenance Perfective maintenance Adaptive maintenance Retirement
Slide 1.15 © The McGraw-Hill Companies, Classical and Modern Views of Maintenance Classical maintenance Development-then-maintenance model This is a temporal definition Classification as development or maintenance depends on when an activity is performed
Slide 1.16 © The McGraw-Hill Companies, 2007 Classical Maintenance Defn Consequence 1 A fault is detected and corrected one day after the software product was installed Classical maintenance The identical fault is detected and corrected one day before installation Classical development
Slide 1.17 © The McGraw-Hill Companies, 2007 Classical Maintenance Defn Consequence 2 A software product has been installed The client wants its functionality to be increased Classical (perfective) maintenance The client wants the identical change to be made just before installation (moving target problem) Classical development
Slide 1.18 © The McGraw-Hill Companies, 2007 Classical Maintenance Definition The reason for these and similar unexpected consequences Classically, maintenance is defined in terms of the time at which the activity is performed Another problem: Development (building software from scratch) is rare today Reuse is widespread
Slide 1.19 © The McGraw-Hill Companies, 2007 Modern Maintenance Definition In 1995, the International Standards Organization and International Electrotechnical Commission defined maintenance operationally Maintenance is nowadays defined as The process that occurs when a software artifact is modified because of a problem or because of a need for improvement or adaptation
Slide 1.20 © The McGraw-Hill Companies, 2007 Modern Maintenance Definition (contd) In terms of the ISO/IEC definition Maintenance occurs whenever software is modified Regardless of whether this takes place before or after installation of the software product The ISO/IEC definition has also been adopted by IEEE and EIA
Slide 1.21 © The McGraw-Hill Companies, 2007 Maintenance Terminology in This Book Postdelivery maintenance Changes after delivery and installation [IEEE 1990] Modern maintenance (or just maintenance) Corrective, perfective, or adaptive maintenance performed at any time [ISO/IEC 1995, IEEE/EIA 1998]
Slide 1.22 © The McGraw-Hill Companies, The Importance of Postdelivery Maintenance Bad software is discarded Good software is maintained, for 10, 20 years or more Software is a model of reality, which is constantly changing
Slide 1.23 © The McGraw-Hill Companies, 2007 Time (= Cost) of Postdelivery Maintenance (a) Between 1976 and 1981 (b) Between 1992 and 1998 Figure 1.3
Slide 1.24 © The McGraw-Hill Companies, 2007 The Costs of the Classical Phases Surprisingly, the costs of the classical phases have hardly changed Figure 1.4
Slide 1.25 © The McGraw-Hill Companies, 2007 Consequence of Relative Costs of Phases Return to CM old and CM new Reducing the coding cost by 10% yields at most a 0.85% reduction in total costs Consider the expenses and disruption incurred Reducing postdelivery maintenance cost by 10% yields a 7.5% reduction in overall costs
Slide 1.26 © The McGraw-Hill Companies, Requirements, Analysis, and Design Aspects The earlier we detect and correct a fault, the less it costs us
Slide 1.27 © The McGraw-Hill Companies, 2007 Requirements, Analysis, and Design Aspects (contd) Figure 1.5 The cost of detecting and correcting a fault at each phase
Slide 1.28 © The McGraw-Hill Companies, 2007 Requirements, Analysis, and Design Aspects (contd) The previous figure redrawn on a linear scale Figure 1.6
Slide 1.29 © The McGraw-Hill Companies, 2007 Requirements, Analysis, and Design Aspects (contd) To correct a fault early in the life cycle Usually just a document needs to be changed To correct a fault late in the life cycle Change the code and the documentation Test the change itself Perform regression testing Reinstall the product on the clients computer(s)
Slide 1.30 © The McGraw-Hill Companies, 2007 Requirements, Analysis, and Design Aspects (contd) Between 60 and 70% of all faults in large-scale products are requirements, analysis, and design faults Example: Jet Propulsion Laboratory inspections 1.9 faults per page of specifications 0.9 per page of design 0.3 per page of code
Slide 1.31 © The McGraw-Hill Companies, 2007 Conclusion It is vital to improve our requirements, analysis, and design techniques To find faults as early as possible To reduce the overall number of faults (and, hence, the overall cost)
Slide 1.32 © The McGraw-Hill Companies, Team Programming Aspects Hardware is cheap We can build products that are too large to be written by one person in the available time Software is built by teams Interfacing problems between modules Communication problems among team members
Slide 1.33 © The McGraw-Hill Companies, Why There Is No Planning Phase We cannot plan at the beginning of the project we do not yet know exactly what is to be built
Slide 1.34 © The McGraw-Hill Companies, 2007 Planning Activities of the Classical Paradigm Preliminary planning of the requirements and analysis phases at the start of the project The software project management plan is drawn up when the specifications have been signed off by the client Management needs to monitor the SPMP throughout the rest of the project
Slide 1.35 © The McGraw-Hill Companies, 2007 Conclusion Planning activities are carried out throughout the life cycle There is no separate planning phase
Slide 1.36 © The McGraw-Hill Companies, Why There Is No Testing Phase It is far too late to test after development and before delivery
Slide 1.37 © The McGraw-Hill Companies, 2007 Testing Activities of the Classical Paradigm Verification Testing at the end of each phase (too late) Validation Testing at the end of the project (far too late)
Slide 1.38 © The McGraw-Hill Companies, 2007 Conclusion Continual testing activities must be carried out throughout the life cycle This testing is the responsibility of Every software professional, and The software quality assurance group There is no separate testing phase
Slide 1.39 © The McGraw-Hill Companies, Why There Is No Documentation Phase It is far too late to document after development and before delivery
Slide 1.40 © The McGraw-Hill Companies, 2007 Documentation Must Always be Current Key individuals may leave before the documentation is complete We cannot perform a phase without having the documentation of the previous phase We cannot test without documentation We cannot maintain without documentation
Slide 1.41 © The McGraw-Hill Companies, 2007 Conclusion Documentation activities must be performed in parallel with all other development and maintenance activities There is no separate documentation phase
Slide 1.42 © The McGraw-Hill Companies, The Object-Oriented Paradigm The structured paradigm was successful initially It started to fail with larger products (> 50,000 LOC) Postdelivery maintenance problems (today, 70 to 80% of total effort) Reason: Structured methods are Action oriented (e.g., finite state machines, data flow diagrams); or Data oriented (e.g., entity-relationship diagrams, Jacksons method); But not both
Slide 1.43 © The McGraw-Hill Companies, 2007 The Object-Oriented Paradigm (contd) Both data and actions are of equal importance Object: A software component that incorporates both data and the actions that are performed on that data Example: Bank account Data :account balance Actions: deposit, withdraw, determine balance
Slide 1.44 © The McGraw-Hill Companies, 2007 Structured versus Object-Oriented Paradigm Information hiding Responsibility-driven design Impact on maintenance, development Figure 1.7
Slide 1.45 © The McGraw-Hill Companies, 2007 Information Hiding In the object-oriented version The solid line around accountBalance denotes that outside the object there is no knowledge of how accountBalance is implemented In the classical version All the modules have details of the implementation of account_balance
Slide 1.46 © The McGraw-Hill Companies, 2007 Strengths of the Object-Oriented Paradigm With information hiding, postdelivery maintenance is safer The chances of a regression fault are reduced Development is easier Objects generally have physical counterparts This simplifies modeling (a key aspect of the object- oriented paradigm)
Slide 1.47 © The McGraw-Hill Companies, 2007 Strengths of the Object-Oriented Paradigm (contd) Well-designed objects are independent units Everything that relates to the real-world item being modeled is in the corresponding object encapsulation Communication is by sending messages This independence is enhanced by responsibility-driven design (see later)
Slide 1.48 © The McGraw-Hill Companies, 2007 Strengths of the Object-Oriented Paradigm (contd) A classical product conceptually consists of a single unit (although it is implemented as a set of modules) The object-oriented paradigm reduces complexity because the product generally consists of independent units The object-oriented paradigm promotes reuse Objects are independent entities
Slide 1.49 © The McGraw-Hill Companies, 2007 Responsibility-Driven Design Also called design by contract Send flowers to your mother in Chicago Call flowers Where is flowers ? Which Chicago florist does the delivery? Information hiding Send a message to a method [action] of an object without knowing the internal structure of the object
Slide 1.50 © The McGraw-Hill Companies, 2007 Classical Phases vs Object-Oriented Workflows There is no correspondence between phases and workflows Figure 1.8
Slide 1.51 © The McGraw-Hill Companies, 2007 Analysis/Design Hump Structured paradigm: There is a jolt between analysis (what) and design (how) Object-oriented paradigm: Objects enter from the very beginning
Slide 1.52 © The McGraw-Hill Companies, 2007 Analysis/Design Hump (contd) In the classical paradigm Classical analysis Determine what has to be done Design Determine how to do it Architectural design determine the modules Detailed design design each module
Slide 1.53 © The McGraw-Hill Companies, 2007 Removing the Hump In the object-oriented paradigm Object-oriented analysis Determine what has to be done Determine the objects Object-oriented design Determine how to do it Design the objects The difference between the two paradigms is shown on the next slide
Slide 1.54 © The McGraw-Hill Companies, 2007 In More Detail Objects enter here Figure 1.9
Slide 1.55 © The McGraw-Hill Companies, 2007 Object-Oriented Paradigm Modules (objects) are introduced as early as the object-oriented analysis workflow This ensures a smooth transition from the analysis workflow to the design workflow The objects are then coded during the implementation workflow Again, the transition is smooth
Slide 1.56 © The McGraw-Hill Companies, The Object-Oriented Paradigm in Perspective The object-oriented paradigm has to be used correctly All paradigms are easy to misuse When used correctly, the object-oriented paradigm can solve some (but not all) of the problems of the classical paradigm
Slide 1.57 © The McGraw-Hill Companies, 2007 The Object-Oriented Paradigm in Perspective (contd) The object-oriented paradigm has problems of its own The object-oriented paradigm is the best alternative available today However, it is certain to be superceded by something better in the future
Slide 1.58 © The McGraw-Hill Companies, Terminology Client, developer, user Internal software Contract software Commercial off-the-shelf (COTS) software Open-source software Linuss Law
Slide 1.59 © The McGraw-Hill Companies, 2007 Terminology (contd) Software Program, system, product Methodology, paradigm Object-oriented paradigm Classical (traditional) paradigm Technique
Slide 1.60 © The McGraw-Hill Companies, 2007 Terminology (contd) Mistake, fault, failure, error Defect Bug A bug crept into the code instead of I made a mistake
Slide 1.61 © The McGraw-Hill Companies, 2007 Object-Oriented Terminology Data component of an object State variable Instance variable (Java) Field (C++) Attribute (generic) Action component of an object Member function (C++) Method (generic)
Slide 1.62 © The McGraw-Hill Companies, 2007 Object-Oriented Terminology (contd) C++: A member is either an Attribute (field), or a Method (member function) Java: A field is either an Attribute (instance variable), or a Method
Slide 1.63 © The McGraw-Hill Companies, Ethical Issues Developers and maintainers need to be Hard working Intelligent Sensible Up to date and, above all, Ethical IEEE-CS ACM Software Engineering Code of Ethics and Professional Practice
2. Software Development Processes. Software Engineering Outline Historical aspects Economic aspects Maintenance aspects Requirements, analysis, and design.
Object-Oriented and Classical Software Engineering Eighth Edition, WCB/McGraw-Hill Stephen R. Schach 1.
Slide 1.1 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. Object-Oriented and Classical Software Engineering Eighth Edition, WCB/McGraw-Hill,
Slide 1.1 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Object-Oriented Software Engineering WCB/McGraw-Hill, 2008 Stephen R.
Dr. DEVENDRA TAYAL– THE SCOPE OF SOFTWARE ENGINEERING.
Slide 1.1 © The McGraw-Hill Companies, 2002 Object-Oriented and Classical Software Engineering Fifth Edition, WCB/McGraw-Hill, 2002 Stephen R. Schach
Slide 1.1 CHAPTER 1 INTRODUCTION TO SOFTWARE ENGINEERING.
1.1/46 Scope Of Software Engineering 1.2/46 Prologue… ‘Have you any idea what happened to our computers! Pay $0.00 bill, …, Pay the $0.00 bill within.
×1= 9 4 1×1= 1 5 8×1= 8 6 7×1= 7 7 8×3= 24.
Copyright © Action Works 2008 All Rights Reserved - Photos by David D. Kempster 1.
Copyright © 2012, Elsevier Inc. All rights Reserved. 1 Chapter 7 Modeling Structure with Blocks.
CALENDAR NEW CALENDAR
1 Budapest University of Technology and Economics, BME, 1872 Budapest University of Technology and Economics, BME, 1872 Happy New Year 2012.
David Burdett May 11, 2004 Package Binding for WS CDL.
MaK_Full ahead loaded 1 Alarm Page Directory (F11)
PP Test Review Sections 6-1 to 6-6 Mrs. Rivas 1. 2.
1 Introduction to Software Engineering Rajkumar Buyya Grid Computing and Distributed Systems Lab Dept. of Computer Science and Software Engineering University.
Break Time Remaining 10:00. Break Time Remaining 9:59.
Chapter 13 Fluids Physics for Scientists & Engineers, 3 rd Edition Douglas C. Giancoli © Prentice Hall.
PROJECT MILESTONES Group Presentations: ~ 5 mins presentations.
13:00 Clock will move after 1 minute PPT – VCIC Timer 15.ppt.
BMU - E I 1 Development of renewable energy sources in Germany in
©2004 by Pearson Education11-1 R.C. Hibbeler Resistência dos Materiais, 5ª ed. 11 – Projetos de Vigas e Eixos.
DLMSO Classroom Timer Select a time to count down from the clock above 60 min 45 min 30 min 20 min 15 min 10 min 5 min or less.
The 5S numbers game. 1. This sheet represents our current work place. Our job during a 20 second shift, is to strike out the numbers 1 to 49 in correct.
1A B C1A B C 2A B C2A B C 3A B C3A B C 4A B C4A B C 5A B C5A B C 6A B C6A B C 7A B C7A B C 8A B C8A B C 9A B C9A B C 10 AA B CBC 11 AA B CBC 12 AA B CBC.
Numerical Analysis 1 EE, NCKU Tien-Hao Chang (Darby Chang)
BMU – KI III 1 Development of renewable energy sources in Germany in
1 STANDARD 1.3 Converting a Fraction to % Problem 1 Problem 4 Problems 3 Problem 2 Problem 5 END SHOW PRESENTATION CREATED BY SIMON PEREZ. All rights reserved.
Create an Application Title 1Y - Youth Chapter 5.
STATISTICS HYPOTHESES TEST (I) Professor Ke-Sheng Cheng Department of Bioenvironmental Systems Engineering National Taiwan University.
AP STUDY SESSION 2. Answers 1.A 2.E 3.A 4.D 5.B 6.E 7.B 8.E 9.A 10.D 11.C 12.B 13.D 14.B 15.E 16.A 17.E 18.C 19.C 20.D 21.B 22.C 23.A 24.D 25. B 26. E.
1 Topic Factoring Quadratics ax ² + bx + c Factoring Quadratics ax ² + bx + c.
Solving a Sudoku Puzzle By Marlene Walther ATeacherFirst.com.
1.step PMIT start + initial project data input Concept Concept.
Copyright Tim Morris/St Stephen's School Area of a Rectangle This is one in a series of Powerpoint slideshows to illustrate how to calculate the area of.
1 Non Deterministic Automata. 2 Alphabet = Nondeterministic Finite Accepter (NFA)
1 Before Between After 2 What comes before. _____ 10 _____
Artificial Intelligence Genetic Algorithms Source: 1.
Time and Labor Processing Day 1. Exercise #1a. Enter Time – Positive.
1 The Scope of Software Engineering Xiaojun Qi. 2 Software Engineering Software engineering is a discipline whose aim is the production of fault-free.
Unit I Topic 2-7 MAC Protocols for Ad Hoc Wireless Networks Department of Computer Science and Engineering Kalasalingam University 1 CSE 6007 Mobile Ad.
Symantec 2010 Windows 7 Migration Global Results.
© 2017 SlidePlayer.com Inc. All rights reserved.