SDLC

Our Software Development Life Cycle (SDLC) is a framework of well defined tasks for each step of our software development process. This SDLC is the structure followed by our development team within Powwow Technologies Ltd. As you can see it consists of a detailed plan describing how to develop software solutions. The life cycle defines a methodology for improving the quality of software and the overall development process.

It starts with a list of potential projects that are approved at a high level and ready for funding. We identify the stakeholders of the project and agree the initial architectural vision. This vision is designed to present the benefits of the proposed solution to the decision-makers within the organisation. The design of the overall solution should:

• Enable the business goals
• Respond to the strategic drivers
• Address any stakeholder concerns and objectives
• Conform with the business principles

Once the architectural vision is agreed it’s on to requirements gathering. This means researching and discovering the requirements of a system from users, customers, and other stakeholders. It sounds like common sense but often times it’s given far too little attention.

The Business Analyst will gather the full project requirements. This can be done by a number of techniques E.G Existing Systems Analysis, Questionnaires, Polls and Prototyping.

Human driven reviews will typically test the security implications of the people, policies, and processes of a system. It can also include inspection of technologies used and architectural designs. These reviews are usually conducted by analysing documentation or chatting with the designers or system owners.

Human driven reviews can be a very powerful and effective techniques for spotting issues early on. By asking how something works and why it’s implemented in this way, it allows testers to quickly determine if any security concerns are likely to be evident. Human driven reviews are one of the few ways to test the software development life-cycle process itself and to ensure that there are adequate skills in place to take on the project.

Once the overall project tasks are prioritised it’s on to Sprint Planning. Each sprint will take 2 weeks. The sprint starts off with Threat Modelling. Threat Modelling is a process where structural vulnerabilities can be identified, enumerated, and prioritised from a hypothetical attacker’s point of view. Not all sprints will need to look at this in detail but it should be discussed at the beginning of each sprint to understand if any vulnerabilities can be identified, worked on and resolved in the current sprint.

Once the tasks/tickets have been created and picked up by the team members the sprint kicks off. Development, unit testing and code reviews take place daily within development teams and any code changes being reviewed will have an associated ticket. Review changes are kept small to allow developers to review code quickly and find potential issues easier. A team stand-up takes place each morning to share the current status of the sprint and to identify any issues or blockers

At the end of each sprint a demo will take place in front of the stake holders and any other interested parties. This is an excellent opportunity for the stake holders to understand how the system will operate and give early feedback. Any issues found at this stage on the latest work can be easily fixed and prioritised in the upcoming sprint if needed. A retrospective should also take place within the team(s) to understand what’s going well, not so well and what improvements can be made.

Once the system is developed the integration testing can take place on a dedicated environment. The purpose of integration testing is to look for faults in the interaction between different parts of the system working together.

Following on from this we implement penetration testing. Penetration testing also called ethical hacking is the practice of testing the system (networks, servers and applications) to find security vulnerabilities that attackers could exploit.

Once all testing has been completed a detailed report is produced. Generally High and Severe Level items need to be fixed before a live release. Medium and Low items can be done with 30-60 days.

Once testing is complete and all required changes implemented it’s time for sign-off and the go-live plan. The project managers and key stake holders will form the sign-off team. Once sign-off is completed the go-live plan is completed and approval is sought for the plan and go-live date.