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 includesof 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 – )

ComputerScience

ManagementCognitiveScience . . . . . . . . . . . . . .

CustomerProblem

Software EngineeringSolution

forCustomer

Computing Field

Traditional Computer Science -Theory of computation - Operating system - Information theory/Coding theory - Real-time systems -Algorithms and data structure - Parallel, concurrent, & multi-processing- Programming Languages - Database and Information Retrieval -Formal Logic and Discrete systems -Network and Distributed systems - Man/Machine Interface -Computer Organization and Architecture

Software Engineering

AI andRobotics

Graphic/Visualizati

on/Animation/

Gaming

Software Engineering Topics

CS Foundation:programming; data structure; algorithms ; database; etc.

Software Development &

Engineering

- Requirements Engr.- Designing-Construction /coding- Testing

Management &Maintenance

- Evolution & Support- Configuration & Release mgmt- Project Management

SoftwareEngineering

Support

- Measurement & Metrics- Process & Methodology- Tools- Ethics

Some Solution Goals for Software Engineers

1. Minimize Cost

2. On Schedule ( & Schedule Integrity)

3. Meets Functional Requirements

4. 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

What is this?

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 insoftware 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. on schedule2. within cost3. meets functional requirements4. meets non-functional requirements5. 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

EngineeringProcesses &

Methodologies

InternalProduct

Structure& Properties

ExternalProduct or

ProjectProperties

What process & methodologycan we devise and use to developthe internal structure and size

What structure and properties shouldthe product have in order to attain the desired, external properties

What set of product propertieswill require which process and which methodologies

Two Major Components of SWE (Again)

1. Understanding the Problem (System Approach - Definition)– 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”

2. Constructing the Solution (Engineering)– Requirements Analysis (more of problem-analysis)– System Design– Program Design– Coding– Code Integration– Testing– Product Builds– Product Delivery

Not all in nicesequence;

We iterate throughthese

(How ?)

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 critical2. Continuing drop in hardware price but increasing

software development cost3. Hardware is getting more and more powerful4. Extensive local and wide-area network ( & the web)5. Adoption of OO (any new technology) - my words

technology6. GUI is the norm7. 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

Cost computation

Input and input verification

Viewing &reporting

combining and groupingrelated functions into evenhigher level abstraction General Project

cost tracking

software Project cost tracking

construction Project cost tracking

class

sub-classsub-class

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 non-reusable 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.