1 / 11

MANAGEMENT OF OBJECT-ORIENTED SOFTWARE PROJECTS

MANAGEMENT OF OBJECT-ORIENTED SOFTWARE PROJECTS. M odern software project management can be subdivided into the following activities:. 1. Establishing a common process framework for a project. 2. Using the framework and historical metrics to develop effort and time estimates.

vartan
Download Presentation

MANAGEMENT OF OBJECT-ORIENTED SOFTWARE PROJECTS

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. MANAGEMENT OF OBJECT-ORIENTED SOFTWAREPROJECTS

  2. Modern software project managementcan be subdivided into the following activities: 1. Establishing a common process framework for a project. 2. Using the framework and historical metrics to develop effort and time estimates. 3. Establishing deliverables and milestones that will enable progress to be measured. 4. Defining checkpoints for risk management, quality assurance, and control. 5. Managing the changes that invariably occur as the project progresses. 6. Tracking, monitoring, and controlling progress.

  3. Object-oriented software engineering appliesa process model that encourages iterative development. That is, OO software evolvesthrough a number of cycles. The common process framework that is used to managean OO project must be evolutionary in nature. • Ed Berard [BER93] and Grady Booch [BOO91] among others suggest the use of a“recursive/parallel model” for object-oriented software development.

  4. In essence therecursive/parallel model works in the following way: • Do enough analysis to isolate major problem classes and connections. • Do a little design to determine whether the classes and connections canbe implemented in a practical way. • Extract reusable objects from a library to build a rough prototype. • Conduct some tests to uncover errors in the prototype. • Get customer feedback on the prototype. • Modify the analysis model based on what you’ve learned from the prototype,from doing design, and from customer feedback. • Refine the design to accommodate your changes. • Code special objects (that are not available from the library). • Assemble a new prototype using objects from the library and the new objectsyou’ve created. • Conduct some tests to uncover errors in the prototype. • Get customer feedback on the prototype.

  5. OO Project Metrics and Estimation • Lorenz and Kidd [LOR94] suggest the following set of project metrics:6 • Number of scenario scripts. A scenario script (analogous to use-cases discussedEach script is organized intotriplets of the form{initiator, action, participant}where initiator is the object that requests some service (that initiates a message);action is the result of the request; and participant is the server objectthat satisfies the request. • Number of key classes.” • Number of support classes. • Average number of support classes per key class. • Number of subsystems. • Number of major iterations. • Number of completed contracts.

  6. An OO Estimating and Scheduling Approach • Lorenz and Kidd [LOR94] suggest the followingapproach: 1. Develop estimates using effort decomposition, FP analysis, and any othermethod that is applicable for conventional applications. 2. Using OOA (Chapter 21), develop scenario scripts (use-cases) and determinea count. Recognize that the number of scenario scripts may change as theproject progresses. 3. Using OOA, determine the number of key classes. 4. Categorize the type of interface for the application and develop a multiplierfor support classes: Multiply the number of key classes (step 3) by the multiplier to obtain an estimatefor the number of support classes. 5. Multiply the total number of classes (key + support) by the average number ofwork-units per class. Lorenz and Kidd suggest 15 to 20 person-days perclass. 6. Cross check the class-based estimate by multiplying the average number ofwork-units per scenario script.

  7. Tracking Progress for an OO Project • Technical milestone: OO analysis completed • All classes and the class hierarchy have been defined and reviewed. • Class attributes and operations associated with a class have been definedand reviewed. • Class relationships (Chapter 21) have been established and reviewed. • A behavioral model (Chapter 21) has been created and reviewed. • Reusable classes have been noted.

  8. Tracking Progress for an OO Project • Technical milestone: OO design completed • The set of subsystems (Chapter 22) has been defined and reviewed. • Classes are allocated to subsystems and reviewed. • Task allocation has been established and reviewed. • Responsibilities and collaborations (Chapter 22) have been identified. • Attributes and operations have been designed and reviewed. • The messaging model has been created and reviewed.

  9. Tracking Progress for an OO Project • Technical milestone: OO programming completed • Each new class has been implemented in code from the design model. • Extracted classes (from a reuse library) have been implemented. • Prototype or increment has been built.

  10. Tracking Progress for an OO Project • Technical milestone: OO testing • The correctness and completeness of OO analysis and design models hasbeen reviewed. • A class-responsibility-collaboration network (Chapter 23) has been developedand reviewed. • Test cases are designed and class-level tests (Chapter 23) have been conductedfor each class. • Test cases are designed and cluster testing (Chapter 23) is completed and theclasses are integrated. • System level tests have been completed.

More Related