http://wikistudent.

ws/Unisa
INF305
Yellow = answered textbook questions Blue = unanswered questions

Chapter 3 – Process Models

Prescriptive process models prescribe a set of process elements:
• Framework activities, tasks, work products, quality assurance…
Generic framework activities:
• Communication
Planning
Modeling
Construction
Deployment

Linear process model:

1. Waterfall model (Classic life cycle)

• Systematic, linear, sequential approach
• For projects with these characteristics:
o The problem is well understood (well-defined requirements)
o The delivery date is realistic
o Major changes in requirements are unlikely
• For when work flows in a reasonably linear fashion
• The linear nature can lead to ‘blocking states’, where you have
to wait for other team members to complete dependent tasks
• Inappropriate model for today’s fast-paced changing software
• Problems:
o Real projects rarely follow a sequential flow
o The customer has to state all requirements explicitly
o Working version of the program appears late in the project
• Software projects that would be amenable to the waterfall model:
o A well-understood modification to an existing program
o A straightforward implementation of a numerical calculation
or business rule, even if it is complex
o A constrained enhancement to an existing program

Incremental process models:

For when requirements are well-defined, and a limited set of software
functionality must be provided quickly, and then refined later.

2. Incremental model
• Combines elements of the waterfall model applied iteratively
• Linear sequences each produce deliverable increments of software
• The first increment is usually a core product, used by customers
• Each increment focuses on the delivery of an operational product
• Good when staffing is unavailable for a complete implementation
• Increments can be planned to manage technical risks
• Software projects amenable to the incremental model:
o A project that has significant functionality that must be
delivered in a very tight time frame (Add on extras later)

1
 http://wikistudent.ws/Unisa
3. RAD model
• An incremental model that emphasizes a short development cycle
• A high-speed adaptation of the waterfall model, where rapid
development is achieved by using component-based construction
• For when requirements are understood and scope is constrained
• For when business applications can be modularized
• A fully functional system is constructed in a very short time
• Each major function is addressed by a separate RAD team and then
integrated to form a whole
• To achieve rapid development, this model assumes the existence
of: a project that can be modularized in a manner that allows
major functionality to be delivered within 60-90 days (This
isn’t always the case – sometimes timelines can be longer)
Drawbacks:
• For large projects, RAD requires sufficient human resources to
develop the increments in parallel
• Projects will fail if people don’t commit to rapid activities
• If a system can’t be modularized, you can’t build components
• Might not work if high performance is an issue
• Might not be appropriate when technical risks are high

Evolutionary process models:

For when core requirements are well understood and a limited version
of the product must be introduced, which will evolve over time.
Iterative, and can easily accommodate product requirement changes.

4. Prototyping
• For when the customer defines a set of general objectives
• For when the developer is unsure of the form of the software
• Can be used as a standalone process model, but is more commonly
used as a technique that can be implemented within other models
• The prototype helps to identify software requirements
• It should be discarded (at least in part)
• Problems with prototyping:
o The customer sees a working version and wants to keep it
o Developers may become comfortable with inefficient choices
• Software projects amenable to the prototyping model:
o Ones which involve human-machine interaction and/or heavy
computer graphics
o Ones where results can easily be examined without real-time
interaction (e.g. command-driven systems using mathematical
algorithms) i.e. not embedded software!
• Process adaptations required if the prototype will evolve into a
deliverable system / product:
o More rigorous design rules and SQA procedures must be
applied from the beginning

2
http://wikistudent.ws/Unisa
o The prototype must be designed with extensibility in mind
and be implemented using a programming environment that is
amenable to production system development
o The prototype is initially a mechanism for identifying
requirements, and then becomes the framework for extensions
that will cause it to evolve into a production system

5. Spiral model
• Combines the iterative nature of prototyping with the controlled
and systematic aspects of the waterfall model
• Rapid development of increasingly complete versions of software
• Software is developed in a series of evolutionary releases
• Each framework activity represents 1 segment of the spiral path
• Risk-driven model: risk evaluation during each iteration
• Anchor point milestones are noted for each evolutionary pass
• This model can apply throughout the life of the software
• Good for developing large-scale systems and software
• Not good if you have a fixed budget, because project cost is
revised as each circuit is completed
• Prototyping reduces risks, and can be applied at any stage
• Problems:
o May be hard to convince customers that it’s controllable
o Demands considerable risk assessment and expertise
o Problems if a major risk is not uncovered and managed
• What happens to the software as you move outwards along the
spiral process flow:
o The product moves towards a more complete state
o The level of abstraction at which work is performed is
reduced (i.e. implementation-specific work accelerates as
we move further from the origin)

6. Concurrent development model

• Represented as a series of framework activities, software
engineering actions & tasks, and their associated states
• All activities exist concurrently but reside in different states
• What the states represent and how they come into play:
o The different parts of a project (framework activities)
will be at different stages of completeness (e.g. ‘under
development’, ‘awaiting changes’, ‘done’), so you can say
that all activities are being performed concurrently
o The challenge is to manage the concurrency and to be able
to assess the status of the project
• A series of events are defined that will trigger transitions
from state to state for each of the software activities / tasks
• This model is applicable to all types of software development
• Often used for the development of client/server applications
• Provides an accurate picture of the current state of the project

3
http://wikistudent.ws/Unisa

Weaknesses of process models:

• Prototyping poses a problem to project planning because of the
uncertain number of cycles required to construct the product
• Evolutionary processes don’t establish the maximum speed of the
evolution
• Software processes should be focused on flexibility and
extensibility rather than on high quality

Specialized process models:

For when a narrowly defined software engineering approach is chosen.

7. Component-based development model

• Incorporates many characteristics of the spiral model, but
composes applications from prepackaged software components
• Works best when object technologies are available for support
• These steps are implemented using an evolutionary approach:
1. Available products are evaluated for the application domain
2. Component integration issues are considered
3. A software architecture is designed
4. Components are integrated into the architecture
5. Comprehensive testing is conducted to ensure functionality
• Benefit: Leads to software reuse
• Software projects amenable to the component-based model:
o Ones where COTS components are available
o If the interfaces for the available components are
compatible with the architecture of the system to be built

8. Formal methods model

• Formal mathematical specification of computer software
• Ambiguity, incompleteness, and inconsistency are easily found
• Offers the promise of defect-free software
• Reasons why it is not widely used:
o Time-consuming and expensive
o Extensive training
o Difficult to use the models to communicate with customers
• Good for safety-critical software (aircraft avionics, medical…)

9. Aspect-oriented software development

• Software has localized features, functions, and information
• These localized characteristics are modeled as components and
then constructed within the context of a system architecture
• Discuss the meaning of crosscutting concerns:
o Concerns (e.g. security, fault tolerance…) that cut across
multiple system functions, features and information
• Aspectual requirements define those crosscutting concerns that
have impact across the software architecture

4
http://wikistudent.ws/Unisa
• Aspects = localizing the expression of a crosscutting concern

10. The Unified Process

• Recognizes the importance of customer communication (use cases)
• Emphasizes the important role of software architecture
• Suggests an iterative, incremental process flow
• The difference between the UP and UML:
o UML = a modeling notation and language
o UP = a process framework in which UML may be applied as
part of SE activities

Phases of the Unified Process:

1. Inception
• Customer communication and planning activities
• Identify software requirements, propose a rough architecture,
and plan for the iterative, incremental nature of the project
• Use cases describe fundamental business requirements
• Work product: Use case model
2. Elaboration
• Customer communication and modeling activities
• Refines and expands the preliminary use-cases
• Expands architectural representation to include 5 views of the
software: Use-case model, analysis model, design model,
implementation model, and deployment model
• Work products: analysis model, design model
3. Construction
• Develop the software that will make each use-case operational
• Unit tests are designed and executed for each component
• Work products: implementation, deployment, and test models
4. Transition
• Encompasses later stages of construction & 1st part of deployment
• Beta testing by end-users to discover defects & deficiencies
• Support information is created (user manuals…)
• Work product: the software increment
(5.) Production
• Coincides with deployment
• On-going use of the software is monitored, support of the
operating environment is provided, and defect reports and
requests for changes are submitted and evaluated

Workflows distributed across the UP phases:

• The difference between a UP phase and a UP workflow:
o A workflow is distributed across all UP phases and
identifies the tasks required to accomplish an action and
the work products produced

5
http://wikistudent.ws/Unisa

Inception Elaboration Construction Transition

Requirements Use case
model
Analysis Analysis
model
Design Design model
Implement Implementation
model
Deployment
model
Test Test model

• Is it possible to combine process models?

o Yes, since they all perform the same set of generic
framework activities
• What happens when we emphasize development speed over product
quality:
o The advantage of developing software in which quality is
‘good enough’ is that it will meet the deadline
o The disadvantage is that it may require more testing,
design and implementation rework

Chapter 4 – An agile view of process

Agility
• An agile team can respond appropriately to changes
• The skills of the team members and their ability to collaborate
is at the core for the success of the project
• Dynamic, content specific, change embracing, and growth oriented
• Encourages team structures and attitudes that ease communication
• Emphasizes rapid delivery of operational software and de-
emphasizes the importance of intermediate work products
• Adopts the customer as a part of the development team
• Recognizes that a project plan must be flexible
• Can be applied to any software process

4 values of agile software development:

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

• Situations in which the 4 values can get a software team into

trouble:
1. A project may fail because the processes & tools are poor

6
http://wikistudent.ws/Unisa
2. Documentation helps maintaining applications years later
3. Negotiation helps avoid unrealistic expectations
4. A chaotic project environment (no plan) can lead to failure

12 principles for achieving agility:

1. Main priority: early & continuous delivery of valuable software
2. Welcome changing requirements, even late in development
3. Deliver working software frequently
4. Business people & developers must work together daily
5. Build projects around motivated individuals
6. Face-to-face conversation with the development team
7. Working software is the primary measure of progress
8. Agile processes promote sustainable development
9. Continuous attention to technical excellence and good design
10. Simplicity is essential
11. The best architectures, requirements, and designs emerge from
self-organizing teams
12. At regular intervals, the team reflects on how to become more
effective, then tunes and adjusts its behavior accordingly

• Select one agility principle and try to determine whether each

of the process models in this chapter exhibits the principle:
o “Welcome changing requirements, even late in development” –
Change, with agile processes, is essential for competitive
advantage, so all the models exhibit this principle
• Try to come up with another agility principle that would help a
software engineering team become even more maneuverable:
o “A team should know whose skills suit a particular project
and get these people on their project”
o “Communication is the key: The customer and developer
should communicate regularly, even if separated”

Agile process
Any agile software process is characterized by 3 key assumptions:
1. It is difficult to predict which software requirements will
persist and which will change (priorities also change)
2. For many types of software, design and construction are
interleaved, and it is difficult to predict how much design is
necessary before construction is used to prove the design
3. Analysis, design, construction, and testing are not as
predictable (from a planning point of view) as we might like

• A process that can manage unpredictability must be adaptable

• It must adapt incrementally, using customer feedback
• An incremental development strategy should be instituted
• Software increments (e.g. prototypes) must be delivered in short
time periods so that adaptation keeps pace with change

7
http://wikistudent.ws/Unisa
• Why does an iterative process make it easier to manage change?
Is every agile process iterative? Is it possible to complete a
project in just one iteration and still be agile? Explain.
o An iterative approach enables customers to evaluate
regularly, provide feedback, and influence the required
changes. (The software team manages change by focusing on a
defined increment and postponing any changes until the next
increment). All agile processes are iterative. If a project
were completed in just one iteration it would not be agile
because frequent software delivery is a key characteristic
of agile development.

• Why do requirements change so much?

o It is difficult to predict in advance which requirements
will persist and which will change
o It is difficult to predict how customer priorities will
change as the project proceeds
o It is difficult for customers to verbalize their software
needs until they see a working prototype

• Describe agility for software projects:

o Agility can be applied to any software process. The process
must be designed in a way that allows the project team to
 Adapt tasks and to streamline them
 Conduct planning in a way that understands the
fluidity of an agile development approach
 Eliminate all but the most essential work products
 Emphasize an incremental delivery strategy that gets
software to the customer as rapidly as feasible

• Most agile process models recommend face-to-face communication.

Yet today, members of a software team and their customers may be
geographically separated from one another. Do you think this
implies that geographical separation is something to avoid? Can
you think of ways to overcome this problem?
o Physical proximity is not always possible. Face-to-face
communication can be achieved with low-cost video
conferencing, Web-based discussion groups and other
electronic means. These are not as powerful as physical
proximity, but they can achieve much the same result.

Human factors:
Key traits that must exist among the people on the software team:
• Competence
Skill and knowledge of the process must be taught to the members
• Common focus
Focus on the goal of delivering a working increment on time
• Collaboration

8
http://wikistudent.ws/Unisa
Team members must collaborate with one another, with the
customer, and with business managers to accomplish tasks
• Decision-making ability
The team is given decision-making authority for project issues
• Fuzzy problem-solving ability
Deal with ambiguity and change, learning lessons from the past
• Mutual trust and respect
A ‘jelled’ team is strongly knit (whole > parts)
• Self-organization
 The team organizes…
1. itself for the work to be done
2. the process to best accommodate the environment
3. the work schedule to best achieve delivery of the increment
o Advantage: improves collaboration and boosts team morale

Agile process models

1. Extreme programming (XP)

• Uses an OO approach as its preferred development paradigm
Planning
• Stories describe required features & functionality of software
• Each story is written by the customer & placed on an index card
• The customer assigns a value (priority) to the story
• Members of the XP team assess each story and assign a cost
(measured in development weeks)
• If the story requires more than 3 weeks, the customer must split
the story into smaller ones
• Customers and the XP team decide how to group stories into the
next release (the next increment)
• Once a commitment is made for a release, the team orders the
stories that will be developed in one of three ways:
o All stories will be implemented immediately
o The stories with highest value will be implemented first
o The riskiest stories will be implemented first
• After the 1st release, the team computes project velocity (the
number of customer stories implemented during the 1st release)
• Project velocity can then be used to:
o Help estimate delivery dates & schedule for other releases
o Determine whether an over-commitment has been made for all
stories across the entire development project
• As work proceeds, the customer can add, change, split, or
eliminate stories, and the team modifies its plans accordingly
• An XP story that describes the ‘favorites’ feature of browsers:
o Each URL that I intend to revisit can be stored in a
favorite places file. I should be able to name and group
URLs by categories that I define, store a favorite place in
a particular category, order the URLs in any way I like and
recall the favorite places file at any time from the
9
http://wikistudent.ws/Unisa
browser menu. I should be able to list all favorite places
as a categorized list in my browser window. I can select a
favorite place using my mouse. Once selected, the browser
will establish a link to that URL and display the website.
Design
• A simple design is always preferred over a complex one
• The design provides implementation guidance for a story
• (The design of extra functionality is discouraged)
• CRC cards identify and organize the OO classes that are relevant
• If a difficult design problem is encountered, create a prototype
• Spike solution = the prototype that is implemented & evaluated
• The only work products are CRC cards and spike solutions
• Refactoring = improving the code design after it’s been written
• Design occurs both before and after coding commences (Refactor!)
Coding
• Develop unit tests to exercise each story before coding
• When the code is complete, it can be unit tested immediately
• Pair programming = having two people work together at one
computer to create code for a story, for quality assurance
• As pair programmers complete their work, their code is integrated
with the work of others, to uncover errors early
• This continuous integration provides a smoke testing environment
Testing
• Tests should be automated to be executed easily & repeatedly
• Regression testing strategy whenever code is modified/refactored
• As the individual unit tests are organized into a ‘universal
testing suite’, integration and validation testing of the system
can occur on a daily basis
• This provides the team with a continual indication of progress
• Acceptance tests / customer tests = ones specified by customers
and focus on overall features (stories) that are visible

2. Adaptive Software Development (ASD)

• Focuses on human collaboration and team self-organization
Speculation
• The project is initiated & adaptive cycle planning is conducted
• Adaptive cycle planning uses the customer’s mission statement,
project constraints, and basic requirements to define the set of
release cycles that will be required
Collaboration
• Motivated people work together in a way that multiplies their
talent and creative output beyond their absolute numbers
• People working together must trust one another to
o Criticize without animosity
o Assist without resentment
o Work as hard / harder as they do
o Have the skill set to contribute to the work at hand
10
http://wikistudent.ws/Unisa
o Communicate problems in ways that lead to effective action
Learning
• ASD teams learn in 3 ways:
1. Focus groups
The customer / users provide feedback on software increments
2. Formal technical reviews
ASD team members review the software components developed
3. Postmortems
The team becomes introspective, addressing its own performance

3. Dynamic Systems Development Method (DSDM)

• Building systems which meet tight time constraints by using
incremental prototyping in a controlled project environment
• Iterative process, but only enough work is required for each
increment to facilitate movement to the next increment
• The remaining detail can be completed later
Feasibility study (additional)
• Establishes the basic business requirements & constraints
• Assesses whether the application is a viable candidate for DSDM
Business study (additional)
• Establishes the functional & information requirements
• Defines the basic application architecture and identifies the
maintainability requirements for the application
Functional model iteration (iterative)
• Produces a set of incremental prototypes for demonstration
• (All DSDM prototypes are intended to evolve into deliverables)
• Additional requirements are gathered by eliciting feedback from
users as they exercise the prototype
Design & build iteration (iterative)
• Revisits prototypes built during the functional model iteration
to ensure that each will provide operational business value
• (The previous activity & this one can occur concurrently)
Implementation (iterative)
• The latest software increment is placed into operation
• Note that the increment may not be 100% complete, and changes
may be requested as the increment is put into place
• DSDM work continues by returning to the function model iteration

4. Scrum
• Small working teams are organized to maximize communication &
knowledge, and minimize overhead
• The process must be adaptable to technical & business changes
• Frequent software increments
• Work and people are partitioned
• Constant testing and documentation
• A product is declared ‘done’ whenever required
• Requirements
analysis
design
evolution
delivery
11
 http://wikistudent.ws/Unisa
• Software process patterns define some development activities:
o Backlog
Prioritized list of project requirements / features
Items can be added to the backlog at any time
o Sprints
Work units that are required to achieve a requirement
defined in the backlog that must fit into a time-box
During the sprint, the backlog items it uses are frozen
o Scrum meetings
Short daily meetings where these key questions are asked:
1. What did you do since the last team meeting?
2. What obstacles are you encountering
3. What do you plan to accomplish by the next meeting?
A ‘scrum master’ assesses the responses from each person
The meetings help the team uncover potential problems early
These daily meetings lead to ‘knowledge socialization’
o Demos
Increment delivered to the customer so that functionality
can be demonstrated and evaluated
The demo mayn’t contain all planned functionality, but only
the functions delivered within the established time-box
• A sample Scrum pattern:
Pattern Scrum meeting
Intent To answer three key questions using an abbreviated meeting
format that is conducted daily
Type Task pattern
Initial 1. The project should have been initiated and a backlog
context developed
2. Sprints should be underway
3. All members of the Scrum team should agree to meet in a
pre-specified location each day for the scrum meeting
4. A team leader should be defined
Problem It is often difficult for members of the team to
understand the status of the project and the status of
work being conducted by each member of the team. When
meetings are conducted, they are often too time-consuming
and ineffective.
Solution Short meetings are held daily and the 3 key questions are
asked and answered by all team members
Resulting At the conclusion of the meeting, each person has answered
context the questions noted in the solution
Related Backlog preparation
patterns Conducting a sprint
Known uses Scrum meetings are conducted throughout every Scrum
/ examples project and are an important element of communication

5. Crystal
• An approach that puts a premium on maneuverability
• Primary goal: delivering useful, working software

12
http://wikistudent.ws/Unisa
• Secondary goal: setting up for the next ‘game’
• To achieve maneuverability, there is a set of methodologies to
choose from, which all have core elements in common
• Reflection workshops are conducted before, during, and after an
increment is delivered
• Why Crystal is called a ‘family of agile methods’:
o The Crystal approach emphasizes collaboration and
communication among people who have varying degrees of
interest in the software project. The method is also
tolerant of varying team cultures and can accommodate both
informal and formal SE approaches. Crystal family is
actually a set of sample agile processes that have been
proved effective for different types of projects. The
intent is to allow agile teams to select the member of the
Crystal family that is most appropriate for their project.

6. Feature Driven Development (FDD)

• A ‘feature’ is a client-valued function that can be implemented
in two weeks or less
• Benefits of the emphasis on the definition of ‘features’:
o Because features are small, users can describe them more
easily and better review them, and their design & code are
easier to inspect effectively
o Features can be organized into a hierarchy
o The team develops operational features every two weeks
o Project planning, scheduling, and tracking are driven by
the feature hierarchy, rather than an arbitrarily adopted
software engineering task set
• Five framework activities (processes):
1. Develop an overall model
2. Build a features list
3. Plan by feature
4. Design by feature
5. Build by feature
• FDD provides greater emphasis on project management guidelines
and techniques than many other agile methods
• To determine if software increments are properly scheduled, FDD
defines 6 milestones: design walkthrough, design, design
inspection, code, code inspection, promote to build

• Use the FDD feature template to define a feature set for a Web
browser, and develop a set of features for the feature set:
(action) the (result) (by | for | of | to) a(n) (object)
Examples:
Specify a URL for a website
Display the content of a website
Fill in the content of a Web form
Show all URLs for favorite places

13
 http://wikistudent.ws/Unisa
7. Agile Modeling (AM)
• With large systems, scope and complexity must be modeled so that
o All can better understand what needs to be accomplished
o The problem can be partitioned effectively among the people
o Quality can be assessed at every step during engineering
• AM = a methodology for modeling & documentation of software in a
light-weight manner: Agile models are barely good, not perfect
• AM provides guidance to practitioners during analysis & design
• An agile team must have the courage to make decisions and
humility to recognize that they don’t have all the answers
• Principles that make AM unique:
o Model with a purpose
Have a specific goal before creating the model
o Use multiple models
Each model should present a different aspect of the system
o Travel light
Keep only the models that will provide long-term value
o Content is more important than representation
Modeling should impart information to its intended audience
o Know the models and the tools you use to create them
Understand the strengths & weaknesses of each model & tool
o Adapt locally
Adapt the modeling approach to the needs of the agile team

• Build a table that maps the generic framework activities into

the activities defined for each agile process:
Generic: XP ASD Scrum
Communi- Plan (user stories) Speculation Requirements
cation Collaboration
Planning Plan (commit to a Speculation Analysis
specific increment) (adaptive cycle
planning)
Modeling Design (refactoring, Collaboration Design
spike solutions) (mini-specs)
Construc- Code (pair programming) Learning (learn Evolution
tion Test (unit testing) as you develop
components)
Deployment Test (acceptance Learning Delivery
testing, customer tests)

Generic: FDD DSDM

Communication Develop an overall model Feasibility study (basic
Planning Build a features list requirements)
(features are grouped Business study (functional
into sets) & info requirements)
Plan by feature
Modeling Design by feature Functional model iteration
Construction (design package) (prototypes)
Design & build iteration

14
 http://wikistudent.ws/Unisa
Build by feature (revisit prototypes)
Deployment (completed function) Implementation

Chapter 5 – Software engineering practice

Software engineering practice
The essence of practice
1. Understand the problem (communication & analysis)
• Who are the stakeholders?
• What data, features, etc… are needed to solve the problem?
• Can the problem be compartmentalized?
• Can an analysis model be created?
2. Plan a solution (modeling & software design)
• Have you seen similar problems before?
• Has a similar problem been solved? (Are elements reusable?)
• Can subprograms be defined?
• Can a design model be created?
3. Carry out the plan (code generation)
• Is source code traceable to the design model?
• Has the design and code been reviewed?
4. Examine the result for accuracy (testing & quality assurance)
• Has a reasonable testing strategy been implemented?
• Has the software been validated against all requirements?

7 Core principles
• Summarize David Hooker’s 7 principles for software development:
1. Software exists to provide value to its users
2. Keep it simple
3. Maintain the vision
4. What you produce, others will consume (maintain)
5. Be open to the future – don’t design yourself into a corner
6. Plan ahead for reuse
7. Think before you act

• Other technical ‘essentials’ that can be recommended for SE:

o The need to test software thoroughly to find errors
o The need to use automated tools to facilitate development
o The need to measure the product to improve quality

• Other management ‘essentials’ that might be recommended for SE:

o Continuous & effective communication with stakeholders
o Implementation of an agile mindset
o A set of management & technical practices that enable the
team to define a road map as it travels towards its goal

1. Communication practices
1. Listen
15
http://wikistudent.ws/Unisa
2. Prepare before you communicate (e.g. an agenda)
3. Someone should facilitate the activity
4. Face-to-face communication is best
5. Take notes and document decisions
6. Strive for collaboration
7. Stay focused, modularize your discussion
8. If something is unclear, draw a picture
9. Move on after you agree / disagree / if something is unclear
10. Negotiation works best when both parties win

• Prepare a set of guidelines that focus solely on facilitation:

o Understand the business domain
o Know who the stakeholders are and what goals each has
o Establish a defined requirements-gathering mechanism
o Create a method for recording requirements
o Establish a way to prioritize needs

• How should communication preparation manifest itself in the

early work that you do? What work products might result?
o Research the business domain that the software will address
o Understand the stakeholders who will specify requirements
o Develop a defined strategy for requirements gathering
o Understand the goals for each of the stakeholders
o Understand that negotiation will occur

• How does agile communication differ from traditional SE

communication? How is it similar?
o

• Why it is necessary to ‘move on’:

o Sometimes people can’t come to an agreement on some
project-related issue, so rather than iterating endlessly,
it is best to move on to achieve communication agility,
leaving the topic for later

2. Planning practices
1. Understand the scope of the project
2. Involve the customer in the planning activity
3. Recognize that planning is iterative
4. Estimate (effort, cost, task duration…) based on what you know
5. Consider risk as you define the plan (make contingency plans)
6. Be realistic (People make mistakes and don’t work all day)
7. Adjust granularity as you define the plan
8. Define how you intend to ensure quality (FTR, pair programming…)
9. Describe how you intend to accommodate change
10. Track the plan frequently and make adjustments as required

• What granularity means in the context of a project schedule:

16
http://wikistudent.ws/Unisa
o Granularity refers to the level of detail that is
introduced as a project plan is developed
o Fine granularity plan: detail, planned over a short time
o Coarse granularity plan: broad work tasks over long periods
o Granularity goes fine
coarse as the timeline moves on

3. Modeling practice
Analysis modeling
1. The information domain (data in-out flows & stores) of a problem
must be represented and understood
2. The functions that the software performs must be defined
3. The behavior of the software must be represented
4. The models that depict information, function, and behavior must
be partitioned to uncover detail in a layered fashion
5. The analysis task should move from essential information towards
implementation detail

• What three domains are considered during analysis modeling?

o Informational, functional, and behavioral domains

Design modeling
1. Design should be traceable to the analysis model
2. Always consider the architecture of the system to be built
3. Design of data is as NB as design of processing functions
4. Interfaces (internal & external) must be designed with care
5. User interface design should be tuned to the needs of the user
6. Components should be highly cohesive
7. Components should be loosely coupled
8. Design representations (models) should be easy to understand
9. The design should be developed iteratively, striving for greater
simplicity with each iteration

• Why models are important in SE work:

o Models help us gain a better understanding of the actual
entity to be built. Analysis models represent customer
requirements, and design models provide a concrete
specification for the construction of the software.

4. Construction practice
Coding principles and concepts
Preparation principles:
1. Understand the problem you’re trying to solve
2. Understand basic design principles and concepts
3. Pick a suitable programming language
4. Select a suitable programming environment
5. Create a set of unit tests for when your component code is done
Coding principles:
1. Constrain your algorithms by adhering to structured programming
2. Select data structures that will meet the needs of the design
3. Create interfaces that are consistent with the architecture
17
http://wikistudent.ws/Unisa
4. Keep conditional logic as simple as possible
5. Create nested loops in a way that makes them easily testable
6. Select meaningful variable names and follow coding standards
7. Write code that is self-documenting
8. The visual layout (new lines, indents…) should aid understanding

Validation principles:
1. Conduct a code walkthrough when appropriate
2. Perform unit tests and correct errors you’ve uncovered
3. Refactor the code
Testing principles
1. All tests should be traceable to customer requirements
2. Tests should be planned long before testing begins
3. Pareto principle: 80% of errors will be found in 20% of code
4. Testing should progress from ‘in the small’ to ‘in the large’
5. Exhaustive testing is not possible

• What is a successful test?

o One that has a high chance of finding an undiscovered error

5. Deployment
• Deployment encompasses three actions:
o Delivery
o Support
o Feedback
1. Customer expectations for the software must be managed
2. A complete delivery package should be assembled and tested
3. A support regime must be established before the software is
delivered
4. Appropriate instructional materials must be provided to users
5. Buggy software should be fixed first, delivered later

• Why feedback is important to the software team:

o Feedback provides the software team with important guidance
that results in modifications to the functions, features,
and approach taken for the next increment

18
http://wikistudent.ws/Unisa

Chapter 7 – Requirements engineering

Requirements engineering tasks
1. Inception
• Most projects begin when a business need is identified
• Stakeholders from the business community…
o define a business case for the idea
o identify the breadth & depth of the market
o do a rough feasibility analysis
o identify a working description of the project’s scope
• Software engineers ask a set of context-free questions to get a
basic understanding of the problem, people, and type of solution

• Feasibility analysis within the context of inception:

o Feasibility analysis identifies a working description of
the project’s scope and assesses whether or not that scope
can be achieved within the context of management and
technical constraints. It defines a business case for an
idea and identifies the breadth & depth of the market.

2. Elicitation
Why requirements elicitation is difficult:
• Problems of scope
o The system boundary is ill-defined
• Problems of understanding
o The customers are not completely sure what is needed
o They don’t know the capabilities & limitations of computers
o They don’t have a full understanding of the problem domain
o They have trouble communicating their needs
o They omit information that is believed to be obvious
o They specify requirements that are ambiguous or untestable
• Problems of volatility
o The requirements change over time
3. Elaboration
• The info from inception & elicitation is expanded & refined
• Driven by the creation and refinement of user scenarios that
describe how the user will interact with the system
• Each user scenario is parsed to extract analysis classes
• Attributes & methods of each analysis class are identified
• Relationships between classes are identified – UML diagrams
• End-result of elaboration: an analysis model that defines the
informational, functional, and behavioral domain of the problem

19
 http://wikistudent.ws/Unisa
4. Negotiation
• Possible conflicts:
o Customers may ask for more than can be achieved
o Different users may propose conflicting requirements
• Users must rank requirements and discuss conflicts in priority
• Risks associated with each requirement are analyzed
• Rough estimates of development effort are made and used to
assess the impact of each requirement on project costs and time
• Using an iterative approach, requirements are eliminated,
combined, and/or modified so that each party is satisfied
5. Specification
• A specification can be a written doc, models, prototype, etc…
• This is the final work product from the requirements engineer
• It describes the function, performance & constraints of a system
6. Validation
• Examine the specification to ensure that all requirements have
been stated unambiguously, with errors & omissions corrected
• Formal technical review = the primary validation mechanism
• The review team includes software engineers, customers, users…
7. Requirements management
• Activities that help the team identify, control and track
requirements & changes at any time as the project proceeds
• Requirements are identified, and traceability tables are made:

o Features traceability table

 Shows how requirements relate to important features
o Source traceability table
 Identifies the source of each requirement
o Dependency traceability table
 Indicates how requirements are related to one another
o Subsystem traceability table
 Categorizes requirements by the subsystems they govern
o Interface traceability table
 Shows how requirements relate to internal & external
system interfaces

1. Inception: Initiating the requirements engineering process

Identifying the stakeholders
• At inception, create a list of people who will contribute input
as requirements are elicited
• The initial list will grow as stakeholders are contacted
Recognizing multiple viewpoints
• There are different kinds of stakeholders, with different views
• As information from multiple viewpoints is collected, emerging
requirements may be inconsistent / conflict with one another
• All stakeholder info must be categorized in a way that will
allow decision-makers to choose a consistent set of requirements

20
 http://wikistudent.ws/Unisa
Working towards collaboration
• Stakeholders must collaborate among themselves
• The requirements engineer identifies commonality/conflict areas
Asking the first questions
• Questions asked at inception should be context-free:
o Who is behind the request for this work?
o Who will use the solution?
o What will be the economic benefit of a successful solution?
o Is there another source for the solution that you need?
o Who is paying for this work?
o Who can we contact in each customer group?
o Do you know of any other business that has solved this
problem successfully?
• These questions help identify stakeholders & project benefits
• The next set of questions enables the team to better understand
the problem and allows the customer to voice his perceptions:
o How would you characterize ‘good’ output?
o What problems will this solution address?
o Can you describe the business environment?
o Will special performance issues affect the solution?
• The final set of questions focuses on the effectiveness of the
communication activity itself:
o Are you the right person to answer these questions?
o Are my questions relevant to the problem that you have?
o Am I asking too many questions?
o Can anyone else provide additional information?
o Should I be asking you anything else?
• These questions help to break the ice & initiate communication
• The Q&A session should be used for the first encounter only and
then replaced by a requirements elicitation format

2. Eliciting requirements
Collaborative requirements gathering
• Basic guidelines for a collaborative requirements meeting:
o Meetings are conducted & attended by both software
engineers and customers (and other stakeholders)
o Rules for preparation and participation are established
o An agenda is suggested
o A ‘facilitator’ controls the meeting
o A ‘definition mechanism’ (work sheets / flip charts / chat
room / bulletin board / wall stickers) is used
o The goal is to identify the problem, propose elements of
the solution and a preliminary set of solution requirements
Quality function deployment
• QFD = a technique that translates the needs of the customer into
technical requirements for software
• Concentrates on maximizing customer satisfaction
• QFD identifies 3 types of requirements:

21
 http://wikistudent.ws/Unisa
o Normal requirements
• Reflect objectives stated for the system
• E.g. specific system functions, levels of performance
o Expected requirements
• Implicit to the system, and not stated explicitly
• E.g. ease of use and installation
o Exciting requirements
• Features that go beyond the customer’s expectations
• E.g. Extra features that are pleasing & unexpected
• Function deployment is used to determine the value of each
function that is required for the system
• Information deployment identifies both the data objects and
events that the system must consume and produce
• Task deployment examines the behavior of the system within the
context of its environment
• Value analysis is conducted to determine the relative priority
of requirements determined during each of the three deployments
• QFD uses interviews & observation, surveys, and examination of
historical data as raw data for requirements gathering
• Customer voice table = a table of requirements from this data
User scenarios
• As requirements are gathered, an overall vision of system
functions & features begins to materialize
• You must first understand how these functions & features will be
used by different classes of end-users before getting technical
• To achieve this developers & users can create a set of scenarios
(use cases) that identify a thread of usage for the system
Elicitation work products
• Info that can be produced as a result of requirements gathering:
o A statement of need and feasibility
o A bounded statement of scope for the system
o A list of stakeholders who participated in the elicitation
o A description of the system’s technical environment
o A list of requirements and each one’s domain constraints
o A set of usage scenarios
o Any prototypes developed to better define requirements

• Some problems that occur when requirements must be elicited from

three or four different customers:
o Problems of understanding, scope, and volatility
o Each customer has his own priorities and views which may
conflict with those of other customers

• What to do when eliciting requirements from a customer who is

too busy to meet:

22
http://wikistudent.ws/Unisa
o Write a memo outlining to the customer the objectives of
the system to be developed. Objectives should be explained
by the customer.
o The QFD approach uses interviews, surveys, historical data…
as raw data for gathering requirements, which can be
translated into a table of requirements: the customer voice
table, that is reviewed with the customer. Diagrams,
matrices, and evaluation methods are then used to extract
the expected requirements.

Developing use-cases
• Primary actors interact to achieve required system function and
derive the intended benefit from the system
• Secondary actors support the system so that primary actors can
do their work
• Questions that should be answered by a use-case:
o Who are the primary actor(s), secondary actor(s)?
o What are the actor’s goals?
o What preconditions should exist before the story begins?
o What main tasks / functions are performed by the actor?
o What exceptions might come up as the story is described?
o What variations in the actor’s interaction are possible?
o What system info will the actor acquire, produce / change?
o Will the actor have to inform the system about changes in
the external environment?
o What information does the actor desire from the system?
o Does the actor wish to be informed of unexpected changes?
• Use-cases can be further elaborated to provide more detail
• Use-cases can be assessed by stakeholders, and assigned priority

• A use-case for making a withdrawal at an ATM:

Use case: ATM withdrawal

Primary actor: Client
Goal in context: To withdraw cash from the ATM quickly and securely
Pre-conditions: The system has been programmed to recognize the
insertion of the bank card and input of a password.
Trigger: Bank card and password
Scenario:
1. User inserts bank card
2. User keys in password
3. User selects which account to draw cash from
4. User keys in the amount of cash
5. User collects cash
6. ATM: Checks if another transaction is required
7. ATM: Ejects bank card if no further transactions are required
8. ATM: Prints bank slip
Exceptions:
1. ATM out of order

23
 http://wikistudent.ws/Unisa
2. Incorrect password entered
3. Password not recognized after 3 attempts
4. ATM does not eject bank card at the end of the transaction
5. User takes a long time to make a selection / to enter password
Priority: Essential, must be implemented
When available: First increment
Frequency of use: As many times as required
Channel to actor: Via ATM control panel
Secondary actors: ATM machine, camera
Channels to secondary actors: ATM machine: computer networks. ATM
machine is independent of the location.
Camera installed for the safety of the client.
Open issues:
1. Should the client use biometrics instead of PIN numbers?
2. Should the ATM machine display client additional information?
3. What will happen if there is a power failure during transaction?
4. How many cameras are to be installed to allow proper
identification should a robbery occur?

Insert card

Enter password

Select account

ATM
Enter amount machine

Process
transaction

Dispense cash

Eject card

Print slip

24
 http://wikistudent.ws/Unisa
3. Elaboration: Building the analysis model
• The analysis model provides a description of the required
informational, functional, and behavioral domains for a system
• The analysis model is a snapshot of requirements at a given time
• As the analysis model evolves, some elements become stable,
while others may be more volatile, indicating that the customer
doesn’t yet fully understand requirements for the system
Elements of the analysis model
• Using different modes of representation forces you to consider
requirements from different viewpoints, which is better
• Generic elements common to most analysis models:
o Scenario-based elements
 Template-based use-cases
 Activity diagrams
o Class-based elements
 Class diagrams
o Behavioral elements
 State diagrams
o Flow-oriented elements
 Data / control flow models
Analysis patterns
• Definition of analysis patterns:
o Things that reoccur across all projects within a specific
application domain. They represent something that can be
reused (e.g. a class, function, behavior…)
• Two benefits that can be associated with analysis patterns:
o They speed up the development of abstract analysis models
o They facilitate the transformation of the analysis model
into a design model by suggesting design patterns
• Information about an analysis pattern is presented in a template
with these headings: Pattern name | Intent | Motivation | Forces
and context | Solution | Consequences | Design | Known uses |
Related patterns

• Why we say that the analysis model represents a snapshot of a

system in time:
o The intent of the analysis model is to provide a
description of the required informational, functional, and
behavioral domains for a computer-based system. The model
changes dynamically as software engineers learn more about
the system to be built and as stakeholders understand more
about what they really require. For that reason, the
analysis model is a snapshot of requirements at any time.

4. Negotiating requirements
• Activities for the beginning of each software process iteration:
1. Identification of the system / subsystem’s key stakeholders
2. Determination of the stakeholders’ “win conditions”

25
http://wikistudent.ws/Unisa
3. Negotiation of the stakeholders’ win conditions to reconcile
them into a set of win-win conditions for all concerned

• If you’ve convinced the customer to agree to every demand you

have, does that make you a master negotiator?
o There should be no winner or loser in a negotiating
situation. Both sides should win. Best negotiations strive
for a ‘win-win’ result, so if the customer feels he has
won, that makes you a master negotiator.

6. Validating requirements
Questions to ask when reviewing requirements:
• Is each requirement consistent with the overall objectives?
• Are all requirements specified at the right level of abstraction
• Is the requirement really necessary?
• Is each requirement bounded and unambiguous?
• Is a source (e.g. an individual) noted for each requirement?
• Do any requirements conflict with other requirements?
• Is each requirement achievable in the system’s environment?
• Is each requirement testable, once implemented?
• Does the requirements model reflect the system’s behavior?
• Has the requirements model been partitioned to progressively
expose more detailed information about the system?
• Have requirements patterns been used to simplify the model? Have
they all been validated? Are they consistent with requirements?

• Define ‘customer’ for IS developers, builders of computer-based

products, and system builders:

o The customer for IS developers is often another department

in the same company – often the ‘user department’
o The customer for builders of computer-based products is
typically the marketing department
o The customer for system builders may be an internal
department, marketing, or an outside entity

• Why many developers don’t pay enough attention to requirements

engineering, and circumstances where you can skip it:
o Software engineers want to begin building something, so
they sometimes give requirement analysis short shrift. In
addition, understanding the requirements of a problem is
difficult, since requirements change, can be contradictory,
and are often difficult to enunciate clearly. Hence,
software engineers want to get through this activity
quickly.

26
http://wikistudent.ws/Unisa
o If the problem is relatively small and reasonably well
understood, an abbreviated approach may be chosen. For more
complex problems with many requirements, every task defined
for comprehensive requirements engineering should be
performed rigorously. Requirements engineering builds a
bridge to design and construction and cannot be skipped.

Chapter 8 – Building the analysis model

Requirements analysis
• Result: specification of software’s operational characteristics
• Indicates software’s interface with other system elements
• Establishes constraints that software must meet
• Allows the software engineer to elaborate on basic requirements
established during earlier requirement engineering tasks
• Provides the software designer with a representation of info,
function, and behavior to be translated into designs
• The analysis model & requirements specification provide the
developer & customer with the means to assess quality
• Throughout analysis modeling, the main focus is on what, not how
Overall objective and philosophy
• The analysis model must achieve 3 primary objectives:
o Describe what the customer requires
o Establish a basis for the creation of a software design
o Define a set of requirements that can be validated later
• The analysis model bridges the gap between a system-level
description and a software design
Analysis rules of thumb
• The model should focus on requirements that are visible within
the problem / business domain & have a high level of abstraction
• Each element of the analysis model should add to an overall
understanding of software requirements and provide insight into
the information domain, function, and behavior of the system
• Delay consideration of infrastructure and other non-functional
models until design
• Minimize coupling throughout the system
• Make sure the analysis model provides value to all stakeholders
• Keep the model as simple as it can be
Domain analysis
• Analysis patterns often reoccur across many applications within
a specific business domain

27
http://wikistudent.ws/Unisa
• If these patterns are defined and categorized to allow reuse,
then creation of the analysis model is speeded up
• More important, the likelihood of applying reusable design
patterns and executable software components grows dramatically
• Software domain analysis = the identification, analysis, and
specification of common requirements from a specific application
domain, for reuse on multiple projects within that domain
• Goal of domain analysis: To find / create those analysis classes
/ common functions and features that are broadly applicable, so
that they may be reused
• Role of the domain analyst: to discover and define reusable
analysis patterns, analysis classes, and related info that may
be used by many people working on similar applications
• Key inputs for domain analysis:
o Technical literature
o Existing applications
o Customer surveys
o Expert advice
o Current / future requirements
• Key outputs for domain analysis:
o Class taxonomies
o Reuse standards
o Functional models
o Domain languages

• The purpose of domain analysis and how it is related to the

concept of requirements patterns:
o Domain analysis is an on-going SE activity that is not
connected to any one software project. The intent is to
find analysis patterns that are widely used within a
specific application domain and to identify a set of
objects and classes that characterize the domain.

• An analysis rule of thumb is that the model ‘should focus on

requirements that are visible within the problem or business
domain’. What types of requirements are not visible in these
domains? Provide a few examples.
o Many infrastructure requirements, e.g.
• Functions required to manage global data
• Functions required to implement network communication
• Functions required to implement a user interface

Analysis modeling approaches

• Describe the differences between structured and OO analysis
• Structured analysis
o Data is separate from the processes that transform the data
o Data objects are modeled to show attributes & relationships

28
http://wikistudent.ws/Unisa
o Processes are modeled in a manner that shows how they
transform data as data objects flow through the system: DFD
• Object-oriented analysis
o Focuses on the definition of classes and the manner in
which they collaborate with one another
• Elements of the analysis model:
o Class-based elements
 Class diagrams
 Analysis packages
 CRC models
 Collaboration diagrams
o Scenario-based elements
 Use-cases – text
 Use-case diagrams
 Activity diagrams
 Swim lane diagrams
o Flow-oriented elements
 Data flow diagrams
 Control-flow diagrams
 Processing narratives
o Behavioral elements
 State diagrams
 Sequence diagrams

• Is it possible to develop an effective analysis model without

developing all four of the above elements?
o Yes, although each element presents a different view and
provides the ability to see potential problems. In
addition, if all four elements are developed, the
transition to design is simplified.

• Is it possible to begin coding immediately after an analysis

model has been created?
o The analysis model will serve as the basis for design and
construction of the domain objects. It is possible to begin
coding after the objects and attributes are defined and
relationships are known. However, the design will suffer as
a result because explicit architectural design will not
have been considered; interfaces will have been developed
in a haphazard manner and global data structures will not
have been explicitly designed.

Data modeling concepts

• Analysis modeling often begins with data modeling
• The analyst defines: all data objects that are processed within
the system, the relationships between the data objects, and
other info that is pertinent to the relationships
Data objects

29
 http://wikistudent.ws/Unisa
• = a representation of composite information
• E.g. ‘dimensions’, which incorporates height, width, and depth
• A data object can be a thing (report), occurrence (phone call),
event (alarm), role (salesperson), organizational unit (sales
dept), place (warehouse), or a structure (file)
• The data object description incorporates the data object and all
of its attributes – there is no reference to operations
Data attributes
• They define properties of a data object and can be used to:
o Name an instance of the data object
o Describe the instance
o Make reference to another instance in another table
• One or more of the attributes must be defined as an ID (key)

Relationships
• Indicate how data objects are connected to one another
Cardinality and modality
• Cardinality = the no of occurrences of objects in a relationship
• Modality = 0 if there is no explicit need for the relationship
• Modality = 1 if an occurrence of the relationship is mandatory

Object-oriented analysis
• Tasks for OO:
1. Basic user requirements must be communicated between customer
& software engineer
2. Classes must be identified (with attributes & methods)
3. A class hierarchy is defined
4. Define object-to-object relationships (connections)
5. Object behavior must be modeled
6. 1 – 5 are reapplied iteratively until the model is complete

Scenario-based modeling
Writing use-cases
• Inception & elicitation provide the info needed to begin
• Requirements gathering mechanisms are used to
o Identify stakeholders
o Define the scope of the problem
o Specify overall operational goals
o Outline all known functional requirements
o Describe the objects that will be manipulated by the system
• Begin by listing functions / activities of a specific actor
• Primary scenarios don’t consider any alternative interactions
• Secondary scenarios answer these questions:
o Can the actor take some other action?
o What error conditions could occur?
o Might the actor encounter some other (external) behavior?
Developing an activity diagram
30
 http://wikistudent.ws/Unisa
• Supplements the use case with a graphical representation of the
flow of interaction within a specific scenario (flow chart!)
• The activity diagram adds additional detail not directly
mentioned (but implied) by the use case
• Rounded rectangles – imply a specific function
• Arrows – represent flow through the system
• Decision diamonds – depict a branching decision
• Solid horizontal lines – indicate parallel activities
Swimlane diagrams
• A variation of the activity diagram
• Additional info: indicates which actor / class is responsible
for the action described by an activity rectangle
• Responsibilities are represented as parallel segments that
divide the diagram vertically

Flow-oriented modeling
• The DFD can be used to complement UML diagrams
• The DFD takes an input-process-output view of a system
• The DFD is presented in a hierarchical fashion, with the first
data flow model (level 0 DFD) representing the system as a whole
Creating a data flow model
• The DFD enables you to develop models of the information domain
and functional domain at the same time
• Performing a grammatical parse on the processing narrative can
generate useful info about how to proceed
• As the DFD is refined into greater levels of detail, the analyst
performs an implicit functional decomposition of the system
• Refine the DFDs until each bubble is ‘single-minded’
Creating a control flow model
• Needed (in addition to the DFD) for applications that:
o are driven by events rather than data
o produce control information rather than reports / displays
o process info with heavy concern for time & performance
• An event / control item is implemented as a Boolean value /
discrete list of conditions (empty/full)
The control specification (CSPEC)
• Represents the behavior of the system in 2 different ways:
• State diagram
o A sequential specification of behavior
• Program activation table
o A combinatorial specification of behavior
• The CSPEC describes behavior, but not the inner workings of the
processes that are activated as a result of this behavior
The process specification (PSPEC)
• Used to describe all flow model processes that appear at the
final level of refinement
• The content can include:
31
http://wikistudent.ws/Unisa
o Narrative text
o Program design language (PDL) description of the algorithm
o Mathematical equations, tables, diagrams, charts…
• By providing a PSPEC to accompany each bubble in the flow model,
you crate a ‘mini-spec’ that can serve as a guide for design of
the software component that will implement the process

Class-based modeling
Identifying analysis classes
• Examine the problem statement and perform a grammatical parse on
the use-cases or processing narratives developed for the system
• 6 selection characteristics when considering potential classes:
1. Retained information
o Must class info be remembered for the system to function?
2. Needed services
o Are there operations that can change the attribute values?
3. Multiple attributes
o A 1-attribute class should be an attribute of another class
4. Common attributes
o Can attributes be applied to all instances of the class?
5. Common operations
o Can operations be applied to all instances of the class?
6. Essential requirements
o External entities that produce / consume info essential to
the system’s operation will always be defined as classes
• A potential class should satisfy all the above characteristics
Specifying attributes
• Study a use-case and select ‘things’ that ‘belong’ to the class
• Ask: What data items define this class in the problem context?
Defining operations
1. Operations that manipulate data (E.g. add, delete, select…)
2. Operations that perform a computation
3. Operations that inquire about the object’s state
4. Operations that monitor an object for the occurrence of an event
• The grammatical parse is again studied and verbs are isolated
CRC modeling

Class: FloorPlan
(Description)
Responsibility: Collaborator:
Defines floor plan name/type
Incorporates walls, doors and windows Wall
Shows position of video cameras Camera
…

Classes
• Entity classes (model / business classes)
o Come directly from the problem statement (e.g. FloorPlan)

32
 http://wikistudent.ws/Unisa
o Typically represent things to be stored in a database
o Persist throughout the duration of the application
• Boundary classes
o Used to create the interface (e.g. interactive screen)
o Manage the way entity objects are presented to the user
• Controller classes
o Manage a ‘unit of work’ from start to finish:
 The creation / update of entity objects
 The instantiation of boundary objects
 Complex communication between sets of objects
 Validation of data communicated between objects
o Generally not considered until design has begun
Responsibilities (attributes & operations)
• Guidelines for allocating responsibilities:
1. System intelligence should be distributed across classes
o If ‘dumb’ classes are servants to ‘smart’ classes
 It concentrates all intelligence within a few classes,
making changes more difficult
 It tends to require more classes, i.e. more effort
o If a class has a very long list of responsibilities, this
is an indication of a concentration of intelligence
o In addition, the responsibilities should exhibit the same
level of abstraction
2. Each responsibility should be stated as generally as possible
o So that they can apply to all subclasses
3. Information & related behavior should reside in the same class
o This achieves encapsulation – a cohesive unit
4. Information about one thing should be localized with a single
class, not distributed across multiple classes
5. Share responsibilities among related classes, when appropriate
o E.g. ‘arms’ and ‘legs’ collaborate with each other
Collaborators
• Collaborations identify relationships between classes
• First see whether a class can fulfill each responsibility itself
• There are three different generic relationships between classes:
o Is-part-of relationship
 Classes that are part of an aggregate class
o Has-knowledge-of relationship
 When one class must acquire info from another class
o Depends-upon relationship
 Other dependencies, e.g. ‘head’ connected to ‘body’
• When a complete CRC model has been developed it can be reviewed:
1. All participants in the review are given a subset of the cards
2. All use-case scenarios should be organized into categories
3. The review leader reads the use-case deliberately. As he comes
to a named class, he passes a token to the person holding the
corresponding class index card.

33
 http://wikistudent.ws/Unisa
4. When the token is passed, the holder of the class card must
describe the responsibilities noted on the card
5. If the responsibilities and collaborations cannot accommodate
the use-case, modifications are made to the cards
Associations and dependencies
• The difference between associations and dependencies:
• An association defines a relationship between classes
• A dependency relationship exists with clients & servers
• Dependencies are defined by a stereotype
• Stereotype = a UML extensibility mechanism that allows you to
define a special modeling element with custom-defined semantics
• In UML stereotypes are represented in <<double angle brackets>>
Analysis packages
• What is an analysis package and how might it be used?
o A package is used to assemble a collection of related
classes and other elements of the analysis model

Creating a behavioral model

• The behavioral model indicates how software will respond to
external events or stimuli
• To create the model, the analyst must perform these steps:
o Evaluate all use-cases to fully understand the sequence of
interaction within the system
o Identify events that drive the interaction sequence and
understand how these events relate to specific classes
o Create a sequence for each use-case
o Build a state diagram for the system
o Review the behavioral model to check accuracy & consistency
Identifying events with the use case
• An event occurs whenever the system & actor exchange information
• Note the info exchanged, and list any conditions / constraints
• After identifying all events, allocate them to objects:
o Objects can generate events
o Objects can recognize events
State representations
• Two different characterizations of states must be considered:
o The state of each class as the system performs its function
o The state of the system as observed from the outside as the
system performs its function
• The state of a class takes on passive & active characteristics:
o Passive state = current status of an object’s attributes
o Active state = current status of the object as it undergoes
a continuing transformation / processing
1. State diagrams for analysis classes
o Shows how a class changes state based on external events
o In addition to specifying the event that causes the
transition to occur, you can specify a guard and an action

34
http://wikistudent.ws/Unisa
o Guard = a Boolean condition that must be satisfied in order
for the transition to occur
o Action = something that occurs concurrently with the state
transition or as a consequence of it
2. Sequence diagrams
o Shows the behavior of the software as a function of time
o Shows how events cause transitions from object to object
o After developing a complete sequence diagram, all of the
events that cause transitions between system objects can be
collated into a set of input events and output events

• How a state diagram for analysis classes differs from the state
diagrams presented for the complete system:
o The state diagrams depicting the state behavior of a system
represent externally observable events and states.
o State diagrams for analysis classes are a component of the
behavioral model and represent the states associated with a
specific analysis class.

Chapter 9 – Design engineering

Design within the context of software engineering
• Each element of the analysis model provides information
necessary to create the 4 design models required:
• Data/class design
o Transforms analysis-class models into design class
realizations and data structures
• Architectural design
o Defines the relationship between major structural elements
of the software, the architectural styles and design
patterns that can be used to achieve the requirements
• Interface design
o Describes how the software communicates with systems that
interoperate with it, and with humans who use it
• Component-level design
o Transforms structural elements of the software architecture
into a procedural description of software components

• If a software design is not a program, then what is it?

o The intent of software design is to apply a set of
principles, concepts, and practices that lead to the
development of a high quality system. The goal of design is
to create a model of software that will implement all
customer requirements correctly and bring delight to users.

• Do you design software when you ‘write’ a program? What makes

software design different from coding?
o Yes, but the design is conducted implicitly – often in a
haphazard manner. During design (in a software engineering
35
http://wikistudent.ws/Unisa
context) we develop representations (models) of programs –
not the programs themselves.

Design process and design quality

• Three characteristics that serve as a guide for the evaluation
of good design:
o The design must implement all of the explicit requirements
contained in the analysis model, and must accommodate all
of the implicit requirements desired by the customer
o The design must be a readable, understandable guide for
those who generate code and for those who test the software
o The design should provide a complete picture of the
software, addressing the data, functional, and behavioral
domains from an implementation perspective
• Quality guidelines
o A design should exhibit an architecture that
 Has been created using architectural styles / patterns
 Has components with good design characteristics
 Can be implemented in an evolutionary fashion
o A design should be modular
o A design should contain distinct representations of data,
architecture, interfaces, and components
o Data structures should be appropriate for the classes
o Components should be functionally independent
o Interfaces should reduce complexity of connections between
components and with the external environment
o Design using a repeatable method that is driven by
information obtained during requirements analysis
o Use a notation that effectively communicates its meaning
• Quality attributes
o Functionality
o Usability
o Reliability
o Performance
o Supportability

• How we assess the quality of a software design:

o Quality is assessed by conducting a series of FTRs and then
assessing the design against a set of quality criteria
o Members of the FTR meeting:
 Review leader (sets an agenda)
 Recorder (takes notes)
 Producer (has his work reviewed)

Design concepts
Abstraction
• At the highest level of abstraction, a solution is stated in
broad terms using the language of the problem environment
• At lower levels of abstraction more details are provided

36
 http://wikistudent.ws/Unisa
• Procedural abstraction
o Instructions that have a specific and limited function
o E.g. ‘Open’ implies a long sequence of procedural steps
• Data abstraction
o A named collection of data that describes a data object
o E.g. ‘Door’ encompasses attributes like type, dimension…
Architecture
• Describe software architecture in your own words:
o The overall structure of the program components, how they
interact, and the structure of the data that they use.
Architecture is also about the ways in which that structure
provides conceptual integrity for a system.
• The architecture serves as a framework from which more detailed
design activities are conducted
• The architectural design can be represented using these models:
o Structural models
 Represent architecture as a collection of components
o Framework models
 Identify repeatable architectural design frameworks
that are encountered in similar types of applications
o Dynamic models
 Address the behavioral aspects of the architecture,
indicating how events can change the structure
o Process models
 Focus on the design of the business or technical
process that the system must accommodate
o Functional models
 Represent the functional hierarchy of a system
Patterns
• Describe design structures that solve particular design problems
within specific contexts
• The intent of each design pattern is to provide a description
that enables a designer to determine
o Whether the pattern is applicable to the current work
o Whether the pattern can be reused
o Whether the pattern can serve as a guide for developing a
similar, but functionally or structurally different pattern
Modularity
• The effort to develop an individual software module does
decrease as the total number of modules increases
• However, as the number of modules grows, the effort associated
with integrating the modules also grows
• Reasons for modularizing a design:
o Development can be more easily planned
o Software increments can be defined & delivered
o Changes can be more easily accommodated
o Testing & debugging can be conducted more efficiently
o Long-term maintenance won’t have serious side effects

37
 http://wikistudent.ws/Unisa
Information hiding
• Details of data structures… are hidden behind a module interface
• Modules communicate with each other only the info necessary to
achieve a software function
• Benefit: inadvertent errors introduced during modification are
less likely to propagate to other locations within the software
Functional independence
• Modules have few functions & interactions with other modules
• This makes them easier to maintain and test because error
propagation is reduced, and reuse is possible
• Independence is assessed using two qualitative criteria:
o Cohesion
 Indication of a module’s relative functional strength
o Coupling
 Indication of the interdependence among modules
Refinement
• You develop a hierarchy by decomposing macroscopic functions
until reaching programming language statements
• Refinement is actually a process of elaboration because you
provide more and more detail with each successive refinement
• Abstraction and refinement are complementary concepts:
o Abstraction enables a designer to specify procedure and
data and yet suppress low-level details
o Stepwise Refinement helps the designer to reveal low-level
details as design progresses
Refactoring
• Refactoring is a reorganization technique that simplifies the
design of a component without changing its function / behavior
• When software is refactored, the existing design is examined for
redundancy, unused design elements, inefficient algorithms, etc.
Design classes
• Analysis classes represent objects, while design classes present
more technical detail as a guide for implementation
• The design classes must
o Refine the analysis classes by providing design detail that
will enable the classes to be implemented
o Include new classes to implement a software infrastructure
• Five different types of design classes:
o User interface classes (E.g. elements of a metaphor)
o Business domain classes (refinements of analysis classes)
o Process classes (implement low-level business abstractions)
o Persistent classes (represent data stores)
o System classes (functions that enable the system to operate
& communicate within its computing environment & the world)
• Four characteristics of a well-formed design class:
o Complete and sufficient (encapsulate all methods necessary
and nothing more)
o Primitiveness (methods should accomplish one service)
38
http://wikistudent.ws/Unisa
o High cohesion
o Low coupling

The design model

• Two dimensions of the design model:
o Process dimension
• Indicates the evolution of the design model as design
tasks are executed as part of the software process
o Abstraction dimension
• Represents the level of detail as each element of the
analysis model is transformed into a design equivalent
• The elements of the design model use many of the same UML
diagrams that were used in the analysis model, but
o These diagrams are refined and elaborated
o More implementation-specific detail is provided
o Architectural structure and style are emphasized
o Interfaces between components are emphasized

Data design elements

• Data design creates a model of data that is represented at a
high level of abstraction (the user’s view of data)
• It is then refined into progressively more implementation-
specific representations that can be processed by the system
• At the program component level
o Design of data structures & associated algorithms
• At the application level
o Translation of a data model into a database
• At the business level
o Data reorganized into a data warehouse enables data mining
Architectural design elements
• The architectural model is derived from three sources:
o Information about the application domain
o Specific analysis model elements, like DFDs, their
relationships and collaborations for the problem
o The availability of architectural patterns and styles
Interface design elements
• These elements tell how information flows into and out of the
system and how it is communicated among the components
• Three important elements of interface design:
o The user interface
o External interfaces to other systems
• Collect this info during requirements engineering
• Incorporate error checking and security features
o Internal interfaces between various design components
• Design realizations of analysis classes show messaging
• Each message must be able to perform the info transfer
Component-level design elements
39
 http://wikistudent.ws/Unisa
• Component-level design fully describes the internal detail of
each software component
• Component-level design defines
o Data structures for all local data objects
o Algorithmic detail for all processing
o An interface that allows access to all component operations
• The design details of a component can be modeled at many
different levels of abstraction:
o Activity diagram – to represent processing logic
o Pseudo code – to represent detailed procedural flow
Deployment-level design elements
• Indicate how software functionality and subsystems will be
allocated within the physical computing environment
• Deployment diagrams show computing elements, with subsystems
o Descriptor form
• No explicit indication of configuration details
o Instance form
• Later stages of design – with details

Pattern-based software design

Describing a design pattern
Design pattern template:
Pattern name Describes the Structure The classes to
essence of the implement the
pattern pattern
Intent What the pattern Participants The
does responsibilities
of the classes
Also known as Synonyms Collaborations How the
participants
collaborate
Motivation An example of the Consequences Trade-offs to
problem consider
Applicability Specific design Related patterns Cross-references
situations where related design
it is applicable patterns
• A description of the design pattern may also consider a set of
design forces, that describe nonfunctional requirements
• Forces define the constraints that restrict the implementation
• Pattern characteristics indicate the design attributes that may
be adjusted to allow the pattern to accommodate various problems
• Guidance associated with the use of a design pattern provides an
indication of the ramifications of design decisions
Using patterns in design
• Architectural patterns
o Define the overall structure of the software
o Indicate relationships among subsystems & components
• Design patterns

40
 http://wikistudent.ws/Unisa
o Address a specific element of the design
o E.g. an aggregation of components to solve a problem,
relationships among components, communication mechanisms…
• Idioms (coding patterns)
o Implement an algorithmic element of a component, a specific
interface protocol, or a communication mechanism
• Each of these pattern types differs in the
o Level of abstraction with which it is represented
o Degree to which it provides guidance for construction
Frameworks
• Definition: an implementation-specific skeletal infrastructure
• The skeleton has a collection of ‘plug points’ that enable it to
be adapted to a specific problem domain
• The plug points enable a designer to integrate problem specific
classes or functionality within the skeleton
• OO context: a framework is a collection of cooperating classes
• To be most effective, frameworks are applied with no changes
• Additional design elements may be added, but only via the plug
points that allow the designer to flesh out the skeleton
Chapter 10 – Creating an architectural design
Software architecture
What is architecture?
• Definition: The structure of the system, which comprises:
o Software components,
o the externally visible properties of those components
o and the relationships among them
• Architecture is a representation that lets a software engineer:
o Analyze the effectiveness of the design in meeting its
stated requirements
o Consider architectural alternatives at a stage when making
design changes is still relatively easy
o Reduce the risks associated with constructing software
• The definition emphasizes the role of ‘software components’ in
any architectural representation
• A software component can be a program module / OO class /
databases / middleware
• Architecture design considers two levels of the design pyramid:
o Data design
• Class definitions in OO systems
o Architectural design
• Focuses on the representation of the structure of
software components, their properties, & interactions
Why is architecture important?
1. Enables communication between all stakeholders
2. Highlights early design decisions that will have a profound
impact on all SE work that follows

41
http://wikistudent.ws/Unisa
3. Constitutes a relatively small, graspable model of how the
system is structured and how its components work together

Data design
• Data design translates data objects defined as part of the
analysis model into data structures at the software component
level and a database architecture at the application level
Data design at the architectural level
• Data mining techniques / KDB (knowledge discovery in databases)
navigate through existing databases to extract appropriate info
• Data mining is difficult in an existing database environment, so
a data warehouse adds an additional layer to the architecture
• Data warehouse = a separate data environment not directly
integrated with day-to-day applications that encompasses all
data used by a business
Data design at the component level
• Focuses on the representation of data structures that are
directly accessed by one or more software components
• Principles applicable to data design:
o The systematic analysis principles applied to function &
behavior should also be applied to data
o All data structures and the operations to be performed on
each should be identified
o Establish a mechanism for defining the content of each data
object and the data & operations applied to it
o Leave low-level data design decisions for later
o Only the modules that use the data directly should know the
representation of the data structure
o A library of useful data structures and the operations that
may be applied to them should be developed
o A software design and programming language should support
the specification and realization of abstract data types

Architectural styles and patterns

• Architectural styles describe a system category encompassing:
o A set of components (e.g. database, computational modules)
o A set of connectors that enable ‘communication,
coordination, and cooperation’ among components
o Constraints for how components can be integrated to form
the system
o Semantic models that let a designer understand the overall
system properties by analyzing the properties of its parts
• An architectural style is a transformation imposed on the design
of an entire system & establishes a structure for all components
• An architectural pattern also imposes a transformation on the
design of an architecture, but it differs from a style:
o The scope is less broad, focusing on one aspect of the
architecture rather than the architecture in its entirety

42
 http://wikistudent.ws/Unisa
o A pattern imposes a rule on the architecture, describing
how the software will handle an aspect of its functionality
o Architectural patterns tend to address specific behavioral
issues within the context of the architecture
Taxonomy of architectural styles
• Data-centered architecture
o A data store resides at the centre of this architecture and
is accessed frequently by other components that modify it
o Integrability: components can be changed & new ones added
to the architecture without concern about other clients
o Client components independently execute processes
• Data-flow architectures
o When input data are to be transformed into output data
o Pipe & filter structure: filters are connected by pipes
that transmit data from one component to the next
o If the data flow degenerates into a single line of
transforms, it is termed batch sequential
• Call and return architecture
o Program structure that is easy to modify & scale
 Main program/subprogram architecture
• Control hierarchy: a main program invokes program
components, which in turn may invoke still others
 Remote procedure call architecture
• The components of a main program / subprogram
architecture are distributed on a network
• OO architecture
o The components of a system encapsulate data and the
operations that must be applied to manipulate the data
o Message passing to accomplish communication & coordination
• Layered architecture
o Different layers, each accomplishing operations that
progressively become closer to the machine instruction set
 Outer layer: components service UI operations
 Intermediate layers: provide utility services and
application software functions
 Inner layer: components perform OS interfacing
Architectural patterns
• Concurrency
o Many applications must handle multiple tasks in a manner
that simulates parallelism
o Ways to handle concurrency:
 Use an OS process management pattern that provides
built-in OS features that allow concurrent execution
 Define a task scheduler at the application level
• Persistence
o A DBMS pattern applies storage & retrieval capability
o An application level persistence pattern builds persistence
features into the application architecture

43
 http://wikistudent.ws/Unisa
• Distribution
o Addresses the manner in which systems / components
communicate with one another in a distributed environment
o There are two elements to this problem:
 The way in which entities connect to one another
 The nature of the communication that occurs
o A common architectural pattern established to address the
distribution problem is the broker pattern (E.g. CORBA)
Organization and refinement
• Control
o How is control managed within the architecture?
o Does a distinct control hierarchy exist?
o What is the role of components within the control hierarchy?
o How do components transfer control within the system?
o How is control shared among components?
o What is the control topology?
o Is control synchronized / asynchronous?
• Data
o How are data communicated between components?
o Is the flow of data continuous/ sporadic?
o What is the mode of data transfer?
o Do data components exist and what is their role?
o How do functional components interact with data components?
o Are data components passive / active?
o How do data and control interact within the system?

Chapter 13 – Testing strategies

A strategic approach to software testing
• A template for software testing should be defined
• Characteristics of testing strategies:
o A software team should conduct effective formal technical
reviews to eliminate errors before testing commences
o Testing begins at the component level and works ‘outward’
towards the integration of the entire system
o Different testing techniques are appropriate at different
points in time
o Testing is conducted by the developer of the software and
(for large projects) an independent test group
o Testing and debugging are different activities, but
debugging must be accommodated in any testing strategy
• Low-level tests verify small source code segments
• High-level tests validate major system functions
Verification and validation
• The difference between verification and validation:
• Verification = ensures that software correctly implements a
specific function (Are we building the product right?)

44
 http://wikistudent.ws/Unisa
• Validation = ensures that the software is traceable to customer
requirements (Are we building the right product?)
• V&V encompasses a wide array of SQA activities including: formal
technical reviews, performance monitoring, simulation,
feasibility study, documentation review, algorithm analysis,
development testing, usability testing, installation testing…
Organizing for software testing
• The developer must test the individual units of the program
• The developer also conducts integration testing
• An independent test group becomes involved only after the
software architecture is complete
• An ITG removes the conflict of interest that may be present
• The developer and ITG work closely throughout the project so
that the developer can correct errors that are uncovered
• The ITG is part of the software development project team in the
sense that it becomes involved during analysis & design and
stays involved throughout a large project

• Some problems that might be associated with the creation of an

independent test group. (Are an ITG and an SQA group made up of
the same people?)

o The most common problem in the creation of an ITG is

getting and keeping good people
o Hostility between the ITG and the SE group can arise
o The ITG may get involved in a project too late, when a
thorough job of test planning & execution can’t be done
o An ITG and an SQA group are not necessarily the same
 The ITG focuses solely on testing
 The SQA group considers all aspects of QA

A software testing strategy for conventional software architectures

• A software testing strategy may be viewed as a spiral:
o Unit testing (Code)
 Concentrates on each unit
o Integration testing (Design)
 Focuses on design & construction of the architecture
o Validation testing (Requirements)
 Requirements are validated against the software
o System testing (System engineering)
 The system and other elements are tested as a whole

• Why is it not always possible to develop a strategy for testing

software that uses the above sequence of steps? What possible
complications might arise for embedded systems?
o The complexity of a test environment for unit testing (i.e.
complicated drivers & stubs) may not justify the benefit

45
http://wikistudent.ws/Unisa
o Integration testing is complicated by the scheduled
availability of unit-tested modules (especially when such
modules fall behind schedule)
o For embedded systems, validation testing cannot be
adequately conducted outside of the target hardware
configuration, so validation & system testing are combined

A software testing strategy for OO architectures

• ‘Testing in the small’
‘testing in the large’
• Instead of units, classes are tested
• As classes are integrated into an OO architecture, a series of
regression tests are run to uncover errors due to
o Communication & collaboration between classes
o Side effects caused by the addition of new classes
• Finally, the system as a whole is tested
Criteria for completion of testing
• Use statistical modeling and software reliability theory to get
models of software failures as a function of execution time
• By collecting metrics during software testing and making use of
existing software reliability models, it is possible to develop
meaningful guidelines for knowing when testing can stop

Strategic issues
• Guidelines that lead to a successful testing strategy:
o Specify product requirements long before testing commences
o State testing objectives explicitly
o Understand the users and give a profile for each category
o A testing plan should emphasize ‘rapid cycle testing’
o Build ‘robust’ software that is designed to test itself
o Use formal technical reviews as a filter beforehand
o Conduct FTRs to assess the test strategy and test cases
o Develop a continuous improvement approach for testing

Test strategies for conventional software

Unit testing
• Tests important control paths and focuses on the internal
processing logic and data structures within a component
• Can be conducted in parallel for multiple components
Unit test considerations:
• Tests that occur as part of unit tests:
o The module interface is tested to ensure that information
properly flows into & out of the program unit under test
o Local data structures are examined to ensure that data
stored temporarily maintains its integrity
o All independent paths are exercised to ensure that all
statements in a module have been executed at least once
o Boundary conditions are tested
o All error handling paths are tested
46
http://wikistudent.ws/Unisa
• Some common errors found during unit testing:
o Misunderstood / incorrect arithmetic precedence
o Mixed mode operations
o Incorrect initialization
o Precision inaccuracy
o Incorrect symbolic representation of an expression
• Test cases should uncover errors such as:
o Comparison of different data types
o Incorrect logical operators / precedence
o Expectation of equality with precision errors
o Incorrect comparison of variables
o Improper / nonexistent loop termination
o Failure to exit when divergent iteration is encountered
o Improperly modified loop variables
• Boundary testing is one of the most important unit test tasks
• Potential errors to be tested when error handling is evaluated:
o Error description is unintelligible
o Error noted does not correspond to error encountered
o Error causes OS intervention prior to error handling
o Exception-condition processing is incorrect
o Error description doesn’t provide enough info to assist
Unit test procedures:
• Unit testing is normally considered as an adjunct to coding
• The design of unit tests can be performed before coding begins
or after source code has been generated
• Each test case should be coupled with a set of expected results
• Because a component is not a stand-alone program, driver and/or
stub software must be developed for each unit test
o A driver is a main program that accepts test case data
o Stubs serve to replace modules subordinate to the component
• Unit testing is simplified when a component has high cohesion

• Why a highly coupled module is difficult to unit test:

o A highly coupled module interacts with other modules, data
and other system elements, so its function is often
dependent on the operation of these coupled elements
o In order to unit-test such a module thoroughly, the
function of the coupled elements must be simulated in some
manner, which can be difficult and time-consuming

• Is unit testing possible or even desirable in all circumstances?

o No, if a module has 3 or 4 subordinates that supply data
essential to a meaningful evaluation of the module, it may
not be possible to conduct a unit test without ‘clustering’
all of the modules as a unit

Integration testing
• Problems that can occur when you integrate modules together:

47
http://wikistudent.ws/Unisa
o Data can be lost across an interface
o One module can have adverse affects on others
o Individually acceptable imprecision may be magnified
• Integration testing uncovers errors associated with interfacing
• The program is constructed and tested in small increments, where
errors are easier to isolate and correct
1. Top-down integration
• Work from the main program down through the control hierarchy
• Modules subordinate to the main control module are incorporated
into the structure in either a depth-first or breadth-first way:
o Depth-first integration
 Integrates all components on a major control path
 A complete function may be implemented & demonstrated
o Breadth-first integration
 Incorporates all components at the same level
• Steps for the integration process:
1) The main control module is used as a test driver, and stubs
are substituted for all components directly underneath
2) Stubs are replaced one at a time with actual components
3) Tests are conducted as each component is integrated
4) On completion of each set of tests, another stub is
replaced with the real component
5) Regression testing may be conducted to ensure that new
errors have not been introduced
• Verifies major control / decision points early in testing
• In a well-factored program structure, decision making occurs at
upper levels in the hierarchy and is therefore encountered first
• Problems encountered with top-down testing:
o When processing at low levels in the hierarchy is required
to adequately test upper levels, you have 3 choices:
 Delay many tests until stubs are replaced with modules
• Difficult to determine the cause of errors
 Develop stubs that simulate the actual module
• Can lead to overhead as stubs become more complex
 Do a bottom-up integration
2. Bottom-up integration
• Begins with atomic modules at the lowest levels in the program
• No stubs because subordinate components are always available
• Implementation steps:
1) Low-level components are combined into clusters that
perform a specific software sub-function
2) A driver is written to coordinate test case input & output
3) The cluster is tested
4) Drivers are removed and clusters are combined moving upward
in the program structure
3. Regression testing
• When a new module is integrated, there are changes which may
cause problems with functions that previously worked
48
http://wikistudent.ws/Unisa
• Regression testing = the re-execution of some subset of tests
that have already been conducted to ensure that changes have not
propagated unintended side effects
• Regression testing may be conducted
o Manually
 By re-executing a subset of all test cases
o Automatically
 With capture/playback tools that let you capture test
cases & results for subsequent playback & comparison
• The regression test suite has 3 different classes of test cases:
o Tests that will exercise all software functions
o Additional tests that focus on software functions that are
likely to be affected by the change
o Tests that focus on the changed software components
• Because the number of regression tests can grow quite large,
they should only address a few errors in each major function
4. Smoke testing
• Designed as a pacing mechanism for time-critical projects,
allowing the team to assess its project on a frequent basis
• Encompasses these activities:
1) Software components that have been translated into code are
integrated into a ‘build’ (includes data files, libraries…)
2) A series of tests is designed to expose errors that will
keep the build from properly performing its function
3) The build is integrated with other builds and the entire
product is smoke tested daily
• Benefits:
o Integration risk is minimized
o The quality of the end-product is improved
o Error diagnosis and correction are simplified
o Progress is easier to assess
Strategic options
• Disadvantage of top-down approach: the need for stubs
• Disadvantage of bottom-up approach: the program as an entity
doesn’t exist until the last module is added
• Sandwich testing = a combined approach that uses top-down tests
for upper levels, and bottom-up tests for subordinate levels
• During integration testing, you should identify critical modules
• Characteristics of a critical module:
o Addresses several software requirements
o Has a high level of control (i.e. high in the structure)
o Is complex / error prone
o Has definite performance requirements
• Critical modules should be tested as early as possible
• Regression tests should focus on critical module functions
Integration test documentation
• An overall plan for software integration and a description of
specific tests are documented in a test specification
49
http://wikistudent.ws/Unisa
• This document contains a
o Test plan (with an integration strategy)
o Test procedure (with testing details)
• Testing is divided into phases and builds that address specific
functional and behavioral characteristics of the software
• Criteria applied for all test phases:
o Interface integrity
o Functional validity
o Information content
o Performance
• The history of actual test results, problems, or peculiarities
is recorded in a test report, added to the test specification

Test strategies for OO software

Unit testing in the OO context
• An encapsulated class is usually the focus of unit testing
• Operations within the class are the smallest testable units
• We can no longer test a single operation in isolation, but
rather as part of a class
Integration testing in the OO context
• Thread-based testing
o Integrates the set of classes required to respond to one
input / event for the system
o Each thread is integrated and tested individually
o Regression testing, to ensure that no side effects occur
• Use-based testing
o First test those classes (independent classes) that use
very few server classes
o Then test the next layer of classes (dependent classes)
which use the independent classes
• The use of drivers & stubs also changes with OO testing
• Drivers can be used to test operations at the lowest level and
for the testing of whole groups of classes
• A driver can also be used to replace the user interface so that
you can test the system functionality before having an interface
• Stubs can be used when collaboration between classes is required
but one or more of those classes has not yet been implemented
• Cluster testing is a step in integration testing of OO software:
o A cluster of collaborating classes (from CRC) is tested to
try uncover errors in the collaborations

Validation testing
• The software requirements specification is a document that
describes all user-visible attributes of the software
• The specification contains a section called validation criteria
with info that forms the basis for a validation testing approach
Validation test criteria
• A test plan outlines the classes of tests to be conducted
50
 http://wikistudent.ws/Unisa
• A test procedure defines specific test cases
• Both plan & procedure are designed to ensure that
o All functional requirements are satisfied
o All behavioral characteristics are achieved
o All performance requirements are attained
o Documentation is correct
o Usability and other requirements are met (compatibility…)
• After each validation test one of two possible conditions exist:
o The function / performance characteristic is accepted
o A deviation from specification is uncovered and a
deficiency list is created
Configuration review (audit)
• Purpose: ensures that all elements of the software configuration
o Have been properly developed
o Are cataloged
o Have the necessary detail to bolster the support phase
Alpha and beta testing
• Alpha testing
o Conducted at the developer’s site by end-users
o The software is used in a natural setting and the developer
looks over the shoulder of users and records problems
o Conducted in a controlled environment
• Beta testing
o Conducted at end-user sites
o The developer is generally not present
o The test is a ‘live’ application of the software in an
environment that can’t be controlled by the developer
o The end-user records all problems and reports them

• Who should perform the validation test – the software developer

or the software user, and why?
o The software user, because you want the user to say that
the software performs to their expectations

System testing
• System testing = a series of different tests that verify element
integration and functionality
Recovery testing
• Recovery testing forces the software to fail in a variety of
ways and verifies that recovery is properly performed
• Automatic recovery: evaluate re-initialization, checkpointing
mechanisms, data recovery, and restart for correctness
• Manual recovery: evaluate mean-time-to-repair (MTTR)
Security testing
• Verifies the protection mechanisms built into the system
• The tester plays the role of the hacker / spy
Stress testing
• Executes a system with abnormal quantity, frequency, or volume

51
 http://wikistudent.ws/Unisa
• Sensitivity testing: Sometimes a very small range of data may
cause extreme processing / performance degradation
• Sensitivity testing uncovers data combinations with valid input
classes that may cause instability / improper processing
Performance testing
• Tests the run-time performance
• Occurs throughout all steps in the testing process, but shows
true system performance only when all elements are integrated
• Often coupled with stress testing and usually requires both
hardware & software instrumentation (i.e. measuring resource
utilization, like processor cycles)
• External instrumentation can monitor execution intervals, log
events, and sample machine states on a regular basis
• By instrumenting a system, the tester can uncover situations
that lead to degradation and possible system failure

The art of debugging

• Debugging occurs as a consequence of successful testing
• When a test case uncovers an error, debugging removes it
The debugging process
• Debugging begins with the execution of a test case
• Results are assessed and a lack of correspondence between
expected & actual performance is encountered
• Debugging will always have one of two outcomes:
o The cause will be found and corrected
o The cause will not be found
• Why debugging is so difficult:
o The symptom and the cause may be geographically remote
o The symptom may disappear when another error is corrected
o The symptom may actually be caused by non-errors
o The symptom may be caused by non-traceable human error
o The symptom may be a result of timing problems
o It may be difficult to reproduce input conditions
o The symptom may be intermittent
o The symptom may be due to causes that are distributed
across a number of tasks running on different processors
Debugging strategies
Debugging tactics
• Brute force
o The most common and least efficient method
o We apply brute force debugging methods when all else fails
• Backtracking
o Manually trace backwards from the source
o As the number of source lines increases, the number of
potential backward paths may become unmanageably large
• Cause elimination
o Manifested by induction / deduction and introduces the
concept of binary partitioning
52
 http://wikistudent.ws/Unisa
o Data related to the error occurrence are organized to
isolate potential causes
o A ‘cause hypothesis’ is devised, and the data are used to
prove / disprove the hypothesis
o Alternatively, a list of all possible causes is developed,
and tests are conducted to eliminate each
Automated debugging
• IDEs provide a way to capture some of the language-specific
errors without requiring recompilation
Correcting the error
• Questions to ask before making a correction:
o Is the cause of the bug reproduced elsewhere in the code?
o Will the proposed fix introduce another bug?
o How could we have prevented this bug in the first place?

Chapter 14 – Testing tactics

Software testing fundamentals
• A software engineer should design and implement a system with
‘testability’ in mind
• The tests must exhibit a set of characteristics that achieve the
goal of finding the most errors with a minimum of effort
• Definition of testability: How easily a program can be tested
Characteristics that lead to testable software:
• Operability
o The better it works, the more efficiently it can be tested
• Observability
o Inputs provided as part of testing produce distinct outputs
• Controllability
o The better we can control the software, the more the
testing can be automated and optimized
• Decomposability
o The system is built from independent modules that can be
tested independently
• Simplicity
o Functional simplicity (Minimum feature set)
o Structural simplicity (Modularized architecture)
o Code simplicity (Coding standard for ease of inspection)
• Stability
o The fewer the changes, the fewer the disruptions to testing
• Understandability

53
 http://wikistudent.ws/Unisa
o Well organized, specific & accurate technical documentation
Test characteristics:
• A good test has a high probability of finding an error
o Understand the software and picture how it might fail
• A good test is not redundant
o Every test should have a different purpose
• A good test should be ‘best of breed’
o If you only have time to use a subset of tests, the test
that has the highest likelihood of uncovering a whole class
of errors should be used
• A good test should be neither too simple nor too complex
o Although it is sometimes possible to combine a series of
tests into one test case, rather execute them separately

Black-box testing
• Tests that are conducted at the software interface
• You know the function that the product must perform

White-box (Glass-box) testing

• Close examination of procedural detail
• You know the internal workings of the product
• A limited number of important logical paths should be selected
• The software engineer can derive test cases that:
o Guarantee that all independent paths within a module have
been exercised at least once
o Exercise all logical decisions on their true and false sides
o Execute all loops at their boundaries and within their
operational bounds
o Exercise internal data structures to ensure their validity

Chapter 16 – Web engineering

Attributes of Web-based systems and applications
• Network intensiveness
o A WebApp must serve needs of a diverse community of clients
• Concurrency
o A large number of users may access the WebApp at once
• Unpredictable load
o The number of users may vary from day to day
• Performance
o WebApp users don’t want to wait too long for access
• Availability
o Users often demand constant availability
• Data driven
o The primary function of many WebApps is to use hypermedia
to present text, graphics, audio, and video to end users
• Content sensitive

54
http://wikistudent.ws/Unisa
o The quality and aesthetic nature of content remains NB
• Continuous evolution
o WebApps evolve continuously, unlike conventional software
• Immediacy
o Time schedules for WebApps are more compressed
• Security
o It is difficult to limit the users who access the WebApp
• Aesthetics
o Part of the appeal of a WebApp is its look and feel

• Other generic attributes that differentiate WebApps from more

conventional software applications:
o Customizable
 Each user can customize the info to his own needs
o Dependent
 The content may be dependent on the content of other
WebApps (e.g. hot links to other websites) that are
not under control of the WebApp developer
o Responsive
 Users can ‘comment’ on the WebApp in real-time and
expect a timely response to their query / comments

• Application categories most commonly encounterd in WebE work:

o Informational (Read-only content)
o Download
o Customizable (Communication among users)
o Interaction
o User input
o Transaction-oriented
o Service-oriented
o Portal (Channels to other Web content)
o Database access
o Data warehousing

WebApp engineering layers

Process
• WebE process models embrace the agile development philosophy
• Framework activities must be defined within a process that
o Embraces change
o Encourages the creativity & independence of staff
o Builds systems using small development teams
o Emphasizes evolutionary / incremental development
Methods
• Communication methods
o Important during requirements gathering & evaluation
• Requirements analysis methods
o Provide a basis for understanding the content to deliver,
the function to provide, and the modes of interaction

55
 http://wikistudent.ws/Unisa
• Design methods
o Address WebApp content, architecture, interface design, and
navigation structure
• Testing methods
o Incorporate formal technical reviews of content & design
model and a wide array of testing techniques that address
component-level and architectural issues, etc…
Tools and technology
• Technologies encompass: HTML, VRML, XML, Java, CORBA, browsers,
multimedia tools, site authoring tools, security tools…

The Web engineering process

• Because WebApps are often content-driven with an emphasis on
aesthetics, it is likely that parallel development activities
will be scheduled within the WebE process and involve a team of
both technical and non-technical people
Defining the framework
• Any of the agile process models can be applied as a WebE process
• Before we define a process framework for WebE, recognize that:
o WebApps are often delivered incrementally
o Changes will occur frequently
o Timelines are short
• The WebE process within the generic process framework:
o Customer communication
 Business analysis – defines business context
 Formulation = a requirements gathering activity
o Planning
 The project plan consists of a task definition &
timeline schedule for the time period of an increment
o Modeling
 Rapid analysis & design models are built
o Construction
 WebE tools are applied to construct the WebApp
 Then a series of rapid tests are conducted
o Deployment
 The WebApp is configured for its operational
environment, delivered to users, and evaluated
Refining the framework
• Tasks associated with WebE framework activities may be modified,
eliminated, or extended based on the characteristics of the
problem, product, project, and people

Web engineering best practices

1. Take the time to understand business needs & product objectives,
even if the details of the webApp are vague
2. Describe how users will interact with the WebApp using a
scenario-based approach
3. Develop a project plan, even if it is very brief
4. Spend some time modeling what it is that you’re going to build
56
http://wikistudent.ws/Unisa
5. Review the models for consistency and quality
6. Use tools & technology that enable you to construct the system
with as many reusable components as possible
7. Don’t rely on early users to debug the WebApp – design
comprehensive tests and execute them before releasing the system

• A list of ‘risks’ that would be likely during the development of

a new e-commerce application designed to sell cell phones over
the Web
o Are users willing to purchase cell phones over the Web?
o What will happen if the database fails during operation?
o Does the project team possess the technical skills needed?
o Does the company have enough staff to assist users?
o Will the website be able to handle the projected user load?
o Are users subject to abnormal privacy violation risks?
o What aspects of the site have the highest security risks?

57