Software

Engineering

By Miss Nida E Rub

Course Introduction
Course Outline
• Nature of Software
• Overview of Software Engineering
• Professional software development
• Software engineering practice
• Software process structure
• Software process models
• Agile software Development
• Agile process models
• Agile development techniques
• Requirements engineering process
• Functional and non-functional requirements
• Context models
Course Outline
• Interaction models
• Structural models
• behavioral models
• model driven engineering
• Architectural design
• Design and implementation
• UML diagrams
• Design patterns
• Software testing and quality assurance
• Software evolution
• Project management and project planning
• configuration management
• Software Process improvement
Chapter # 2

PROCESS MODELS
2.1 A GENERIC PROCESS MODEL
Software process includes :
Tasks – Focus on a small, specific
objective.
Action – Set of tasks that produce a major
work product.
Activities – Group of related tasks and
actions for a major objective.
2.1 A GENERIC PROCESS MODEL
• A generic process framework for software
engineering defines five framework activities—
communication, planning, modeling,
construction, and deployment.
• In addition, a set of umbrella activities—project
tracking and control, risk management, quality
assurance, configuration management, technical
reviews, and others—are applied throughout the
process.
2.1 A GENERIC PROCESS MODEL
Process Flow
• Describes how the framework activities and the
actions and tasks that occur within each
framework activity are organized with respect to
sequence and time.
2.1 A GENERIC PROCESS MODEL
• A linear process flow executes each of the
five framework activities in sequence,
beginning with communication and
culminating with deployment
2.1 A GENERIC PROCESS MODEL
• . An iterative process flow repeats one or more
of the activities before proceeding to the next
2.1 A GENERIC PROCESS MODEL
• An evolutionary process flow executes the
activities in a “circular” manner. Each circuit
through the five activities leads to a more
complete version of the software
2.1 A GENERIC PROCESS MODEL
• A parallel process flow executes one or more
activities in parallel with other activities
• (e.g., modeling for one aspect of the software
might be executed in parallel with construction of
another aspect of the software).
 2.1.1 Defining a Framework Activity
Consider communication activity.
• For small project, this can be defined as having tasks set:
• Making a phone call with stakeholder.
• Discuss requirements and note them down.
• Organize requirements.
• Mail stakeholder for review and approval.
• For large projects -- This may have extended actions such as
• Feasibility Study: A feasibility study aims to provide an independent
assessment that examines all aspects of a proposed project
• Elicitation Of Requirements: The process of communicating and
collaborating with key stakeholders to assemble the insight and identify
the project's needs.
• Elaboration Of Requirements: Identifying the user stories first
• Specification Documents
• Validation: Requirements are complete and consistent ac- cording to
user requirements.
2.1.2 Identifying a task set
• Task set is the actual work to be done to achieve an objective
of engineering action.
• For small project, consider elicitation action in communication
activity
• This may include :
• Prepare a list of stakeholders of the project.
• Organize a meeting for stakeholders.
• Discuss requirements.
• Finalize requirements list.
• Make a list of issues raised.
• For large projects extraneous steps may be added to
elicitation such as interviewing each stakeholderseparately
before the group meeting, more techniques are applied in
discussing requirements…etc.
2.1.3 Process Patterns
• Process patterns are patterns used to
describe problems and their solutions in
the context of software process.
• Problems can arise at different levels such
as :
• Problems associated with a complete
process model
• Within a framework activity
• Within an action in an activity
2.1.3 Process Patterns
• Patterns can be described using a pattern template which
include :
• Pattern name
• Intent (describes process pattern in one or two paragraphs)
• Forces and Types (environment in which problem is
encountered is identified and the type of pattern is specified)
• Stage pattern – explains problems related to framework activity
and it may include multiple task patterns as well.
Example: ‘Establishing Communication’ (stage pattern) includes
‘Requirements Gathering'(task pattern)
• Task pattern – describes problems related to software
engineering action or task such as Requirements Gathering.
• Phase pattern – defines a sequence of framework activities and
ensures each section in the activity is addressed correctly such as
in prototyping, spiral model etc.
2.1.3 Process Patterns
• Initial context – Situation to which the pattern is applied.
Defines work done so far before the pattern is applied. Actions
and activities that have taken place before the pattern is
introduced.
• Problem – Specific problem that is to be solved by the
pattern.
• Solution – Implements pattern and initial context is modified
to resolve the problem.
• Resulting context – Situation which will result from carrying
out the process pattern solution.
• Related patterns – A list of patterns related to the current one
is documented for further reference.
• Known uses or examples – Indicates where or how the
process pattern is applicable.
2.1.3 Process Patterns (An example:)
• Pattern name – requirements unclear.
• Intent – an approach to build a prototype so that stakeholder
can assess and determine specific requirements.
• Type – phase pattern.
• Initial context – stakeholders have been identified,
communication mode has been selected, initial understanding
of problem and scope of the project determined.
• Problem – recognized that stakeholder has a general idea of
requirements and cannot place specific requirements.
• Solution – prototyping can help the stakeholder to be more
specific about requirements and hence prototype can be
evolved.
2.1.3 Process Patterns (An example:)
• Resulting context – a prototype fulfilling basic requirements is
approved by stakeholder and the prototype may be evolved or
thrown for making a new one which will become the finished
product.
• Related patterns – customer communication, iterative design,
requirement extraction.
• Known uses/examples – unclear requirements problem can
be solved through prototyping.