7/28/2019 INF305 Notes (Pressman)
1/57
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 realistico 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 todays 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 Awell-understood modification to an existing programo A straightforwardimplementation of a numerical calculation
orbusiness rule, even if it is complexo 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 tomanage 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
7/28/2019 INF305 Notes (Pressman)
2/57
3. RAD model
An incremental model that emphasizes a short development cycle
A high-speed adaptation of thewaterfall model, where rapiddevelopment 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 teamand thenintegrated to form a whole
To achieve rapid development, this model assumes the existence
of: a project that can bemodularizedin a manner that allowsmajor functionality to be deliveredwithin 60-90 days (Thisisnt always the case sometimes timelines can be longer)
Drawbacks:
For large projects, RAD requires sufficient human resources todevelop the increments in parallel
Projects will fail if people dont commit to rapid activities
If a system cant be modularized, you cant 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 graphicso Ones where results can easily be examinedwithout 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 beapplied from the beginning
2
7/28/2019 INF305 Notes (Pressman)
3/57
o The prototype must be designed with extensibility in mindand be implemented using a programming environment that is
amenable to production system development
o The prototype is initially a mechanism for identifying
requirements, and thenbecomes the framework for extensionsthat 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 isrevised as each circuit is completed
Prototyping reduces risks, and can be applied at any stage
Problems:
o May be hard to convince customers that its 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 aswe 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 concurrentlyo 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
7/28/2019 INF305 Notes (Pressman)
4/57
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 dont 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 considered3. 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
Aspects = localizing the expression of a crosscutting concern
4
7/28/2019 INF305 Notes (Pressman)
5/57
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 languageo 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 distributedacross all UP phases andidentifies the tasks required to accomplish an action andthework products produced
5
7/28/2019 INF305 Notes (Pressman)
6/57
Inception Elaboration Construction Transition
Requirements Use casemodel
Analysis Analysismodel
Design Design model
Implement ImplementationmodelDeployment
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 isgood 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 tools2.Working software over comprehensive documentation3. Customer collaboration over contract negotiation4. 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
2. Documentation helps maintaining applications years later
3. Negotiation helps avoid unrealistic expectations
6
7/28/2019 INF305 Notes (Pressman)
7/57
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 processAny 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 strategyshould be instituted
Software increments (e.g. prototypes) must be delivered in short
time periods so that adaptation keeps pace with change
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.
7
7/28/2019 INF305 Notes (Pressman)
8/57
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 processmust 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 thisimplies 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:
CompetenceSkill 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
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
8
7/28/2019 INF305 Notes (Pressman)
9/57
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 environment3. 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 thestories 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 firsto The riskiest stories will be implemented first
After the 1st release, the team computesproject velocity (thenumber 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
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.
9
7/28/2019 INF305 Notes (Pressman)
10/57
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)
CRCcards 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 its 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 onecomputer to create code for a story, for quality assurance
As pair programmers complete their work, their code is integratedwith the work of others, to uncover errors early
This continuous integration provides a smoke testing environmentTesting
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 systemcan occur on a daily basis
This provides the team with a continual indication of progress
Acceptance tests / customer tests = ones specified by customersand 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 customers 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
o Communicate problems in ways that lead to effective action
Learning
ASD teams learn in 3 ways:
1. Focus groups
10
7/28/2019 INF305 Notes (Pressman)
11/57
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 usingincremental 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
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
11
7/28/2019 INF305 Notes (Pressman)
12/57
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 maynt 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 meetingformat that is conducted daily
Type Task pattern
Initialcontext
1. The project should have been initiated and a backlog
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 tounderstand 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 areasked and answered by all team members
Resultingcontext
At the conclusion of the meeting, each person has answered
the questions noted in the solution
Relatedpatterns
Backlog preparation
Conducting a sprint
Known uses/ examples
Scrum meetings are conducted throughout every Scrum
project and are an important element of communication
5. Crystal
An approach that puts a premium onmaneuverability
Primary goal: delivering useful, working software
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
12
7/28/2019 INF305 Notes (Pressman)
13/57
Reflection workshops are conducted before, during, and after anincrement 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 isactually 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 areeasier 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 feature5. Build by feature
FDD provides greater emphasis onproject management guidelinesand 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
7. Agile Modeling (AM)
With large systems, scope and complexity must be modeled so thato All can better understand what needs to be accomplished
13
7/28/2019 INF305 Notes (Pressman)
14/57
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 andhumility to recognize that they dont 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 locallyAdapt 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-
cation
Plan (user stories) Speculation
Collaboration
Requirements
Planning Plan (commit to a
specific increment)
Speculation
(adaptive cycle
planning)
Analysis
Modeling Design (refactoring,spike solutions)
Collaboration(mini-specs)
Design
Construc-
tion
Code (pair programming)
Test (unit testing)
Learning (learn
as you develop
components)
Evolution
Deployment Test (acceptance
testing, customer tests)
Learning Delivery
Generic: FDD DSDM
Communication Develop an overall model
Build a features list
(features are groupedinto sets)
Plan by feature
Feasibility study (basic
requirements)
Business study (functional& info requirements)
Planning
Modeling Design by feature
(design package)
Build by feature
(completed function)
Functional model iteration
(prototypes)
Design & build iteration
(revisit prototypes)
Construction
Deployment Implementation
14
7/28/2019 INF305 Notes (Pressman)
15/57
Chapter 5 Software engineering practice
Software engineering practiceThe 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 Hookers 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 dont 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 errorso The need to use automated tools to facilitate developmento The need tomeasure the product to improve quality
Other management essentials that might be recommended for SE:
o Continuous & effective communication with stakeholderso Implementation of an agile mindseto A set ofmanagement & technical practices that enable the
team to define a road map as it travels towards its goal
1. Communication practices1. Listen
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
15
7/28/2019 INF305 Notes (Pressman)
16/57
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 thebusiness domaino Know who the stakeholders are and what goals each haso Establish a defined requirements-gatheringmechanismo Create a method for recording requirementso Establish a way toprioritize needs
How should communication preparation manifest itself in the
early work that you do? What work products might result?
o Research thebusiness domain that the software will addresso Understand the stakeholders who will specify requirementso Develop a defined strategy for requirements gathering
o Understand the goals for each of the stakeholderso 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 cant 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 practices1. 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 dont 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:
o Granularity refers to the level of detail that isintroduced as a project plan is developed
o Fine granularity plan: detail, planned over a short timeo Coarse granularity plan:broadwork tasks over long periods
o Granularity goes fine coarse as the timeline moves on
16
7/28/2019 INF305 Notes (Pressman)
17/57
3. Modeling practiceAnalysis 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 modeling1. 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 actualentity to be built. Analysis models represent customer
requirements, and design models provide a concretespecification for the construction of the software.
4. Construction practiceCoding principles and conceptsPreparation principles:
1. Understand the problem youre 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 programming2. Select data structures that will meet the needs of the design
3. Create interfaces that are consistent with the architecture
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
17
7/28/2019 INF305 Notes (Pressman)
18/57
Validation principles:
1. Conduct a code walkthrough when appropriate
2. Perform unit tests and correct errors youve uncovered
3. Refactor the code
Testing principles1. 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 Feedback1. 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
7/28/2019 INF305 Notes (Pressman)
19/57
Chapter 7 Requirements engineering
Requirements engineering tasks1. 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 marketo do a rough feasibility analysis
o identify a working description of the projects 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 projects scope and assesses whether or not that scopecan be achievedwithin the context of management andtechnical constraints. It defines abusiness 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 dont know the capabilities & limitations of computers
o They dont 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
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
19
7/28/2019 INF305 Notes (Pressman)
20/57
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 processIdentifying 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
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?
20
7/28/2019 INF305 Notes (Pressman)
21/57
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 andthen replaced by a requirements elicitation format
2. Eliciting requirementsCollaborative 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:
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
21
7/28/2019 INF305 Notes (Pressman)
22/57
7/28/2019 INF305 Notes (Pressman)
23/57
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 actors 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 actors 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 withdrawalPrimary actor: ClientGoal in context: To withdraw cash from the ATM quickly and securelyPre-conditions: The system has been programmed to recognize theinsertion 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
2. Incorrect password entered3. 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 implementedWhen available: First incrementFrequency of use: As many times as requiredChannel to actor: Via ATM control panelSecondary actors: ATM machine, camera
23
7/28/2019 INF305 Notes (Pressman)
24/57
Channels to secondary actors: ATM machine: computer networks. ATMmachine 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?
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
doesnt yet fully understand requirements for the system
Elements of the analysis model
Insert card
Enter password
Select account
Enter amount
Processtransaction
Dispense cash
Eject card
Print slip
ATM
machine
24
7/28/2019 INF305 Notes (Pressman)
25/57
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 specificapplication 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 modelso 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 adescription of the required informational, functional, and
behavioral domains for a computer-based system. The model
changes dynamically as software engineers learn more aboutthe 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 / subsystems key stakeholders
2. Determination of the stakeholders win conditions3. Negotiation of the stakeholders win conditions to reconcile
them into a set of win-win conditions for all concerned
If youve 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
25
7/28/2019 INF305 Notes (Pressman)
26/57
for a win-win result, so if the customer feels he has
won, that makes you a master negotiator.
6. Validating requirementsQuestions 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 systems environment?
Is each requirement testable, once implemented?
Does the requirements model reflect the systems 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 internaldepartment, marketing, or an outside entity
Why many developers dont pay enough attention to requirements
engineering, and circumstances where you can skip it:
o Software engineers want tobegin building something, sothey 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.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.
26
7/28/2019 INF305 Notes (Pressman)
27/57
Chapter 8 Building the analysis model
Requirements analysis Result: specification of softwares operational characteristics
Indicates softwares 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 overallunderstanding 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 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 applicationdomain, for reuse on multiple projects within that domain
27
7/28/2019 INF305 Notes (Pressman)
28/57
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 literatureo 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 theconcept 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 arewidely usedwithin aspecific 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
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
28
7/28/2019 INF305 Notes (Pressman)
29/57
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 begincoding after the objects and attributes are defined and
relationships are known. However, the design will suffer as
a result because explicit architectural design will nothave been considered; interfaces will have been developedin a haphazard manner and global data structures will nothave 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
= 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
29
7/28/2019 INF305 Notes (Pressman)
30/57
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 modelingWriting 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 dont 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
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 directlymentioned (but implied) by the use case
Rounded rectangles imply a specific function
Arrows represent flow through the system
Decision diamonds depict a branching decision
30
7/28/2019 INF305 Notes (Pressman)
31/57
Solid horizontal lines indicate parallel activities
Swimlane diagrams
A variation of the activity diagram
Additional info: indicates which actor / class is responsiblefor 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 datao produce control information rather than reports / displayso 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 theprocesses that are activated as a result of this behavior
The process specification (PSPEC)
Used to describe all flow modelprocesses that appear at the
final level of refinement The content can include:
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
31
7/28/2019 INF305 Notes (Pressman)
32/57
Class-based modelingIdentifying 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 rememberedfor the system to function?
2. Needed serviceso 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 tothe systems 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 thatmanipulate data (E.g. add, delete, select)2. Operations that perform a computation3. Operations that inquire about the objects state4. Operations thatmonitor 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 theproblem statement (e.g. FloorPlan)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 arepresentedto the user
Controller classes
o Manage a unit of work from start to finish:
The creation / update of entity objects
32
7/28/2019 INF305 Notes (Pressman)
33/57
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 distributedacross 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 possibleo So that they can apply to all subclasses
3. Information & related behavior should reside in the same classo 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.
4. When the token is passed, the holder of the class card mustdescribe 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
33
7/28/2019 INF305 Notes (Pressman)
34/57
Stereotype = a UML extensibility mechanism that allows you todefine a special modeling element with custom-defined semantics
In UML stereotypes are represented in
Analysis packages
What is an analysis package and how might it be used?
o A package is used to assemble a collection of relatedclasses 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 systemo 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 eventso 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 objects 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 eventso In addition to specifying the event that causes the
transition to occur, you can specify a guard and an action
o Guard= a Boolean condition that must be satisfied in orderfor the transition to occur
o Action = something that occurs concurrently with the statetransition or as a consequence of it
2. Sequence diagrams
o Shows the behavior of the software as a function of timeo 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
34
7/28/2019 INF305 Notes (Pressman)
35/57
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 elementsof 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 amodel of software that will implement allcustomer 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
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 requirementscontained in the analysis model, and must accommodate all
of the implicit requirements desired by the customer
35
7/28/2019 INF305 Notes (Pressman)
36/57
7/28/2019 INF305 Notes (Pressman)
37/57
7/28/2019 INF305 Notes (Pressman)
38/57
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 modules relative functional strengtho Coupling
Indication of the interdependence among modules
Refinement
You develop a hierarchy by decomposing macroscopic functionsuntil reaching programming language statements
Refinement is actually a process of elaboration because youprovide more and more detail with each successive refinement
Abstraction and refinement are complementary concepts:
o Abstraction enables a designer to specify procedure anddata and yet suppress low-level details
o Stepwise Refinement helps the designer to reveal low-leveldetails as design progresses
Refactoring
Refactoring is a reorganization technique that simplifies thedesign 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 presentmore technical detail as a guide for implementation
The design classes must
o Refine the analysis classes by providing design detail thatwill 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)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
38
7/28/2019 INF305 Notes (Pressman)
39/57
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 emphasizedo 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 users 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 levelo 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 Component-level design fully describes the internal detail of
each software component
Component-level design defines
o Data structures for all local data objectso Algorithmic detail for all processingo An interface that allows access to all component operations
The design details of a component can be modeled at many
different levels of abstraction:
39
7/28/2019 INF305 Notes (Pressman)
40/57
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
allocatedwithin thephysical computing environment
Deployment diagrams show computing elements, with subsystems
o Descriptor form
No explicit indication of configuration detailso Instance form
Later stages of design with details
Pattern-based software designDescribing a design pattern
Design pattern template:
Pattern name Describes theessence of the
pattern
Structure The classes toimplement the
pattern
Intent What the pattern
does
Participants The
responsibilitiesof the classes
Also known as Synonyms Collaborations How theparticipants
collaborate
Motivation An example of theproblem
Consequences Trade-offs toconsider
Applicability Specific designsituations where
it is applicable
Related patterns Cross-referencesrelated design
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 maybe adjusted to allow the pattern to accommodate various problems
Guidance associated with the use of a design pattern provides anindication 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 patternso 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
40
7/28/2019 INF305 Notes (Pressman)
41/57
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 tobe 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 architectureWhat is architecture?
Definition: The structure of the system, which comprises:o Software components,
o the externally visible properties of those componentso 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 stakeholders2. Highlights early design decisions that will have a profound
impact on all SE work that follows
3. Constitutes a relatively small, graspable model of how thesystem is structured and how its components work together
Data design
Data design translates data objects defined as part of theanalysis model into data structures at the software componentlevel and a database architecture at the application level
Data design at the architectural level
41
7/28/2019 INF305 Notes (Pressman)
42/57
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