7 tips to choose a Methodology for Software Development

There is quite a variety of Process Models and Methodologies that could be used for a project.  Although there are fans of each model and methodology,  the question to answer is which one fits best for our specific need. This is where I will try to help you in this post.

Sometimes a methodology is used in a company due to company standards (i.e. SixSigma is a standard for General Electric), or just because it has been used during some time, or because the project managers and sponsors do not know well the benefits to apply other methodologies, or just because they are frightened of the change. 

For Software Development we could use different Process Models, like 

• Linear Process Models, that follow a pattern of phases completed one after the other without repeating phases (Waterfall, V-model, Sawtooth model,..) and

• Iterative Process Models, that allow repeating stages of the process and are cyclical (Spiral model, Unified Process Model,...). These models may be used along with Agile Methodologies, like Lean, Kanban, Extreme Programming or Scrum to mention a few.

dilbert.com all rights reserved

I would like here to point out some tips and benefits of the mostly used Process Models and Methodologies, to get some idea on what is better for us:

1. Linear Process Models are not very adaptable to change. I used quite often these models, but usually for projects with very fixed and well defined requirements, that involved not only software development, but hardware integration. Although changes could happen in this model by applying Change Management practices, the model is not very well designed for those changes, so if these changes happen late in the project, they may add great delays and costs.
2. Iterative Process Models are more adequate for Software Development as they are focused on iterations, with releases deployment after each iteration, getting feedback from customer and improving/modifying the product in each iteration. Desirable this iterations are short (under one month), so adaptation to change is much easier than with Linear Models
3. Unified Process Model is one of the most interesting Iterative Process Models, that emphasizes gradual development. Something I like from this model is that it considers parallel work at the same time as cyclic iterations. Therefore for example it is possible to design the product architecture while developing tests at the same time. This is good and logic, as the Architecture may change when there are changes in the requirements and sometimes it is not necessary to have the full system architecture design ready before the coding phase starts. It is ok to have a general architecture definition at the beginning and go more into detailed architecture design for the features we are going to prepare during an iteration.
4. Extreme Programming Agile Methodology or XP is all about client satisfaction by encouraging customer feedback during all development, small and frequent releases, simple designs (adaptable to change), coding standards, continuous integration and testing, balance between work and personal life and something that, in specific phases of the project is really good, although costly, that is “pair programming”, meaning that programming is done in groups of two developers, using the same computer and developing the same piece of code. It is interesting because drastically reduces failures in the code design, but needs to ensure that there are no personality conflicts in each pair. Also we need to keep in mind that XP is designed for small development teams. With big groups may become a mess, specially in the integration part
5. Scrum is one of the most popular Agile Methodologies that is based on three pillars: Transparency, Inspection and Adaptation. From the Transparency pillar I really like the common agreement on standards and the “definition of Done” concept, that basically emphasizes clear common understanding on when a feature to develop is considered finished. This prevents misunderstandings and false expectations that later could add complaints and delays to the project. Also from the Inspection pillar I like the four events that happen in a Sprint (cycle in which a working release is produced). These events are: Sprint planning, daily Scrum, Sprint review and Sprint retrospective. They are a good way to progress in the project without spending much time in management or micromanagement.
6. Lean software development (LSD) is a translation of lean manufacturing principles and practices to the software development domain, to reduce risks and deliver high quality products quickly. It sounds good, isn’t it?. I like one of it’s main principles: “Eliminate waste”. It states that anything that doesn’t add value is considered waste, like unnecessary meetings, unclear requirements or product defects. Other important principle, “Building Quality in” promotes the use of the best practices available to avoid errors in development, may be by using the pair programming concept, well commented code and good documentation, Refactoring if needed and automated testings.
7. Kanban is used in Lean Software Development. This approach aims to manage work by balancing the demands with available capacity, and improving the handling of system level bottlenecks reaching the ideals of Just-in-time manufacturing. In Software Development this balance is made having multi-functional teams that could be placed in one or other phase depending on the demand. For example a developer could become tester during a specific period of time, depending on the “work in progress limits” established in each phase. Work items are visualized to give participants a view of progress and process, from start to finish usually via a Kanban board. Work is pulled as capacity permits, rather than work being pushed into the process when requested.

In summary, choosing one Process Model and Methodology depends on the kind of products to develop, the size of the development team, the culture of the company and the relationship with the customer, between others.

Depending on the company I worked for and the kind of project, I used Six Sigma (not described in this post), Waterfall, or Scrum Agile methodologies, but usually I added some ingredients from other methodologies that I considered may add value and adaptation to the needs. Sometimes being too strict with the methodology may not be the best option, depending on each specific situation. Because of that, it is good to know several methodologies, even if you are just using only one of them.

Reference:

• Lean Software Development. Wikipedia. https://en.wikipedia.org/wiki/Lean_software_development
• Software Product Management. University of Alberta. Coursera. https://www.coursera.org/specializations/product-management
• Kanban. Wikipedia. https://en.wikipedia.org/wiki/Kanban_(development)#Software_development
• Software Development Methodologies. IT Knowledge Portal. http://www.itinfo.am/eng/software-development-methodologies/

ROS, for more than proofs of concept

It was not so far in time when I used to program robots using assembler language, a sort of machine code extremely close to the hardware of the machine. In those times programming a robot for complex functions, like navigating autonomously from one room to another was a difficult and time consuming project, that may take months for a team of people.

Robotics is evolving very fast as well as the open source movement. A really interesting outcome of both evolutions is ROS (Robot Operating System). ROS is an open-source, meta-operating system for robots, is a robotics middleware (i.e. collection of software frameworks for robot software development). It provides the services you would expect from an operating system, including hardware abstraction, low-level device control, implementation of commonly-used functionality, message-passing between processes, and package management. It also provides tools and libraries for obtaining, building, writing, and running code across multiple computers.

Nowadays it is possible to program a proof of concept for a robotics system in few days, thanks to ROS and all the open source, already available tools. Its integration with Gazebo Open Source Simulator is also a great help on the design and test of algorithms and behaviors.

Just as an example, let me share with you a development I did recently, using ROS. It took me about 10 hours to write on my own an application for a robot to work as a messenger, able to go to any room or location in a house  or an office to deliver goods. The function of the robot is very straightforward: You just put something on the tray of the robot and indicate in the touch screen where to deliver. Then the robot, using a 360 degrees laser scanner for detection of the environment and SLAM navigation technology, finds a trajectory to the required location. This development would have taken easily 6 months of work for a team of 5 people 10 years ago. Now you could have it in 10 hours of only one developer and with a hardware technology (robot platform, lidar, embedded computer) 

HERE you could also find all the documentation about the development of this solution.  In fact this documentation will be one of the chapter of my next book about ROS that I expect to publish soon.

But ROS is not only for developing a proof of concept, but real products for consumer and industrial market. I will talk more about it in future posts.

Thanks for the Open Source philosophy, thanks for the developers of Linux, the Open Source Operating System in which ROS works, thanks for all the hard work done by Willow Garage team for the development did of ROS and thanks to the incredible community of developers that share their knowledge and code for the Robotics evolution. This is the key factor of this time. We all are working to make the Robotics technology evolve, by sharing, for the art of sharing.

GIThub repository: https://github.com/aalonsopuig/MrMess_Robot.git

Reference:
[ Wikipedia. https://en.wikipedia.org/wiki/Robot_Operating_System ]
[ Ros.org http://wiki.ros.org/ROS/Introduction ]