Sommerville [199] defines Software Engineering (SE) as
an engineering discipline that is concerned with all aspects of software pro- duction from the early stage of system specification to maintaining the system after it has gone into use.
1. Engineering discipline — Engineers make things work. They apply theories, method- ologies and tools where these are appropriate, but they use them selectively and al- ways try to discover solutions to problems even when there are no applicable theories and methodologies. Engineers also recognise that they must work to organisational and financial constraints, so they look for solutions within these constraints.
2. All aspects of software production — SE is not just concerned with the technical pro- cess of software development but also with the development of tools, methodologies and theories to support software production.
In general, software engineers adopt a systematic and organised approach to their work, as this is often the most effective way to produce high-quality software. How- ever, engineering is all about selecting the most appropriate methodology for a set of circumstances and more creative, less formal approach to development may be effective circumstances.
The first key challenge in the SE is the production of software with a well-defined quality level, but this is not enough. There is also a need to model and engineer the development process that should be controllable, and well documented. These needs require abstractions, process, methodologies and tools.
Software deals with entities having a real-world counterpart such as numbers, dates, names, persons, documents, etc. . . . These entities must be modelled in terms of abstrac- tions. Abstractions are the building blocks for creating the models and they depend on the available technologies: for example functions, objects, agents, etc.. . . . Different kinds of abstraction lead both to different ways of thinking about the problems and the solu- tions, and to different levels of model complexity: complicated problems are well captured by object and agent abstractions, while functions could lead to have very very complex models for representing the problem. In the same way the models of the solution are heavily influenced by the paradigm.
In the reminder of this section are presented the definitions of software development processes (Subsection 3.2.1) and methodologies (Subsection 3.2.2), while Subsection 3.2.3 presents tools for SE.
3.2.1
Software Development Processes
A Development Process [26] is an ordered set of steps that involve all those activities, constraints and resources required to produce a specific desired output satisfying a set of input requirements. Typically, a process is composed by different stages/phases put in relation with each other. Each stage/ phase of a process identifies a portion of work to be done in the context of the process, the resources to be exploited to that purpose and the constraints to be obeyed in the execution of the phase. Case by case, the work in a phase can be very small or more demanding. Phases are usually composed by a set of activities that may, in turn, be conceived in terms of smaller atomic units of work (steps).
A Software Development Process [67] is the coherent set of policies, organisational structures, technologies, procedures and deliverables that are needed to conceive, de- velop, deploy and maintain a software product. A software process exploits a number of contributions and concepts [67]:
• Software development technology: technological support used in the process. Cer- tainly, to accomplish software development activities there is the need for tools, infrastructures, and environments.
• Software development methods and techniques: guidelines on how to use technology and accomplish software development activities. The methodological support is essential to exploit technology effectively.
• Organisational behaviour : the science of organisations and people.
• Marketing and economy: software development is not a self-contained endeavor. As any other product, software must address real customers’ needs in specific market settings.
There are four fundamental process activities that are common in all software pro- cesses. These are [199]:
• Specification — is the process of understanding and defining what services are re- quired from the system and identifying the constraints on the system’s operation and development.
• Design and Implementation — is the process of description of the structure of the software to be implemented, the data which is part of the system, the interface be- tween the system’s components and, sometimes, the algorithms used. Subsequently this specification is converted into an executable system.
• Validation — is the process that intended to show that a system conforms to its specification and that the system meets the expectations of the customers.
• Evolution — is the process that changes the software in response to changing de- mands.
There is not an ideal process. Different types of systems need different development processes [199]: for example in real time software, an aircraft has to be completely spec- ified before development begins, while in e-commerce systems, the specification and the program are usually developed together. Consequently, the generic activities, specified above, may be organised in different ways and described at different levels of detail for different types of software. The use of an inappropriate software process may reduce the quality or the usefulness of the software product to be developed and/or increased.
A Software Process Model is a simplified representation of a software process, presented from a specific perspective [199]. Process model prescribes around which phases a process should be organised, in which order such phases should be executed, and when interactions and coordination between the work of the different phases should be occur. In other words, a process model defines a skeleton, a template, around which to organise and detail an actual process. Examples of process models are:
• Workflow model — this shows the sequence of activities along with their inputs, outputs and dependencies
• Activity model — this represents the process as a set of activities, each of which carries out some data transformation
• Role/action model — this depicts the roles of the people involved in the software process and the activities for which they are responsible
The best known generic process models are:
• Waterfall — separate and distinct phases of specification and development
• Iterative development — specification, development and validation are interleaved • Component-based software engineering — the system is assembled from existing
components
3.2.2
Methodologies
Disagreement exists regarding the relationship between the terms method and methodol- ogy. In common use, the methodology is frequently substituted for method; seldom does the opposite occur. Some argue this occurs because methodology sounds more scholarly or important than method. A footnote to the word methodology in the 2006 American Heritage Dictionary notes that
the misuse of methodology obscures an important conceptual distinction be- tween the tools of scientific investigation (properly methods) and the principles that determine how such tools are deployed and interpreted (properly method- ologies).
In Software Engineering the is no a common denominator: on one hand some authors argue that a software engineering method is a recipe, a series of steps, to build soft- ware, while a methodology is a codified set of recommended practices. In this way, a software engineering method could be part of a methodology. On the other hand, some authors believe that in a methodology there is an overall philosophical approach to the problem. Using these definitions, Software Engineering is rich in methods, but has fewer methodologies.
The definitions adopted in this thesis for methodology and method are from Ghezzi and Cernuzzi. In particular, Ghezzi et al. [73] define methodology as a collection of methods covering and connecting different stages in a process. The purpose of a methodology is to prescribe a certain coherent approach for solving a problem in the context of a software process by preselecting and putting in relation a number of methods. A methodology has two important components: one that describes the process elements of the approach, and a second that focuses on the work products and their documentation. According to this definition of methodology, Cernuzzi et al. [26] define a method as a way of performing some kind of activity within a process, in order to properly produce a specific output (i.e., an model or a document) starting from a specific input (again, an artefact or a document). Any phases of a process, to be successfully applicable, should be complemented by some methodological guidelines (including the identification of the techniques and tools to be used, and the definition of how artifacts have be produced) that could help the involved stakeholders in accomplishing their work according to some defined best practices.
Based on the above definitions, and comparing software processes and methodologies, some common elements can be found in their scope [26]:
• both focus on what we have to do in the different activities needed to construct a software system
• however, while the software development process is more centered on the global process including all the stages, their order and time scheduling, the methodology focuses more directly on the specific techniques to be used and work to be produced In this sense, methodologies focus more explicitly on how to perform the activity or tasks in some specific stages of the process, while processes may also cover more general management aspects, e.g., basic questions about who and when, and how much.
As for the software development process, there is not an ideal methodology, and dif- ferent methodologies have different areas where they are applicable. For example, object- oriented methodologies are often appropriate for interactive systems but not for systems’ stringent real-time requirements [199].
3.2.3
Tools
The acronym CASE stands for Computer-Aided Software Engineering. It covers a wide range of different types of programs that are used to support software process activities such as requirement analysis, system modelling, debugging and testing. All methodologies should come with associated CASE technology such as editors for the notation used in the methodologies, analysis modules which check the system model according to the methodology rules and report generators to help create system documentation. The CASE tools may also include a code generator that automatically generates source code from the system model and some process guidance for software engineers.