Off-the-shelf software provides all (or, at least most) of the functionality we need. As a result, this is what most consumers and many businesses choose to buy. Until recently, this software was hosted on hardware devices owned and managed by the enterprise using the application.
Today, more and more firms are using Software-as-a-Service (SaaS). In this delivery model, software is hosted on the cloud and accessed via a browser. With SaaS, the enterprise typically pays a per-person, per-month fee that eliminates all ownership and maintenance costs.
However, some companies feel they have unique needs. Others are using digital technology to generate business advantage. Such companies may therefore choose to develop their own custom software using in-house teams. This can then be deployed on-premise or on the cloud.
The Software Development Process
Different types of people are involved in creating software.
Chief among these are the software engineers responsible for the design of the application as a whole. They apply engineering principles to software creation and software testing.
The bulk of computer programming is carried out by development teams. They work with key stakeholders to determine what their needs are; then use development tools to implement the application and ensure it is aligned to the design.
Both groups make use of the Software Development Life Cycle (SDLC). The SDLC is a structured process that enables efficient creation of high-quality software. It breaks down the long, complex task of software creation into discrete steps.
The benefits of the SDLC are many and varied. Chiefly, it ensures that software is created with maximum speed, and minimum risk and cost. It does this by providing a standard framework which defines all activity and outcomes.
Multiple process models are available for the SDLC, each of which has pros and cons. If you select the wrong model for you, this will increase the risk of project failure. So, this is a decision that needs careful thought. The most popular models in use are:
- Waterfall Model. This is the oldest and least complex model. Under this, you simply finish one phase before moving to the next. It is simple but it is not quick. It also allows for little in the way of course correction if any problems are discovered. Many believe this model to be unsuited to the needs of a volatile business environment.
- V-Shaped Model. This is a variation of the Waterfall approach. It is also known as the Verification and Validation model. This directly assigns a testing element to every phase in the development cycle. This means problems are easier to detect. However, large-scale changes to software design are still hard to achieve.
- Iterative Model. This is a more cyclical process. Instead of starting with a clear set of business needs, it aims to implement a set of software requirements. As the name suggests, a working version of the software is created quickly. This is then iterated repeatedly, and the functionality of the software expands with each iteration. As you might case, this process needs to be tightly governed. If not, ‘scope creep’ can easily set in and resources and costs can rise out of control.
- Spiral Model. It combines aspects of both the iterative and waterfall models. It features both iterative and sequential development with a strong emphasis on risk analysis. The project passes repeatedly through four phases in a ‘spiral’ until it is finished. This allows for strong end-user input and enables very bespoke software creation. The risk, of course, is that the spiral never finishes.
- Agile Model This model is also highly iterative. However, rather than aiming for complete applications, it focuses on creating functional capabilities. These are then combined together to fulfil business requirements. Agile uses the scrum framework to guide software development. It also deploys diverse teams in ‘sprints’ which focus on the delivery of a function in a finite time frame. The Agile model can be very efficient. However, a clear direction for the project needs to be defined at the outset and maintained throughout.
The Stages of the SDLC
There are usually six stages in this process.
- Needs analysis. It is the most fundamental and critical stage of the SDLC. If aims or processes are unclear, this is likely to increase both the cost and the risk of the project. If a commercial software company is creating the software, this stage will require extensive market research. If it is done in-house, project leaders will need to engage with key stakeholders to understand the outcomes they want the project to deliver. In both cases, the aim is to deliver a Software Requirements Specification (SRS) document. This describes what functionality the software is planned to have; and how it is be expected to perform.
- Design. Once the needs are known, software design development can begin. This is codified in a Software Design Document (SDS) which provides the high-level architecture of the application. This should specify the hardware platform, operating system, and programming language to be used. This should also define all the key modules of the product; and dictate communication and data flows with any external or third-party elements. A prototype or proof-of-concept (PoC) might then be created to flush out any glaring problems or to firm up requirements.
- Development and Testing. This is the point at which the actual software starts to be created. It is crucial that each member of the coding team sticks to the plans defined previously in the SDLC. This team has different types of skills. Front-end experts tackle the user interface. Database Administrators (DBAs) ensure the right data is available. And software developers write and implement the code.
Once created, it is vital to confirm that the code meets the defined requirements. This is when the Quality Assurance (QA) team takes over. They test the finished software, flagging any bugs so the coding time can fix them. This process continues until the software meets the required functional and quality threshold.
- Deployment. Once the code has been tested and approved, it then needs to be released into a production environment. For commercial software products, this may involve some customization and additional testing. Training and support should also be considered: software that isn’t used properly will not deliver on its full potential. All software must also continue to adapt to the real-world environment. New security issues will arise. New (or overlooked) user requirements will be discovered. Ongoing development will be necessary to ensure the continued relevance of the software. This means that the whole SDLC must be repeated on an ongoing basis, though hopefully on a much smaller scale.
- Documentation. For any programmer, reliable documentation is always essential. Documentation helps monitor the different aspects of the completed software. It also enhances its long-term quality by ensuring it can easily be kept up to date or enhanced. Good documentation makes information easily accessible and ensures knowledge transfer. It lowers support costs by enabling new users to quickly learn what they need to know. Documentation can include, but is not restricted to, the following: business rules; database records; server platform; and installation and deployment.
- Evaluation. This is sometimes called a post-implementation review. Not every company considers this to be an official part of the SDLC. Some believe it to be part of the maintenance stage. While opinions vary, there is no doubt that evaluation is critical. It is how you confirm that the system maps to the initial needs and objectives. It is how you prove that the system is stable. This is also the phase when any flaws can be identified and addressed. It is also a chance to look at the effectiveness of the development process itself. Important lessons can be learned through evaluation that could have a positive impact on future projects.
Software creation is complex, so project management of the SDLC is crucial. The role of project managers is varied. They manage all the people and teams involved in the project. They ensure quality assurance so that the completed application is stable and fit for purpose. And they must keep all those with a stake in the success of the project fully up to date.
Secure SDLC (SSDLC) ensures that security is built into software creation and not bolted on at the end of the process. It gathers best practices that aim to add security to the existing SDLC approach. More than just a process, SSDLC requires a mind shift from development teams. It is no longer good enough just to think about functionality. Instead, it requires a focus on security at each phase of the SDLC. This approach ensures that security flaws are spotted earlier – and that the costs of fixing them are reduced.
Proprietary vs. Open Source Software
For decades, all software was proprietary or ‘closed source’. This protects the intellectual property of those that created the software. On the other hand, it limits the ability of developers to adapt the code to their unique needs. Only the original authors of the code are legally allowed to copy or amend closed source software.
Their customers are asked to sign a license agreement that ensures they do not tamper with the code in any way. Microsoft Windows and the Apple macOS are both examples of closed code software.
In the mid-1990’s, Linux – an open source alternative to the Unix platforms that powered many businesses – became popular. Since then, the open source movement has grown into a widely accepted foundation for software creation. According to opensource.com, the term refers to
“Software with source code that anyone can inspect, modify, and enhance”.
It is free to use, but conditions attach to this. Any improvements you make must be given back to the open source code community that created the original code.
Today there are 180,000 open source products and they are used by 90% of companies. Many commercial companies choose to donate their proprietary code to the open source community. For example, Google donated its Kubernetes platform for running containerized workloads to the Cloud Native Computing Foundation. In doing so, it made its technology the de facto industry standard.
In truth, it is impossible to say with certainty whether open or closed source software will be the right one for you. There are pros and cons to each approach. The biggest demerit of closed source software is that you have to pay for it. However, many people choose to do so because they believe it offers a better alternative to a free product. For instance, a million businesses worldwide use Microsoft Office 365. This is despite the fact that Google G Suite is available at no cost. Proprietary software also tends to offer a high degree of integration with the other parts of your IT estate.
Fans of open source software point to the fact that the community consists of perhaps tens of millions of people worldwide. That is a huge resource that offers an almost limitless capacity for innovation. On the other hand, open source software may be tricky to use and may not be compatible with other software products. There may also be issues with warranties and with getting the support you need.
The biggest challenge of software development is that it’s hard. It takes time (and patience!), and it’s not really over once you hit publish. In this ever-changing world, you need to continually evolve it to meet users' demands.
The good news is that now there are modern development approaches with embedded tools designed to accelerate app development and automate much of the application lifecycle.
OutSystems is a software development solution that helps developers build serious applications quickly and efficiently.
A visual, model-driven development environment with industry-leading AI-based assistance ensures apps are built in days or weeks instead of months or years. Platform services, also with AI, provide automation enhancing the entire application lifecycle so apps can be deployed with a single-click and managed with unparalleled ease. You can give it a try by signing-up for our free edition.