The document discusses software processes and process models. It describes the waterfall model, evolutionary development, and component-based software engineering. It also covers process iterations, activities like specification, design, implementation, validation, and maintenance. Incremental and spiral development are iterative process models. Overall the document aims to explain how software process models can help structure software development and reduce risks.

1. SEN2-Software processes
Group 1:
Vadim Emrich
Lukas Bäcker

2. Content
Software process..........................................................................................................................................3
Software process models..............................................................................................................................3
Waterfall model........................................................................................................................................3
Evolutionary Development.......................................................................................................................3
Component Based Software Engineering.................................................................................................3
Process iterations and process activities......................................................................................................3
Incremental development........................................................................................................................5
Pros:..............................................................................................................................................5
Cons:.............................................................................................................................................5
Spiral development...................................................................................................................................6
Process activities..........................................................................................................................................6
Software specification..............................................................................................................................6
Software-design and –implementation....................................................................................................6
Software-validation and –verification.......................................................................................................7
System maintenance................................................................................................................................8
Software models...........................................................................................................................................8
Conclusion....................................................................................................................................................8

3. SEN2 – Software processes
Software process
According to developing software, there are a lot of things that possibly can go wrong. The sooner an
error occurs that has not been recognized, the higher is the amount of aftereffects. An important reason
for that fact is that developer lose track of controlling their software development. Obviously the
production of a software program, whether it has to be completely new or not, is that complex, that you
necessarily need a well-structured planning. That kind of planning is called software process. A software
process results in the creation of a software product.
Although many organizations, which deal with software development, enormously differ from each other
the way they do this work, there are also fundamental similarities. These similarities are specification,
design and implementation, validation and evolution of software. The specification of software names
its restraints of usage, and the role the software is intended to. Furthermore evolution of software means
that the software has to be made able to make progress. In short software has to be customizable.
As already mentioned, there is no "best" software process. But standardization reduces the amount of
possibilities and results in improvement (also of communication). Another advantage of standardization
is the possibility to support the software process by automation.
Software process models
A Software process model or process paradigm is an abstraction of a software process and each has its
individual view to a software process. From this it follows that each Software process model shows only a
fraction of the software process.
There are many common models for being extended or matched. But exclusively 3 of them are described
in the following. They are called "waterfall model", "evolutionary development" and "component based
software engineering".
The waterfall model is characterized by separation of the elementary process sequences "specification",
"development", "validation" and "progress making". In contrast to that, the evolutionary development
combines "specification", "development" and "validation". The component based software engineering
differs from both models ahead: its issue is to reuse components that already exist to integrate them to a
new system.
Although distinguishing these three models, they are often used in combination. The Rational Unified
Process does so. But also the formal development process is a form of such a combination. An example
for that is the Cleanroom-process which expects to specify all primal cuts mathematically for being
implemented by that later on.
There is no doubt for the importance of using a software process model when developing software. But
why do we need a software process model? To underline that, think of a hypothetical software project
where you do not use such a model. The development process might become bad structured, which
leads to a number of further problems. Those problems can be unstructured code and bad or even no
Page | 3

4. code documentation and so to solve occurring errors can take a lot of time, because you have to
intensively search in the code. It is not only the fact, that time costs money, but if you often need more
time than you expected to, the possibility to pass the deadline increases. And being aware of increasing
time pressure supports increasing stress pressure. Of course software development under too hard stress
cannot result in a qualified product. Indeed the worst case is if the product does not match with the
customer's expectations.
Waterfall model
The waterfall model is divided into 5 phases: "requirement analysis and definition", "design of system
and software", "implementation and testing components" and "operation and maintenance".
While the first phase developers define the system specifications in detail by working with the system’s
users. The second phase is about finding a basic abstraction of the system’s architecture, its components
and relations between components. Next step is to implement the components and test them in the
third phase. That leads to the fourth phase to implement the components’ relations and test the whole
architecture. The following step is to deliver the software for usage. At last the fifth phase is about
removing errors from the software that occur while its usage.
Each phase leads to a different phase. But for entering a new one, the current one has to be finished.
That means for example that produced documents must have been reviewed. Having entered the new
phase, problems based on the phase before can be found by interchange of information between both
phases. A little different to that the last phase which is for evaluating the software that resulted from the
previous phases. At least one of them has to be repeated, whether the software result does not correlate
to the expectations of the customer. For using the waterfall model sensible, those expectations should be
fixed before starting and should not change while working on the software. In a different case, the
waterfall model does not make any sense, as the condition to comply the separation of phases does not
leave any space for customization meanwhile.
Evolutionary Development
The evolutionary development is based on a sketched implementation that should make the customer
say which parts make him satisfied and which not. Next step is to customize the implementation to that
and let the customer re-evaluate the implementation. Gradually, the reiteration of these steps, lead to a
product that more and more matches with the customer's expectations. In this case, there are two ways
of evolutionary development: "explorative development" and "throw-away prototype development". The
goal of the explorative development is to create a final software product the way described above. In
contrast to that, the throw-away prototype development the goal is to understand the customer's
expectations in detail. As soon as the prototype is complete, the developers start to create the final
software product.
But there are two disadvantages for managing a project when using the evolutionary development: As
there are changes in the software again and again while the development process is alive, the possibility

5. SEN2 – Software processes
that the software architecture is worse structured is very high. So doing a change afterwards might take
much time and is expensive. Furthermore in this case a highly-qualified software-documentation is too
expensive. In general this means that the evolutionary development does only make sense, if the size of
the project is nearly small.
Component Based Software Engineering
The component based software engineering (CBSE) is that structured, that the realization of a new
system consists of the integration of many standardized components that had already been completed.
There are six steps involved to CBSE: "specification", "analysis of components", "adapt to specifications",
"design with reuse", "development and implementation" and "validation of the system". Both the first
and the last step can be found in other processes, too. But the rest differ: the second step is about
finding components to comply the specification. The third step is for analyzing, how the specifications
have to be adapted to the chosen components. The forth step is for designing a system from the
specifications with the chosen components. If there is a need to produce a new component, it has to be
done by then. While the fifth step the software parts that do not exist for the system have to be
implemented.
There are many reasons for developing software by using CBSE: If you nearly never have to produce
completely new software, the costs decrease and the amount of errors is low. But the standardization
also makes it more possible, that individual expectations of a customer cannot be matched.
Process iterations and process activities
Like in all bigger software projects, changes are ineluctable. Changes will occur in dimensions the
company, which commissioned the software, reacts on the external environment. Some company
process changes or technology changes could take effect on the created design or implementations in a
way that these have to be changed. Software processes are never fixed and the process activities have to
be repeated regularly to adopt changes. At this point you need iterative development where you repeat
processes or iterate processes. There are two common process models existing for these iterating
processes. The incremental development and spiral development are these models which will be
described later.
An important part of iterative processes is the fact that the specification and the software itself are
developed simultaneously, so the most companies and business models disagree with this type of model.
They need a complete specification of the system but while the system is developed with an incremental
method there is no complete specification, so they need a new contract, which bigger companies in most
cases don’t like.
Page | 5

6. Incremental development
In a waterfall model you have to create requirements in the beginning of the development process and
you cannot change them in a later progress. Actually you need them before you have started with the
design. So if you are in al further progress of development and you have to change some requirements,
you maybe have to repeat the whole development progress. The distinction between design and
implementation leads to an exact documentation, for this an evolutionary method leads to badly
structured and complex software but you can make decisions at one’s leisure. An incremental
development tries to combine the pros of both. In the beginning of the development progress you decide
some chunky requirements, also which are important and which are not. In the next step you decide
which parts or increments of a system have to be delivered. The parts, which have a higher priority, will
be delivered first. In the last step you also have dedicated the increments to the requirements. In the
next step you design system architecture and begin with the development of the first subsystem. You also
validate and integrate this subsystem to the whole software system and validate that one. In the end of
this cycle you check if your system if complete or not. If it’s not than you have to proceed to the next
subsystem and begin with the implementation of this one.
Pros:
- Customer don’t has to wait for a complete system
- Customer could test early stages of the program with prototypes
- Less risks of getting a failed project
- Because of developing the important subsystems first they will be tested more often and will get
the most attention
Cons:
- Difficult to detect functions early, which will be used by many subsystems

7. SEN2 – Software processes
Spiral development
Another incremental development process is the spiral development process. The activities aren’t shown
in a series but rather the whole software process is shown like a spiral.
Each turn is a phase of the process. The inner turn is about the base software concepts, the next turn is
about definition of requirements, and the next is about system design et cetera. The whole model is
divided into four segments.
- Determine objectives: determine special goals, basic conditions, management plan and risks
- Identify and resolve risks: analyze each risk and initiate steps to resolve these risks
- Development and Test: select the right development model depending on your basic risks and
begin with development and validation
- Plan the next iteration: check your project if you could proceed to the next turn of the spiral.
The basic difference between the spiral model and different models is that the spiral model concentrates
on risks.
Page | 7

8. Process activities
There are four basic process activities. These are specification, development, validation and
maintenance. Depending on which process model you use these activities are performed one after
another, like in a waterfall model, or concurrently, like in an evolutionary development.
Software specification
Software specification or requirements analysis means that you analyze and try to understand
constraints, functions and requirements the system has during development and in customer practice.
This part of the whole development process is the most important because mistakes in the analysis lead
to problems in design and implementation phase. The main analysis is split into four main steps:
- Operability research: Here you determine if you can fulfill the requirements of the customer
with today’s software- and hardware-technologies and if it’s cost-effective. Here you decide if
you should continue with a further analysis.
- Definition and analysis of Requirements: Upon discussions with customers and observation of
existing systems you can create different software models and prototypes. This helps the analyst
to understand the system.
- Specification of requirements: Collect all information into a document. This specification contains
functional and non-functional requirements.
- Validate requirements: Check if your requirements are realistic, consistent and complete.
Software-design and –implementation
In this phase you create a specification into an executable system. You use design- and programming-
activities, but if you are using an evolutionary method you may change the specification. In design
activities you describe the structure of a system, the data and interfaces. This design document will be
developed iterative over many versions. The separate activities in a design process are:
- Architecture design: Define subsystems and their relationship.
- Abstract specification: Create for each subsystem an abstract specification.
- Interface design: Define for each interface a specification.
- Component design: Allocate components to services and design their interfaces.
- Data structure design: Specify data structures which are used in the system.
- Algorithm design: Specify algorithms for the services.
This is an abstract model of the design phase which is not fixed and could be adapted in praxis.
In agile development methods results aren’t separate specification models, but rather shown in program
code. If you use structured development methods you may use these models to design the software:
- Object model

9. SEN2 – Software processes
- Sequence model
- State model
- Data flow model
All these models help you to understand and implement the system. Some classes are maybe specified
and designed in more detail than other and you can maybe use CASE-tools to generate program code
from design models. In the last part you test your created code for correct function. For this you need to
find at first the error, and then plan how to resolve the error, resolve the error and test your program
again.
Software-validation and –verification
The verification and validation should show that all specifications are implemented and are implemented
proper. During the whole development process you should test and check your results for correctness but
the most validation costs occur after the implementation.
Beside small programs you shouldn’t test the whole system at once. First you should test each
component separately then in combination with other components until you can test it with the
customer. If you found some errors and resolved them you maybe have to repeat some subtest to
guaranty correct behavior.
In general component implementation and testing are connected and done simultaneously. In an
incremental development model you do testing during the development phase, while in extreme
programming you design tests during the analysis phase what leads to a test-driven development.
In later test phases you should implement the planned tests by a special test team. To connect the test
activities and development activities you can use the V-Model.
Page | 9

10. System maintenance
In bigger systems it’s very expensive to make changes at hardware. Software changes aren’t so expensive,
so you could make these at any time. Even serious software changes are cheaper than hardware changes.
In the past the development part and the maintenance where strictly separated. Development was more
esteemed than maintenance, although maintenance was multiple times costly than development
process. Nowadays this partition will become more and more unimportant, because developed software
systems aren’t often complete new systems, so the engineering process becomes more and more an
evolutionary process and combines both.
The process of maintenance works like shown in this diagram.
Software models
Software models describe a software system in a graphical model and are used to design a software
system by means of a structured method. These models maybe are object-models, sequence-models,
state-models and many others. The most used models are defined in UML (UML 2.0). They help you to
create a traceable design, but the creativity of the developers will be furthermore required. They still
have to split the system and make sure they follow the specification.
Conclusion
We as software engineers intend to produce software that is usable, changeable, and it preferably has a
low price. As producing software is complex and there are lots of ways to do that, it is an improvement to
standardize this process in form of a software process model. Supporting the development of software by
a software process model improves communication of engineers and helps to control the process. In
General a software process model can make it easier to develop software.