I am building a software and trying to learn the typical steps for software life cycle, I am not sure if what I did is correct or enough so I would like to ask for the typical steps you follow during your life cycle in terms of actual steps taken for example requirement gathering is a not the step i mean, but gathering requirements using User Stories from the customer or from the requirements documents is the step I mean.

This is what I do now,

  1. Write User Stories from the requirement document I had.
  2. Write Use Cases for these stories.
  3. Collected nouns from the requirement documents and used them as classes to build class diagram.
  4. Draw state diagrams for main entities in the class diagram.
  5. Draw database diagram to map the class diagram to database tables
  6. Started coding to 3-tier architecture.

Please tell me if I am doing it right or missing something.

  • I think you either have user stories OR use cases. Having both seems an overlap of two different life cycles. User Stories belong to Agile development methods, while use cases are a part of "formal" approaches existing before Agile became the way forward for most cases. – Ozair Kafray Sep 11 '13 at 10:16
  • 1
    i dont think they are really the same, please check this stackoverflow.com/questions/13524763/… – Sisyphus Sep 11 '13 at 10:48
  • @OzairKafray, both user stories and use cases are widely used in development methodologies, usually with differences in meaning too. What matters is in your methodology is how are they defined – Michael Shaw Sep 11 '13 at 11:03

Ah, one of life's great questions. There are many ways to answer this question and the answer that works for you will depend entirely on:

  • The skill and professionalism of the development team
  • The nature of the development work
  • How the customers interact with the development team
  • How the development team is financed
  • The character of the manager / company owner responsible for the development team
  • The latest management buzz words on software development

Ohh, who am I kidding, the list is infinite.

Software development is always done somewhere on the spectrum between complete chaos, and a defined development methodology that has some flaws, but its how we have decided to do it here. Most developers believe its closer to the chaos end, and managers think its following the methodology

The steps you have described are part of several methodologies, but are not appropriate to be used in other situations. Take for example, the start-up company boldly going to launch a new product in a new market sector with no existing customers. Its very difficult to write clear and definitive user stories when you don't yet know who your customers are going to be, or what they expect your service to do in the kind of detail needed to do this properly.

Other environments, are very formal, This IS the set of requirements, That IS what you will deliver, and last month IS when you will have delivered it. (Otherwise characterised as industry standard software - costs too much to develop, doesn't do what the end customer wanted, full of bugs and delivered years late)

In reality, the practical solution is this:

There are a range of process approaches that have strengths and weaknesses. You make a choice from these approaches of which aspects fit within the business and team constraints about how the world around the development team operate, and develop accordingly.

If your customer is big on requirements, specifications etc, then you are more likely going to be developing along a waterfall approach.

If your customer is problem focused, 'solve this problem for me' then you are much more likely going to be doing agile or rapid prototyping development.

  • thank you for your reply, but unfortunately i am still confused until now, let me say, if you are working alone on a project, have a 50 paper requirments document for a small to medium sized project, your boss is very understanding and putting almost not technical restrictions on you, and you cant say that the schedule is tight, you will finish this project view it to the customer who wrote the requirment documents, he may request few modifications or additions, you will do it for him, and you are done, what would be your 1 2 3 for this project life cycle? thanks :) – Sisyphus Sep 11 '13 at 10:09
  • You need to figure out your commercial imperative here. Is your companies commercial incentive to deliver against this spec, be paid, and then charge for amendments? Or have you got a time and materials commercial agreement, where the commercial goal is to make effective use of the time for the customer and to finish the work with the customer happy with the product? – Michael Shaw Sep 11 '13 at 10:25
  • i guess the second one would be closer to the case. – Sisyphus Sep 11 '13 at 10:45
  • 1
    In that case, I personally would read the spec, visit the customer, see the problem they are trying to solve, and then adopt an agile style approach, where they were receiving a new demo on a regular basis (every couple of weeks hopefully), using the requirements as guidance, but using the customer for clarification, and to question requirements that don't make sense. In terms of tool chain, I would use source control and a build server, mainly to ensure consistent releases, and remain focused on what the customer wanted to achieve and how much of your time it will cost them – Michael Shaw Sep 11 '13 at 10:54
  • 1
    The advantages of this approach, is that the customer is very likely to get the product they actually need, that they have very clear visibility of progress, and there is little chance of a major contract bust up since its commercial base is time/materials and the customer is directing where the time is spent. – Michael Shaw Sep 11 '13 at 10:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.