Company and organizations now appreciate applying the engineering disciple to software. And therefor are in constant search for Software Engineers. Actually a report that was published by Mashable ranks the job of software engineer as the first technology job of 2014. Yet, we can see that in practice software engineering (SE) is misunderstood. In order to clear that we will try to answer this three questions:
- What is software engineering and why is it important?
- What are the building blocks of software engineering?
- What are the processes and methods that differentiate it as a discipline?
What is software engineering?
According to IEEE, SE is defined as “the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software” One thing we need to take from this definition is that SE is applied through the entire software lifecycle, from specifications all the way to maintenance after system deployment. So why use an engineering approach to software? A simple answer is, because that alternative would be to use ad hoc or disordered approach, while an engineering approach means predictability and quantifiable results which is achieved through the applications of theories, methodologies, frameworks and tools. SW in practice is built in three layers. The first layer is that of the process, the process defines the framework and the order around various activities undertaken in a software project. It sets out how requirements, design, construction (implementation) and testing are performed. The second layer is the methods. Software engineering methods are proven techniques to perform certain activities. For example there are methods of requirement analysis / modeling, design and design modeling, testing and etc. The final layer is that of the tools, software engineering tools allow automations of activities. Which helps in the systematic approach in software engineering. Figure 1 Illustrates all the layers.
Figure 1 Software engineering layers
Software Process and Process Model
The process of software creation contains a set of generic activities. Which we will summarize as follows:
Figure 2 Lifecycle of software
In addition to this process activates, there are those activities (commonly referred as umbrella) that span the entire software lifecycle. Such as project management, quality management, configuration management and process improvement. So now that we know the set of activates required to create a software, we come back to the question what is a software process? A software process, also called a software development lifecycle (SDLC), defines the set of tasks inside of the software engineering activities, the order and details of these task and activities, their flow (e.g. Iterative, linear and etc) and the type and details of artefacts generated by them (e.g. requirement and design models). All these activities are based on selected model. So the next question is, what are the available software process models, which we could choose from? Some of the best known models are traditional models (e.g. waterfall), iterative and incremental models (e.g. prototyping, spiral, agile and unified model) and specialized models (e.g. component-based development, formal methods and aspect-orientated development). So which model is best to use? The answer depends on various factors, including project type and organization maturity. Typically the project manager in coordination with the lead software engineer decides on the process model most appropriate for a specific project.
Software Engineering Methods.
SE Methods are practices with proven technique to perform certain activities in organized and systematic approach. To clarify this we will further develop our layers diagram, which you can see in Figure 3. For example the requirements and analysis activities, moreover their order, focus and artefacts generated is covered with a method, which contains the technical know-how. Similarly to this there are methods for design, testing and etc.
Structured analysis and design, object-oriented analysis and design and formal methods are the one most known software engineering methods.
Figure 3 Software engineering layers
Software engineering tools
SE Tools are intended to assist the software lifecycle processes by automating actions. Let’s give some examples. For requirement management (modeling) we have Enterprise Architect (Sparx), IBM Rational (IBM), for construction (implementing) we have tools such as Visual Studio (Microsoft) and Eclipse (open source), software testing tools such as Team Foundation Server (Microsoft) and HP Quality Center (HP) and project management tools as Enterprise project management (Microsoft). Keep at mind that these examples to not exhaust all the possible options. There are many other tools, thanks to technology innovation.
Being a Software Engineer.
The job title of Software Engineer is less formally define than Software Engineering, as a discipline. We can notice, that in practice that the title Software Engineer is replacing the title Software Developer, but this is because the first title indicates more knowledge and from their responsibilities. However we already established that Software Engineering is applied through the whole SDLC, so it is not only for development phase. So if a Software Developer is a Software Engineer, does that also make a designer or a tester a Software Engineer? For this question a clear answer does not exist. In general, anyone who applies the engineering discipline to the analysis, design, development, testing and operation is a qualified Software Engineer. So in the end we can say, being a Software Engineer is a matter of knowledge and responsibilities.
Project management in the context of Software Engineering.
PM, we already established that it is an umbrella activity. We also established that Software Engineering is about applying the discipline through the whole SDLC. From there we can say that project management begins before any activity is started and continues through the entire SDLC until the system is retired. PM activities include control, communication, cost analysis, work breakdown structure, task scheduling and risk analysis. All of which are outside the scope of software engineering.
So far we know that a software process combines a set of generic activities in addition to a set of umbrella activities that both span the entire software lifecycle. IEEE Computer Society publishes the Software Engineering Body of Knowledge (SWEBOK) as an international standard. This body of knowledge, which currently is version 3, promotes a consistent view and specifies the scope of Software Engineering, it does so by organizing Software Engineering activities into 15 knowledge areas (KA).
- Software requirements
- Software design
- Software construction
- Software testing
- Software maintenance
- Software configuration management
- Software engineering management
- Software engineering process
- Software engineering models and methods
- Software quality
- Software engineering professional practice
- Software engineering economics
- Computing foundations
- Mathematical foundations
- Engineering foundations
We are going to cover knowledge areas 1, 2, 3, 4, 8 and 9.