SOFTWARE ENGINEERING

Nature of Software

– Software is both a product and a vehicle that

delivers a product
– Software delivers the most important product of
our time – information
– An information transfer – producing, managing,
acquiring, modifying, displaying, or transmitting
information
– Role of computer software undergone significant
changes over years, yet there are problems…
 – Why does it take so long to get software finished?
– Why development cost so high?
– Why errors not found before delivering to
customers?
– Why much effort spent on software maintenance?
– Difficulty in measuring progress as software being
developed and maintained.
• These concerns led to the adoption of best
software engineering practice
• Defining Software
– Many definitions are there, but they are not
measurably understanding.
– Hence, the characteristics of software are
examined
• Logical rather than a physical element
• Software doesn’t wear out when compared with
Hardware which wear out as a function of time (Fig.1
showing the Bathtub Curve)

But it does deteriorate…

 • Spare parts are available for
hardware, but not for software.

Fig.1: Failure curve for Hardware

• Idealized curve is a gross over simplification of actual failure

models for software

Fig.2: Failure curves for Software

 – Software maintenance tasks are more complex than hardware
maintenance
• Software Application Domains (7 broad categories of
computer software)
– System software
– Application software
– Engineering/scientific software
– Embedded software
– Product-line software
– Web/mobile applications
– Artificial Intelligence software
• Legacy Software
– 100s of 1000s of programs are there in the software
application domains listed
– Most programs are older
– Referred to as legacy software and have been the focus of
continuous attention & concern since 1960s.
• Dayani-Fards’ description
Legacy software systems . . . were developed decades ago and have been
continually modified to meet changes in business requirements and computing
platforms. The proliferation of such systems is causing headaches for large
organizations who find them costly to maintain and risky to evolve.
• Liu extend this description
Many legacy systems remain supportive to core business functions and are
‘indispensable’ to the business.
• Legacy software is
characterized by durability
& business criticality

• But one additional

characteristic – poor quality

What to do?
• Nothing, if the system works fine…
• But, as time passes, legacy systems evolve for one or more of
the following reasons:
– adapt to meet the needs of new computing environments or
technology
– enhance to implement new business requirements
– extend to make it interoperable with other more modern systems
or databases
– re-architected to make it viable within a evolving computing
environment.
• Hence legacy system should be reengineered
– Devise methodologies that are founded on the notion of evolution
• 4 broad categories of software are evolving to
dominate the industry:
– Webapps
– Mobile applications
– Cloud computing
– Product Line software
Key Concepts
• Realities behind the software development
– It follows that a concerted effort should be made
to understand the problem before a software
solution is developed.
– It follows that design becomes a pivotal activity.
– It follows that software should exhibit high quality.
– It follows that software should be maintainable
• Software in all of its forms and across all of its
application domains should be engineered.
• Defining Software Engineering as proposed by IEEE
– (1) The application of a systematic, disciplined, quantifiable
approach to the development, operation, and maintenance of
software; that is, the application of engineering to software.
(2) The study of approaches as in (1).
– What about other approaches?
Adaptability and Agility
– Layered technology
• Any engineering approach must rest on an organizational
commitment to quality
• Process
– glue that holds the technology layers together & enables rational
and timely development of computer software
– Forms the basis for management control of software projects and
establishes the context in which
• technical methods are applied
• Work products are produced
• Milestones are establishes
• Quality is ensured &
• Change is properly managed
• Methods encompass a broad array of tasks that include
– Communication
– Requirements analysis
– Design modeling
– Program construction
– Testing &
– Support
• Rely on a set of basic principles that govern each area of the
technology and include modeling activities and other descriptive
techniques.
• Tools provide automated or semi-automated support for the
process and methods
 The Software Process

• A process is a collection of activities, actions, and tasks

that are performed when some work product is to be
created
– Activity: strives to achieve broad objective
– Action: encompasses a set of tasks that produce a major
work product
– Task: focuses on a small, but well-defined objective that
produces a tangible outcome
• It is an adaptable approach that enables the people
doing the work to pick & choose the appropriate set of
work actions and tasks
• The Process Framework
– Foundation for a software engineering process through a small
number of framework activities
• Communication
• Planning
• Modeling
• Construction
• Deployment
– Encompasses a set of umbrella activities that are applicable across
the entire software process.
– Typical activities include,
• Software Project Tracking and Control
• Risk Management
• Software Quality Assurance
• Formal Technical Reviews
 • Measurement
• Software Configuration Management
• Reusability Management
• Work Product preparation and production
• Process Adaptation
– It should be agile and adaptable
– Therefore, a process adopted for one project might be significantly
different than a process adopted for another project
– How do process models differ from one another?
• Interdependencies among activities and tasks
• Degree to which work tasks are defined within each framework activity
• Degree to which work products are identified and required
• Manner in which Quality assurance, Project Tracking and Control
activities are applied
 • Degree of detail and severity of the process applied
• Degree to which customers are involved
• Level of autonomy to the team
• Degree to which team organization and roles are prescribed
• Prescriptive Process Models exists for the past 30 years
– objectives not achieved
– Due to rigidity and without adaptation
– Increase the level of bureaucracy associated and unintentionally
create difficulty for developers and customers
• Agile Process Models in recent years
– Project agility
– More informal but no less effective approach
– Emphasize maneuverability and adaptability
 Capability Maturity Model Integration
(CMMI)
• Software Engineering Institute (SEI)
–Developed a comprehensive process meta-model for organizations
reaching different levels of process capability and maturity

–To achieve these capabilities, organizations should develop process

models that conforms to CMMI guidelines

• CMMI represents a process meta-model in 2 different ways

1. A continuous model (fig 37.2)
a) Each process area is formally assessed against “specific goals” and “practices” and is rated
according to the various capability levels

2. A staged model
Continuous
CMMI meta-
model
• Level 0: Incomplete –process area either not performed or not achieving
all goals and objectives defined by CMMI for level 1 capability

• Level 1: Performed – all the specific goals of process area are satisfied,
work tasks carried out to produce defined work products

• Level 2: Managed – all works associated with process area conforms to an

organizational defined policy; access to adequate resources; stakeholders
involved; all work tasks & products are “monitored, controlled and
reviewed & are evaluated for adherence to the process description”

• Level 3: Defined – the process is “tailored from the organization’s set of

standard processes according to the organization’s tailoring guidelines, and
contributes work products, measures, and other process-improvement
information to the organizational process assets”
• Level 4: Quantitatively managed – the process area is controlled
and improved using measurement and quantitative assessment.
“Quantitative objectives for quality and process performance are
established and used as criteria in managing the process”

• Level 5: Optimized – the process area is adapted and optimized

using quantitative (statistical) means to meet changing customer
needs and to continually improve the efficacy of the process area
under consideration

• Specific goals establish the characteristics that must exist if the

activities implied by a process area are to be effective
• Specific practices refine a goal into a set of process-related activities
• Example: Project Planning – one of the eight process areas defined by
CMMI for “project management” category.*
• Specific Goals and Specific Practices defined are
• SG 1 Establish Estimates
– SP 1.1-1 Estimate the Scope of the Project
– SP 1.2-1 Establish Estimates of Work Product and Task Attributes
– SP 1.3-1 Define Project Life Cycle
– SP 1.4-1 Determine Estimates of Effort and Cost
• SG 2 Develop a Project Plan
– SP 2.1-1 Establish the Budget and Schedule
– SP 2.2-1 Identify Project Risks
– SP 2.3-1 Plan for Data Management
– SP 2.4-1 Plan for Project Resources
– SP 2.5-1 Plan for Needed Knowledge and Skills
– SP 2.6-1 Plan Stakeholder Involvement
– SP 2.7-1 Establish the Project Plan
• SG 3 Obtain Commitment to the Plan
– SP 3.1-1 Review Plans That Affect the Project
– SP 3.2-1 Reconcile Work and Resource Levels
– SP 3.3-1 Obtain Plan Commitment
• In addition to specific goals and practices, CMMI also defines a set of 5 generic
goals and related practices for each process area
• The generic goals (GG) & practices (GP) for the project planning process area are:
– GG1 Achieve specific goals
• GP 1.1 perform base practices
– GG2 Institutionalize a managed process
• GP 2.1 establish an organizational policy
• GP 2.2 plan the process
• GP2.3 provide resources
• GP 2.4 Assign Responsibility
• GP 2.5 Train People
• GP 2.6 Control Work Products
• GP 2.7 Identify and Involve Relevant Stakeholders
• GP 2.8 Monitor and Control the Process
• GP 2.9 Objectively Evaluate Adherence
• GP 2.10 Review Status with Higher Level Management
 – GG 3 Institutionalize a Defined Process
• GP 3.1 Establish a Defined Process
• GP 3.2 Collect Process Related Experiences
– GG4 Institutionalize a quantitatively managed process
• GP 4.1 establish quantitative objectives for the process
• GP 4.2 stabilize sub-process performance
– GG 5 Institutionalize an optimizing process
• GP 5.1 ensure continuous process improvement
• GP 5.2 correct root causes of problems
• The staged model defines 5 maturity levels, rather than 5
capability levels
Level Focus Key Process Area Result
5 Continuous Process •Organizational Innovation and Deployment Highest Quality /
Optimizing Improvement •Causal Analysis and Resolution Lowest Risk

4 Quantitatively •Organizational Process Performance Higher Quality /

Quantitatively Managed •Quantitative Project Management Lower Risk
Managed

3 Process •Requirements Development Medium Quality /

Defined Standardization •Technical Solution Medium Risk
•Product Integration
•Verification
•Validation
•Organizational Process Focus
•Organizational Process Definition
•Organizational Training
•Integrated Project Mgmt with IPPD extras
•Risk Management
•Decision Analysis and Resolution
•Integrated Teaming IPPD only
•Org. Environment for Integration IPPD only
•Integrated Supplier Management SS only

2 Basic Project •Requirements Management Low Quality /

Managed Management •Project Planning High Risk
•Project Monitoring and Control
•Supplier Agreement Management
•Measurement and Analysis
•Process and Product Quality Assurance
•Configuration Management

1 Process is informal Lowest Quality /

Initial and Adhoc Highest Risk
 Process Patterns
• Provides a template – A consistent method for describing an important
characteristic of the software process
• By combining patterns, a software team can construct a process that best
meet the needs of a project
• Pattern used to describe a complete process; to describe an important
framework activity; to describe a task within a framework activity
• Ambler’s template for describing a process pattern
– Pattern Name: given a meaningful name that describe its function within the
software process (eg. Customer-communication)
– Intent: objective of pattern described briefly
– Type: 3 types are there
• Task patterns: defines a work task (eg. Requirements gathering)
• Stage patterns: defines a framework activity for the process; incorporates
multiple task patterns that are relevant to the stage (eg. Communication)
• Phase patterns: define the sequence of framework activities that occur within the
process (eg. Prototyping)
– Initial context: conditions under which the pattern applies are
described
• What organizational or team activities have already occurred?
• What is the entry state for the process? &
• What software engineering information or project information already exists?
– Problem: to be solved by the pattern is described
– Solution: implementation of the pattern is described
– Resulting context: conditions that will result once the pattern has
been successfully implemented are described
• What team activities must have occurred?
• What is the exit state for the process? &
• What software engineering information or project information has been developed?
– Related Patterns: list of process patterns directly related are
described
• Eg. Communication (stage pattern) encompasses the task patterns,
– Project-team assembly, Collaborative-guideline definition, Scope-isolation,
Requirements-gathering, Constraint-description, & mini-spec / model
creation
Process Assessment
– Known Uses / Examples: the specific instances in which the pattern is
applicable are indicated
• Whether software process will guarantee about the delivery on time; will
meet the customer’s needs; will lead to long-term quality characteristics?
• Process itself has to be assessed to ensure that it meets a set of basic
process criteria that have been shown to be essential for a successful
software engineering
– Number of different approaches proposed for software process
assessment and improvement:
– SCAMPI: 5-step process assessment model that incorporates 5 phases-
initiating, diagnosing, establishing, acting, and learning
– CBA IPI: provides a diagnostic technique for assessing the relative
maturity of a software organization
– SPICE (ISO/IEC15504): a standard that defines a set of requirements for
software process assessment.
– ISO 9001:2000 for Software
 Requirements of a Teacher
• Programming Exam for second year students:
Question : String concatenation.
One Student, works on but gets runtime error. Output is
something like this :
Enter String one : ABC
Enter String two : XYZ
Segmentation Fault
• He was not able correct it, and finally it was time where the
teacher expect his requirements i.e., the results
• Here's what he showed to teacher.
Enter String one : Segmentation
Enter String two : Fault
Segmentation Fault
 Requirements Engineering
• A bridge to design and construction
– Software developers continually argue that designing and
building software is challenging and requirements engineering
is a waste of time
– Bottom line is to produce a working program and all other
things are secondary
– But this will lead to flaw and a failure software project
– Requirement engineering must be adapted to the needs of the
process, the project, the product, and the people doing the
work

Requirements Engineering is a software engineering action that begins

during the communication activity and continues into the modeling activity
 Requirements cannot be observed or asked for from
the users, but have to be created together with all
the stakeholders.
Vesa Torvinen, University of Turku

• Overall, the software team must adapt its approach to Requirements

Engineering
• Crucial for the Software Team => to make a real effort to understand the
requirements of a problem before the team attempts to solve the problem
• Where does the bridge originate?
– Allowing the software team to examine the context of software work to be
performed
– Specific needs that design & construction must address
– Priorities that guide the order in which the work is to be completed
– Information, functions and behaviors that will have a profound impact on the
resultant design
• Requirement Engineering Tasks
– RE process accomplished through the execution of 7 distinct functions:
• Inception, Elicitation, Elaboration, Negotiation, Specification, Validation
and Management
• Inception
– How does a Software Project get started?
• A simple conversation is all that is needed
– Most projects begin when a business need is identified or a potential new
market or service is discovered
– To ask a set of context-free questions
• Who is behind the request for this work?
• Who will use the solution?
• What will be the economic benefit of a successful solution?
• Is there another source for the solution that is needed?
– Intent is
• to establish a basic understanding of the problem
• The people who want a solution
• Nature of the solution that is desired &
• The effectiveness of preliminary communication and collaboration between the
customer and the developer
• Elicitation
– Christel & Kang proposed a number of problems that help us understand why requirements
elicitation is difficult:
• Problems of Scope
• Problems of Understanding
• Problems of Volatility
• Elaboration
– Focuses on developing a refined technical model of software functions, features, and
constraints
– It is an analysis modeling action i.e., composed of a number of modeling and refinement
tasks
– Is driven by the creation and refinement of user scenarios that describe how the end-user
will interact with the system
– User scenario parsed to extract analysis classes – business domain entities that are visible
to the end user.
– Attributes of each analysis class are defined and the services are identified
– Relationships and collaborations between classes are identified
– End result of Elaboration: An analysis model that defines the informational, functional, and
behavioral domain of the problem
• Negotiation
– Customers propose conflicting requirements
– Requirement Engineers to settle these conflicts through Negotiation process
– Customers asked to rank requirements and then discuss conflicts in priority
– Risks associated are identified and analyzed
– Rough “guestimates” of development effort made & used to assess the impact of each
requirement on project cost and delivery time
• Specification
– Can be a written document, a set of graphical models, a formal mathematical model, a
collection of usage scenarios, a prototype or a combination of all
– For large systems: a written document combining natural language descriptions &
graphical models
– For smaller products: user scenarios
– Final work product produced by the Requirements Engineer
– Foundation for the subsequent software activities
– Describes the functions & performance of a computer-based system & constraints that
govern its development
• Validation
– Work products produced are assessed for quality
– Requirements validation examines the specification to ensure that all software
requirements are stated
• Unambiguously
• Correctly and detects the inconsistencies, omissions and errors
• According to the conforms of standard established for the process, project and the product
– Primary requirements validation mechanism
• Formal Technical Review
• Requirements Management
– Is a set of activities that help the project team identify, control and track
requirements and changes to requirements at any time as the project proceeds
– Begins with Identification: each requirement assigned a unique identifier
– Traceability tables are developed: relates requirements to one or more aspects of
the system or its environment
– Possible Traceability tables are as follows:
• Features Traceability Table
• Source Traceability Table
• Dependency Traceability Table
• Subsystem Traceability Table
• Interface Traceability Table
 Initiating the Requirements Engineering
Process
• Customers
– May be in a different location, have only a vague idea of what is required, have
conflicting opinions about the system to be built, have limited technical knowledge,
limited time to work with Requirements Engineer
• Software team forced to work with these constraints
• Then how to keep moving the project forward toward a successful solution
• Here are the steps to follow:
– Identifying the Stakeholders: Business Operations Manager, Product Managers,
Marketing people, Internal and External Customers, End-users, Consultants and
others
• At inception, RE should create list who will contribute inputs as requirements are
elicited
– Recognizing Multiple Viewpoints:
• As information from multiple viewpoints are collected, REs should categorize all
stakeholder information (including inconsistent and conflicting requirements) in a
way that will allow authorities to choose an internally consistent set of
requirements for the system
 – Working towards Collaboration
• In many cases, Stakeholders collaborate by providing their view of
requirements, but a strong “Project Champion” may take the final
decision on the redundant requirements
– Asking the first questions
• Who is behind the request for this work?
• Who will use the solution?
• What will be the economic benefit of a successful solution?
• Is there another source for the solution that you need?

These questions will help – stakeholder interest in the software

measurable benefit of successful implementation.
– Next set of questions (better understanding of the
problem)
• Customer’s voice and perception about a solution
– How would you characterize “good” output that would be
generated by a successful solution?
– What problem(s) will this solution address?
– Can you show me the business environment in which the
solution will be used?
– Will special performance issues or constraints affect the
way the solution is approached?
• Final set of questions focuses on the effectiveness of
communication itself
–Are my questions relevant to the problem?
–Am I asking too many questions?
 –Can anyone else provide additional information?
–Should I be asking you anything else?
• Meta-questions
– Are you the right person to answer these questions? Are your answers
“official”?
– Are my questions relevant to the problem that you have?
– Am I asking too many questions?
– Can anyone else provide additional information?
– Should I be asking you anything else?
• Q&A sessions should be replaced by a requirements
elicitation format that combines elements of problem
solving, elaboration, negotiation, and specification
 Eliciting Requirements
• Collaborative Requirements Gathering
– Many different approaches proposed with each having
slightly different scenario, but all apply some variation on
the following basic guidelines
• Meetings are conducted and attended by both software engineers
and customers
• Rules for preparation and participation are established
• Formal agenda suggested to cover all important points
• “Facilitator” to control the meeting
• “Definition Mechanism” used
• Goal to identify the problem, propose elements of the solution,
negotiate different approaches, & specify a preliminary set of
solution requirements
• During initial meetings, Stakeholders write a “product request” and
distribute to all the attendees
• Reviewing the “product request”, each attendee asked to
– Make a list of objects that are part of the environment that surrounds the
system
– Other objects to be produced by the system
– Objects that are used by the system to perform its functions
– Each attendee to list services that manipulate or interact with the objects
– Lists of constraints and performance criteria are also developed
• Requirements gathering team composed of representatives from
Marketing, Software and Hardware Engineering, and Manufacturing
• Consider an excerpt from a pre-meeting document written by
a Marketing person involved in the SafeHome project. This
person wrote the following narrative about the home security
function
• List the objects described for SafeHome
– control panel
– smoke detectors
– window and door sensors
– motion detectors
– an alarm
– an event
– a display
– a PC
– telephone numbers
– a telephone call
• List the services
– configuring the system
– setting the alarm
– monitoring the sensors
– dialing the phone
– reading the display
• List the constraints
– system must recognize when sensors are not operating
– must be user friendly
– must interface directly to a standard phone line
• Quality Function Deployment
– A technique that translates the needs of the customers into technical
requirements for software
– “concentrates on maximizing customer satisfaction from the software
engineering process”
– Identifies 3 types of requirements
• Normal - reflect objectives & goals stated for a product / system. If these
requirements are present, customers are satisfied
• Expected – implicit to the product/system and fundamental; customers may not
explicitly state them.
• Exciting – reflect features that go beyond the customer’s expectations and prove to
be very satisfying when present
– In actuality, QFD spans the entire engineering process
– Here QFD concepts applicable to the requirements elicitation activity is
present
– Function deployment: 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: conducted to determine the relative
priority of requirements determined during each of the 3
deployments
– VOICE OF CUSTOMER – Customer Voice Table
• User Scenarios
– As requirements are gathered, an overall vision of system
functions and features begins to materialize
– But difficult to move into technical software engineering
activities until the s/w team understands how these
functions and features used by different classes of end-
users
– To create a set of scenarios that identifies a thread of
usage for the system
– Often called as use-cases => provides a description of how
the system will be used
 Developing Use-cases
• How an end-user interacts with the system under a specific set of
circumstances?
• A use-case depicts the system from the end-user’s point of view
• First define the set of “actors”
– Represent the roles that people or devices play as the system operates
– Consider an example: a machine operator who interacts with the control
computer for a manufacturing cell that contains a number of robots and
numerically controlled machines
– Now the software for control computer requires 4 different roles for
interaction: how many actors are needed here?
–Actors
However Actors and end-users are different in terms of
End-users
functionality
Represents a class of external entities Plays an no. of different roles when using
that play one role in the context of use- a system
case
 – Not all actors are identified during the first iteration
– Identify primary actors during the first iteration and
secondary actors while learning the system further
– Primary actors interact to achieve required system
function & derive the intended benefit from the system;
work directly and frequently
– Secondary actors support the system so that primary
actors shall do their work
• Once actors identified, use-cases can be developed.
• Number of questions to be answered by use-case:
• Who is the primary actor, the secondary actor(s)?
• What are the actor’s goals?
• What preconditions should exist before the story begins?
• What main tasks or functions are performed by the actor?
• What exceptions might be considered as the story is
described?
• What variations in the actor’s interaction are possible?
• What system information will the actor acquire, produce, or
change?
• Will the actor have to inform the system about changes in the
external environment?
• What information does the actor desire from the system?
• Does the actor wish to be informed about unexpected
changes?
• For the SafeHome project, who are all the actors?
– 4 actors
• HomeOwner
• Setup Manager
• Sensors
• Monitoring and Response subsystem
– Considering the actor: Homeowner

(1) enters a password to allow all other interactions,

(2) Inquires about the status of a security zone
(3) inquires about the status of a sensor
(4) presses the panic button in an emergency
(5) activates/deactivates the security system.

– Consider the situation in which the homeowner uses the control

panel
– Basic use-case for system activation follows:
– Basic use-case presents a high level story that describes the
interaction between the actor and the system.
• The homeowner observes the SafeHome control panel ( Figure 8.1 ) to
determine if the system is ready for input. If the system is not ready, a not
ready message is displayed on the LCD display, and the homeowner must
physically close windows or doors so that the not ready message disappears.
[A not ready message implies that a sensor is open; i.e., that a door or
window is open.]
• The homeowner uses the keypad to key in a four-digit password. The
password is compared with the valid password stored in the system. If the
password is incorrect, the control panel will beep once and reset itself for
additional input. If the password is correct, the control panel awaits further
action
• The homeowner selects and keys in stay or away (see Figure 8.1 ) to activate
the system. Stay activates only perimeter sensors (inside motion detecting
sensors are deactivated). Away activates all sensors
• When activation occurs, a red alarm light can be observed by the homeowner.
• Template for detailed description of use-cases
– Use case: Initiate Monitoring
• Primary Actor:
• Goal in context:
• Preconditions:
• Trigger:
– Scenario:
• Homeowner: observes control panel
•:
•:
– Exceptions:
• Control panel is not ready:
•:
•:
– Priority: Essential, must be implemented
– When available: First increment
– Frequency of use: Many times per day
– Channel to actor: Via control panel interface
– Secondary actors: Support technician, sensors
– Channels to secondary actors:
• Support technician: phone line
• Sensors: hardwired and radio frequency interfaces
– Open issues:
• Should there be a way to activate the system without the use of a
password or with an abbreviated password?
• Should the control panel display additional text messages?
 Building the Analysis Model
• To provide a description of the required informational, functional, and behavioral domains
for a computer-based system
• Analysis Model => snapshot of requirements at any given time and we expect it to change
• Elements of the Analysis Model
– Scenario-based elements
• First part of the model that is developed; serve as input for the creation of other
modeling elements. Basic use-cases evolve into more elaborate template-based use-
cases
– Class-based elements
• Each usage scenario implies a set of “objects” that are manipulated as an actor interacts
with the system. These objects are categorized into classes
– Behavioral elements
• state diagram is one method for representing the behavior of a system by depicting its
states and the events that cause the system to change state
– Flow-oriented elements
• Information transferred as it flows through a system. System accept variety of inputs, applies
functions to transform it, and produces output in a variety of forms.
A different approach to
scenario-based
modeling depicts the
activities or functions
that have been defined
as part of the
requirement elicitation
task
 Classes – a collection of things
that have similar attributes and
common behaviours

State diagram
indicates what
actions are taken
A state is any as a consequence
observable of a particular
mode of event
behavior
• Analysis patterns
– Certain things reoccur across all objects within a specific
application domain: called Analysis patterns
– represent something (class, function or behavior) within the
application domain
– reused when modeling many applications
– Geyer-Schulz and Hahsler suggest 2 benefits
• Information about an analysis pattern presented in a standard template
– Pattern Name: a descriptor that captures the essence of the pattern; the
descriptor is used within the analysis model when reference is made to the
pattern
– Intent:
– Motivation
– Forces and Context: a description of external issues (forces); External issues
encompass business-related subjects, external technical constraints, and people-
related matters
– Solution
– Consequences
– Design: discusses how the analysis pattern can be achieved through the use of
known design patterns
– Known uses
– Related patterns
• Negotiating Requirements
– Boehm defines a set of negotiation activities at the beginning of
each software process iteration
• Identification of the system or subsystem’s key stakeholders.
• Determination of the stakeholders’ “win conditions.”
• Negotiation of the stakeholders’ win conditions to reconcile them into a
set of win-win conditions for all concerned (including the software team).
– Handshaking
• allows detailed requirements to be delegated to software teams.
• The teams need to elicit requirements from customers (e.g., product
users and domain experts), thereby improving product acceptance
– “A compromise is the art of dividing the cake in such a way that
everyone believes that he has the biggest piece”
• VALIDATING REQUIREMENTS
–To examine for inconsistencies, omissions and ambiguity
–A review of the requirements model addresses the following questions:
• Is each requirement consistent with the overall objectives for the system or product?
• Have all requirements been specified at the proper level of abstraction?
• That is, do some requirements provide a level of technical detail that is inappropriate at this stage?
• Is the requirement really necessary or does it represent an add-on feature that may not be essential
to the objective of the system?
• Is each requirement bounded and unambiguous?
• Does each requirement have attribution? That is, is a source (generally, a specific individual) noted
for each requirement?
• Do any requirements conflict with other requirements?
• Is each requirement achievable in the technical environment that will house the system or product?
• Is each requirement testable, once implemented?
• Does the requirements model properly reflect the information, function, and behavior of the system
to be built?
• Has the requirements model been “partitioned” in a way that exposes progressively more detailed
information about the system?
 User Satisfaction…?
• A Software Engineering is walking along a beach and finds a lamp.
• He rubs the lamp, and a genie appears and says
– “I am the most powerful genie in the world. I can grant you any wish, but only
one wish.”
• The Software Engineer pulls out a map, points to it and says,
– I want peace in the Middle East.
• The genie responds,
– Gee, I don’t know. Those people have been fighting for millennia. I can do just
about anything, but this is likely beyond my limits.
• The S/w Engineer then says,
– Well, I am a Project Manager, and my application have lots of users. Please
make all my users satisfied with my software and let them ask for sensible
changes.
• At which point the genie responds, Um, let me see that map again
 Functional vs Non-Functional Requirements
Functional Non-functional
Any requirement which specifies what the Any requirement which specifies how the system
system should do; performs a certain function;
providing particular service to the user. how a system should behave;
generally specify the system’s quality attributes
or characteristics

e.g. e.g.
“Send email when a new customer signs “Modified data in a database should be updated
up”; for all users accessing it within 2 seconds”
“Open a new account”
Typical Functional Requirements include: Typical non-functional requirements include:
Business Rules; Performance – for example: response time,
Transaction corrections, adjustments and throughput, utilization, static volumetric;
cancellations; Scalability; Capacity; Availability; Reliability
Administrative functions; Recoverability; Maintainability; Serviceability;
Authentication; Authorization levels; Security; Regulatory; Manageability
Audit Tracking; External Interfaces; Environmental; Data Integrity;
Certification Requirements; Usability; Interoperability
Reporting Requirements; Historical Data;
Legal or Regulatory Requirements
• Business Rules
– Example: License Inspection Project
– Rule 1:
• A Driver of a Vehicle must have a valid Driver's License.
– Rule 2:
• A Driver's License must be considered valid if all of the following are
true:
– The Driver's License belongs to the Driver.
– The Expiry Date of the Driver's License is later than the Inspection Date.
– The physical proof is produced within 24 hours of the Inspection Date.
• Possible business requirements to enforce these rules:
– Police officer to inspect driver's license.
– Scanner to read driver's license for validity.
– Card reader for driver to insert driver's license when driving through a
checkpoint.
• Exercise:
• Construct Business Rules for Order Entry
System (Hint: Email Address)
 Analysis Model – first technical
representation of the system
Requirements Analysis provides the
• Requirements Analysis software designer with a representation
– Build models that depict of information, function and behavior
that can be translated to architectural,
• user scenarios,
interface and component-level designs.
• functional activities,
• problem classes and their relationships,
• System and class behavior &
• The flow of data as it is transformed
– Throughout analysis modeling, software engineer’s focus is on what
and not how Software engineers perform
• What objects does the system manipulate? analysis modeling and create
an analysis model to provide
• What functions must the system perform? information of 'what'
• What behaviors does the system exhibit? software should do instead
• What interfaces are defined? & of 'how' to fulfill the
requirements in software.
• What constraints apply?
• Analysis model must achieve 3 primary objectives:
– To describe what the customer requires
– To establish a basis for the creation of a software design
– To define a set of requirements that can be validated once the software is built
• Analysis rules of Thumb (Arlow and Neustadt)
– The model should focus on requirements that are visible within the problem or
business domain
– 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
& other non-functional models until design
– Minimize coupling throughout the system
– Be certain that analysis model provides value to all stakeholders
 – Keep the mode as simple as it can be
• Domain Analysis
– How are analysis patterns recognized in the first place?
– Who defines them, categorizes them, and readies them for use on subsequent
projects?
– Firesmith describes “Software domain analysis is the identification, analysis,
and specification of common requirements from a specific application domain,
typically for reuse on multiple projects within that application domain . . .
[Object-oriented domain analysis is] the identification, analysis, and
specification of common, reusable capabilities within a specific application
domain, in terms of common objects, classes, subassemblies, and frameworks”.
• Analysis Modeling approaches
– Structured analysis
• Considers data and the processes that transforms the data as separate
entities
– Object-oriented analysis
• Focuses on the definition of classes and the manner in which they
collaborate with one another to effect customer requirements. UML & the
Unified Process are predominantly object-oriented
– Lead to the derivation of one or more of these modeling elements
• Data Modeling Concepts
– Analysis modeling begins with data modeling
– Software engineer defines all data objects that are processed
within the system, relationships between them, & other
information pertinent to the relationships
– Data Objects: representation of any composite information
• Can be an external entity, a thing, an occurrence, an event, a role, an
organizational unit, a place or a structure. E.g. Figure below shows an
object : car
– Data Attributes
• Defines the properties of a data object and take on one of 3 different characteristics
as follows:
– Name an instance of the data object,
– Describe the instance
– Make reference to another instance in another table
• One or more of the attributes defined as an identifier – key (unique)
• Set of attributes for data objects should be determined based on the problem
context
• What additional attributes shall be added to the car? (Hint: for an Automobile
Company that needs manufacturing control s/w)
– Relationships
– Cardinality and Modality
• How many occurrences of object X are related to how many occurrences of object
Y?
• Data Model: capable of representing the no. of occurrences of objects in a given
relationship
• Tillmann
defines the
Cardinality of an object/relationship pair in the following manner:
“Cardinality is the specification of the number of occurrences of one object that can
be related to the number of occurrences of another object”.
Cardinality also defines “the maximum number of objects that can participate in a
relationship”
– A 1:1 relationship
– A 1:N relationship
– An M:N relationship
• How it can be known that a particular data object must participate in the
relationship?
• Through Modality
• Modality is 0 if there is no explicit need for the relationship to occur; 1 – if the
occurrence of the relationship is mandatory
• Scenario-based Modeling
– Analysis modeling with UML begins with the creation of scenarios
in the form of use-cases, activity diagrams, and swimlane diagrams
– Writing Use-cases
– Concept: describes a specific usage scenario in simple language
from the point of view of a defined actor
• What to write about?
– To begin develop a set of use-cases, the functions or activities performed by a
specific actor are listed
• How much to write about it?
• How detailed to make our description?
• How to organize the description?
• SafeHome Surveillance subsystem identifies the following functions
performed by the homeowner actor:
 • Select camera to view
• Request thumbnails from all cameras
• Display camera views in a PC window
• Control pan and zoom for a specific camera
• Selectively record camera output
• Replay camera output
• Access camera surveillance via the Internet
– Requirements-gathering team develops use-cases for each of
the functions noted
• Access camera surveillance via the Internet—display camera views
( ACS-DCV )
• Homeowner actor
• Use-case: Access camera surveillance via the Internet—display
camera views (ACS-DCV)
Actor: homeowner
If I’m at a remote location, I can use any PC with appropriate browser
software to log on to the SafeHome Products website. I enter my user ID and
two levels of passwords and once I’m validated, I have access to all
functionality for my installed SafeHome system.
To access a specific camera view, I select “surveillance” from the major
function buttons displayed. I then select “pick a camera” and the floor plan
of the house is displayed. I then select the camera that I’m interested in.
Alternatively, I can look at thumbnail snapshots from all cameras
simultaneously by selecting “all cameras” as my viewing choice.
Once I choose a camera, I select “view” and a one-frame-per-second view
appears in a viewing window that is identified by the camera ID. If I want to
switch cameras, I select “pick a camera” and the original viewing window
disappears and the floor plan of the house is displayed again. I then select
the camera that I’m interested in. A new viewing window appears
• The variation of a narrative use-case presents the interaction as an ordered sequence of user
actions.
• Use case: Access camera surveillance via the Internet—display camera views
(ACS-DCV) also referred to as primary scenarios
• Actor: homeowner
1. The homeowner logs onto the SafeHome Products website.
2. The homeowner enters his or her user ID.
3. The homeowner enters two passwords (each at least eight characters in length).
4. The system displays all major function buttons.
5. The homeowner selects the “surveillance” from the major function buttons.
6. The homeowner selects “pick a camera.”
7. The system displays the floor plan of the house.
8. The homeowner selects a camera icon from the floor plan.
9. The homeowner selects the “view” button
10.The system displays a viewing window that is identified by the camera ID.
11.The system displays video output within the viewing window at one frame per second.
• Refining a Preliminary Use-case
– Each step in the primary scenario is evaluated by asking the
following questions
a) Can the actor take some other action at this point?
b) Is it possible that the actor will encounter some error condition at this
point? If so, what might it be?
c) Is it possible that the actor will encounter some other behavior at this
point (e.g., behavior that is invoked by some event outside the actor’s
control)? If so, what might it be?
– Answering these questions create a set of secondary scenarios
– Consider steps 6 & 7: answer the question for a) b) & c)
• One secondary scenario: “view thumbnail snapshots for all cameras”
(step 6)
• Secondary scenario: Error condition “No floor plan configured for this
house”
Secondary Scenario
• To develop an
Activity Diagram
– Supplements the use case by
providing a graphical representation of
the flow of interaction within a specific
scenario
• Rounded rectangles implies a
specific system function
• Arrows represent flow through the system
• Decision diamonds depict a branching decision
• Solid horizontal lines indicate that parallel activities are occurring
Adds additional
details not
directly
mentioned by
the use-case
• Swimlane diagrams
– Allows to represent the flow of activities described by the use case
and at the same time indicate which actor or analysis class has
responsibility for the action described by an activity rectangle.

– Responsibilities are represented as parallel segments that divide the

diagram vertically, like the lanes in a swimming pool.

– Activity diagram is rearranged so that activities associated with a

particular analysis class fall inside the swimlane for that class
• Flow-oriented Modeling
– DFD (Data Flow Diagram) complement UML diagrams & provide additional insights into
system requirements & flow
– DFD: takes an input-process-output view of a system
– Data Objects represented by labeled arrows and transformations represented by circles
– First data flow model (level 0 DFD or context diagram): fig 8.9
– Creating a Data Flow Model
• DFD enables the Software Engineer to develop models of the information domain &
functional domain at the same time
• Guidelines
– Level 0 DFD depict the software as a single bubble
– Primary i/p & o/p carefully noted
– Refinement begin by isolating candidate processes, data objects, & data stores to be
represented at the next level
– All arrows and labels should have meaningful names
– Information flow continuity maintained from level to level
– One bubble at a time should be refined
Data
objects

Primary
external
entities
• Next expand the level 0 DFD to level 1 DFD (fig. 8.10)
– Perform “Grammatical Parse” on the narrative that describes the context
level bubble
– i.e., isolate all nouns and verbs from the SafeHome Processing Narrative
 – Verbs are processes, represented as bubbles in a subsequent DFD
– Nouns are either external entities (boxes), data or control objects (arrows) or data
stores (double lines)
– Context level processes expanded to six processes; information flow between
processes at level 1 derived from the parse; information flow continuity maintained
between levels 0 &1.
– DFD level 1 further refined into lower levels (fig. 8.11)
– The process “monitor sensors” can be refined into a level 2 DFD
• Creating a Control Flow Model
– Large class of applications driven by ‘events’ rather than data,, produce control
information rather than reports or displays
– Process information with heavy concern for time & performance
– An event or control item implemented as a Boolean value or a discrete list of
conditions
– Listing all potential candidate events with the guidelines as follows:
• List all sensors that are “read” by the software
• List all interrupt conditions
 • List all “switches” that are actuated by an operator
• List all data conditions
• Describe the behavior of a system by identifying its states, identify how each
state is reached, & define the transitions between states
• Control Specification (CSPEC) => represents the behavior of the
system in 2 different ways: (fig. 8.12)
– Contains a state diagram=> sequential specification of behavior
– Program activation table => combinatorial specification of behavior
– By reviewing the state diagram, a software engineer determines the
behavior of the system & more importantly ascertain whether there are
“holes” in the specified behavior.
– Describes the behavior of the system, but gives no information about
the inner working of processes that are activated as a result of this
behavior
• Process Specification (PSPEC)=> used to describe all flow
model processes that appear at the final level of refinement
• Content of process specification includes
– Narrative text
– Program Design Language (PDL) description of the process algorithm
– Mathematical equations, tables, diagrams or charts
• Software Engineer creates a “mini-spec” => serve as a guide
for design of the software component that will implement the
process
• E.g., PSPEC for “process password” take the form:
• Class-based Modeling
– Identifying Analysis Classes
• By performing a “grammatical parse” on the use-cases or processing narratives developed
for the system to be built
• Classes determined by nouns
• What should we look for once all of the nouns have been isolated?
• Candidate classes: External Entities, events, roles, places, structures, things, organizational
units, etc.
• Taxonomy of classes suggested by Budd: producers (sources) & consumers (sinks) of data,
data managers, observer classes and helper classes
• What are not considered as classes or objects?
 • E.g. Medical Imaging system
– InvertImage
– ImageInversion Are these two are classes?

– Cashman states “the intent of object-orientation is to encapsulate, but still keep

separate, data and operations on the data”.
– For SafeHome Security function: Extracting the nouns, we can propose a number
of potential classes: (shown in the next slide)
– Coad and Yourdon suggest 6 selection characteristics that should be used as an
analyst considers each potential class for inclusion in the analysis model:
• Retained information
• Needed services
• Multiple attributes
• Common attributes
• Common operations
• Essential requirements
Potential Class General Classification
homeowner role or external entity
sensor external entity
control panel external entity
installation occurrence
system (alias security system) thing
number, type not objects, attributes of sensor
master password thing
telephone number thing
sensor event occurrence
audible alarm external entity
monitoring service organizational unit or external entity
Potential Class Characteristic Number That Applies
homeowner rejected: 1, 2 fail even though 6 applies
sensor accepted: all apply
control panel accepted: all apply
installation rejected
system (alias security function) accepted: all apply
number, type rejected: 3 fails, attributes of sensor
master password rejected: 3 fails
telephone number rejected: 3 fails
sensor event accepted: all apply
audible alarm accepted: 2, 3, 4, 5, 6 apply
monitoring service rejected: 1, 2 fail even though 6 applies
– Specifying Attributes
• What data items fully define a class in the context of problem
at hand?
• E.g. ‘system’ class
• It was noted that, homeowner can configure the security
function to reflect sensor information, alarm response
information, activation / deactivation information,
identification information, etc.
identification information = system ID + verification phone number +system
status
alarm response information = delay time + telephone number
activation/deactivation information = master password + number of allowable
tries +temporary password
– Defining operations
• Defines the behavior of an object
• Generally divided into 4 broad
categories:
– Operations that manipulate data in some way,
– Operations that perform a computation,
– Operations that inquire about the state of an object,
– Operations that monitor an object for the occurrence of a controlling
event
– Class – Responsibility – Collaborator (CRC) Modeling
• Provides a simple means for identifying and organizing the
classes that are relevant to the system or product
requirements.
• Ambler describes CRC Modeling as
A CRC model is really a collection of standard index cards that represent classes.
The cards are divided into three sections. Along the top of the card you write the
name of the class. In the body of the card you list the class responsibilities on
the left and the collaborators on the right.
– Attributes and Operations that are relevant for the class
– Required to provide a class with the information needed to complete a responsibility
• Classes: Taxonomy of class types can be extended
– Entity classes / Model classes / business classes
– Boundary classes
– Controller classes
• Responsibilities: guidelines for identifying attributes and operations
– System intelligence should be distributed across classes to best address the
needs of the problem
– Each responsibility should be stated as generally as possible
– Information and the behavior related to it should reside within the
same class
– Information about one thing should be localized with a single class,
not distributed across multiple classes.
– Responsibilities should be shared among related classes, when
appropriate.
 Design Engineering
• Goal: to produce a model or representation that exhibits firmness,
commodity and delight
• To accomplish this, designer must practice diversification and convergence
• Computer software design changes continually as new methods, better
analysis, and broader understanding evolve
• Design within the context of software engineering
– Last software engineering action within the modeling activity & sets the stage for
construction
– Flow of information during software design is shown in the fig – Translating the
Requirements model into Design model
– Data / Class design transforms analysis models into design class realizations & the
requisite data structures required to implement the software
– Architectural design defines the relationships between major structural elements
of the software, the architectural styles & design patterns
 – that can be used to achieve the requirements of the system
– The architectural design representation derived from the system
specification, the analysis model, & the interactions of subsystems
defined within the analysis model
– Interface design describes how the software communicates with
systems that interoperate with it, and with humans who use it.
– Component-level design transforms structural elements of the software
architecture into a procedural description of software components
• Importance of software design: quality
• Design Process and Design Quality
– Software design is an iterative process
– Represented at a higher level of abstraction
• As design iterations occur, subsequent refinement leads to design
representations at much lower levels of abstraction
• Throughout the design process, the quality of evolving design is assessed
with a series of formal technical reviews or design walkthroughs
• McGlaughlin’s 3 characteristics (goals) as a guide for the evaluation of a
good design:
– Design should implement all of the explicit requirements and it must
accommodate all of the implicit requirements desired by stakeholders
– Design should be a readable, understandable guide for those who generate code;
who test and subsequently support the software.
– Design should provide a complete picture of the software, addressing the data,
functional, and behavioral domains from an implementation perspective.
• Quality Guidelines – establish technical criteria for a good design
– Design should exhibit an architecture that
1. Has been created using recognizable architectural styles or patterns
2. is composed of components that exhibit good design characteristics
3. can be implemented in an evolutionary fashion
 – Design should be modular
– Design should contain distinct representations of data, architecture, interfaces, and
components
– Design should lead to data structures that are appropriate for the classes to be
implemented
– Design should lead to components that exhibit independent functional characteristics
– Design should lead to interfaces that reduce the complexity of connections between
components and with the external environment
– Design should be derived using a repeatable method that is driven by information obtained
during software requirements analysis
– Design should be represented using a notation that effectively communicates its meaning
• Quality Attributes – HP’s set of software quality attributes as acronym – FURPS –
Functionality, Usability, Reliability, Performance and Supportability
– Functionality: assessed by evaluating the feature set, capabilities of program, generality of
functions, & security of the system
– Usability: assessed by considering human factors, aesthetics, consistency and
documentation
 – Reliability: evaluated by measuring the frequency & severity of failure, accuracy of
o/p results, MTTF, ability to recover from failure, & predictability
– Performance: measured using processing speed, response time, resource
consumption, throughput, and efficiency
– Supportability: combines extensibility, adaptability, and serviceability,
maintainability, testability, compatibility, configurability
• Design Concepts
– M. A. Jackson [Jac75] once said: “The beginning of wisdom for a [software
engineer] is to recognize the difference between getting a program to work, and
getting it right.”
– Fundamental software design concepts provide the necessary framework for
“getting it right.”
– Abstraction:
• At highest level of abstraction: solution provided using the language of problem
environment
• At lower levels of abstraction: solution provided as detailed description
• Procedural and Data abstractions
• Procedural abstraction refers to a sequence of instructions that have a
specific and limited function
• E.g. “open a door”
– Walk to the door
– Reach out and grasp knob
– Turn knob
– Pull door
– Step away from moving door
• Data abstraction a named collection of data that describes a data object
• E.g. “door”
– Door type
– Swing direction
– Opening mechanism
– Weight
– Dimensions
– Architecture
– Alludes to “the overall structure of the software and the ways in which
that structure provides conceptual integrity for a system”
– To derive an architectural rendering of a system which serves as a
framework for conducting more detailed design activities
– Shaw and Garlan [Sha95a] describe a set of properties that should be
specified as part of an architectural design
• Structural properties: define “the components of a system (e.g., modules,
objects, filters) and the manner in which those components are packaged
and interact with one another”.
• Extra-functional properties: address “ how the design architecture achieves
requirements for performance, capacity, reliability, security, adaptability,
and other system characteristics”.
• Families of related systems: “draw upon repeatable patterns that are
commonly encountered in the design of families of similar systems”
 • Given the specification of these properties, the architectural design is
represented using 1 or more number of different models:
– Structural models: organized collection of program components
– Framework models: increase the level of design abstraction
– Dynamic models: addresses the behavioral aspects
– Process models: focus on the design of the business or technical process
– Functional models: represents the functional hierarchy of a system
• Number of different Architectural Description Languages (ADL) developed
to represent these models
– Patterns
• a named nugget of insight which conveys the essence of a proven solution
to a recurring problem within a certain context amidst competing
concerns
• Intent of each design pattern is to provide a description that enables a
designer to determine
 – whether the pattern is applicable to the current work
– whether the pattern can be reused and
– Whether the pattern can serve as a guide for developing a similar, but functionally or
structurally different pattern
– Separation of Concerns
• A concern is a feature or behavior that is specified as part of the requirements
model for the software
• divide-and-conquer strategy
– Modularity
• most common manifestation of separation of concerns
• Monolithic software cannot be easily grasped => no. of control paths, no. of
variables, etc.
• The cost to develop an individual module decreases as the total number of
modules increases
• However, as the no. of modules grows, the effort associated with integrating the
modules also grows.
No necessary sophistication
to predict M with assurance

Care should be taken to stay

in the vicinity of M.
Undermodularity and
Overmodularity should be
avoided

– Information Hiding
• How do we decompose a software solution to obtain the best set of
modules?
• Principle: modules be “characterized by design decisions that each hides
from all others”
• Hiding defines & enforces access constraints to both procedural detail
within a module & any local data structure used by the module handover
– Functional Independence
• Direct outgrowth of modularity and the concepts of
abstraction and information hiding
• Design software so that each module addresses a specific sub-
function of requirements
• Has a simple interface
• Easier to maintain
• Error propagation is reduced
• Reusable modules are possible
• Independence assessed using 2 qualitative criteria:
– Cohesion: indication of relative functional strength of a module
– Coupling: indication of relative interdependence among modules
 • Cohesion
– Natural extension of the information hiding concept
– Should ideally do just one thing
• Coupling
– Depends on the interface complexity between modules, the point at which entry or
reference is made to a module & what data pass across the interface
– Refinement
• A process of elaboration
• Abstraction and Refinement are complementary concepts
• Refinement helps the designer to reveal low-level details as design
progresses
– Refactoring
• Important design activity for agile methods
• “Is the process of changing a software system in such a way that it does not
alter the external behavior of the design yet improves its internal structure”.
 • Existing design is examined for
– Redundancy
– Unused design elements
– Inefficiency or Unnecessary algorithms
– Poorly constructed or inappropriate data structures
– Design classes
• As the design model evolves, the software team must define a set of design
classes that
(i) Refine the analysis classes by providing design detail that will enable the
classes to be implemented &
(ii) Create a new set of design classes that implement a software
infrastructure to support the business solution
• 5 different types each representing a different layer of design
architecture are suggested:
– User Interface Classes: define all abstractions that are necessary for
human computer interactions
– Business domain Classes: are often refinements of the analysis classes
– Process Classes: implements lower-level business abstractions required
to fully manage the business domain classes
– Persistent Classes: represent data stores that will persist beyond the
execution of the software
– System Classes: implement software management and control
functions that enable the system to operate and communicate within
its computing environment and with the outside world
• Each design class is reviewed to ensure that it is “well-formed”
which define 4 characteristics:
– Complete and sufficient
– Primitiveness: methods associated with a design class should
be focused on accomplishing one service for the class
– High cohesion: small, focused set of responsibilities and
single-mindedly applies attributes and methods to implement
those responsibilities
– Low coupling: design classes within a subsystem should have
only limited knowledge of classes in other subsystems. This
restriction is called “ Law of Demeter” and suggest that a
method should only send messages to methods in
neighboring classes
represents the level of detail as each element indicates the evolution of the design model
of the analysis model is transformed into a as design tasks are executed as part of the
design equivalent and then refined iteratively software process

– The Design Model

– Elements of the design model use many of the same UML
diagrams that were used in the analysis model
7

– Difference:
• refined and elaborated as part of the design
• More implementation specific detail is provided
• Architectural structure and style, components that reside within the
architecture and
• Interfaces between the components and with the outside world
– Design model has 4 major elements
• Data design elements
• Architectural design elements
• Interface design elements
• Component-level design elements
 – Data Design Elements
• creates a model of data and/or information that is represented
at a high level of abstraction.
Structure of the data Always been an important part of software design
At the program-component level the design of data structures and the associated
algorithms required to manipulate them is essential to
the creation of high- quality applications.
At the application level the translation of a data model (derived as part of
requirements engineering) into a database is pivotal to
achieving the business objectives of a system
At the business level the collection of information stored in distinct
databases and reorganized into a “data warehouse”
enables data mining or knowledge discovery that can
have an impact on the success of the business itself.
– Architectural Design Elements
• Equivalent to the floor plan of a house which gives us an
overall view of the house
• Give us an overall view of the software
• the model derived from 3 sources:
– Information about the application domain for the software to be built
– specific requirements model elements such as use cases or analysis
classes, their relationships & collaborations for the problem at hand &
– the availability of architectural styles and patterns
– Interface Design Elements
• Equivalent to a set of detailed drawings for the doors,
windows, & external utilities of a house
• Detailed drawings tells us how things and information flow into
and out of the house and within the rooms that are part of the
floor plan
• Depict information flows into and out of a system and how it is
communicated among the components defined as part of the
architecture
• 3 important elements of interface design:
1. The user interface (UI)
2. External interfaces to other systems, devices, networks, or other
producers or consumers of information
3. Internal interfaces between various design components
• UI design incorporates
– Aesthetic elements
– Ergonomic elements (e.g., information layout and placement,
metaphors, UI navigation)
– Technical elements (e.g., UI patterns, reusable components)
• External Interface design incorporates
 – Error checking and appropriate security features
• Design of internal interface closely aligned with component-
level design
• To enable communication and collaboration between
operations in classes => messaging
• Messaging: designed to accommodate the requisite information
transfer and the specific functional requirements of the
operation that has been requested
• In UML, an interface is defined as:
– “An interface is a specifier for the externally-visible operations of a class,
component, or other classifier without specification of internal
structure”
– More simply stated “an interface is a set of operations that describes
some part of the behavior of a class and provides access to these
operations”
 – E.g. SafeHome Security Function
– Interface: Control Panel class

ControlPanel class provides

KeyPad operations as part
of its behavior.

In UML, this is characterized as

a realization. That is, part of
the behavior of ControlPanel
will be implemented by
realizing KeyPad operations.
These operations will be
provided to other classes that
access the interface
– Component-level Design Elements
• Equivalent to a set of detailed drawings for each room in a
house
• Component-level design for software fully describes the
internal design of each software component
• To accomplish this, the component-level design defines data
structures for all local data objects and algorithmic detail for all
processing that occurs within a component and an interface
that allows access to all component operations
– Deployment-level Design Elements
• Indicate fhow software functionality and subsystems will be
allocated within the physical computing environment that will
support the software.
• E.g. SafeHome Product
– Configured to operate within 3 primary computing environments
» A home-based PC,
» The Safe-Home control panel, and
» A server (providing Internet services)
– Descriptor form
– Deployment diagram shows the computing environment but does not
explicitly indicate configuration details
 Creating an Architectural Design
• Objective: to provide a systematic approach for the derivation of the
architectural design – preliminary blueprint from which the software
is constructed
• Software Architecture
– Shaw and Garlan in 1996
“Ever since the first program was divided into modules, software systems have had
architectures, and programmers have been responsible for the interactions among the
modules and the global properties of the assemblage. Historically, architectures have been
implicit—accidents of implementation, or legacy systems of the past. Good software
developers have often adopted one or several architectural patterns as strategies for system
organization, but they use these patterns informally and have no means to make them explicit
in the resulting system”

“The –software architecture and

Bass, Clements, of a program
Kazman’sor definition
computing system is the structure or structures of
the system, which comprise software components, the externally visible properties of those
components, and the relationships among them.”
– Architecture is not the operational software
– It is a representation that enables a software engineer to
1. Analyze the effectiveness of the design in meeting its stated
requirements
2. Consider architectural alternatives at a stage when making design
changes is still relatively easy, and
3. Reduce the risks associated with the construction of the software
– In the context of architectural design, a software component
can be => a simple program module, or an object-oriented
class, or it can be extended to include databases and
middleware
– The design of software architecture considers 2 levels of the
design pyramid – data design and architectural design
 Data Design
• Data Design
– To represent the data component of the architecture in conventional
systems and class definitions in object-oriented systems
• Architectural Design
– Focuses on the representation of the structure of software
components, their properties and interactions
• Data design action 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
– Big Data / Databases with hundreds of TeraBytes
– How to extract useful information from this data environment,
particularly when the information desired is cross-functional?
 – Solution:
• Data mining techniques, also called Knowledge Discovery in Databases
(KDD) that navigate through existing databases in an attempt to extract
appropriate business-level info
• Also have Data Warehousing which adds an additional layer to the data
architecture
• A data warehouse is a separate data environment that is not directly
integrated with day-to-day applications but encompasses all data used by a
business
• A large, independent database that has access to the data that are stored in
databases that serve the set of applications required by a business
• Data Design at the Component level
– A set of principles used to specify and design data structures
• The systematic analysis principles applied to function and behavior should
also be applied to data
• All data structures and the operations to be performed on each
should be identified
• A mechanism for defining the content of each data object should be
established and used to define both data and the operations applied
to it
• Low-level data design decisions should be deferred until late in the
design process
• The representation of a data structure should be known only to those
modules that must make direct use of the data contained within the
structure: concept of Information Hiding and the related concept of
Coupling
• A library of useful data structures and the operations that may be
applied to them should be developed
• A software design and programming language should support the
specification and realization of abstract data types
 Architectural Styles and Patterns
• Architectural style – a template for construction; is a transformation
that is imposed on the design of an entire system
• Software built exhibits one of many architectural styles; each style
describes a system category that encompasses
1. A set of components that perform a function required by a system
2. A set of connectors that enable “communication, coordination, and
cooperation” among components
3. Constraints that define how components can be integrated to form the
system and
4. Semantic models that enable a designer to understand the overall properties
of a system by analyzing the known properties of its constituent parts
• An Architectural pattern – imposes a transformation on the design
of an architecture
• But a pattern differs from a style in a number of fundamental ways:
 1. The scope of a pattern is less broad, focusing on one aspect of the architecture
rather than the architecture in its entirety
2. A pattern imposes a rule on the architecture, describing how the software will
handle some aspect of its functionality at the infrastructure level (e.g., concurrency)
3. Architectural patterns tend to address specific behavioral issues within the context
of the architecture
• A Brief Taxonomy of Architectural Styles
– Data-Centered Architectures
– Data-Flow Architectures
– Call and Return Architectures:
To achieve a program structure that is relatively
easy to modify and scale.
• Main program / subprogram Architectures
• Remote Procedure Call Architectures
– Object-oriented Architectures
– Layered Architectures
 Client software accesses the data independent
of any changes to the data or the actions of
other client software.

promote integrability, i.e., existing components can be changed and new

client components added to the architecture without concern about other
clients

update, add,
delete, or
otherwise
modify data
within the store

In some cases the data

repository is passive.
Client components independently execute
processes.
 Each filter works independently of those components
upstream and downstream, is designed to expect data
input of a certain form, and produces data output (to
the next filter) of a specified form

Applied when input data are to

be transformed through a series of
computational or manipulative
components into output data.

A pipe-and-filter pattern ( Figure 13.2

) has a set of components, called If the data flow degenerates into a single line of
filters , connected by pipes that transforms, it is termed batch sequential.
transmit data from one component This structure accepts a batch of data and then applies a
to the next. series of sequential components (filters) to transform it
 Agile
• Definition
– A software development methodology to build a software
incrementally using short iterations of 1 to 4 weeks so that the
development process is aligned with the changing business needs
• Roles in Agile Adopts a process of
– Scrum Master frequent feedback
• is a team leader and facilitator who helps the team members to follow
agile practices so that they can meet their commitments
• Responsibilities
– To enable close co-operation between all roles and functions
– To remove any blocks
– To shield the team from any disturbances
– To work with the organization to track the progress and processes of the company
– To ensure that Agile Inspect & Adapt processes are leveraged properly which
includes
 » Daily stand-ups,
» Planned meetings,
» Demo,
» Review,
» Retrospective Meetings, &
» To facilitate team meetings and decision-making process
– Product Owner
• is the one who drives the product from business perspective. The
responsibilities of a Product Owner are as follows:
– To define the requirements and prioritize their values
– To determine the release date and contents
– To take an active role in iteration planning and release planning meetings
– To ensure that team is working on the most valued requirement
– To represent the voice of the customer
– To accept the user stories that meet the definition of done and defined
acceptance criteria
– Cross-Functional Team
• A self-sufficient team with 5 to 9 team members
• Average experience of 6 to 10 years
• An agile team comprises of
– 3 to 4 developers
– 1 tester
– 1 technical lead
– 1 product owner &
– 1 scrum master
• How an Agile Team plans its work?
–An Agile team works in iterations to deliver user stories where each iteration is of 10 to 15 days
–Each user story is planned based on its backlog prioritization and size
–The team uses its capacity: how many hours are available with team to work on tasks − to
decide how much scope they have to plan?

–Point A Point defines how much a team can commit. A point usually refers to 8 hours. Each
story is estimated in points.
 – Capacity: Capacity defines how much an individual can commit. Capacity
is estimated in hours.
• What is a User Story?
– a requirement which defines what is required by the user
as functionality
– Two forms:
• As a <User Role> I want <Functionality> so that <Business Value>
• In order to <Business value> as a <User Role> I want
<Functionality>
– During release planning, a rough estimate is given to a
user story using relative scale as points. During iteration
planning, the story is broken down into tasks
• Relationship of User stories and tasks
User stories Tasks
Talks about what is to be done ; Talks about how it is to be done ;
It defines what a user needs It defines how a functionality is to be
implemented
Each story is a collection of tasks Stories are implemented by tasks
User story is divided into tasks when it is Tasks are estimated in hours, typically
planned in current iteration from 2 to 12 hours
Stories are validated using acceptance
tests
• Create an Initial Product Backlog
– Product Backlog is a dynamic prioritized source for all the work that
needs to be done to deliver a product. This artifact is product focused
not system focused.
• A product backlog consists of:
– Features
– Enhancements
– Defects
– Non IT Deliverables
• Example:
– As the mail room I must scan mortgage applications from the customer
so that they can be processed
– As the system I must load scanned images so they are available to the
indexing user
– As the indexer I want to be able to view a list of all applications requiring
indexing
• What information do we capture in the product backlog?
– The details below provide a guideline to what information you
may want to capture in a product backlog
• An example is shown below:
• When a Story is Done
– The team decides what done means. The criteria may be:
• All tasks (development, testing) are completed.
• All acceptance tests are running and are passed.
• No defect is open.
• Product owner has accepted the story.
• Deliverable to the end-user
• What is Acceptance Criteria?
– Criteria defines the functionality, behavior, and performance required by a feature so
that it can be accepted by the product owner
– It defines what is to be done so that the developer knows when a user story is
complete.
• How the Requirements are Defined?
– Requirements are defined as
• A User Story,
• With Acceptance Criteria, and
• Tasks to implement the story
 Agile – Manifesto

•For software development…

–To uncover better ways of developing software by doing it & helping others do it, the software experts
value,
•Individuals and interactions over Processes and tools
•Working software over Comprehensive documentation
•Customer collaboration over Contract negotiation
•Responding to change over Following a plan
•Twelve Principles of Agile Manifesto
1.
Customer Satisfaction: highest priority given
2.
Welcome Change: Ever-changing requirements should be welcome, even late in the development
phase
3.
Deliver a Working Software: frequently, considering a shorter time-scale
4.
Collaboration: Business people and developers work together during the entire life of the project
5.
Motivation: trust the individual team members so as to make them feel responsible to get the
job done.
6.
Face-to-face Conversation: most effective and efficient method of conveying information
7.
Measure the Progress as per the Working Software:
•
 8. Maintain Constant Pace: Agile processes aim towards sustainable
development. The business, the developers, and the users should be able
to maintain a constant pace with the project
9. Monitoring: technical excellence and good design to enhance agility
10.Simplicity: use simple terms to measure the work that is not completed.
11. Self-organized Teams: best architectures, requirements, and designs
emerge from self-organized teams
12.Review the Work Regularly: reflect on how to become more effective and
adjust its behavior accordingly
• Agile – Characteristics
– Iterative: no direct long-term planning for any requirement; iterations are
planned of very short period of time
– Incremental: a cross-functional team created for each iteration that works in
all functions of software development
– Ready to evolve: result at the end of iteration is a working product and
demonstrated to the stakeholders.
 after demo, review comments are taken and planned to be
incorporated in the working software as required
– Face-to-face Communication: product owner act on behalf of
stakeholders and answer the queries of the developers in between
iterations;
Information Radiator located in the premise that shows an up-to-date
summary of the status of a project
– Feedback Loop: is a kind of a brief session where each team member
reports to each other regarding the status of what they have done,
what to do next, and any issues they are facing.
• Also, known as Daily Scrum (Daily Stand-up) and is a common culture of
any Agile development
• Agile Daily Stand-up
– is a daily status meeting among all the members of an agile
team & it is held roughly for 15 minutes.
– provides a forum for regular updates
– brings the problems of team members into focus so that it can
be quickly addressed
– is a must-do practice, no matter how an agile team is established
regardless of its office location
– Every member has to answer three important questions:
• What I did yesterday?
• What I'll do today?
• Any obstacle I am facing.../ I am blocked due to...
– is for status update, not for any discussion
 – Benefits
• The team can evaluate the progress on a daily basis and see if they can deliver as per the
iteration plan
• Each team member informs all about his/ her commitments for the day
• It provides visibility to the team on any delay or obstacles
– Attendees
• Scrum Master: responsible to take note of each team member’s queries & the problems
they are facing
• Product owner
• Delivery team
• Stakeholders
• Customers act as observers only
• Agile – Definition of Done
– Definition of Done for User Story, Iteration and Release
– User Story
• A requirement formulated in a few sentences (user’s language) and should
be completed within an iteration
 • A user story is done when
– All the related code have been checked-in.
– All the unit test cases have been passed.
– All the acceptance test cases have been passed.
– Help text is written.
– Product Owner has accepted the story.
– Iteration
• is a time boxed collection of user stories / defects to be worked upon and
accepted within the release of a product
• defined during iteration planning meeting and completed with an iteration
demo and review meeting
• Also termed as a Sprint
• An iteration is done when
– Product backup is complete
– Performance has been tested
– User stories have been accepted or moved to the next iteration
– Defects have been fixed or postponed to the next iteration
 – Release
• is a major milestone that represents an internal or external delivery of
working, tested version of the product/system
• A release is done when
– System is stress tested.
– Performance is tuned.
– Security validations are carried out.
– Disaster recovery plan is tested.
• Agile – Release Planning
– Purpose: to create a plan to deliver an increment to the product; It is done
after every 2 to 3 months
– Who is involved?
• Scrum Master
• Product Owner
• Agile Team
• Stakeholders
– Prerequisites of Planning
• A ranked product backlog, managed by the Product Owner
• Generally 5 to 10 features are taken which the product owner feels that can be
included in a release
• Team's input about capabilities, known velocity or about any technical challenge
• High-level vision
• Market and Business objective
• Acknowledgement whether new product backlog items are needed
– Materials required
• Posted agenda, purpose
• Flip charts, whiteboards, markers
• Projector, way to share computers having data/tools required during planning
meeting
• Planning data
– Planning Data
• List of data required to do release planning
– Previous iterations or release planning results
– Feedback from various stakeholders on product, market conditions, and deadlines
– Action plans of previous releases / iterations
– Features or defects to be considered
– Velocity from previous releases/ estimates
– Organizational and personal calendars
– Inputs from other teams and subject matter experts to manage any dependencies
– Output
• Release plan
• Commitment
• Issues, concerns, dependencies, and assumptions which are to be
monitored
• Suggestions to improve future release plannings
• Agenda
– Opening ceremony
– Product Vision, Roadmap
– Review previous releases
– Release name / theme
– Velocity
– Release schedule
– Issues and concerns
– Review and Update the Definition of Done
– Stories and items to be considered
– Determine sizing values
– Coarse the size of stories
– Map stories to iterations
– New concerns or issues
– Dependencies and assumptions
– Commit
– Communication and logistics planning
– Parking lot
– Distribute Action items and action plans
– Retrospect
– Close
 • Agile – Iteration Planning
– Purpose: to complete the set of top-ranked product backlog items by the
team
– This commitment is time boxed based on the length of iteration and team
velocity.
– Who is involved?
Release Planning Iteration Planning
Scrum Master acts as a facilitator for the agile acts as a facilitator for the agile delivery
delivery team team

Product Owner represents the general view of deals with the detailed view of the
the product backlog product backlog and their acceptance
criteria

Agile Team provides insights on the technical defines their tasks and sets the effort
feasibilities or any dependencies estimates required to fulfill the
commitment
– Prerequisites of Planning
• Items in product backlog are sized and have a relative story point assigned
• Ranking given to portfolio items by the product owner
• Acceptance criteria clearly stated for each portfolio item
– Planning Process
• Determine how many stories can fit in an iteration
• Break these stories into tasks and assign each task to their owners.
• Each task is given estimates in hours
• These estimates help team members to check how many task hours each
member have for the iteration
• Team members are assigned tasks considering their velocity or capacity so
that they are not overburdened
– Velocity Calculation
• Velocity is an average number of units required to finish user stories in an
iteration
• An agile team calculates velocity based on past iterations
 • Planned velocity tells the team how many user stories can be completed in
the current iteration
• If the team quickly finishes the tasks assigned, then more user stories can
be pulled in
• Otherwise, stories can be moved out too to the next iteration
– Task Capacity
• Derived from the following three facts
– Number of ideal working hours in a day
– Available days of person in the iteration
– Percentage of time a member is exclusively available for the team
– Planning Steps
• Product Owner describes the highest ranked item of product backlog
• Team describes the tasks required to complete the item
• Team members own the tasks
• Team members estimate the time to finish each task
• These steps are repeated for all the items in the iteration
• If any individual is overloaded with tasks, then his/her task is distributed
among other team members
DESIGN ENGINEERING
 PRODUCT METRICS
• Direct measures are unusual in the software world
• Software metrics are indirect
• Measures used to assess the quality of the software product as it is
being engineered
• Software Quality is conformance to explicitly stated functional and
performance requirements, explicitly documented development
standards, and implicit characteristics that are expected of all
professionally developed software.
– Software requirements: foundation from which quality is measured; Lack of
conformance to requirements is lack of quality
– Specified standards: define a set of development criteria that guide the
manager in which the software is engineered
– If software conforms to its explicit requirements but fails to meet implicit
requirements, quality is compromised
• Mccall’s Quality factors
– propose a useful categorization of factors that affect software quality.
– focus on three important aspects of a software product: its operational
characteristics, its ability to undergo change, and its adaptability to new
environments
• McCall and his colleagues provide the following descriptions:
– Correctness - The extent to which a program satisfies its specification and fulfills
the customer’s mission objectives
– Reliability.
– Efficiency.
– Integrity - Extent to which access to software or data by unauthorized persons
can be controlled.
– Usability
– Maintainability
– Flexibility
– Testability
– Portability.
– Reusability
– Interoperability
• Difficult to develop direct measures of these quality factors
• ISO 9126 Quality Factors
– Was developed to identify quality attributes for computer
software
– Functionality: degree to which the software satisfies stated
needs as indicated by the following sub-attributes:
• suitability, accuracy, interoperability, compliance, and security.
– Reliability: amount of time that the software is available
for use as indicated by the following sub-attributes
• Maturity, fault tolerance, recoverability
– Usability: degree to which the software is easy to use as
indicated by the following sub-attributes
• understandability, learnability, operability
 – Efficiency: degree to which the software makes optimal use of
system resources as indicated by the following sub-attributes
• Time behavior, resource behavior.
– Maintainability: The ease with which repair may be made to the
software as indicated by the following sub-attributes
• analyzability, changeability, stability, testability.
– Portability: The ease with which the software can be transposed
from one environment to another as indicated by the following
sub-attributes
• adaptability, installability, conformance, replaceability
• The transition to a Quantitative view
– Quality is subjective, a more precise definition of software quality is
needed as a way to derive quantitative measurements of software
quality for objective analysis
• A framework for Product Metrics
– Within the software engineering context,
• Measure : provides a quantitative indication of the extent, amount,
dimension, capacity, or size of some attribute of a product or process
• Measurement: the act of determining a measure.
• Metric: “a quantitative measure of the degree to which a system,
component, or process possesses a given attribute”.
– A software engineer collects measures and develops metrics so
that indicators will be obtained
– Indicator: a metric or combination of metrics that provides insight
into the software process, a software project, or the product itself.
– When a single data point has been collected (e.g., the number of
errors uncovered within a single software component), a measure
has been established
– Measurement occurs as the result of the collection of one or more data points
(a number of component reviews and unit tests are investigated to collect
measures of the number of errors for each).
– Software metric relates the individual measures in some way (e.g., the average
number of errors found per review or the average number of errors found per unit
test)
– What are the steps of an effective measurement process?
• Formulation
• Collection
• Analysis
• Interpretation
• Feedback
– Software metrics are useful only if they are characterized effectively & validated so
that their worth is proven:
• A metric should have desirable mathematical properties
• When a metric represents a software characteristic that increases when positive traits occur
or decrease when undesirable traits are encountered, the value of metric should increase or
decrease in the same manner
 – Each metric should be validated empirically in a wide variety of contexts before
being published or used to make decisions
• The Product Metrics Landscape
– Metrics for the Analysis model
• Functionality delivered
• System size
• Specification quality
– Metrics for the Design model
• Architectural metrics
• Component-level metrics
• Interface design metrics
• Specialized OO design metrics
– Metrics for Source code
• Halstead metrics
• Complexity metrics
• Length metrics
– Metrics for testing
• Statement and Branch coverage metrics
• Defect-related metrics
• Testing Effectiveness
• In-process metrics
– Function-based Metrics
• FP metric
• Function points derived using an empirical relationship based on direct
measures of software’s information domain & assessments of software
complexity
• Information domain values:
– No. of external inputs
– No. of external outputs
– No. of external queries
– No. of internal logic files (ILF)
– No. of external interface files (EIF)
• Organizations that use function point methods develop criteria for
determining whether a particular entry is simple, average or complex
• To compute FPs, the following relationship holds:
– FP = count total x [0.65 + 0.01 x ∑ (Fi)]
– Fi (i=1 to 14) are value adjustment factors (VAF) based on responses to the
following questions: