Professional Documents
Culture Documents
Software Engineering
Note: This summary is not sufficient for exam preparation. It doesn’t cover 100% of the material.
The best way to use it is for last day revision when time is very limited. A complete revision of
the slides is necessary in order to be ready for the exams.
Plan-driven processes are processes where all of the process activities are planned in advance and
progress is measured against this plan.
In Agile processes, planning is incremental -> easier to change the process to reflect changing customer
requirements.
In practice, most practical processes include elements of both plan-driven and agile approaches.
• The Waterfall Process Model: Plan-driven model. Separate phases of specification and
development.
• Incremental Process Model: Plan-driven or agile model. Separate and distinct phases of
specification and development in increments.
• Evolutionary Process Model: An iterative model. It enables you to develop increasingly more
complete version of the software. Emphasis on risk management.
In practice, most large systems are developed using a process that incorporates elements from all of
these models.
• Mostly used for large systems engineering projects where a system is developed at several
sites. As the plan-driven nature of this model helps coordinate the work.
5- Waterfall drawbacks:
a. The main drawback of the waterfall model is the difficulty of accommodating change after the
process is underway. In principle, a phase has to be complete before moving onto the next phase. It is
often difficult for the customer to state all requirements explicitly from the beginning.
Therefore, this model is only appropriate when the requirements are well-understood and changes will
be limited during the process.
b. The customer must have patience. A working version of the program(s) will not be available until late
in the project time span.
c. A major mistake, if undetected until the working program is reviewed, can be disastrous.
There are many situations in which initial software requirements are reasonably well defined, but the
overall scope of the development effort prevents a purely linear process. In addition, there may be a
compelling need to provide a limited set of software functionality to users quickly and then refine and
expand that functionality in later software releases. In such cases, you can choose a process that
produces the software in increments.
The Incremental Process can use waterfall model in an iterative manner. It focuses on the delivery of an
operational product with each increment: the development and delivery is broken down into
increments, with each increment adding a part of required functionality
User requirements are prioritised, and the highest priority requirements are included in early
increments. Once the development of increment is started the requirements are frozen though
requirements for later increments can continue to evolve.
Early increments are simplified versions of the final product, but they are valuable to the business and
provide a platform for evaluation by the user.
As a result of use and/or evaluation of an increment, a plan is developed for the next increment. The
plan addresses the modification of the product to better meet the needs of the customer and the
delivery of additional features. This process is repeated until the complete product is produced.
c. The highest Priority system services tend to receive most system testing.
d. Incremental development is particularly useful when staffing is unavailable until the end of the
project.
e. Early increments can be implemented with fewer people. If the core product is well received, then
additional staff can be added to implement the next increments.
f. Increments can be planned to manage technical risks. For example, a major system might require
the availability of new hardware that is under development and whose delivery date is uncertain. It
might be possible to plan early increments in a way that avoids the use of this hardware, thereby
enabling partial functionality to be delivered to end users without inordinate delay.
i. It is easier to get customer feedback on the development work that has been done.
j. Customers can comment on demonstrations of the software and see how much has been
implemented.
a. The process is not visible: Managers need regular deliverables to measure progress. If systems are
developed quickly, it is not cost-effective to produce documents that reflect every version of the system.
b. System structure tends to degrade as new increments are added: Unless time and money is spent on
refactoring to improve the software, regular change tends to corrupt its structure.
Software like all complex systems evolve over time. Business and product requirements often change as
development proceeds -> this makes a straight-line path to an end-product unrealistic; tight market
deadlines make completion of a comprehensive software product impossible.
We need a process model that has been explicitly designed to accommodate a product that meets
competitive or business pressure and evolves over time.
• Evolutionary models are iterative. They are characterized in a manner that enables to develop
increasingly more complete versions of the software in increments.
• They are used when some core system requirements are well understood and additional system
requirements have yet to be defined.
10- Prototyping
Often, a customer defines a set of general objectives for software but doesn’t identify details for the
functions and features. In other cases, the developer may be unsure of the efficiency of an algorithm. In
such cases, the Prototyping approach may be useful.
• The Prototype can serve as “the first system”. Some prototypes are built as “Throw away” others
slowly evolve into the actual system.
• Prototyping begins with communication. You meet with other stakeholders to define the overall
objectives for the software, identify known requirements, and outline areas where further definition
is necessary.
• A quick design focuses on a representation of those aspects of the software that will be visible to
end users (e.g., human interface layout or output display formats).
• The quick design leads to the construction of a prototype. The prototype is deployed and evaluated
by stakeholders, who provide feedback used to further refine requirements.
• Iteration occurs as the prototype is tuned to satisfy the needs of various stakeholders, while at the
same time enabling you to better understand what needs to be done.
a. Benefits of Prototyping: Both stakeholders and software engineers benefit from prototyping. Users
get a feel for the actual system, and developers get to build something immediately and improve the
system before deployment.
b. Drawbacks of Prototyping: Stakeholders see what appears to be a working version of the software,
unaware that in the rush to get it working you haven’t considered overall software quality or long-term
maintainability. As a software engineer, you often make implementation compromises in order to get a
prototype working quickly:
After some time, you may become comfortable with these choices and forget all the reasons
why they were inappropriate. The less-than-ideal choice has now become an integral part of the
system.
The Spiral Model couples the iterative nature of prototyping with controlled and systematic aspects of
waterfall. It allows rapid development of increasingly more complete versions of the software.
The Spiral Model is a risk-driven process model. It has two main distinguishing features:
a. One is a cyclic approach for incrementally growing a system’s features while decreasing risks.
b. The other is a set of milestones for ensuring stakeholders commitment to feasible and useful system
solution.
planning
estimation
scheduling
risk analysis
communication
modeling
analysis
design
start
deployment
construction
delivery
code
feedback test
• A spiral model is divided into a set of activities defined by the software engineering team. Each
of the activities represent one segment of the spiral path illustrated in the previous figure.
• As this process begins, the software team performs activities that are implied by a circuit around
the spiral in a clockwise direction, beginning at the center.
• Anchor point milestones are a combination of work products and conditions that are attained
along the path of the spiral.
• The first circuit around the spiral might result in the development of a product specification;
subsequent passes around the spiral might be used to develop a prototype and then
progressively more sophisticated versions of the software.
• Each pass through the planning region results in adjustments to the project plan. Cost and
schedule are adjusted based on feedback derived from the customer’s feedback after delivery.
In addition, the project manager adjusts the planned number of iterations required to complete
the software.
• Unlike other process models that end when the software is delivered, the spiral model can be
adapted to apply throughout the life of the software.
• The spiral model is a realistic approach to the development of large-scale systems and software.
Because software evolves as the process progresses, the developer and customer better
understand and react to risks at each evolutionary level.
• It uses the systematic stepwise approach suggested by the classic life cycle but incorporates it
into an iterative framework that more realistically reflects the real world.
Based on software reuse where systems are integrated from existing components or application systems
(sometimes called COTS -Commercial-off-the-shelf systems).
Reused elements may be configured to adapt their behaviour and functionality to user’s requirements.
Reuse is now the standard approach for building many types of business systems (ex: web stores, blogs).
• We can reuse components that are already made or we can make components that may be
reused.
• Used by vendors who offer the products that provide targeted functionality with well-defined
interfaces that enable the component to be integrated into the software to build.
• Modelling and construction activities begin with the identification of candidate components.
These components can be designed as either conventional software modules or object-oriented
classes or packages of classes.
• Reusability provides software engineers with a number of measurable benefits including a
reduction in development cycle time and a reduction in project cost.
b. Software discovery and evaluation: Available component-based products are researched and
evaluated for the application domain in question.
f. Component adaptation and integration: Components are integrated into the architecture.
a. Stand-alone application systems that are configured for use in a particular environment.
c. Web services that are developed according to service standards and which are available for remote
invocation.
PART II : Process activities:
1- The Requirements Engineering Process (The software specification):
It is the process of establishing what services are required and the constraints on the system’s
operation and development.
The activities of design and implementation are closely related and may be inter-leaved.
Design activities:
a. Architectural design, where you identify the overall structure of the system, the principal components
(subsystems or modules), their relationships and how they are distributed.
b. Database design, where you design the system data structures and how these are to be represented
in a database.
c. Interface design, where you define the interfaces between system components.
d. Component selection and design, where you search for reusable components. If unavailable, you
design how it will operate.
System implementation:
Debugging is the activity of finding program faults and correcting these faults.
3- Software validation
Verification and validation (V & V) is intended to show that a system conforms to its specification and
meets the requirements of the system customer.
System testing involves executing the system with test cases that are derived from the specification of
the real data to be processed by the system.
Stages of testing
a. Component testing: Individual components are tested independently. Components may be functions
or objects or coherent groupings of these entities.
b. System testing: Testing of the system as a whole. Testing of emergent properties is particularly
important.
c. Customer/acceptance testing: Testing with customer data to check that the system meets the
customer’s needs.
4- Software evolution
As requirements change through changing business circumstances, the software that supports the
business must also evolve and change.