This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes Agile and Other Processes and the fly likes Requirements for OO development of a lifecycle!!!! Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Requirements for OO development of a lifecycle!!!!" Watch "Requirements for OO development of a lifecycle!!!!" New topic
Author

Requirements for OO development of a lifecycle!!!!

Rishi Singh
Ranch Hand

Joined: Dec 09, 2000
Posts: 321
An appropriate and full fleged lifecycle methodology for OO developments must which all components:
Rishi Singh
Ranch Hand

Joined: Dec 09, 2000
Posts: 321
I meant what are the components which are must for the OO development of a life cycle process.and how does is comes, the order.
Corey McGlone
Ranch Hand

Joined: Dec 20, 2001
Posts: 3271
I think the basic requirements really vary upon the specific process that you plan to use. However, here are the general phases of the process:
Analysis/Assessment
Planning
Design
Implementation
Testing
Maintenance
Retirement
Each specific SDP will have required deliverables for each phase, but that can vary. For example, some processes require use case inventories, some don't. Some processes require context diagrams, some don't.
What is required is really dependent upon the SDP.
Corey


SCJP Tipline, etc.
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4445
    
    5

Rishi,
There's way too much about OO dev't. life cycles to discuss in one post. I recommend that you start by searching the web for "Iterative and Incremental Development".
You'll find some interesting papers on it at http://www.objectmentor.com
Martin Fowler also once wrote "Use an iterative development process only if you plan to succeed." or something to that effect.
Frank Zheng
Ranch Hand

Joined: Jun 12, 2001
Posts: 76
Interested in XP? Check this:
http://www.extremeprogramming.org/map/project.html


Sun Certified Java Programmer
Reid M. Pinchback
Ranch Hand

Joined: Jan 25, 2002
Posts: 775
Originally posted by Junilu Lacar:
There's way too much about OO dev't. life cycles to discuss in one post. I recommend that you start by searching the web for "Iterative and Incremental Development".

There is also a lot process around the development lifecycle that has little to do with OO, but can be very important for the long-term survival of a company that develops or integrates software products (e.g. quality assurance, configuration management, project management, usability, infrastructure management, information management, knowledge management).
[ June 06, 2002: Message edited by: Reid M. Pinchback ]

Reid - SCJP2 (April 2002)
Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
It should be noted that none of the processes described has anything to do with OO. OO languages are simply a tool used in a process. What has been discussed above applies equally well to proceedural code.
--Mark
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4445
    
    5

True, OO and IID are orthogonal (is that the right word?) but IID is more often than not discussed in the context of OO. Mark is right though, the processes mentioned are equally applicable for non-OO development life cycles.
Reid M. Pinchback
Ranch Hand

Joined: Jan 25, 2002
Posts: 775
Originally posted by Mark Herschberg:
It should be noted that none of the processes described has anything to do with OO.

Some of them that is definitely true. For others I think I'd be more inclined to say that there is a great deal of similarity in how issues are handled between OO and non-OO environments. Good OO design can result in loose coupling between subsystems, which tends to make some QA, CM, infrastructure issues more tractable. The resource maintenance problems for these processes are solveable in procedural coding approaches, but maybe not in quite the same way.
I've spent too much time pounding my head against EJB and database builds/deploys and related source maintenance to believe any longer that there is a complete separation between technology, methodology, and process.
[ June 06, 2002: Message edited by: Reid M. Pinchback ]
Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
Originally posted by Reid M. Pinchback:

Good OO design can result in loose coupling between subsystems, which tends to make some QA, CM, infrastructure issues more tractable. The resource maintenance problems for these processes are solveable in procedural coding approaches, but maybe not in quite the same way.
I've spent too much time pounding my head against EJB and database builds/deploys and related source maintenance to believe any longer that there is a complete separation between technology, methodology, and process.

I think you slightly misunderstood me. The high level process itself is the same. The execution of the process will differ. Clearly the tools and medium will yield different benefits, especially in the software issues of testability, maintainability, deployability, etc. That's why we choose the medium and tools we do.
To further invoke the overused construction
analogy, no matter how you build a building, the overall process is the same. You pick a spot, design the building, come up with blueprints, construct it, patch up the errors produced during construction and put on finishing touches, and finally let people move in. This is true regardless of whether you are building a log cabin with a hammer and saw, or a skyscaper with cement mixes and pneumatic drills.
--Mark
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4445
    
    5

Feels like this thread is starting to belong more in the Process forum. Moving it there right now...
Thanks.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Corey McGlone:
Analysis/Assessment
Planning
Design
Implementation
Testing
Maintenance
Retirement

Notice that these 'phases' don't need to be totally separated. So, for example, you don't need to fully specify the design before starting implementation - it probably even would be a bad idea.
This is because the phases get feedback from their successor: Only if you show the system to the users you know wether your tests really tested for the right things. Only by testing you know wether your implementation works. Only by implementing it, you know wether the design is appropriate. And only by doing all this and paying attention to your development speed, you know wether your plan is reasonable.
So, if you don't want to realize that you build the wrong system in a way that doesn't work not until the project is "90% done", you should probably do the above in *very* tiny circles of short iterations (as short as a couple of weeks).


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
Reid M. Pinchback
Ranch Hand

Joined: Jan 25, 2002
Posts: 775
Originally posted by Mark Herschberg:

I think you slightly misunderstood me. The high level process itself is the same. The execution of the process will differ.

Not really a misunderstanding of what you said. I agree with your distinction between the high level process and the low-level execution details, although in some situations those details don't stay very low. Example: relational database CM process problems when you use Oracle technologies can't be solved without tackling application design standards; the same process dependency might not exist with Sybase. Here two processes that normally might be thought of as independent become dependent because of the particular choice of infrastructure component. Yes, the high level processs are the same, but the veneer between 'high' and 'low' can become increasingly thin.
Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
Originally posted by Reid M. Pinchback:
Not really a misunderstanding of what you said... Yes, the high level processs are the same, but the veneer between 'high' and 'low' can become increasingly thin.

Fair enough.
--Mark
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Requirements for OO development of a lifecycle!!!!
 
Similar Threads
Is PageContext Works Same As Servlet Context
I hate NullPointerExceptions!
WA #1.....word association
Essentials
software testing