-3

Ok please dont downvote because im serious about this question. I hope im asking this in the right place.

At programming school they are currently teaching us about project management. Instead of teaching us the classic waterfall model, spiral model, smart or other project management models they have their own which basically states that:

Decision making comes after planning

Now I personaly have a problem with that because I believe you should decide before you do the planning. I mean we should know our target system, the framework and language we are using and other factors. Not doing any decision making before the planning phase either means the software becomes way too generic.

  • 3
    “planning” and “decision making” are both very vague. How can you decide unless you have multiple plans to choose from? I assume these terms have more specific meanings inside the framework you are being taught. But without knowing that context, this question is unanswerable. – amon Mar 3 '18 at 14:40
-1

Now I personaly have a problem with that because I believe you should decide before you do the planning. I mean we should know our target system, the framework and language we are using and other factors.

If you're in a planning phase you should first pick up the requirements.

You may elaborate the pros and cons for specific target systems to realize these, and decide what should be used after.
This process needs to have some knowledge about the target systems, frameworks and programming languages in question of course.

Not doing any decision making before the planning phase either means the software becomes way too generic.

You seem to miss some steps here. Planning the concrete software architecture and components, comes after requirement analysis.


As from your comment the proposed phases are

  1. Information Gathering
  2. Planning
  3. Decision Making
  4. Realization
  5. Testing
  6. Evaluation

Phase 1 and 2 is what I got known to as Requirements Analysis and Architecture Design.
As mentioned that requires to evaluate some possible ways to go for specific target systems, frameworks and programming languages.

At the end of this phase, you should have at least two or more alternatives you can choose from.

Phase 3 isn't actually a "phase" but more a gateway into the realization phase.
At this point we decide which is the best way to realize the requirements by means of

  • cost
  • feasibility with the available personnel and their skills
  • assessable time and efforts
  • assessable ROI (return of investment)

At the Realization phase the software developers refine and detail the chosen software architecture model together with the requirements analysts and software architects.
This also requires decisions and team consensus by means of

  • assesable time and efforts
  • robustness against change requests
  • overall maintainability

The Testing phase should approve that the realized software components meet all of the requirements.

Evaluation means to make acceptance tests with selected customers and approval if the use cases described in phase 1 and 2 were well selected and understood.

All of these phases should give some feedback to the former ones, and may require to make refinements and change decisions made formerly.
This can even go that far, that a project manager decides to "pull the ripcord", and the whole project may be stopped to prevent burning further money with a hopeless undertaking.


I've been and are in all of these roles for about 30 years now:

  • Requirements analyst
  • Software architect
  • Software developer

Thus I know a bit of what I'm talking about, no matter what that thing is called at academia.
I've always just picked up the methodologies which best fitted my needs, and these might differ by means of scalability.
In any case decisions are made after former analysis and feedback, not beforehand.


At arc42 you can find some excellent material and templates to support this process.

  • The way they split it up is: "Information Gathering" - "Planning" - "Decision Making" - "Realisation" - "Testing" - "Evaluation". In German the model is called: IPERKA. Does that mean that decision making is part of the requirement analysis? – Asperger Mar 3 '18 at 14:42
  • @Asperger Well, I'd call "Information Gathering" and "Planning" Requirements Analysis. But decisions are made after (at least as a gateway to the Realization phase). That's perfectly fine IMO. – πάντα ῥεῖ Mar 3 '18 at 14:44
  • @Asperger "In German the model is called: IPERKA" Wieder mal so eine arme Buzzword Sau die da durch die Uni getrieben wird :-D. Glaub' mir: Es ist seit 30 Jahren immer dasselbe. – πάντα ῥεῖ Mar 3 '18 at 14:49
  • When I think about planning im thinking about UML Diagrams, API Design etc. What exactly do you usually decide after you done that part? I decide to develop my software in C# and WPF. Maybe i might even list some alternative frameworks and decide which to use. I evaluates the pros and cons. That all dictates the way I design my software. Then I design my software according to these decisions. – Asperger Mar 3 '18 at 14:51
  • @Asperger Those phases look like a classic management model, usually with a feedback from testing/evaluation back to planning or decision making. It's not really a software development methodology. – amon Mar 3 '18 at 14:52

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.