Title: Modelling the Process and Life Cycle
1Modelling the Process and Life Cycle
- Software development usually involves the
following stages - Requirements analysis and definition
- System design
- Program design
- Program implementation (writing the program)
- Unit testing
- Integration testing
- System testing
- System delivery
- Maintenance
2What is a process?
- A series of steps involving activities,
constraints and resources that produce an
intended output of some kind - Characteristics of a process
- prescribes all of the major process activities
- uses resources, subject to a set of constraints
(such as a schedule), and produces intermediate
and final results - may be composed of sub-processes that are linked
in some way. - each process activity has an entry and exit
criteria, so we know when each activity begins
and ends
3What is a process? (continued)
- activities are organised in a sequence, so that
it is clear when one activity is performed
relative to the other activities - a set of guiding principles that explain the
goals of each activity - constraints or controls may apply to an activity,
resource or product. - e.g. budget or schedule may constrain length of
time activity may take
4Reasons for modelling a process
- Common understanding of the activities, resources
and constraints - Helps in the finding of inconsistencies,
redundancies and omissions - Help evaluate candidate activities for their
appropriateness in meeting the goals, such as
building high-quality software. - Every process should be tailored for the special
situation in which it will be used. Building a
model helps the team understand where that
tailoring is to occur
5Waterfall model
6Waterfall model advantages
- Very useful in helping developers layout (very
high-level view) what they need to do - Simplicity makes it easy to explain to
customers (who are not familiar with software
developers) - Explicitly states which intermediate products are
necessary in order to begin next stage
7Waterfall model disadvantages
- Failure to treat software as a problem solving
process. Software is a creation process not a
manufacturing process. Software evolves as the
problem is understood and the alternatives are
evaluated. - In particular, creation involves trying a little
of this or that, developing and evaluating
prototypes, assessing the feasibility of
requirements, contrasting several designs,
learning from failure and eventually settling on
a satisfactory solution to the problem
8Waterfall model disadvantages
- It provides no guidance of how each activity
transforms one artefact into another, such as
requirements to design. Thus the model provides
no guidance to managers and developers on how to
handle changes to products and activities that
are likely to occur during development. - If requirements change during coding, what
changes do we make to design and code?
9Software development in reality
10Process models
- The software development process can help control
the thrashing by including activities and
sub-processes that enhance understanding. - Prototyping is such a sub-process a prototype is
a partially developed product that enables
customers and developers to examine some aspect
of the proposed system and decide it is suitable
or appropriate for the finished product.
11Prototyping model
12Prototyping model
- Prototyping can be the basis of an effective
process model. This model allows all or part of
the system to be constructed quickly to
understand or clarify issues. - The overall goal is to reduce risk and
uncertainty in development.
13Phased development model
14Phased development model
- This is used to reduce cycle time. The system is
designed so that it can be delivered in pieces,
enabling users to have some functionality while
the rest is being developed. There are usually
two systems functioning in parallel the
production system and the development system
15Incremental model
- In the incremental model, the system as specified
in the requirements is partitioned into
sub-systems by functionality. The releases are
defined by beginning with one small functional
sub-system and then adding functionality with
each new release.
16Iterative model
- This model delivers a full system at the very
beginning and then changes the functionality of
each sub-system with each new release.
17Phased development advantages
- Training can begin on an early release. The
training process allows developers to observe
how certain functions are executed, suggesting
enhancements for later releases. - In this way, the developers can be very
responsive to the users
18Phased development advantages
- Markets can be created early for functionality
that has never before been offered - Frequent releases allow developers to fix
unanticipated problems as they are reported - The development team can focus on different areas
of expertise with different releases.
19Question
- Should a development organisation adopt a single
process model for all of its software
development? Discuss the pros and cons.
20Answer
- Pros
- Standardization of training, terminology, the
collection of process metrics, planning and
estimation. Works well if the projects are very
similar in nature. - Cons
- Adopting a single standard process may
unnecessarily constrain some projects from using
the process that is best suited to the problem
and the solution.
21Question
- Suppose your contract with the customer specifies
that you use a particular software development
process. How can work be monitored to enforce
the use of this process?
22Answer
- Conformance to a particular process is often
checked with the use of milestones. That is, the
process is defined in such a way that there are
tangible products in the process whose existence
indicates that particular process steps have been
carried out. - For example, when using the waterfall process.
These intermediate products, or milestones, could
be a requirements document, a design document,
the code itself, test documents etc. The timing
of these products indicate whether or not the
process was being followed as planned.
23Answer (continued)
- Another way to monitor use of a process is by
measuring effort. Developers working on the
project could be required to report the effort
they spent on different process activities. By
tracking when effort is spent on which
activities, progress through the steps of the
process could be monitored.
24The Rational Unified Process
- a process framework that can be adapted and
extended to suit the needs of an adopting
organization. - general and comprehensive enough to be used "as
is," i.e., out-of-the-box, by many
small-to-medium software development
organizations, especially those that do not have
a very strong process culture.
From an article by Philippe Kruchten (check
course webpage)
25The Rational Unified Process
- Can also modify, adjust, and expand the RUP to
accommodate the specific needs, characteristics,
constraints, and history of its organization,
culture, and domain. - Process should not be followed blindly,
generating useless work and producing artefacts
that are of little added value. - Instead, must be made as lean as possible while
still fulfilling its mission to help developers
rapidly produce predictably high-quality
software.
From an article by Philippe Kruchten (check
course webpage)
26The RUP Captures Software Development Best
Practices
- RUP captures many of modern software
development's best practices in a form suitable
for a wide range of projects and organizations - Develop software iteratively.
- Manage requirements.
- Use component-based architectures.
- Visually model software.
- Continuously verify software quality.
- Control changes to software.
From an article by Philippe Kruchten (check
course webpage)
27Develop Software Iteratively
- Most software teams still use a waterfall process
for development projects, completing in strict
sequence the phases of requirement analysis,
design, implementation/integration, and test. - idles key team members for extended periods
- defers testing until the end of the project
lifecycle, when problems tend to be tough and
expensive to resolve - pose a serious threat to release deadlines
- By contrast, RUP represents an iterative approach
that is superior
From an article by Philippe Kruchten (check
course webpage)
28Manage Requirements
- Requirements management is a systematic approach
to eliciting, organising, communicating, and
managing the changing requirements of a
software-intensive system or application.
From an article by Philippe Kruchten (check
course webpage)
29Continuously Verify Quality
- There is no worker in charge of quality in the
RUP - Because quality is not added to a product by a
few people. - Instead, quality is the responsibility of every
member of the development organization. - In software development, our concern about
quality is focused on two areas - product quality
- process quality.
From an article by Philippe Kruchten (check
course webpage)
30Continuously Verify Quality (continued)
- Product quality -- The quality of the principal
product being produced (the software or system)
and all the elements it comprises (for example,
components, subsystems, architecture, and so on). - Process quality -- The degree to which an
acceptable process (including measurements and
criteria for quality) was implemented and adhered
to during the manufacturing of the product.
From an article by Philippe Kruchten (check
course webpage)
31Rational Unified Process
From an article by Philippe Kruchten (check
course webpage)
32From an article by Philippe Kruchten (check
course webpage)
33Agile Methods
- Agile manifesto focuses on four simple value
statements, which defines preferences - Individuals and interactions over processes and
tools - Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Respond to changes over following a plan
34Agile Processes
- Extreme Programming(XP)
- Crystal
- Scrum
- Adaptive Software Development
35Extreme Programming(XP)
- Leveraging the creativity of developers and
minimising the amount of administration overhead - Emphasises four characteristics of agility
- Communication
- Simplicity
- Courage
- Feedback
36XP (continued)
- Communication
- Continual interchange between customers and
developers - Simplicity
- Encourages developers to select the simplest
design or implementation to address the needs of
the customer - Courage
- Commitment to delivering functionality early and
often - Feedback
- Loops are built into various activities during
development process
37Crystal
- Collection of approaches based on the notion that
every project needs a different set of policies,
conventions and methodologies - Suggests the following
- quality of the projects and processes improves as
the quality of the people involved improves - Productivity increases through better
communication and frequent delivery because there
is less need for intermediate products
38Scrum
- Uses iterative development, where each 30-day
iteration is called a sprint - During a sprint, implement the products
backlog of prioritised requirements - Multiple self-organising and autonomous teams
implement product increments in parallel - Coordination is done at a brief daily status
meeting called a scrum
39Adaptive Software Development
- has six basic principles
- A mission that acts as a guideline
- Features are viewed as the crucial point of the
customer value - Iteration is important
- Change is embraced
- Fixed delivery times
- Risk is embraced
40ASD (continued)
- A mission that acts as a guideline
- setting out the destination but not prescribing
how to get there - Features are viewed as the crucial point of the
customer value - so the project is organised around building
components to provide features - Iteration is important
- so redoing is as critical as doing
41ASD (continued)
- Change is embraced
- so that change is viewed not as a correction but
as an adjustment to the realities of software
development - Fixed delivery times
- force the developers to scope down the
requirements essential for each version produced - Risk is embraced
- so that the developer tackles the hardest
problems first