This is about software engineering.Software engineers apply engineering principles and knowledge of programming languages to build software solutions for end users. Software engineers design and develop computer games, business applications, operating systems, network control systems, and middleware—to name just a few of the many career paths available.
2. The Software
Process
Process defines a framework for a set
of key process areas that must be
established for effective delivery of
software engineering technology.
A structured set of activities required
to develop a software system.
3. Software process descriptions
When we describe and discuss processes, we usually talk about
the activities in these processes such as specifying a data
model, designing a user interface, etc. and the ordering of
these activities.
Process descriptions may also include:
Products, which are the outcomes of a process activity;
Roles, which reflect the responsibilities of the people
involved in the process;
Pre- and post-conditions, which are statements that are
true before and after a process activity has been enacted or
a product produced.
4. Plan-driven and agile processes
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, and it is
easier to change the process to reflect changing customer
requirements.
In practice, most practical processes include elements of
both plan-driven and agile approaches.
There are no right or wrong software processes.
5. Software process activities
Many different software processes but all involve:
Software specification, where customers and engineers define the software
that is to be produced and the constraints on its operation.
Software development, where the software is designed and programmed.
Software validation, where the software is checked to ensure that it is what
the customer requires.
Software evolution, where the software is modified to reflect changing
customer and market requirements.
7. Software process models
A software process model is an abstract representation of a process. It
presents a description of a process from some particular perspective.
The waterfall model
Plan-driven model. Separate and distinct phases of specification and development.
Incremental development
Specification, development and validation are interleaved. May be plan-driven or
agile.
Integration and configuration
The system is assembled from existing configurable components. May be plan-driven
or agile.
In practice, most large systems are developed using a process that
incorporates elements from all of these models.
8. SDLC Model by
Summerville
Requirements Definition
System and Software Design
Implementation and Unit testing
Integration and System Testing
Operation and maintenance
10. The Waterfall Model
It is the oldest paradigm for SE. When requirements are well
defined and reasonably stable, it leads to a top-down fashion.
The classic life cycle suggests a systematic, sequential approach
to software development.
11.
12. Waterfall model phases
There are separate identified phases in the waterfall model:
Requirements analysis and definition
System and software design
Implementation and unit testing
Integration and system testing
Operation and maintenance
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.
13. Waterfall model problems
Inflexible partitioning of the
project into distinct stages makes
it difficult to respond to changing
customer requirements.
• Therefore, this model is only
appropriate when the
requirements are well-
understood and changes will be
fairly limited during the design
process.
• Few business systems have
stable requirements.
The waterfall model is mostly used
for large systems engineering
projects where a system is
developed at several sites.
• In those circumstances, the plan-
driven nature of the waterfall
model helps coordinate the
work.
14. The V-Model
A variation of waterfall model
depicts the relationship of
quality assurance actions to
the actions associated with
communication, modeling and
early code construction
activities.
Team first moves down the left
side of the V to refine the
problem requirements. Once
code is generated, the team
moves up the right side of the
V, performing a series of tests
that validate each of the
models created as the team
moved down the left side.
20. The Incremental Model
When initial requirements are reasonably well defined, but the
overall scope of the development effort prevents a purely linear
process. A convincing need to expand a limited set of new functions
to a later system release.
It combines elements of water fall model in an iterative way. Each
linear sequence produces deliverable increments of the software.
The first increment is often a CORE PRODUCT with many additional
features. Users use it and evaluate it with more modifications to
better meet the needs.
21. Incremental
development
benefits
• The amount of analysis and
documentation that has to be
redone is much less than is
required with the waterfall model.
The cost of
accommodating
changing customer
requirements is
reduced.
• Customers can comment on
demonstrations of the software
and see how much has been
implemented.
It is easier to get
customer feedback
on the development
work that has been
done.
• Customers are able to use and gain
value from the software earlier
than is possible with a waterfall
process.
More rapid delivery
and deployment of
useful software to
the customer is
possible.
22. Incremental
development
problems
• 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.
The process is not visible.
• Unless time and money is spent on
refactoring to improve the software, regular
change tends to corrupt its structure.
Incorporating further software changes
becomes increasingly difficult and costly.
System structure tends to degrade
as new increments are added.
23. Pros and cons
Generates working software quickly and early during the
software life cycle.
More flexible – less costly to change scope and requirements
Easier to test and debug during a smaller iteration.
Easier to manage risk because risky pieces are identified and
handled during its iteration.
Each iteration is an easily managed milestone
Each phase of an iteration is rigid and do not overlap each
other
Problems may arise pertaining to system architecture because
not all requirements are gathered up front for the entire
software life cycle.
24. RAD Model
Rapid application development (RAD) is an incremental software
development process model
It emphasizes an extremely short development cycle
The RAD model is a “high-speed” adaptation of the linear sequential
model in which rapid development is achieved by using component-
based construction. If requirements are well understood and project
scope is constrained, the RAD process enables a development team
to create a “fully functional system” within very short time
periods(60-90 days)
25. Pros and cons
Increases reusability of components
Progress can be measured.
Encourages customer feedback
Quick initial reviews occur
Reduced development time
Inapplicable to cheaper projects as cost of modeling and
automated code generation is very high.
It is suitable for systems that are component based and scalable.
Requires highly skilled developers/designers.
Requires user involvement throughout the life cycle.
27. Evolutionary Models
Software system evolves over time as requirements often change as
development proceeds. Thus, a straight line to a complete end product is not
possible. However, a limited version must be delivered to meet competitive
pressure.
Usually a set of core product or system requirements is well understood, but
the details and extension have yet to be defined.
You need a process model that has been explicitly designed to accommodate
a product that evolved over time.
It is iterative that enables you to develop increasingly more complete version
of the software.
Two types are introduced, namely Prototyping and Spiral models.
28. Evolutionary Models: Prototyping
When to use: Customer defines a set of GENERAL OBJECTIVES but does not
identify detailed requirements for functions and features. Or Developer may
be unsure of the efficiency of an algorithm, the form that human computer
interaction should take.
What step: Begins with communication by meeting with stakeholders to define
the objective, identify whatever requirements are known, outline areas where
further definition is mandatory. A quick plan for prototyping and modeling
(quick design) occur. Quick design focuses on a representation of those
aspects the software that will be visible to end users. ( interface and output).
Design leads to the construction of a prototype which will be deployed and
evaluated. Stakeholder’s comments will be used to refine requirements.
Both stakeholders and software engineers like the prototyping paradigm. Users
get a feel for the actual system, and developers get to build something
immediately. However, engineers may make compromises in order to get a
prototype working quickly. The less-than-ideal choice may be adopted forever
after you get used to it.
29. Evolutionary Models: Prototyping
prototyping, analysis and design
Construction
of prototype
communication
Quick
plan
Modeling
Quick design
Construction
of prototype
Deployment
delivery &
feedback
30. Pros and cons
Model allows a high user interface of the customer.
It provide actual look and feel of system being developed for
customer review and feedback about the system functionality.
Errors and issues can be detected very easily.
Risk of insufficient requirement analysis owing to too much
dependency on prototype.
Users may get confused in the prototypes and actual systems.
Developers may try to reuse the existing prototypes to build
the actual system, even when it’s not technically feasible.
Less-than-ideal choice has now become an integral part of the
system
31. Evolutionary Models: The Spiral
Spiral model is one of the most important Software
Development Life Cycle models, which provides support
for Risk Handling. In its diagrammatic representation, it looks
like a spiral with many loops. The exact number of loops of the
spiral is unknown and can vary from project to project. Each
loop of the spiral is called a Phase of the software
development process. The exact number of phases needed to
develop the product can be varied by the project manager
depending upon the project risks. As the project manager
dynamically determines the number of phases, so the project
manager has an important role to develop a product using
spiral model.
33. Pros and cons
Highly flexible model
Risk handling
Fast and cost-effective development
Well-suited for large scale projects and mission-critical developments
Works well for complex projects
Monitoring is easy and effective
The end product can be highly customized
Can be expensive to implement – especially if spirals continue infinitely
The risk analysis aspect of the project may require specialist expertise
Not an ideal fit for smaller or low-risk projects
Success may depend greatly on the risk analysis
Documentation can be heavy, due to the number of intermediate stages
End of project may be difficult to define beforehand
34. Three Concerns on
Evolutionary Processes
First concern is that prototyping poses a problem to project planning
because of the uncertain number of cycles required to construct the
product.
Second, it does not establish the maximum speed of the evolution. If
the evolution occur too fast, without a period of relaxation, it is
certain that the process will fall into confusion. On the other hand if
the speed is too slow then productivity could be affected.
Third, software processes should be focused on flexibility and
extensibility rather than on high quality. We should prioritize the
speed of the development over zero defects. Extending the
development in order to reach high quality could result in a late
delivery of the product when the opportunity has disappeared.
35. Integration
and
configuration
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 a user’s
requirements
Reuse is now the standard approach for
building many types of business system
36. Reuse-Oriented Model
The reuse-oriented model, also called reuse-oriented development (ROD)
Method of software development in which a program is refined by producing
a sequence of prototypes called models
Each model is automatically derived from the preceding one according to a
sequence of defined rules.
37. Types of reusable software
Stand-alone application systems (sometimes called COTS) that are configured
for use in a particular environment.
Collections of objects that are developed as a package to be integrated with
a component framework such as .NET or J2EE.
Web services that are developed according to service standards and which are
available for remote invocation.
40. Advantages and disadvantages
Reduced costs and risks as less software is developed from scratch
Faster delivery and deployment of system
But requirements compromises are inevitable so system may not meet real
needs of users
Loss of control over evolution of reused system elements
41. Still Other Process Models
Component based development—the process
to apply when reuse is a development
objective (COTS)
Unified Process—a “use-case driven,
architecture-centric, iterative and
incremental” software process closely
aligned with the Unified Modeling Language
(UML) to model and develop object-oriented
system iteratively and incrementally.
42. Unified Modeling
Class Diagram (View System Architecture)
Use Case Diagram (View System Functionality)
Sequence Diagram (View System Behavior)
State Diagram (View System States)