Download presentation
Presentation is loading. Please wait.
Published byToby Austin Modified over 9 years ago
1
Process Refactoring Michael L. Collard, Ph.D.
2
Real World Often ad hoc with no process Different levels of developers knowledge, experience, and capabilities Different levels of management knowledge, experience, and capabilities Stated goals versus reality The problems in your work situation are not unique
3
To Improve Process Massive, all at once changes, will lead to failure due to personalities, previous history, etc., and are often wrong Especially the case for ad-hoc environments Incremental changes give entire system (people) time to adjust and prepare the way for further changes
4
Process Refactoring Identify parts of the process that are missing: look for methods, tools that are being used, but not integrated into the process Improve that part Get the new part integrated into the system Allow time for the ramifications to occur (and you to get credit)
5
Format Refactoring Change to a better format for artifacts “better” in the sense of: – Easier to maintain – Grows with the project – Can be used to automatically generate other artifacts Examples: XML, Atom, XHTML formats Converters may be needed
6
Forward Engineering Refactoring Automatically generate artifacts from other artifacts E.g., Generate base code from UML design Problem: Evolution Small scale example: Generate terms for documentation from code
7
Integrate Tool Usage Take existing method and support it with new tool E.g., writing test cases Since method is currently being used, motivation to develop/purchase/integrate the tool is there Avoid the “exercise machine” syndrome
8
Version Control Refactoring Introduce version control into the system Release code from version control Versioning applies to any artifact Can be done locally by individual developers before integrated into overall group
9
Bug Tracking Refactoring Put bugs and requests into a bug-tracking system, e.g., Trax, Bugzilla Could be just a mail archive What is the difference between a bug and a new feature? Recording history of the project is useful for later analysis, determining credit, example for other projects
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.