What is Software Engineering?
Why do we need it?
• I already know how to code --- I am good programmer.
• I have been developing systems for years.
• I have been supporting systems and answering tough
customers questions for years.
• We are using Agile process and we are just cool --making a lot of money in the process.
What is Software Engineering
•
Software Engineering has 2 main parts:
1.
Identification and Analysis of “problems”
2. Identification, Synthesis, and Construction of the
“solution” to the problem.
See page 3,5,11
of text
(not that
SIMPLE)
Yes, support and maintenance is important, and it also includes
of the above two portions, too.
Software Engineering
• In identifying and analyzing software problems, we use:
– techniques: elicitation, documentation, prototyping, reviews, etc.
– business knowledge: domain specific info., business flow, etc.
• In solving problems software engineering employs:
– Methodology or Technique: (e.g.) designing, programming, testing,
integrating, etc. which are directly related to the end product
– Tools: (e.g.) development platform, version control, visual diagram,
etc.
– Procedure & Policies: (e.g.) inspection/review, tracking, metrics,
change management, etc. which are indirectly related to the product
– Process / Paradigm : (e.g.) Waterfall, Spiral, Incremental, etc. which
are a combination of methodology, tools, and procedures
Anything missing in the problem identification and analysis part? Tools?, etc.
Software Engineering & Other Disciplines
• Software Engineers uses the “computing” theories, tools,
algorithms, etc. from computer science.
• Software Engineers uses procedures, techniques, and tools
from other disciplines such as management science, industrial
engineering, and cognitive science.
• Software Engineers also perform in depth research in some of
the above areas themselves. (my view: I differ with the text author, p.5,
a bit here – )
Computer
Science
Customer
Problem
Cognitive
Science
..............
Software Engineering
Management
Solution
for
Customer
Computing Field
Software
Engineering
Graphic/
Visualizati
on/
Animation/
Gaming
AI and
Robotics
Traditional Computer Science
-Theory of computation
- Information theory/Coding theory
-Algorithms and data structure
- Programming Languages
-Formal Logic and Discrete systems
- Man/Machine Interface
- Operating system
- Real-time systems
- Parallel, concurrent, & multi-processing
- Database and Information Retrieval
-Network and Distributed systems
-Computer Organization and Architecture
Software Engineering Topics
Software
Development &
Engineering
- Requirements
Engr.
- Designing
-Construction
/coding
- Testing
Management &
Maintenance
- Evolution &
Support
- Configuration &
Release mgmt
- Project
Management
Software
Engineering
Support
- Measurement &
Metrics
- Process &
Methodology
- Tools
- Ethics
CS Foundation:
programming; data structure; algorithms ; database; etc.
Some Solution Goals for
Software Engineers
1.
2.
3.
4.
What is this?
Minimize Cost
On Schedule ( & Schedule Integrity)
Meets Functional Requirements
Meets Non-Functional Requirements (some calls this
“quality” requirements)
–
–
–
–
–
–
–
Performance in response time, transaction time, etc.
Security
New technology (marketability)
Reliability
Availability
Flexibility and Future Maintainability
etc.
Some use the word, “quality” to only address defects which resulted from
errors made by the software engineers
Software Quality (“defect-free”)
• Software Quality (mainly defects) has been an on-going issue
and was the main catalyst that started Software Engineering
(late 1960’s) when software application grew: (from simple
programs to business systems ---- today; software is managing our
lives)
– Larger (more complex) problems and products
– More “sophisticated” effort needed to solve more complex problems
– More people needed to understand and solve the problem
• Focus on:
– Product Quality
– Process Quality
– Quality in Business (“technical value” vs “business value”- controversial)
Future software engineers must understand that investing in
software demands a return in value to business --- to make the
investment a worthwhile one.
We Focus on Both Deliverables (Product)
and Process/Methodologies
• What are the software deliverables ?
– documents (requirements, design, test cases,
training material, etc.)
– code (source code, executables, libraries, initialized
data base, test harness, etc.)
• Will our methodology, tools, process, etc. that
we employ produce the deliverables ?
1.
2.
3.
4.
5.
on schedule
within cost
meets functional requirements
meets non-functional requirements
Delight the customer!
Cognizant of “Multiple” Perspectives in
Software Engineering
• Customer cares about cost, schedule, and meeting
requirements
• Users care about meeting the requirements with
emphasis on learning, usage, & recoverability from
problems, etc.
• Developers care about “meeting”: requirements,
schedule, productivity/cost, technical challenges, risks
& other goals/targets.
• Sometimes Customers and Users are the same group;
sometimes the customers, users and the developers all belong
to the same company.
Software Engineering
Internal
Product
Structure
& Properties
What process & methodology
can we devise and use to develop
the internal structure and size
Engineering
Processes &
Methodologies
What structure and properties should
the product have in order to
attain the desired, external properties
What set of product properties
will require which process and
which methodologies
External
Product or
Project
Properties
Two Major Components of SWE (Again)
1.
Understanding the Problem (System Approach - Definition)
–
–
–
2.
What is the “total” system (hardware; software; business; people; law;
technology, timing/schedule, etc.)
What are the boundaries
What are the major components of the system and how they “inter-relate”
Constructing the Solution (Engineering)
–
–
–
–
–
–
–
–
Requirements Analysis (more of problem-analysis)
System Design
Program Design
Not all in nice
Coding
sequence;
Code Integration
We iterate through
Testing
these
Product Builds
(How ?)
Product Delivery
Software Engineering “Team”
•
•
•
•
•
Applications/Business Analysts - User Requirements
Designers - System and subsystem level solutions
Programmers - code level solutions (a “must” skill)
QA &Testers - design and code level defect detection
Process and Tool Specialists - version control,
configuration management, packaging, process, and
metrics
• Trainers - user, customer & maintenance education
• Maintenance Support - customer support, product
fixes, and future enhancements
Question: Where do UI experts fit in?
Changes in Computing World
(forcing continuous changes to software engineering)
1. Speed to market is more critical
2. Continuing drop in hardware price but increasing
software development cost
3. Hardware is getting more and more powerful
4. Extensive local and wide-area network ( & the web)
5. Adoption of OO (any new technology) - my words
technology
6. GUI is the norm
7. Waterfall process model is too conservative ; looking
for new process / techniques/ tools
A Relatively Young Discipline & Has No “Laws” - but
• Software Engineering is continuously evolving & there are many players
in this field.
• Tony Wasserman’s 8 fundamentals for effective software engineering:
(Also, check out Alan Davis’ 15 principles of Software Engineering - in
IEEE Software/Nov. 1994 & his 1995 book)
– Abstraction : viewing substance in a more “general” way
– Analysis and Design Methods and Notation : building and communicating
models
– UI Prototyping : constructing parts of the UI to understand user
requirements and also to demonstrate feasibility
– Software Architecture : constructing a set of “basic” solution units and
showing how the units inter-relate
– Software Process : understanding and applying the “best” development
process for the project
– Reuse : taking advantage of previous work
– Measurement : devising and quantifying measurement for software
engineering
– Integrating tools : developing integrated development environment and
tools for the complete software life cycle
Abstraction
• Large projects involve many, interrelated
elements and thus:
– Hard to understand
– Hard to express
– Hard to solve
• Simplify through “abstraction” (or generalization)
– Find “common” attributes and combine elements
• Express only the “essential” commonalities and drop the details
(what level of detail is considered droppable?)
– Find “related” elements and compose to form a “new
element”
• We do this when we design a “class” in OO design activity
Note: “abstraction” used here is NOT meant to compare intangible versus tangible
Abstraction Example
• Problem: the software we need “must have features for
inputting number of programmers and others used in the
project every week; inputting the hourly time expended by
all different type of people ---- verify all the inputs are
correct; compute the cost using the different rates; -----etc.”
– Abstraction: we need a “software project cost tracking software.”
Software Project cost
tracking
Input and input
verification
Cost
computation
combining and grouping
related functions into even
higher level abstraction
Viewing &
reporting
class
General Project
cost tracking
sub-class
software Project
cost tracking
sub-class
construction Project
cost tracking
Analysis & Design Methods and Notation
• Large, complex projects need many, different people to
complete within time:
– We need express and keep our own thoughts and solutions
– We need to communicate our thoughts and solutions to others
– We need to understand other people’s thoughts and solutions
• Requires a common methodology and notation so that we
can communicate with ourselves (later in time) and with
others with different background and culture.
– Requirements specification document (Joey’s question – on assignment)
– Design document
– Etc.
UI Prototyping
• Prototyping means build a “mocked” version to:
– Demonstrate feasibility
– Understand the requirements, design, coding needs
– Negotiate requirements and design
• UI Prototyping used to improve UI requirements
specification and design:
–
–
Aid the users to better identify and express the
interface (and functional flow) requirements
Aid the developers to better understand the UI needs
(and functional needs) of the users
Software Architecture
• Large software systems have many inter-related
parts, thus defining the “framework” of the solution
with these inter-related elements is important:
– easier understanding of the principle behind the details of
design
– easier to make modification and maintain the software
• To define the software solution framework, we have
to specify the software architecture:
– Basic components
– Inter-relations among the components (what’s a “relation”
in software?)
Software Architecture Considerations
• How do we design/specify the basic components
and their relationships?
–
–
–
–
–
Modular (or functional) decomposition/composition
Data decomposition/composition and structure
Event decomposition/composition
Input/Output decomposition/composition
Object/Class composition/decomposition
We may use combinations of these techniques.
Note: we do not have a common software architecture
technique and notation, yet (refer to earlier point)
Software Process
• For large, complex software projects, we utilize
many, different people; besides needing “common
notation” and “good communication,” we need an
organized and structured way to conduct business.
• Software Development Process defines:
1. major tasks/activities involved
2. sequence of performing and relationship among the
tasks/activities
3. skills and people required to perform the different
tasks (often leads to organizational structure)
4. tools needed to support the tasks
- Different large software projects may use different process.
- But using no process is a high risk for large projects!
Reuse
• Developing large, complex software system
takes lots of people and time --- and is very
competitive (time and effort).
• One way to reduce time and cost is to reuse
components:
– code library for pre-coded functionalities by
Programming Language
– Development kit with code frame-work
• Besides code, we need to make more software
artifacts reusable:
– Requirements specification
– Design
– Test cases
Barriers to Reuse
1. Sometimes faster to build a small component than
search for a perfect match
2. No motivation(rewards) for developers to make his/her
work general enough to be reusable by others
3. No assurance that an available, reusable component is
well tested and performs as stated
4. Difficult to get support of a reusable component
5. Difficult to understand a reusable component written
by others, especially with no common notations
6. Performance and other attribute trade-off of general
versus specific component sometimes favor the nonreusable specific component.
Measurement
• Without “quantified” measurements, it is very
difficult to assess, control, and improve any
aspects of a product, process, people, etc.
• Other engineering fields have some very well
defined attributes and metrics.
• Software Engineering is working to improve on
this to become a “real engineering” field (e.g.):
– Size of software
– Complexity of software
– Reliability of software
- This is a “fertile” area for research and for jobs in large companies
- Needs experience and knowledge
Tools and Integrated Environment
• Tools have been the key to human civilization
and advancement. Software engineering is no
different.
• We need to continue to develop better tools,
especially for large complex projects:
–
–
–
–
–
Interoperate in heterogeneous environment
Present integrated and common user interface
Have integrated linkage between tools and processes
Data are shared among the related tools
Tools are automated to have better control among
themselves, initiating, terminating and passing
information
Wasserman’s 8 Fundamental Notions
• These 8 points touch upon different aspects of
software engineering
• They are all important in varying degree
• Some are specific and some are more general
Hopefully
Your appreciation of these will grow as we move forward
Also, read Chapter 1 of your Text-Book that complements this
lecture.