Lecture 2
Introduction to Software
Engineering
Engr. Hafiza Sundus Waleed
Today’s Overview
• Software Engineering Practices
• General Principles of Software Engineering
• Generic Process Model
• Process Flow
• Defining a Framework Activity
• Identifying the Task Set
• Process Pattern
• Process Pattern Types
• Process Pattern Template
Software Engineering Practice
How does the practice of software engineering fit in? for this, gain a basic
understanding of the generic concepts and principles that apply to framework
activities.
1. Understand the problem (communication and analysis).
2. Plan a solution (modeling and software design).
3. Carry out the plan (code generation).
4. Examine the result for accuracy (testing and quality assurance).
SE Practice: Understand the problem
Spend a little time answering a few simple questions:
• Who has a stake in the solution to the problem?
That is, who are the stakeholders?
• What are the unknowns?
What data, functions, and features are required to properly solve the problem?
• Can the problem be compartmentalized?
Is it possible to represent smaller problems that may be easier to understand?
• Can the problem be represented graphically?
Can an analysis model be created?
SE Practice: Plan the Solution
Spend a little time answering a few simple questions:
• Have you seen similar problems before?
Are there patterns that are recognizable in a potential solution? Is there existing
software that implements the data, functions, and features that are required?
• Has a similar problem been solved?
If so, are elements of the solution reusable?
• Can sub problems be defined?
If so, are solutions readily apparent for the sub problems?
• Can you represent a solution in a manner that leads to effective
implementation?
Can a design model be created?
SE Practice: Carry out the Plan
The design you’ve created serves as a road map for the system you want to
build. There may be unexpected detours, and it’s possible that you’ll discover
an even better route as you go, but the “plan” will allow you to proceed
without getting lost.
• Does the solution conform to the plan?
Is source code traceable to the design model?
• Is each component part of the solution provably correct?
Have the design and code been reviewed, or better, have correctness proofs been
applied to the algorithm?
SE Practice: Examine the Results
You can’t be sure that your solution is perfect, but you can be sure that you’ve
designed a sufficient number of tests to uncover as many errors as possible.
• Is it possible to test each component part of the solution?
Has a reasonable testing strategy been implemented?
• Does the solution produce results that conform to the data, functions, and
features that are required?
Has the software been validated against all stakeholder requirements?
General Principles
David Hooker has proposed seven principles that focus on software
engineering practice as a whole. They are reproduced as:
• The First Principle: The Reason It All Exists.
A software system exists for one reason: to provide value to its users. Ask yourself:
“Does this add real value to the system?” If the answer is “no,” don’t do it. All other
principles support this one.
• The Second Principle: Keep It Simple, Stupid!
All design should be as simple as possible, but no simpler. This facilitates having a
more easily understood and easily maintained system.
• The Third Principle: Maintain the Vision
A clear vision is essential to the success of a software project. Without one, a project
almost unfailingly ends up being “of two [or more] minds” about itself.
General Principles Contd.
• The Fourth Principle: What You Produce, Others Will Consume
Always specify, design, and implement knowing someone else will have to
understand what you are doing!
• The Fifth Principle: Be Open to the Future
A system with a long lifetime has more value. The systems must be ready to adapt
to changes in future.
• The Sixth Principle: Plan Ahead for Reuse
Planning ahead for reuse reduces the cost and increases the value of both the
reusable components and the systems into which they are incorporated.
• The Seventh principle: Think!
Placing clear, complete thought before action almost always produces better results.
When you think about something, you are more likely to do it right.
Generic Process
Model
Process Flow
• 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. Common types Process Flow are:
1. Linear Flow
2. Iterative Flow
3. Evolutionary Flow
4. Parallel Flow
Contd.
Contd.
Defining a Framework Activity
• Different projects demand different task sets.
The software team chooses the task set based on problem and project characteristics
• For a small software project with simple requirements
The communication activity can be conducted using a phone call or email
Action is phone conversation
Task Set
Make contact with stakeholder via telephone
Discuss requirements and develop notes
Organize notes into a brief written statement of requirements
Email to stakeholder for review and approval
Defining a Framework Activity
• For complex project the activity can be divided into different actions.
The possible actions for activity Communication:
Inception, Elicitation, Elaboration, Negotiation, Specification, and
Validation
Each actions would have many work tasks and a number of distinct work products.
Identifying a Task Set
• A task set defines the actual work to be done to accomplish the objectives of
a software engineering action.
• For a small simple project, the task set for elicitation or requirement
gathering (An Action) can be:
Make a list of stakeholders for the project.
Discuss requirements and build a final list.
Prioritize requirements.
Note areas of uncertainty.
Identifying a Task Set
• For complex project, the task set for elicitation or requirement
gathering (An Action) can be:
Make a list of stakeholders for the project.
Interview each stakeholder separately
Build a preliminary list of functions and features based on stakeholder input.
Schedule a series of facilitated application specification meetings.
Conduct meetings.
Build a revised list of stakeholder requirements.
Use quality function deployment techniques to prioritize requirements.
Package requirements so that they can be delivered incrementally.
Note constraints and restrictions that will be placed on the system.
Discuss methods for validating the system.
Process Patterns
• A process pattern
Describes a process-related problem that is encountered during software
engineering work;
Identifies the environment in which the problem has been encountered;
Suggests one or more proven solutions to the problem.
• Generally, a process pattern provides you with a template:
A consistent method for describing problem solutions within the context of the
software process.
• A Patterns might be associated with:
process model (e.g., prototyping)
framework activity (e.g., planning )
an action within a framework activity (e.g., project estimating)
Process Pattern Types
• Stage patterns
defines a problem associated with a framework activity for the process. E.g.
Establishing Communication
• Task patterns
defines a problem associated with a software engineering action or work task.
E.g. Requirements Gathering
• Phase patterns
define the sequence of framework activities that occur with the process, even
when the overall flow of activities is iterative in nature. E.g. Spiral Model or
Prototyping
Process Pattern Template
• Ambler has proposed a template for describing a process pattern as:
Pattern Name: TechnicalReviews
Type: Task Pattern
Initial Context: Initial Condition when pattern applied
Problem: specific problem to be solved
Solution: how to implement the pattern successfully
Resulting Context: condition after pattern implemented
Related Patterns: list of process patterns related to this one
Known uses and examples: specific instance where pattern is applicable
Thank you!
