Download Capability Maturity Model Integration-Methods Of Software Engineering-Lecture Notes and more Study notes Software Engineering in PDF only on Docsity!
public static Movie newNewRelease(String name){ Movie result = new Movie (name); result.beNewRelease(); return result; } public static Movie newRegular(String name){ Movie result = new Movie (name); result.beRegular(); return result; } public static Movie newChildrens(String name) { Movie result = new Movie (name); result.beChildrens(); return result; }
private Movie(String name) { _name = name; }
After compiling and testing I now change getting and setting methods to use the new class.
public void beRegular() { _price = Price.regular(); }
public void beNewRelease() { _price = Price.newRelease(); }
public void beChildrens() { _price = Price.childrens(); } public int priceCode() { return _price.priceCode(); }
And provide the priceCode methods on Price and its subclasses.
Class PriceÖ abstract int priceCode();
Class RegularPriceÖ int priceCode(){ return Movie.REGULAR; }
To do this I need to make the constants non-private again. This is fine, I donít mind them having a little fame before they bite the dust.
I can now compile and test and the more complex methods donít realize the world has changed.
After moving the data I can now start moving methods. My prime target is the charge() method. It is simple to move.
Class MovieÖ double charge(int daysRented) { return _price.charge(daysRented); }
Class PriceÖ double charge(int daysRented) { double result = 0; switch (priceCode()) { case Movie.REGULAR: result += 2; if (daysRented > 2) result += (daysRented - 2) * 1.5; break; case Movie.NEW_RELEASE: result += daysRented * 3; break; case Movie.CHILDRENS: result += 1.5; if (daysRented > 3) result += (daysRented - 3) * 1.5; break;
} return result; }
Once it is moved I can start replacing the case statement with inheritance. I do this by taking one leg of the case statement at a time, and creating an overriding method. I start with RegularPrice.
Class RegularPriceÖ double charge(int daysRented){ double result = 2; if (daysRented > 2) result += (daysRented - 2) * 1.5; return result; }
This will override the parent case statement, which I just leave as it is. I compile and test for this case, then take the next leg, compile and testÖ. (To make sure Iím executing the subclass code, I like to throw in a deliberate bug and run it to ensure the tests blow up. Not that Iím paranoid or anything.)
Putting in the state pattern was quite an effort, was it worth it? The gain is now that should I change any of priceís behavior, add new prices, or add extra price dependent behavior; it will be much easier to change. The rest of the application does not know about the use of the state pattern. For the tiny amount of behavior I currently have it is not a big deal. But in a more complex system with a dozen or so price dependent methods this would make a big difference. All these changes were small steps, it seems slow to write it like this, but not once did I have to open the debugger. So the process actually flowed quite quickly.
Lecture No. 44
Capability Maturity Model Integration (CMMI)
Capability Maturity Model or CMM is a reference model of mature practices in a specified discipline, used to assess a group‘s capability to perform that discipline. In fact there are a number of CMMs. They differ by discipline (software, systems, acquisition, etc.), structure (staged versus continuous), how maturity is defined (process improvement path), and how capability is defined (institutionalization). Hence ―Capability Maturity Model ® ‖ and CMM ® are used by the Software Engineering Institute (SEI) to denote a particular class of maturity models.
Software CMM, the one we saw earlier on, is one of the many CMM models.
Name Structure Domain Software CMM staged software development System Engineering CMM continuous system engineering Software Acquisition CMM staged software acquisition System Security Engineering CMM continuous security engineering
FAA-iCMM continuous
software engineering, systems engineering, and acquisition IPD-CMM hybrid integrated product development People CMM staged workforce SPICE Model continuous software development
Since these models have different structure and application domains, an organization could potentially use many of these models for their different activities, at times it could become problematic for them.
CMMI Integrates systems and software disciplines into single process improvement framework and provides a framework for introducing new disciplines as needs arise. It can now be applied to just the software engineering projects in an organization or for the entire spectrum of activities outlined above.
CMMI Representations
A representation allows an organization to pursue different improvement objectives. There are two types of representations in the CMMI models: staged and continuous. The organization and presentation of the data are different in each representation. However, the content is the same.
Staged Representation
Staged representation is classical representation we have already seen previously. It: Provides a proven sequence of improvements, each serving as a foundation for the next. Permits comparisons across and among organizations by the use of maturity levels.
The process area capability of an implemented process can be represented by a bar as shown below.
Relating Process Area Capability and Organizational Maturity
Organizational maturity is the focus of the staged representation, whereas process area capability is the focus of the continuous representation.
Organizational maturity and process area capability are similar concepts. The difference between them is that organizational maturity pertains to a set of process areas across an organization, while process area capability deals with a set of processes relating to a single process area or specific practice.
Comparison of Representations
Staged
Process improvement is measured using maturity levels. Maturity level is the degree of process improvement across a predefined set of process areas. Organizational maturity pertains to the ―maturity‖ of a set of processes across an organization
Continuous
Process improvement is measured using capability levels. Capability level is the achievement of process improvement within an individual process area. Process area capability pertains to the ―maturity‖ of a particular process across an organization.
Process
Capability Level
This point
represents
a higher level
of “maturity”
than this point
in a specific
process area
3
2
1
0 Process Area n
Process
Capability Level
This point
represents
a higher level
of “maturity”
than this point
in a specific
process area
3
2
1
0 Process Area n
Advantages of Each Representation
Staged provides a roadmap for implementing groups of process areas and sequencing of implementation. It has a familiar structure for those transitioning from the Software CMM.
Continuous provides maximum flexibility for focusing on specific process areas according to business goals and objectives and has a familiar structure for those transitioning from EIA 731.
As the staged representation requires all KPAs to be addressed at a particular level before a company can move to the next maturity level, it may not be easy for small companies to implement this model. There may be a number of activities that may not be relevant to their type of work but they would still have to do them in order to be at a certain level. On the other hand, organization can focus on their own areas of expertise and may be able to achieve high capability levels in some areas without bothering about the rest. This is a great advantage for small organization and hence this model is believed to be more suitable for small Pakistani organizations than the staged one.
i) Processes and their outputs could be visible to management at defined points, but results may not always be consistent. For example, for project/program management processes, even though (say) some basic processes are established to track cost, schedule, and functionality, and if a degree of process discipline is in place to repeat earlier successes on projects with similar applications and scope, there could still be a significant risk of exceeding cost and time estimates.
Level 3 - Defined
It is characteristic of processes at this level that there are sets of defined and documented standard processes established and subject to some degree of improvement over time. These standard processes are in place (i.e., they are the AS-IS processes) and used to establish consistency of process performance across the organization.
Organizational implications
(a) Process management starts to occur using defined documented processes, with mandatory process objectives, and ensures that these objectives are appropriately addressed.
Level 4 - Managed
It is characteristic of processes at this level that, using process metrics, management can effectively control the AS-IS process (e.g., for software development ). In particular, management can identify ways to adjust and adapt the process to particular projects without measurable losses of quality or deviations from specifications. Process Capability is established from this level.
Organizational implications
a) Quantitative quality goals tend to be set for process output - e.g., software or software maintenance. b) Using quantitative/statistical techniques, process performance is measured and monitored and generally predictable and controllable also.
Level 5 - Optimizing
It is a characteristic of processes at this level that the focus is on continually improving process performance through both incremental and innovative technological changes/improvements.
Organizational implications
(a) Quantitative process-improvement objectives for the organization are established, continually revised to reflect changing business objectives, and used as criteria in managing process improvement. Thus, process improvements to address common causes of process variation and measurably improve the organization‘s processes are identified, evaluated, and deployed.
