SEN2-Software processesGroup 1:

Vadim Emrich

Lukas Bäcker

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

SEN2 – Software processes

Software processAccording 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 modelsA 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

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 modelThe 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 DevelopmentThe 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

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 EngineeringThe 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 activitiesLike 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

Incremental developmentIn 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

SEN2 – Software processes

Spiral developmentAnother 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

Process activitiesThere 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 specificationSoftware 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 –implementationIn 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

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 –verificationThe 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

System maintenanceIn 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 modelsSoftware 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.

ConclusionWe 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.