Every software or website goes through a series of steps before it is fully functional and ready to be deployed. Depending on the scale and nature of the website, these steps might see some compensation. In most cases, these steps are the standard that is followed.
The entire life cycle of the software can be split into the following six categories which are only the broad description of what one might expect. Additional steps may be needed in some cases to achieve some specific end goals.
SRS
An SRS or Software Requirements Specification is a technical document that describes a project’s goals, functionality, non-functional elements, limitations, design and overall operation.
SRS serves as an agreement between the developer and the customers that defines how the product is supposed to function. There are two major factors that constitute the SRS, namely
- Functional Requirements
- Non-functional Requirements
1. Functional Requirements
Functional requirements pertain to the actual work that a product is supposed to do. Without meeting these requirements, a particular end goal or result cannot be reached. By perfectly defining the functional requirements of a product, a customer limits the extent of a program’s potential, which is crucial for developers to know.
2. Non-Functional Requirements
On the other hand, non-functional requirements are specific to the overall state of the product. In simple words, non-functional aspects talk about the qualities of a product.
Is it mobile-friendly? Is it portable? Is the algorithm stable?
Such questions are all criteria that can be used to judge a program or product. These qualities don’t necessarily talk about the purpose of the product but of the wider aspects on the whole.
Makeup of a Standard SRS
By using specific conditions such as functional and non-functional requirements, as well as use cases and other specifications and limitations of a product, it becomes easy for a web developer to gauge the extent and complexity of a project.
SRS serves as a compass at every step of the way, thereby reducing the chances of software failure and redesign. SRS also lists the costs, risks, milestones, and schedules pertaining to certain parts of the software.
Overall description covers both the product perspectives like interfaces and memory constraints, as well as system attributes such as security and maintainability. Other descriptions may include environmental and functional characteristics.
Mockups and Wireframes
Even though mockups and wireframes are spoken interchangeably, they aren’t necessarily the same thing. However, the purpose they serve does coincide.
Mockups and wireframes are designed to picture the idea on a screen. They are essentially a framework that defines what goes where on a website or app and what it looks like to the user. Moreover, they tell developers how different elements are coordinated together.
To sum up, they are designed to cover design aspects concerning information, navigation, and interface.
Mockups and wireframes are created using a number of methods. One of the simplest ways is to sketch the interface on paper. Some mockup and wireframe tools may be used for a digital framework instead of a more analogue pencil and paper approach.
Wireframes vs Mockups
The basic difference between mockups and wireframes is that wireframes are much more primitive looking.
Wireframes don’t have any graphics, icons, colours, or style. They simply define what goes where on the website. Wireframes rely on segmenting the screen into small areas, where some functional element is supposed to go.
Wireframes are divided into low and high fidelity.
On the other hand, mockups are a step up after the wireframes. They don’t have the backend functionality of a website but they show exactly what the website or app is supposed to look like. For example, a mockup will consist of buttons and grids as they are expected to look. But no action is performed on clicking the buttons.
Mockups are, therefore, visual models that help designers decide the final web design. Some consider mockups to be the same as high fidelity wireframes.
Who designs Mockups and Wireframes?
Mockups and wireframes are a crucial part of web design that play a pivoting role in communicating the right idea between teams and individuals.
They are created by a collaboration between business analysts, web designers and developers. Factors that are most valuable to consideration while constructing a wireframe or mockup are
- User experience, interaction and preference
- Information architecture
- Range of functions and their effects
- Visual design
Component Design
Component design is a web design approach that entails dividing the entire project into smaller, more manageable pieces. This modular approach adds flexibility to the whole process of web design and development.
The modules may be defined by the customers themselves in the SRS or the supplier might be aligned towards the idea and divide the project into smaller components. Components are created based on their functionality, making certain codes reusable.
A good example of component design is building blocks. Each block is subsistent on its own but joined with other components, becomes capable of performing bigger operations. Each component is easy to attach and subsequently detach without rendering the program paralysed.
Benefits of Component Design
- Every component is well-defined. It is clear what function a component performs.
- Debugging is easier and doesn’t take long.
- Scaling becomes easier and efficient.
- Components are reusable.
- Cost is reduced due to reusability and a modular approach.
- Changes are easily incorporated.
APIs
API or Application Programming Interface is an approach that enables computer programs to communicate with each other. APIs are complete standalone softwares that are not dependent on another program but may be used to increase functionality of some software by extracting and sharing data.
As opposed to user interface, APIs are not meant to be interacted with by users. They are meant for connecting computers with some pieces of bigger software. In fact, modern APIs are specifically designed to be used by developers, who incorporate them into their programs.
APIs often have a document with them, explaining how to use it. This document is called an API specification.
Why APIs are Important
APIs help achieve abstraction which is the process of hiding the details of a function, while only revealing what a certain action is expected to achieve. In simpler words, APIs are a way to clean the path for the developers who are working on them.
APIs improve the speed of the program or website that they are exposed to. APIs are also used to query a server for a specific set of data from a web server.
APIs essentially exist everywhere. Some of the most common examples seen on websites are social media sharing, e-commerce and online shopping, Google maps, payment methods, video sharing, and AI suggestions and prompts.
API Documentation
API documentation covers everything an API is capable of doing and how to get it done. This documentation is disclosed to the clients when a software is programmed or when web designs are created.
Documentation constitutes a crucial part of development and maintenance of applications that use API. API documentation is enclosed in files through documentation systems like Javadoc, Twilio, etc.
Testing
Testing the software covers many aspects and relies on the methods of validation and verification. Developers often use a hierarchy of testing difficulty, while assuming certain hypotheses and operating the product in those situations. The results are then compared to past versions of the product, relevant standards, specifications, or other test oracles that may be set forth by the client himself.
The purpose of this testing isn’t to see whether a product works properly in some situations, but rather to see where it doesn’t work properly.
Through proper testing, it is evaluated whether the functional parts of the program or website do what they are expected to.
Requirement Gaps
Testing doesn’t only look for logical errors that may prevent some function from executing properly, but also requirement gaps that cannot be evaluated against a standard scale and are purely subjective.
Requirement gaps stem from non-functional elements, such as scaling, maintainability, etc. For such requirement gaps, client preferences and SRS serve as the major defining line.
Moreover, since a website or software cannot be tested for every probable circumstance at every possible time, combinatorial testing is used which allows for greater test coverage with fewer tests.
Testing Approaches and Levels
While it is not possible to go into the details of every testing approach at every level in our space, they are still worth mentioning.
- Static, dynamic, and passive testing
- Exploratory approach
- The box approach (white box, grey box, black box, and visual testing)
Testing levels describe the stage of development a testing approach is implemented at. It can also define the scale of the testing approach that needs to be taken.
- Unit testing
- Integration testing
- System testing
- Acceptance testing
Types of Testing
Some types of testing associated with web design, development, and deployment include:
- Software performance testing
- Usability testing
- Security testing
- Integration testing
- Unit testing
- Regression testing
- Compatibility testing
- Sanity testing
- Database testing
- Crowdsourced testing
Deployment
Deployment is the process of making the web design available to users.
Hosting
The first step of deployment is acquiring hosting, which is essentially an address where the website can exist. Hosting providers built a specialised backend computing infrastructure to provide space for new websites.
The address of the website is accessible by the domain name that is used to represent the website. Hosting is of various types such as shared hosting, dedicated hosting and cloud hosting.
DNS Records
Next is setting up a DNS record. DNS stands for Domain Name System. DNS records are information holders that include a certain domain’s IP and how to handle requests for it. In simpler words, DNS records define a path for when a request comes in and where it needs to go.
Some types of DNS records that are most commonly used are:
- A
- AAAA
- ALIAS
- CNAME
- MX
- NS
- PTR
- SOA
- SRV
- TXT
Testing and Going Live
After running appropriate tests to check if the site works alright, live testing sites are set up. The goal of these sites is to be as close to the real thing as possible. Once that is done, tests and benchmarks are executed to see how the site performs or if it needs optimisation.
Once testing is done and red flags are removed, all that remains is going live. Monitoring the site performance and maintenance is still necessary even after deployment is complete.
