Raheal Mazumder discusses the issues and techniques for developing a software application, based on the principles of software engineering.
What is software engineering?
There are many definitions of software engineering. The IEEE standard glossary of Software Engineering Terminology (IEEE610, 1990) defines it as 'The application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software, that is, the application of engineering the software.'
The basic idea of the process is to take a problem (or a range of problems or challenges) faced by an end-user and produce a solution using technological skills and knowledge that will overcome those problems. In addition to this, there is an emphasis on other skills, such as iteration, project management and communication skills, etc, which are significant to software development.
The importance of iteration and project management
An important point to consider is that the best software is normally produced by developers who constantly iterate. Iteration is a term that is used when developers inform their end-users on how they are doing and explain what they are doing at each stage of the software process. It's always a good idea to keep the end-user up to date with the latest thing you are working on and even show demos on what has been done so far.
It is common that those who don't iterate do not deliver the project successfully, mainly because there wasn't enough communication between the developer and the user, which results in developers not achieving or fulfilling the user's requirements.
As for project management, it's vital that the project manager plans, organises and manages the project in order to accomplish the necessary goals and objectives. The project manager can divide the project into a number of parts, whereby each part is assigned to groups of developers, who can focus and specialise on that particular aspect of the project. In addition, provisional deadlines can be set for each stage of the project, which everyone must comply to.
Requirements specification
The first stage that requires a great deal of focus is devising the requirements specification. The purpose of this stage is to gather as much information as possible about the current problem/system that is being faced by end users. This can range from a variety of activities, such as interviews with current users, observational sessions (observing how the current system works), etc.
There are a number of activities that need to be completed for the requirements specification. The most important activity is to design and construct use case models. Use case models provide a simplified, graphical notation of how users interact with the system. This method is proved to be an effective part of requirements capture and improves communication between developers and end users.
Simple use-cases are more likely to develop when other related use cases from other parts of the system are added to it, which will come together to form a final generalised use case.
In addition to the use case model diagrams, the developer would need to include a 'use case description' section. This provides a descriptive flow of events, which can be laid out in the form of sequenced instructions (or a path) to explain how the system works. The developer can highlight alternative paths that need to be executed and paths that shouldn't be executed, at any point in time, when the system is in operation.
Use cases are described using 'natural language'. This aids developers and end-users to have a clear understanding as to how the system flows when it's used by the user(s), which can then be processed further in the later stages of the system life-cycle.
Analysis and design
The next phase is the analysis, which focuses more on the internal view of the system and also improves on the special and functional characteristics of the system - this tends to go to another level of developers trying to break apart 'use case model diagrams' from the requirements section and restructure them with the use of UML analysis model diagrams, or better known as 'collaboration diagrams', to help create a clearer picture of how the system really works.
A collaboration diagram will contain three main symbols - called 'analysis classes', which are used to re-create use-cases, with more detail and annotation on how each of these classes/objects can interact with each other in the system.
The ‘Design’ section swiftly moves from the analysis, where developers decide what programming language to use in order to implement the application. Java and C++ are common programming languages that possess the 'object-orientation' feature for creating applications that involve the use of fundamental concepts, such as object classes, methods, instances and many more.
One of the activities for the design would be to construct 'design classes'. This involves taking the parts of the collaboration diagram and the functional requirements from the analysis section, and producing a class diagram with object oriented features of what that ‘class’ will do in terms of whether it will process or store data, etc. Here is an example:
Occasionally, if there are two or more classes that have something in common, or are required to work together to complete an operation of a system, then they are packaged together into a 'subsystem'. The graphical representation of a subsystem is shown here:
Developers sometimes produce a number of design classes, each of which will be linked together to produce a full working system. To demonstrate how these classes work together, a sequence diagram needs to be produced, which shows some technical details on how methods, within each of the classes, interact with each other to produce the final output of the system. This would provide a better visualisation of what could happen in the program internally.
Implementation and testing
In the implementation, the classes or subsystems from the design phase are developed by constructing a set of source codes.
Developers would need to refer to the design documentation and revise what methods and instances should be in the source code. Any design subsystems are then converted into ‘implementation subsystems’ as the classes are written as source code.
Unit testing is a way of testing out the source code. There are two categories for unit testing: Black-box testing and white-box testing. Black box testing aims to look at an external perspective of the system. The developer would enter valid and invalid values into the application to see what results it produces.
White box testing focuses on the internal structure (the source code). The developer would examine the source code, line-by-line, on what paths it takes when valid/invalid data is inputted and also checks how robust the system is when it deals with high levels of data. Any errors that are detected are noted down and the source code is modified to fix the bug.
Deployment and maintenance
You may find that using a programming developer kit, such as Eclipse, would be very useful for deploying an application. Once it is deployed as an executable, you can then package it up into an installation program.
There may be times where developers are informed of changes in the system or unexpected errors that occur more frequently. That is why maintenance is very important to solve these issues. Unexpected errors can be resolved if developers produce software recovery patches.
To summarise, software development requires a good understanding of the end-users' requirements for constructing an effective piece of software.
