A software engineering process is the model chosen for managing the creation of software from initial customer inception to the release of the finished product. The chosen process usually involves techniques such as
· Analysis,
· Design,
· Coding,
· Testing and Debugging,
· Maintenance
Several different process models exist and vary mainly in the frequency, application and implementation of the above techniques, for example, different process models use different analysis techniques, other models attempt to implement the solution to a problem in one big-bang approach, while others adopt an iterative approach whereby successively larger and more complete versions of the software are built with each iteration of the process model.
The Software Engineering Process — The Software Life Cycle
The illustration below highlights the various phases of what is probably the oldest software development process in existence, namely the classic life-cycle paradigm, sometimes called the “waterfall model,”. This paradigm implies a systematic, sequential approach (rarely achieved in practice) to software development that begins at the system level and progresses through analysis, design, coding, testing and maintenance.
Modelled after the conventional engineering cycle, the life-cycle paradigm encompasses the above activities. Let’s take a look at each of these phases in turn and explain what is involved.
System Engineering and Analysis
Because software almost always forms part of a much larger system, work begins by establishing requirements for all components of the system, identifying not only the role played by the software but, more importantly, its interface and interaction with the outside world.
This ‘system view’ is essential when software must interface with other elements such as hardware, people, databases and computers outside of, and beyond the control of the system designer. In essence Systems engineering involves exploring some of the following issues:
1. Where does the software solution fit into the overall picture? The software being proposed may be one small cog in a very large wheel. Maybe the software is a calculating employee pay or tax, or perhaps has to co-ordinate the activities of several distributed systems controlling a production/manufacturing plant or warehouse distribution system. Until the overall picture is clear, no analysis of the software can begin.
2. What does the system do? Is it required to control or monitor some process or activity or is it simply performing analysis of data?
3. What environment will the system be placed in?
4. What inputs and outputs are required/produced and what is the form of that data: Paper, Database, Disk file, Graphics, Network, Analogue to digital converter outputs?
In answering the above question, a list of external devices is uncovered and can be explored further, e.g. what size of paper, what resolution graphics, what format is the data accepted/displayed, what capacity of disk, what resolution of Analogue to digital converter etc.
Design and Coding
Once the analysis of the system has been completed, design or development can begin. This is an attempt to translate a set of requirements and program/data models that were laid down in the “requirements document” into a well designed and engineering software solution. Design is best summarised by the following sequence of steps
· The data flow/UML diagrams that represent the system model are converted into a suitable hierarchical, modular program and data structure/architecture.
· Each program module is converted into an appropriate cohesive function subroutine or class, that is designed to perform a single well-defined task.
· Design then focuses on the implementation of each module/class. The sometimes loose and vague, perhaps English like, description of the modules role/function within the program is expanded and translated into an algorithm, which describes in detail exactly what, when and how the module/class carries out its task. The interfaces and its interaction
with other modules/objects are also considered and assessed for good design (see coupling and cohesion in future lectures).
· The modules algorithm can then be translated into a flowchart, which is a
step-by-step graphical representation of the actions carried out by the module expressed in terms of sequence, selection and repetition.
· The flowchart can then be translated into Pseudocode, which conveys the same information as a flowchart, but presents it a way that is more amenable to translation into program code.
· Finally, the Pseudocode for each module is translated into a chosen programming language and the various modules entered, compiled, integrated into a system ready for testing.
Software Testing and Debugging
Once the constituent software components/modules have been written, testing and debugging can begin. Testing involves the following techniques (amongst others)
· Verification and Validation. That is, checking that the software meets the agreed specification and checking that the software is correct in its operation.
· Black and white box testing techniques. That is, testing the insides of the modules for correct operation and testing the interfaces to the module.
· Integration Testing: Testing that the modules all work together.
· Acceptance Testing: Letting the customer test the product.
· Debugging: The ‘art’ of identifying the cause of failure in a piece of software and correcting it.
Software Maintenance
Software maintenance reapplies each of the preceding life cycle steps to an existing program rather than a new one in order to correct or add new functionality.
By: Saabsoft
Saabsoft is a leading Software Company based in Dubai — UAE. Saabsoft has been founded in 2018 by IT experts with over 20 years of experience in technology.
