GeeCON Prague 2014*
The moose likes Agile and Other Processes and the fly likes CMM , PSP, TSP Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "CMM , PSP, TSP" Watch "CMM , PSP, TSP" New topic
Author

CMM , PSP, TSP

HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
Personal Software Process (PSP), based on the Capability Maturity Model (CMM), and Team Software Process (TSP) to provide ability to connect the processes .Capability Maturity Model

All variations on a theme.
PSP sounds like XP.
TSP is probably similar to RUP.
Any ideas where CMM fit in ? I think CMM goals and measurements of success are set outside the organisation.
So however the RUP process is implemented the project may still have to make sure it meets the TSP requirements of the CMM if the project organisation elects to be have the people running the CMM program to give their stamp of approval .
It's like having External Auditors in to audit the accounts, in this case , audit systems.
An additional overhead in selecting a process. Seeing as the CMM is still in it's early stages,
will this affect ,say, RUP years later down the line ?
I notice some Press statement from Rational that they are including processes for functional decomposition because that's what some customers want. How do you stop cross-process pollination , so you don't combine Use-cases with functions. menu options ?
regards
[ July 02, 2003: Message edited by: HS Thomas ]
HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
Though the scope of CMM covers a lot more than just systems.
regards
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by HS Thomas:
PSP sounds like XP.

In which ways?
TSP is probably similar to RUP.

Again, in which ways?
Any ideas where CMM fit in?

As far as I know, CMM basically doesn't care much about the actual specifics of a process, but only about that it is documented and repeatable. I've heard of CMM auditors claiming that it shouldn't be hard to reach at least CMM level 3 for an XP shop.
A problem with CMM and similar programs is that they are concentrating on reducing risk - which is quite opposed to being innovative! (There is a very good chapter on this in the second edition of "Peopleware" by DeMarco and Lister.)
I notice some Press statement from Rational that they are including processes for functional decomposition because that's what some customers want. How do you stop cross-process pollination , so you don't combine Use-cases with functions. menu options ?

I don't understand you here. Can you please try to rephrase?


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
Well, taking up the last point, I assume the old method of Structured Analysis and Design relied on functional decomposition, and data flow diagrams is not familiar to some.
OOA&D combined the data and the functionality into objects, and modeled the relationships between objects (inheritance, aggregation, and association). OOA&D seems to have effectively healed the data-functionality split that has caused headaches for so long.....
Although OOA&D creates a more stable (and yet more flexible) design, people still tend to state requirements in functional terms as in :
A:Use Case requirements gathering :
Developers and clients get together and discuss how a proposed system will be used. "Actors" are identified, which are roles that users play with the system. For example, the actors for a banking system might be "customer", "teller", "loan officer", "system administrator", etc.
The way actors use the systems are called "Use Cases". For example, a "Use Case" for a customer using an ATM might go something like this:
Customer inserts ATM card.
ATM requests pin.
Customer enters pin.
ATM verifies PIN with central bank.
ATM requests transaction type.
Customer enters transaction type.
B:The old functional decomposition with Data Flow Diagrams method:

For example, a "DFD functional decomposition" for a customer using an ATM might go something like this:
High-level functions: Withdrawal/Balance enquiry
enter pin.
verify pin.
enter transaction type.
etc., etc.
A function was broken down further until the requirements could be described on an A4 sheet of paper.
If the Rational press statement is to be believed , customers want this way of gathering requirements back, so Rational are incorporating functional decomposition.
I hope they keep the two tracks separate. But a developer can work in one Rational shop with Functional decomposition then move to another Rational shop using Use Cases for requirements gathering. Use Case and functionally decomposed requirements ( what I meant by cross-pollination).
Phew! SWIM (S'What I Meant).
I can't find the press statement but here's a whitepaper on The Estimation of Effort based on Use Cases.
I just found it curious when they announced that customers wanted FDR back with all it's inherent problems.
More links on the Functional decomposition debate - Thoughts on Functional Decomposition
regards
[ July 03, 2003: Message edited by: HS Thomas ]
HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
PSP is similar to XP in that it advocates a disciplined approach to producing quality work.
The TSP has a waterfall-type Analysis, Design,Code,Test phases but is more to do with software process improvement than software process engineering.
I suppose I must make it clear that CMM is all about Quality Assurance (and Risk Management).
regards
[ July 02, 2003: Message edited by: HS Thomas ]
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by HS Thomas:
Although OOA&D creates a more stable (and yet more flexible) design, people still tend to state requirements in functional terms as in:

I don't see any problems with stating requirements in functional terms. Specifically, I don't buy the argument that OOA (whatever that is meant to be) helps much in getting a better OO design.
Analysis is about understanding the problem. If the problem has important functional aspects, then why don't use functional terms to explain/explore them?
HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
I don't see any problems with stating requirements in functional terms.

I'd agree with you, Illja , if you were talking about the concept of breaking down a problem into smaller parts in order to tackle the larger problem.That is a natural thing to do since time immemorial.
But the practise of functional decomposition as it was done in the past in software development, probably created more problems than was set out to solve.
"Thoughts on Functional Decomposition" covers a few examples of FD applied incorrectly.
The outcome of using functional requirement allocation to create an architecture -- rather than starting with a defined architecture -- is subsystems with duplicate code. This leads to unnecessarily large, complex systems that are costly to develop and operate, and difficult to maintain.

Using functional decomposition methods to derive the system architecture and set subsystem requirements puts the system at risk.

Functional decomposition usually started with examining operation procedures then scoping the system into sub-systems , meant that a lot of duplication was factored in.
For example, a bank account management system may have one subsystem dedicated to online customer transactions and another subsystem for in-branch transactions. These subsystems maintain their separate databases.

Here is an actual example: One image satellite ground support system that is currently being fielded was built with a functional decomposition architecture. The system requirements included the ability to plan missions, control the satellites, and process the collected data for analysis. Accordingly, the developer built three subsystems: mission planning, command and control, and data processing. Each of these subsystems was given to an independent team for development. During the project, each team independently discovered the need for a database with the satellite's orbital history (the satellites can, to some extent, be steered to different orbits as needed). So each team built its own separate database, using separate formats. But the information needs to be consistent for the overall system to operate correctly, and now, the effort required to maintain these three databases is excessive and could easily have been avoided had the team done some kind of object analysis, including a study of the enterprise data architecture.

I'd like to think the Object Orientated approach would not have these problems.
I am sure there have been many successful projects that used FD .(I'd like to think I've worked on some of them). Perhaps the architecture requirements had been sorted out earlier, and a lot of common sense applied first before starting functional decomposition.

To be frank , probably the same defects can be said of Use Cases too.
So the problem may not be Functional Decomposition , per se, but the context(s) in which it is used.
Can you make wrong assumptions about the systems architecture while using Use Cases ? So that you'd end up duplicating most of the information or processes ? And have one hell of a problem integrating the lot some day?

regards
[ July 04, 2003: Message edited by: HS Thomas ]
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by HS Thomas:
I'd like to think the Object Orientated approach would not have these problems.

I don't think the above was cause by functional decomposition, but by a dysfunctional team. The problem was caused by missing communication between the subteams. As most often, it seems to be more of a social problem than a technical one.
I am sure there have been many successful projects that used FD .(I'd like to think I've worked on some of them). Perhaps the architecture requirements had been sorted out earlier, and a lot of common sense applied first before starting functional decomposition.

Perhaps. I have also heard of big teams where there was an architectural subteam and even a small "communications team" only responsible for fostering communication between the other teams.
Can you make wrong assumptions about the systems architecture while using Use Cases?

I don't understand this question. I don't think that Use Cases have anything to do with architecture.
HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
Illja, thanks for the earlier comments.
I don't think that Use Cases have anything to do with architecture.

Well here is an example , a rather feeble one:
The Use Case is written as ATM asks Customer for PIN ( Personal Identification Number). Catering for other ATMs early may be too expensive.
The Design implements this as a method verifying a number,the identificationVerifier method.
The requirements change to allow for ATMs requesting either a PIN , a signature, an eye scan, a fingerprint, etc because the business has gone into partnership with other businesses using other types of ATMs.
Each of these brings into the picture in other types of machinery to verify the Customer.
Error messages in the design like " Sorry , you entered an invalid number" is not valid 4/5 times now.
A couple of mergers and ...hasn't the architecture changed!
I suppose the identificationVerifier method can be changed to be responsible for asking for the mode of verification as well as supplying the valid/invalid message.
But after a systems requirement to cut down on network traffic , the relevant mode(s) of verification is/are displayed on ATM screen at start-up. Not all ATMs have the full set of modes of verification.
The Use Case now reads Customer Selects mode of verification and enters identifier . This is a feeble example of Use Case depending on architecture.
Unless it's read as Use Case depends on Business Rules / Systems Rules which depend on Architecture. OK, then I agree. Someone has borne in mind the physical ATM architectural change requirements and the logical network architectural changes and re-stated the requirements in Business Rules.Which the amended Use Cases now describes.
Or the Use Case written at the right level of abstraction Customer enters identifier makes no assumptions about the physical architecture. This may be the correct way to write the Use Case at the very beginning.
An aditional Use Case about the new change in business requirementsCustomer selects mode of identification is added when needed.
What do you think?
Use Cases and Functional decompositions used correctly should make no assumptions about architecture , physical or logical ?

regards
[ July 05, 2003: Message edited by: HS Thomas ]
HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
Hi,
Seems you can use Use Cases to determine architecture as in :

Dana's Use Case Template
not to the same extent in :
Alistaire Cockburn's Use Case Template
Seems to be many flavors to Use Cases .
I take it an XP Programmer shouldn't mix Use Cases with Architecture but an Architect would ?
regards
[ July 06, 2003: Message edited by: HS Thomas ]
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Architectures are largely derived from use cases. Use cases describe functional requirements and the architecture has to meet them. (And the detailed design has to meet them. And the tests have to verifiy them. In short, everybody on the team should have a use case in one hand at all times! Why else would they be doing anything?)
Use cases will sometimes reflect architecture, because some architectural elements may be known going into the project. If the customer charters the project to run on existing web servers and interact with existing systems, those decisions will show in use cases. For example, some existing systems may be actors. Still, I would deliberately minimize the architecture influence on use cases.
An XP team will have a pile of stories instead of use cases, with just enough detail to estimate. They'll consider all the stories together and design just enough architecture to get started. They'll know more architectural things are coming, but devote the least possible time & effort to them until they are needed.
I'm just reading Robert Martin about deferring architecture decisions for as long as possible. His example is implementing a rich object model with no database behind it. A challenging idea to teams accustomed to doing data models first!


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
Thanks Stan.
Where does functional decomposition come in, if at all?
I get the feeling functional decomposition is anti something but cannot figure out what!
Anti -OO ? To me OO means design objects, design objects in the abstract where you'd have more than 1 concrete implementation,design with interfaces (contracts), in short.
regards
[ July 07, 2003: Message edited by: HS Thomas ]
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
I like functional decomposition as a structural pattern. For non-OO langauges. I cut my teeth on COBOL and still use some scripting languages that are not OO so FD is far from dead.
FD also applies in the small when refactoring big methods into little ones, though none of the OO folks who preach little methods would ever say so. They're just making the code express what it does. Whatever.
FD is one way to slice a large problem into smaller, manageable bits. OO is another. They take you to very different places, and mixing them is probably not a good plan. I'd argue that the slices you get from OO design are "better" by some measures that I care about. I heard that one release of IBM's CICS was designed through OOAD and implemented in 370 assembler and PLI. They did not get inheritance but they got a lot of other great benefits, particularly vastly improved encapsulation and just better organized code.
I'm not sure that a procedural system done with skilled FD would have any worse duplication (except where OO would remove it though inheritance), coupling or any other serious evils. Reuse would be in different sized chunks, not as flexible as in an OO design but still present. Reuse of low-level IO and utility modules is common enough; reuse of larger subsystems is certainly possible. And on my last CICS project I built an architecture I'd proudly use again today. (Actually, I have used parts of it again, since CICS is nothing but a gigantic stateless server for thin clients!)
I've seen OO trainers start classes by saying everything you ever knew before was wrong. Given the choice I'd have fired them on the spot.
[ July 07, 2003: Message edited by: Stan James ]
HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
Thanks Stan.I hadn't thought of functional decomposition as a Structural Pattern in an OO world .
I heard that one release of IBM's CICS was designed through OOAD and implemented in 370 assembler and PLI. They did not get inheritance but they got a lot of other great benefits, particularly vastly improved encapsulation and just better organized code.

I did start as a CICS programmer a while ago but moved to using Tools that were more CICS COBOLesque finally ended up on a project that developed a COBOLesque front-end to generated Java/C++ objects. This was for Fortune 500 company that just wasn't hedging any bets. And why should they , they were in the business of risk management.
What they didn't get was re-use to any great extent. Just prior to that I'd worked for a Start-up that were really seriously into re-use but took off for new shores (Canada) after making a kiiling on the SE. [In fact of all of the old projects I worked on , when I look for new business models based on the old businesses , I usually find them in Canada. That must be one country that's got it's overall act together (governments,IT,education, visas,out-sourcing).]
Anyway, I digress , are there any other patterns
besides Structural that may help leveraging re-use from a *legacy* system.
Need some kind of mapping like:
Functional decomposition ----> Structural Pattern
Data Flows ----> ??? Pattern
Data Stores ----> ??? Pattern
E-R diagrams --->
Entity life histories ---> ??
If related to J2EE patterns, even better, if you can think of them as delivering re-usable components ! Hopefully the benefits you percieve in the old system are retained (vastly improved encapsulation and just better organized code.) Any patterns to deal with these ?
Obviously these reusable bits apply to
those components that need to be exposed to the networkas well as those don't.

regards
[ July 08, 2003: Message edited by: HS Thomas ]
 
GeeCON Prague 2014
 
subject: CMM , PSP, TSP