Chapter 3: Software engineering processes

Introduction
The Classical Life Cycle
 In the classical life cycle model (also known as the waterfall model), the development of
software proceeds linearly and sequentially from requirement analysis to design, coding,
testing, integration, implementation, and maintenance. Thus, this model is also known as
the linear sequential model.
 The waterfall model comprises different phases and each phase has its distinct goal. After
the completion of one phase, the development of software moves to the next phase.
 Each phase modifies the intermediate product to develop a new product as an output
 The new product becomes the input of the next process.
 Life cycle stages:
o Requirement Analysis
 This phase focuses on the requirements of the software to be developed.
 The purpose of this stage is to obtain a thorough understanding of what is
needed from the system
 To specify the requirements, users' specifications should be clearly
understood and their requirements be analysed.
 This phase involves interaction between the users and the software
engineers and produces a document known as Software Requirements
Specification (SRS).
o Design
 It utilizes software requirements defined by the user and translates them
into software representation.
 In this phase, the emphasis is on finding solutions to the problems defined in
the requirements analysis phase.
 The software engineer is mainly concerned with the data structure,
algorithmic detail and interface representations.
o Coding
 This phase emphasizes translation of design into a programming language
using the coding style and guidelines.
 The programs created should be easy to read and understand.
 All the programs written are documented according to the specification.
o Testing
 This phase ensures that the software is developed as per the user's
requirements.
 Testing is done to check that the software is running efficiently and with
minimum errors.
 It focuses on the software functions to ensure that all the statements have
been tested.
 Note that testing is a multistage activity, which emphasizes verification and
validation of the software.
 o Implementation and maintenance
 This phase delivers fully functioning operational software to the user.
 Various changes occur due to changes in the external environment (these
include-upgrading a new operating system or addition of a new peripheral
device).
 Software will undoubtedly undergo change after it is delivered to the
customer
 Change will also occur because of errors that are encountered because the
software must be adopted to accommodate changes in the external
environment.
 Reapplies each of the preceding life-cycle steps to an existing program
rather than a new one.
 Advantages and disadvantages
o Advantages
 Simple to understand and follow
 Each phase of the development proceeds sequentially
 Allows managerial control where a schedule with deadlines is set for each
stage of development.
 Helps in controlling schedules, budgets, and documentation.
o Disadvantages
 The model is based on the idea that the steps must be strictly followed
sequentially and cannot go back to the previous stage
 Requirements need to be specified before the development proceeds.
 The changes of requirements in later phases of the waterfall model cannot
be done. This implies that once the software enters the testing phase, it
becomes difficult to incorporate changes at such a late phase.
 No user involvement and the user will only see the system once it is
completed.
 Does not involve risk management.
 It is a very rigid approach

Contemporary software engineering

 Although the life cycle has its shortcomings it is still used, especially where the requirements
are clear and accurate and unlikely to change. (for example, writing software to control an
elevator mechanism)
 Requirements are usually very difficult to specify as they involve lots of people, systems and
components, and they are interconnected with other systems.
 Add to this the fact that the organisation will change while the system is being developed
and you quickly realise why the life cycle model is increasingly problematic.
 Fred Brooks’s words, ‘there is no silver bullet’ for software development.
 By this he means that there is no one single approach that is perfect for developing all
software.
 The following fictional story provides an account of an organisation facing a high degree of
development and business uncertainty. It provides an example of why a company might
need to adopt different software development practices.
 Example story: problems at Alpha Corporation Alpha Corporation is based in Chicago and is
responsible for producing trays of meals for the airline industry. With the largest airport in
the USA to serve, this is big business and they realised early on that computer technology
would be central to their success. Their in-house development team began developing a
simple scheduling system in the 1970s to ensure that the trays were ready and waiting for
the aeroplanes to arrive. While quite complex, this system was essentially operated by one
person (the manager) who entered the details of flights coming in to the airport, and the
number of food trays required. The system would then print out scheduling lists to be
handed to the workers on the production line, and data-tapes for the finance department to
bill the airline. In developing the system they had followed the life cycle, using structured
systems analysis (entity relationship diagrams and data flow diagrams) to model the data
flows, and constructing data-base tables from their ER diagram. The system had taken two
years to develop and had been well received when launched.

 Today Alpha’s operation has changed and it is trying to keep up by developing a new
computer system to handle its orders. The airlines are highly automated and expect Alpha to
plug into their computer systems. Messages for orders are sent electronically in a variety of
differing formats (depending on the individual airline’s system) which need translating into
Alpha’s order formats. The food trays are no longer standard for all airlines, but must be
tailored to specific requirements (different coloured trays, cutlery etc). For business class the
larger airlines are now demanding trays produced for each individual customer, so that the
customer can select their choice of food from a menu. This requires that each tray be
barcoded, and that the production line be equipped with screens telling workers what food
is required on each tray. This also means that the ingredients need to be ordered on a per-
tray basis and that the computer system interacts with the food wholesalers in order that
the ingredients are delivered ‘just in time’ so that they remain fresh.

 In addition Alpha is under pressure from their competitor (Beta Inc) and needs to cut costs
to a minimum. In achieving this, the Board of Directors of Alpha are demanding that the new
computer system provide them with a wide range of statistics on costs and profit.
Unfortunately the Board have little idea what statistics they require, simply saying ‘we will
know what we need when you show us what you can give us’. They are also demanding that
the new system be ready in three months since some of their contracts expire then and the
system will be important in winning new contracts. In developing the computer system the
in-house development team must understand this complex situation; they need to interact
with the airlines, airport and wholesaler in identifying requirements (all of whom may at any
time decide to change their own systems), respond to demands from the board of directors,
and ensure that the system is easy to use. The users of the system will include almost all the
company, from the managing directors down to the people working on the production line.
Clearly this is not going to be an easy task for the in-house development team to achieve
using the life cycle.
Evolutionary systems development
 Evolutionary software development approaches allow software engineers to develop
increasingly complete versions of a system over time (Pressman, 2005)
 The software developers build a rough prototype and show it to the user. The user analyses
and uses the prototype and gives some feedback to the developer. Then the developer
keeps on refining the prototype.
 It is particularly useful where the user doesn’t know exactly what he wants.
 By seeing and using the system the user will gain a better understanding of what is wants
and what he is expecting from the system to do.
 Two type of prototypes:
o Evolutionary prototype
o Throwaway prototype
 Evolutionary prototype
o The initial prototype is constructed, evaluated and evolved continually until it forms
the final system
o You begin by developing the most visible aspects of the system.
o You demonstrate that part of the system to the customer, and then continue to
develop the prototype based on the feedback you receive.
o At some point, you and the customer agree that the prototype is “good enough”,
and you release the prototype as the final product.
 Throwaway prototype
o A throwaway prototype is developed and given to the user to try it out and evaluate
it. Based on the end user feedback the developer will have a better idea what the
user requirements are. This prototype is then thrown away.
o The final product is then developed based on the user requirements
 Advantages and disadvantages of prototyping
o Advantages
 There is less resistance to change because the user is involved in the
development and he sees the system before it is ready. This way the user
will know how the final product will be and will have some knowledge of
how to use it
 Prototyping can be very useful when the user doesn’t know exactly what is
expected from the system. By developing a prototype the developer will be
able to build the user requirements form the users feedback.
 If there are any errors, they can be caught at a very early stage
 Since the user is involved throughout the development, if there is any
missing functionality it can also be caught early
o Disadvantages
 Practically, this methodology may increase the complexity of the system as
scope of the system may expand beyond original plans.
 It is difficult to decide when the development should actually stop.
 This might lead to a more expensive project because there is always space
for iterations
 Since the belief of prototyping is to get the software working as soon as
possible the quality of the software might be poor and documentation might
not be given enough attention.
  In the case of throwaway prototyping, there may be some user
dissatisfaction with the delay in receiving the working version of the system
they had apparently just seen fully operational.

Incremental development

 The belief of incremental development is to give an exploration opportunity to the customer

of software systems which will allow some delays to build the system requirements. This will
provide the user with some experience with the actual system.
 The customer needs to determine and prioritise the functions that he thinks are most
important.
 The incremental model combines elements of the linear sequential (classical lifecycle) model
with the iterative philosophy of prototyping.
 The system is developed in increments, starting with the function with the highest priority
and integrating further increments as they are completed.
 When an increment is completed it is used by the user to gain some knowledge of how it
works.
 Once the increment is completed the user cannot request for any refinements.
 Each increment can have a different development approach. E.g. if the requirements for a
particular increment are clear then the life cycle approach can be used. However, if the
requirements are not clear then the evolutionary approach will be a better fit.
 Advantages
o The user can make use of the system at a very early stage rather than he has to wait
for the final product to be completed
o The early use of the system will make it more clear of what the requirements will be
for the system
o It may reduce the risk that the project will fail
o The most important system components are exposed to the most rigorous testing by
the user since they are implemented and delivered first.

Rapid Application Development

 Rapid application development is an example of an incremental software development
process.
 Rapid application development (RAD) is a software development methodology that uses
minimal planning in favor of rapid prototyping. A prototype is a working model that is
functionally equivalent to a component of the product.
 This approach is used when the overall requirements are well known, but the detailed
requirements are poorly specified, and where the project’s scope is constrained.
 The aim is that a small development team (4–10 people) can develop a working system in a
period of about 60–90 days.
 In doing this it sidelines many traditional systems development practices and therefore can
produce somewhat error-prone and difficult to maintain systems; however, this also means
it can produce working systems quickly.
 The aim is to undertake development as a series of ‘timeboxes’ – short periods of
development in which analysis, design and implementation are undertaken in a fixed time
without slippage.
 The assumptions behind RAD are:
o that it is impossible to specify complex requirements in advance
o that the application (i.e. the software) acts as its own model – and therefore that the
code includes comments which make it clear how it works, and for what purpose
(hence avoiding lots of diagrams and documents)
o that design and testing is iterative
o that we should keep the application software in a working state at all times
o that users form an integral part of the development team, working alongside the
developers. Unfortunately, this is expensive (in users’ time) and may be difficult to
arrange.
 To achieve rapid speeds one can use incrementally developing software and by employing
tools such as databases, user interface design software, CASE tools etc.
 Since the aim is not to miss deadlines the approach focuses on making hard decisions about
requirements – it is better to drop requirements than to miss deadlines.
 Rather than simply asking what users want, it suggests developers and users should debate
requirements in order to rate them in the following way (known by the acronym MoSCoW)
o Must-have
o Should have
o Could have
o Won’t have.
 The reason for doing this is that it is noted that 80 per cent of a system’s functionality can be
delivered with around 20 per cent of the effort needed to complete 100 per cent of the
requirements (this is called the Pareto Principle or 80/20 rule).
 Finally, it is worth remembering that the cost of an application should not simply be
measured in terms of development costs (for which RAD may be cheaper than traditional
approaches), but for the whole life of an application (where the difficulty of maintenance
may make it more expensive).
 RAD Model Vs Traditional SDLC
o The traditional SDLC follows a rigid process models with high emphasis on
requirement analysis and gathering before the coding starts. It puts a pressure on
the customer to sign off the requirements before the project starts and the
customer doesn.t get the feel of the product as there is no working build available
for a long time.
o The customer may need some changes after he actually gets to see the software,
however the change process is quite rigid and it may not be feasible to incorporate
major changes in the product in traditional SDLC.
o RAD model focuses on iterative and incremental delivery of working models to the
customer. This results in rapid delivery to the customer and customer involvement
during the complete development cycle of product reducing the risk of non-
conformance with the actual user requirements
  RAD Model Pros and Cons
o RAD model enables rapid delivery as it reduces the overall development time due to
reusability of the components and parallel development.
o RAD works well only if high skilled engineers are available and the customer is also
committed to achieve the targeted prototype in the given time frame. If there is
commitment lacking on either side the model may fail.
o Following table lists out the pros and cons of RAD Model:
 Pros
 Changing requirements can be accommodated.
 Progress can be measured.
 Iteration time can be short with use of powerful RAD tools.
 Productivity with fewer people in short time.
 Reduced development time.
 Increases reusability of components
 Quick initial reviews occur
 Encourages customer feedback
 Integration from very beginning solves a lot of integration issues.
 Cons
 Dependency on technically strong team members for identifying
business requirements.
 Only system that can be modularized can be built using RAD.
 Requires highly skilled developers/designers.
 High dependency on modelling skills.
 Inapplicable to cheaper projects as cost of modelling and automated
code generation is very high.
 Management complexity is more.
 Suitable for systems that are component based and scalable.
 Requires user involvement throughout the life cycle.
 Suitable for project requiring shorter development times.

The Spiral Model

 The Boehm’s Spiral Model was designed to include the best features of the Prototyping and
Waterfall models and introduces a new component – risk assessment.
 As the name implies the spiral model takes the form of a spiral in which each loop
represents a phase of the development process, such as requirements determination, design
etc.
 The spiral model has four phases. A software project repeatedly passes through these
phases in iterations called Spirals:
o Determine the objective
 This phase starts with gathering the business requirements in the baseline
spiral. Objectives are decided and a management plan is built. At this stage
any risks are also listed.
o Identify and resolve risks
 The risks that have been identified in the previous phase are now analysed.
These risks are discussed and will try to be solved and other alternatives are
taken into consideration. The aim of this stage is to reduce the risks.
o Development and test
  Based on the risks, a development approach is chosen and Proof Of Concept
is developed to be evaluated by the users and feedback is also given.
o Plan the next iteration
 A review of the project takes place and decide whether to proceed to the
next development loop or whether to stop working on the project.
 Advantages and disadvantages of the spiral model
o The advantage of spiral lifecycle model is that it allows for elements of the product
to be added in when they become available or known. This assures that there is no
conflict with previous requirements and design.
o This method is consistent with approaches that have multiple software builds and
releases and allows for making an orderly transition to a maintenance activity.
Another positive aspect is that the spiral model forces early user involvement in the
system development effort.
o On the other side, it takes very strict management to complete such products and
there is a risk of running the spiral in indefinite loop. So the discipline of change and
the extent of taking change requests is very important to develop and deploy the
product successfully.
o The following table lists out the pros and cons of Spiral SDLC Model:
 Advantages
 Changing requirements can be accommodated.
 Allows for extensive use of prototypes
 Requirements can be captured more accurately.
 Users see the system early.
 Development can be divided into smaller parts and riskier parts can
be developed earlier which helps better risk management.
 Disadvantages
 Management is more complex.
 End of project may not be known early.
 Not suitable for small or low risk projects and could be expensive for
small projects.
 Process is complex
 Spiral may go indefinitely.
 Large number of intermediate stages requires excessive
documentation.

‘Internet speed’ development

 It is not considered as a software engineering methodology but it is worth mentioning since
it is having bit impact of developing software for websites.
 Internet-Speed Development is an Agile Software Development method using a combined
spiral model/waterfall model with daily builds aimed at developing a product with high
speed.
 It was developed because Companies where having problems delivering products with the
correct requirements within the time scheduled for the project and as such were changing
to more agile software development methods.
 More details about how the internet-speed method was developed can be seen in the
evolutionary map in the paper of Abrahamsso
  From their studies Baskerville et al 2003, they discovered that companies developing
software for the internet had a lot of pressures to complete the projects on time with vague
requirements.
 The study suggested that organisations adopt the following approaches when developing
internet speed systems (they are therefore particularly applicable to web-based companies
such as Ebay, Yahoo or Amazon):
o develop in parallel - One way to increase speed is to use overlapping parallel
development.
o release more often - To match the perception of speed, releases are smaller and
more frequent.
o depend on tools - heavy use of development tools that speed up the work
o establish stable architectures - this helps anchor a rapid development process which
is never stable.
o assemble and reuse components - maximizing reuse speeds up the process both
from a development as well as from a testing perspective
o implant customers in the development environment - lets customers participate
more closely in all phases of development
o ignore maintenance - Systems should change fast enough to not require any
maintenance
o tailor the methodology daily -
 This suggests that it is not important to develop software precisely and it is more important
to develop software that is good and be able to keep up with the speed of the market.
 Such approach is only ideal where the environment changes very fast and where time is very
crucial for the company.
 Developing in parallel thus ensures that we can have new features being developed
continuously, for as one feature is implemented and released, another parallel development
team can be analysing the next feature.
 Releasing often is possible because the only version of the software is the one running on
the company’s web servers;
 Depending on tools, establishing stable architectures and taking advantage of reuse are
clearly aimed at speeding up the development of the software. Likewise, implanting
customers is aimed at ensuring the developing software features reflect customers’ needs.
 Ignoring maintenance is rational because we expect to continue to employ the original
developers for some time (so they can fix problems), because we can make changes to the
software and introduce them very quickly, and because the risk of launching late is higher
than the risk of facing maintenance issues.
 This final point is perhaps the most crucial to our discussion of contemporary software
engineering. It is the realisation that we must balance cost, time and risk against each other
in selecting our approach to software engineering. The next chapter will consider this
balancing act in detail.

End User development

 Finally it is worth reflecting on the fact that a large amount of important systems
development occurs without any formal software engineering process at all.
 Within offices, businesses and factories, a wide range of people (end-users of software)
regularly tailor their software, or construct new software, to support their work without any
reference to software engineering.
 So called end user development is the practice of users writing small scripts in this way.
Spreadsheets, simple access databases, word-processing macros and even simple scripting
languages are often used.
 These end-users developed systems can, however, become crucial to the work practices of
businesses, and software engineers may end up needing to look at them to discover the
requirements for a new system.