This post is related in some ways related with Application Lifecycle Management (APL), DevOps and Continous integration (CI).
Steps on Software Project Management
Steps:
- Planning
- Development Methodology
- Requirement Specification
- Design
- Implementation
- Testing
- Follow-up
- Transition to maintenance
Planning
Planning is vital to achieve objectives. All activities within a plan should be focused on achieving the desired objective.
Planning must take into account:
- Time constraints
- Budget constraints
- Resources constraints
All steps since the beginning of the project must be planned. However, plan may start drafted and be updated and more detailed as the project progress. For example, it is impossible to define how long will a project take when we are not having the estimations. But the initial planning can cover the initial steps like, for example, consider all the previous steps until estimations are achieved.
Also, estimations can be provided in different level of details. For example, we can start with high-level estimation, and then update them with low-level estimations. This will imply an update in the plan.
Deviation and progress must be taking into account.
Deviation and change of scope are common in project development. We must assume it happens sometimes rather than denying it, and consider a very human limitation being unable to predict the future. The important thing is to register this deviation and change of scope, and re-plan and inform all stakeholder about the consequences on a timely manner.
Development Methodology
The main development methodology groups are:
- Waterfall
- Agile
- Singular
Waterfall is a sequential development process that flows like a waterfall through all phases of a project (analysis, design, development, and testing, for example), with each phase completely wrapping up before the next phase begins.
Agile is a group of methodologies that focus on iterative cycles rather than a one-way cycle. Its goal is to deliver faster that waterfall methodology by fostering direct collaboration between product and development teams. An example of agile methodology is Scrum.
Singular groups all other methodologies that are specific to companies or industries.
In my opinion, most companies or institutions tend to think they are using a very specific methodology when they are not really using it in an orthodox way. They usually cherry-pick features from different existing development methodologies and call it like one of them, while they are really taking customized or hybrid approach.
As agile methodologies sounds more modern and flexible that waterfall, many people involved in software projects have a tendency to rush to say they do “agile” approach even when they do not really know what it means. The worst thing of this is that they think there is no improvement margin (as they think the 100% of their processes is already “agile”) and are usually reluctant to hear the proposal of something in the custom or hybrid approach because they think of it as a step back, though they are actually already in that situation but are unaware of this.
In a general line, this is my advice when recommending a development methodology:
- Hybrid or pure methodology?
- Changes in development methodology require a process of change management. Both product and dev team may be reluctant for the change, so you may need to adapt the methodology to the current processes as a hybrid methodology.
- When going for hybrid methodologies, the processes must be very clear, negotiated and approved by all stakeholders and always accessible. The biggest risk of going for a hybrid methodology is that it is unclear and every stakeholder do what they want based on their own criteria.
- Use a pure methodology (e.g., orthodox waterfall or agile methodologies) in case there is no possibility of agreement among the different stakeholders. Then, it can always be said that the industry best practices are the chosen ones, and not a particular opinion within the group.
- Waterfall or Agile? These are my recommendations.
- In case of doubt, go to Agile or use it as a template and then add waterfall/singular characteristics. Generally, agile has better press and is more welcomed by stakeholders than waterfall. Waterfall is perceived as outdated, and agile as the natural replacement.
- Use waterfall if ANY of these characteristics is met:
- Trust and true collaboration cannot be established between product and dev teams, or there is interest than the other team fails or is publicly exposed. Example: there is a strong competition between both teams, and everything done in a team is used against itself.
- Project takes several months, requirements can be defined in advanced, they are very rigid and there are inflexible deadlines. Agile has the drawback that as there are short sprints and it is more difficult to plan in the long run.
- Note: You can add agile characteristics to waterfall to strengthen the weak points. Example: add periodical demos to share progress to product team, or organize daily stand-ups.
- Use agile if these characteristics are met:
- Specifications are not clear from the beginning. There is no clear understanding of the product or the desired outcome.
- Trust can be built between product and dev team
- There is no need to strongly document the requirements. If it is needed, some time on each sprint can be reserved to create documentation, but this will make the process less “agile”, in all senses.
- There is no frequent rotation of employees
Requirement Specification
When you start a software development, you need at least a hint of what you are expecting to get. This is what I call requirement specification. Depending on the methodology used, it may have a different name like business requirements, definition or specifications.
These goals must be defined by the product owners.
The definition will be more or less detailed, and more formally or informally, depending on the methodology.
Level of detail of requirements depend on developer expertise, connection with the product owners or understanding of the product or industry. , the most probable.
Waterfall methodology require more level of detail, because the idea is not to repeat iterations, so you must ensure that before starting implementation all definitions and scenarios are clear.
Definitions are sometimes used as a contract. This is specially important when we work in a functionality achievement approach (rather than a set of developers assigned permanently to a project), and also when outsourcing development.
It is a good practice to define test scripts during definition. In this way, the expected outcome is clear for the developer. In addition, it adds a measurable and objective way to assess whether the development objective was achieved, as a true-false statement (“Is the outcome of the process what has been defined in test scripts?” The only possible answers, if the test scripts are well defined, is yes or no).
Remember to define not only the positive cases where the process run smoothly, but also the possible errors. It is common to have to spend more time analyzing the error scenarios than the correct scenarios, as the error ones are more complex situations.
Design
You may have a design phase once or many times during the project lifecycle, depending on the methodology.
Some technical decisions that were avoid during requirement specification are taken during the design phase.
Low-level definitions are not usually delivered until this phase.
Implementation
You may have one or many development cycles, depending on development methodology applied.
You need to set a software development environment, what is expanded in this post.
This can be considered the most technical challenging part of the software creation process. The rest of the steps require are more balanced with the
Testing
There are different types of test. This one goes in a top-down approach:
- User Acceptance Test
- Functional
- End-to-end
- Integration
- Unit
Tests can be:
- Manual: requires human interaction
- Automatic: do not require human interaction
Depending on the automatic testing tool, a team member may need to program or record the tests that must be done as a previous manual step before achieving automatic tests. It may imply also some manual maintenance. This is the case of tools like GreenPepper.
An alternative is that testing tool detects possible bugs automatically. This is the case of Sonar Qube.
Identified bugs or faults must be registered in an software tracking system. You can find a list of popular software tracking systems on this post.
Different environments are used. The most usual is to have these environments:
- Development
- Test
- Production
There may be one or serveral test environment. They receive names like UAT, QUA, Preprod, etc. Each test environment may have a different version. Usually they are progressive, so the latter environments are closer to production environment.
Follow-up
Software projects require a regular follow-up.
It is very important to check that all deadlines are met. In case they are not met, it must be informed to stakeholders as soon as possible. Some of the stakeholders may provide solutions (for example, provide additional resources, reduce project scope, etc.).
Software tracking system should be accurately informed and always updated. This means the commitment of the whole team, who must understand the negative consequences of not being strict when using it.
Daily stand-ups is a method proposed by agile methodologies to ease communication in an informal way.
Transition to maintenance
At the end of each cycle, project team must complete a transition process to ensure that the delivered product can be maintained in a correct way.
Frequently project and maintenance teams are composed by different people, so in this case it is even more important that this transition is properly done.
Some of the taks that must be done during transition to maintentace:
- Inform users about new functionalities
- Train maintenance team about the new functionalities and possible issues
- Update monitoring and alert tools, if required