Software can be developed in many forms from Web development, mobile or PC apps to embedded microcontrollers used in manufacturing, such as a car’s onboard computer or in medial instrumentation.
This is a summary of software design and development. There might be one flow of work in a traditional ‘water fall’ approach. There will likely be some planning before the project gets off the ground. Some of the processes might be skipped completely depending on the complexity of the project it depends on regulatory requirements but also the organisations or individuals ethos. However, in some situations, there is a legal requirement to fulfil a specific set of processes. For example, producing software for products that are FDA regulated. This can include keeping a logbook of all design considerations and the process being followed as a whole. This depends on the risk factors involved.
(I just thought I should add that this process is normally a team effort.)
Principle stages for deveopment include:
Ideation
Depending on the situation the ideation phase may be done by the customer already. If this is an internal project the ideation phase would have to be carried out internally. This may be an informal process where a need for new software arises. However, it may be used formally when looking at new software product ideas. This is standard design practice for the creation of new products and services.
Analysis
Outline Specification or Brief
There will likely be an outline specification or brief that has the outcomes from the ideation phase or has been sent from a client. This is the starting point from which other areas of study will follow.
Feasibility Study and Research
The could be a feasibility study depending on the application being envisioned. This would look at relevance in the market, and how outside influences might impact the project. (Informally known as a sanity check.)
Risk Analysis
The risk analysis might cover more than just a risk to the project. This can include risks to equipment or even people depending on the type of product being developed.
Formal Specification
The analysis phase should include the formation of a specification document. The specification document will include all required features in the software and detail any specific industry requirements that are relevant, for example, legal requirements for data personal capture, storage and handling. There may be specific languages support required. This process would likely include site visits to and contact with the client or clients. Internal developments should treat the individuals or departments requiring the software as customers. The specification should try to order things as features of the software or system.
Sign-off
The specification should be signed off with the client. A change process should be in place and accounted for.
Change Control
The change list should be kept throughout the duration of the project as issues do occur. There can be changes within industry sectors or the client may convey their own internal requests that might be generated throughout the duration of the project.
Design
The design phase should include formally generating documentation to cover the areas of the specification. This should include how each of the requirements will be implemented during development. It is useful to create a matrix for validation as the design is worked on. This helps as a summary to ensure all points are covered from the specification. There could be a choice made between different development chains here or this might form part of the specification. This can raise questions for clarification of the spec. The design phase should consider ‘how’ the specific element should be accomplished and ‘why’ that way has been chosen.
The design could use diagrams such as flow charts or just be written in textual format. Sometimes there could be pseudo-code, which is a form of code written in plain English rather than actual computer languages.
Development
Planning and Assignment
There should be a rough estimate of how long different features will take to implement. There should be a task assignment too. Where there are the most ‘unknowns’ these areas should be highlighted for further research. This might involve dropping back to the design phase for enhancing the design.
Writing
Includes writing the software. This phase also includes implementing communication between hardware should specific equipment be involved. It is likely that the unit testing would be written during this phase too. This helps with informal testing before sending it to the testing team or individual. The development phase might be implemented as a staged process depending on the design. With a good design, it might be possible to test different modules while continuing to develop at the same time. This could be achieved using plugins.
Good programming guidelines should be in place to ensure consistent software patterns and styles are used throughout the software. When writing in C# I follow the Microsoft Coding Conventions (link subject to change), where no formal process is provided to me by the client or company.
Source Management
Source code needs to be managed through a source control server or systems such as Source Safe, Apache Subversion (SVN) or Git. A server will be required, I use Visual SVN Server and a client is required, I use Tortoise SVN. I also use Github for online collaboration projects.
Installation Packages
The software will likely need to be packaged into an installable executable. I use Inno Setup desktop for applications.
Testing & Quality Control
Unit Testing
Some development platforms, for example, Microsoft Visual Studio, allow for unit testing to be built into the software. Things like complex calculations or protocol responses or as simple as string manipulation can be tested using unit tests with test data. These can be performed within Visual Studio and can yield a test result showing any tests that have failed.
Verification
Does the software have bugs?
During the testing phase verification is required that will check the software follows the design thus, the design has been implemented in the actual development. An actual test specification may be written to check that the features are working as expected as per the design from the development phase. There is a need to have a verification matrix to show which design points are covered by the verification/testing documentation.
Validation
Does the software cover all specified requirements?
A quality process needs to be in place to validate that the software deliverable covers the items in the specification from the analysis phase. A matrix can be used to assist this process with the specification allowing for items to be listed via references between specification and design. This is a quick way to help guide the design phase to ensure all aspects of the specification have been accounted for.
User Case Testing
The software might be sent out to formal testers as a beta test application. This could likely be used for interface issues and usability tests.
Installation Testing
Likely using a virtual machine. The software installation should be tested.
Launch
There should be a checklist that all parts of the documentation are completed. That the quality control team have checked the software following their procedures. The software will go to a formal release version. This should be reflected in the source control. Executables will be signed using a security certificate (if not already).
Installation & Maintenance
Installation
Some software might require specific installation with validation on-site.
Training
There will likely be training either internally, externally or both. This could come in the form of direct training or might be from video tutorials or written documentation.
Documenting
There may be a need for a user guide especially if there is equipment to interface with.
Contracts
A support contract would likely be in place to offer customers continued updates and additional support.
Support
Support may be offered as part of a support contract. If the software is released to the general public rather than business to business that there is likely to be support processes online without a paid contract. This can include community support forums where other more experienced users can help with general questions. Support can also include making changes to the software for new features depending on the contract terms.