Software Methodologoes


For a list of software development life cycles (methodology ?!) see:


Notes on Life Cycle

Defining the Project

  • Document usecases even when the project is small. No need for usecase diagrams.
  • Do not repeat terms in every usecase. Have a reference document.
  • Prototyping the GUI and signing it off is always a good idea.


  • Estimate based on the slowest person in the team
  • Always consult the person responsible for the task for the estimation.
  • Consider time for environment setup, testing, leaves, etc.
  • More man power rarely saves a late project! That is because of the increase in communication and coordination. It usually adds more cost and it is better to be done as early as possible.
  • Humans are not good at estimation, whether it is story point or time based. Teams are better when they re-estimate frequently.

An Algo for Estimation

  • Step 1: For each usecase account for the number of screens in GUI, external application interfaces, database tables, table or file conversions.
  • Step 2: Account for analysis, design, development, integration and unit testing time.
  • Step 3: Add 20% to your estimate for any additional developer.
  • Step 4: Review your estimate over time, consider risk and share it with the others.
  • If developers are not involved in estimation then you will have a problem.

Objects Identification

  • Identify objects as early as possible. Relations are not that important now.
  • Trying to generate code from UML is just a time loss!
  • Turn objects into classes

Data Model

  • Pay attention to m-m and normal forms. m-m relations may produce extra objects.


  • Do some design even in the fastest agile methods. Do not dive into coding straight away.
  • Once the project passed the analysis and high level design then you need a change request control mechanism.

Scattered Notes

  • Define a non-negotiable end date for the iteration
  • Individuals and Interactions are more valuable than Processes and Tools.
  • Sacrifice functionality to keep the team on schedule.
  • End dates focus the team on delivering the required functionality. Even if some features are not completed, delivering those that are ensures customers get new functionality on a regular basis.

My Sequence

Define use cases (use case analysis) — > Estimation —> Identify application interfaces —> Fix high level architecture —> Create object model from usecases —> Turn objects into classes and refine your design —> Identify objects into layers or packages they belong to —> Identify methods —> Create data model (can be done before object model if you like) —> Network architecture design


  • : team collaboration and communication


Minimum Viable Product is a strategy and not a methodology used for fast and quantitative market testing of a product or product feature. It is different in concept from agile methods.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License