Software Development Lifecycle RRS feed

  • Question

  • Hi

    We hear so many things nowadays about Softwate Development Lifecycle, Architechture, UML, Design Pattern etc etc. I know it may not sound good to some of you. But can anyone list out the activities of a Software Development Lifecycle. Lets say I want to develop a brand new product / project what stages would be involved I mean how would I implement all the things I have mentioned above to the development. I have some idea on all the things I have mentioned above.



    Thursday, December 14, 2006 11:31 AM

All replies

  • Not shure if this is what you mean, but here is a basic outline of how I plan product development:

    - Write basic product definition including business case and basic functional requirements

    - Get a budget (money or time)

    - Make a functional design

    - Make a basic technical design

    - Determine prototypes and proofs of concept and build them

    - Make detailed technical design

    - Make release plan (based on budget, likely not all functions can be build)

    - Build it

    - Test it (then go back to build it until you're done)

    - Document it

    - Release it


    Personally I don't use UML and I feel design patterns should come natural. Technical design is idealy a team effort, where the architect has a leading role.

    Hope this helps you.

    Thursday, December 14, 2006 1:00 PM
  • This Blog points to a paper on the EssUP which may be helpful.


    Thursday, December 14, 2006 4:58 PM
  • The seven Steps :

    1. Preliminary Investigation
    2. Requirement Analysis
    3. Design
    4. Development
    5. Testing
    6. Implementation
    7. Maintenance

    This Seven process is called a Software Development Life Cycle(SDLC)
    Friday, December 15, 2006 5:12 AM
  • The Seven Steps as Practiced in a “Real World” Vertical Market Software Company

    1. Preliminary Investigation


    -          Mary Jo, a product manager in marketing, reads a magazine article and decides the company needs a product that has every new and hot feature she just read about. Does it matter that a lot of it isn’t practical or applicable to the product lines you sell? Of course not! She sells her boss, Stan, the VP of Sales and Marketing, on the idea and he tells Phil, the CEO, that this is a “must have ASAP” product. Phil then orders Ryan, the CIO and your boss, to get the project started right away. Ryan pulls you, a development team lead/manager, off the project you’re working on and tells you to get with Mary Jo about the new product.

    2. Requirement Analysis


    -          Mary Jo is very busy. It takes about 2 weeks to schedule a meeting with her because she keeps canceling. Finally, you meet for about 15 minutes and she hands you her ideas scribbled on a couple of legal pad sheets and a poor photocopy of the article. Then she’s off to a marketing conference in Jamaica for 10 days. Of course, you have questions about her off-the-wall scribbling but Ryan wants to know why your team isn’t coding the project yet.

    3. Design


    -          With Mary Jo not around you put together a preliminary design document and some prototype screens to show her when she returns from her ‘conference’.  Ryan drops by, takes a look at the prototypes and says, “This is great. We’ll have the product ready to ship in no time.” When you explain that these are simple, non-working, prototypes Ryan explodes at  you, questions your team’s competence as programmers, calls you lazy and a poor leader, and tells you to stop wasting time working on ‘fluff’ and code the [explicative] program.

    4. Development


    -          After your verbal beating, you start turning the prototypes into the actual application. Ryan is happy to see that you’re coding and tells you that he’ll sign off on the design since Mary Jo isn’t available. Soon though, Mary Jo is back and, after the usual 2 week delay to schedule a meeting, she looks at your in-development work. She goes ballistic because what you’ve done isn’t want she wanted. She complains to Stan and Phil about it and they question Ryan about it. Ryan tells them that you’re a “loose cannon” who went ahead and started coding without permission and that he’ll reprimand you for it.  Ryan then delivers another verbal beating, insulting your abilities in a monthly staff meeting.

    Frustration mounts as Mary Jo refuses to sign off on a design while Ryan insists that you code and complains that you’re behind schedule.  After several painfully long meetings and a little arm twisting by Ryan, Mary Jo signs off on the design while letting everyone know how unhappy she is about the product. A project timeline is created by Ryan that is unrealistic but you agree to it in order to avoid yet another verbal assault. Your team codes like crazy, working extra hours and weekends, and manages to deliver an internal test version of the program on the target date set in the timeline. Ryan is livid though because his development completion date meant the ship date, not the date it went to testing.

    5. Testing


    -          Pat, the QA manager, takes the internal test version CD from you and throws it on her desk and, after a day or two, hands it to Tim, a QA tester. The disc has been damaged and won’t load but Tim is too busy betting on sports over the Internet to get a new one from you. After a few days, he tells Pat that the product won’t install properly and is too defective to test effectively. Soon you get another visit from Ryan who lets you know exactly what kind of idiot you are.  You prepare new install CDs, deliver directly to Tim with Ryan in tow and make sure that it installs on his system and runs correctly. Tim sighs, knowing he doesn’t have an easy out this time around. His testing process is slow but he doesn’t find any major defects.

    6. Implementation


    -          Bob, a Sales Manager, has a large client that wants the new product “NOW!” even though it’s still in testing. He gets permission from Stan, the VP of Sales and Marketing, and Ryan to take an install CD from the test lab and deliver it to his very important customer. You don’t find out about this until Joan in the tech support group calls you and asks why the new product won’t install on the customer’s system. Yes, they sent the customer the original defective CD.

    Finally, the actual product is released. Ryan is in a good mood for once and gives you a quarterly achievement award for all your hard work, a handsome MS Publisher template certificate printed on the color printer and a $20 gift certificate from his favorite restaurant.

    7. Maintenance


    -         A few bugs are found in the program once it’s in the field but you aren’t concerned about this since you no longer work at the company. A couple of weeks after the product release it was review time and Ryan, as part of the company’s “top grading” HR plan, decided that you were a “C” player and needed to be fired for “the good of the company”. He has his formal reprimands plus Mary Jo’s and Tim’s complaints about you to back him up. You’re called to HR and they deliver the bad news to you and security escorts you out of the building without you being allowed to go back to your desk. The company ships the personal contents of your desk (what’s left after people pick through your stuff, that is) to you in a week or so.

    You find another job, eventually. Steve, your new boss, mentions that you’re replacing a guy who just didn’t work out and would you meet with Beth in Marketing about a new project she has in mind. You think, “The road goes on forever and the party never ends”.

    • Proposed as answer by Ashwini47 Thursday, May 10, 2012 1:27 PM
    Thursday, December 21, 2006 4:51 PM
  • What Frank means to say is, always confirm by email and keep an archive!

    This way, when a review comes along, you can smack people around with it if they are trying to get you out and just maybe, they will leave you alone the next time around.

    I like this slightly overdone, but mostly realistic representation (you can't tell me you get fired after every single project and still blame everybody else...

    ...or do you?).

    Friday, December 22, 2006 6:37 AM
  •  Jonathan van de Veen wrote:

    I like this slightly overdone, but mostly realistic representation (you can't tell me you get fired after every single project and still blame everybody else...

    ...or do you?).

    Thanks, I’m glad you enjoyed it. It comes from the “worst of” experiences from about 5 or 6 different projects, not all of them mine, thank goodness.


    But I’ve mostly worked as a contractor so, yes, I do get ‘fired’ at the end of every project.


    Friday, December 22, 2006 5:41 PM