1 / 25

Challenges and Strategies in Software Maintenance: Insights from Phil Gross

This presentation by Phil Gross focuses on the critical aspects of software maintenance, highlighting the challenges software engineers face throughout the lifecycle of a project. Gross emphasizes the significant amount of time spent on corrective and adaptive maintenance, shares insights on handling fault reports, and underscores the importance of documentation. The discussion also delves into case studies that illustrate real-world issues in maintainability and the need for effective management strategies from the outset of software development.

terrel
Télécharger la présentation

Challenges and Strategies in Software Maintenance: Insights from Phil Gross

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Software Engineering 3156 6-Nov-01 #19: Maintenance and Swing Phil Gross

  2. Administrativia • Prototype status • Modify schedule again, give a few more days? • Perl Tomorrow 6-8pm • No Wednesday class • Guest speaker on Thurs 2

  3. FYI 3

  4. Being a maintenance programmer • Lots of maintenance: 67% on average of total time in lifecycle • Most difficult: incorporate everything else 4

  5. Corrective maintenance • Need to debug if fault report is good • Deal with regression faults • Poor documentation • Testing, including regression testing • Need to document changes • But what about adaptive and perfective maintenance? 5

  6. Even more work… • Often, you need new functionality implemented • Must go through requirements, specification, …, integration again • Or change existing ones • Again, lack of documentation • Conclusion: you need a good programmer 6

  7. And in return… • No thanks: if users were happy, they wouldn’t need maintenance • User’s problems frequently caused by original developer, but maintainer blamed • Original code might be badly written • Not a “glamorous job”: drudge work • “After-sales service” • Needs management help 7

  8. Mini-case study • Temperate Fruit Committee • “We need only 7 fruits” • Maintainance • “Oh, we actually need 8” • Fortunately, hooks were in there • Time passes… • “We now need 26… you went from 7 to 8, so it must be trivial” 8

  9. Case study lessons • Problem with product: no provision for expansion • Original developer’s fault: “obey” chairman • Original developer probably thought it was a success • Client doesn’t understand that maintenance is hard • Previous perfective maintenance succeeded, right? • Software development should keep an eye out for maintenance • Why were 7 hardcoded? Why not arbitrary numbers? 9

  10. Managing maintenance (I) • Fault reports • Need to establish a standardized fault report • Both user and maintainer update it • Circulate to other users: “known problems” • Common: usually gather up faults • Authorizing changes • Need to have separate SQA group test it against baseline code • Schach: “must, must, must” be independent 10

  11. Managing maintenance (II) • Ensuring maintainability • Maintenance is not a one-time effort! • Plan for maintenance from the beginning • Documentation • Variable naming, etc • Repeated maintenance • Moving target problem • As long as the client has money… • No easy solution 11

  12. Object-oriented maintenance • Not really easier • In fact, can make maintenance harder • Inheritance, polymorphism, etc. can make understanding the code a more subtle effort • Use CASE tools to help • And time, of course 12

  13. Maintenance skills vs. development skills • Ability to determine failures, etc. not just for maintenance: used throughout integration and testing • Standard lifecycle skills (Requirements, Design, etc.) needed here as well • Conclusion: skills not particularly different • Except that a maintenance programmer must be skilled in all of them 13

  14. Reverse engineering (I) • You don’t want to, but sometimes have to • Poor documentation • (gasp!) No source code • CASE tools help with the first • Reconstruct just design, or specifications? • Usually the former, latter very hard • Restructuring: not changing functionality • Reformatting source code 14

  15. Reverse engineering (II) • No source code, you say? • Decompile • Oh, BTW, lots of luck • Java slight exception here… • JAD is supposedly really good • Introspection side effect 15

  16. Challenges • Did I mention enough already? • Classical SE is development-then-maintenance • Schach would like this changed so that one thinks of maintenance from day 1 • Unrealistic • Requirements change frequently • Faults often have to be fixed • Development from scratch now becoming rare • Often, maintain before delivery! 16

  17. Rapid review of AWT/Swing • Swing: set of user interface components built on AWT • AWT questions/review • Themeable, very flexible • Event model • Swing’s model-view-controller mechanism • So, what tools will you need for the project? 17

  18. Layout management • Need to lay out various components • Might use IDE for this, though I don’t • BorderLayout, GridLayout, CardLayout, FlowLayout, GridBagLayout • Last one pain to do by hand • Use JPanels to embed one in another • setPreferredSize() • Tip: draw out on paper first 18

  19. Images (I) • Toolkit.getDefaultToolkit().loadImage(…) • Create a MediaTracker to wait for image to load • Caching images: Java or you? • Drawing images: g.drawImage(…) • Override paint method in the class 19

  20. Images (II) • Image transparency • Needed for object-on-tile • Use Photoshop or even the GIMP to edit images • We linked to a set on the webboard • May release our modifications/subset • Consider laying out tiles in a GridLayout 20

  21. Images (III) • Alternative image construct: ImageIcon • Can embed in a JLabel • Useful for buttons and other places where you don’t have access to Graphics context • More awkward for actual game board 21

  22. JTables • Capable of showing complex data constructs fairly easily • Set up a data model behind the table • Extend AbstractTableModel • Specify the number of rows and columns • Specify what data is in each cell • Let the JTable do the rest • JLists are similar: AbstractListModel • Can use Default{Table,List}Model: less useful 22

  23. Actions • JButton • addActionListener(new ActionListener()…) • Keyboard • addKeyListener(new KeyAdapter()…) • KeyEvent lets you check for most any key plus modifiers • Right-click • addMouseListener(new MouseAdapter()…) • Uses button masks (1.4 supports wheel!) 23

  24. Miscellany • JMenu/JMenuBar for menus • JPopupMenu – the name implies it all • repaint(), revalidate() • JScrollPane to support scrolling of large areas • Grid, perhaps?  • Jsp.getViewport().setViewPosition(…) to force the scrollpane around • Ideally, have it “follow” the player 24

  25. What does this mean for you? • Regexps: Important for AI people, to be covered a bit in recitation next week • Maintenance: you’re mostly off the hook for this one, excepting between base and full implementation • AWT/Swing: Client people will need this 25

More Related