SE: CHAPTER 1 Why Software Engineering ? What We Mean by SE ? SE’s Key Issues What We Mean by “good software” Differences between Computer Science.

SE: CHAPTER SE: CHAPTER 11Why Software Why Software Engineering ?Engineering ?

What We Mean by SE ?

SE’s Key Issues

What We Mean by “good software”

Differences between Computer Science Problems and Engineering Ones ?

Peoples Involved in SE

Changing of SE since 1970s

1.1 What Is Software Engineering ?1.1 What Is Software Engineering ?Software Is One Way to Solve Problems

There are some other ways

Solving Problems NeedUnderstanding the Nature of ProblemsIf Possible and Appropriate, Using Software to

Implement the Solution

Software Is a Good Way to Solve Complex Problems

Never Impose anything on Problem that Comes Our Way

Solving Problems

The Process of Solving Problems Investigating Problem at Hand by Analyzing it

Break the Problem into Pieces We Can UnderstandDescribe the Problem as a Collection of Small Problems

and Their Interrelationships Construct the Solution from Components Address

the Problem’s Various Aspects through SynthesisPut together of Large Structure from Solutions of Small

Problems The Synthesis or Composition from Solutions of

Small Problems to The Large Problem May Be as Challenging as Analyzing and Finding Solutions Themselves.

See Fig 1. 1 and Fig 1.2 (p.3)

Solving Problems To Help Solving a Problem, We Employ

Various Methods, Tools, Procedures and Paradigms A Method or Technique Is a Formal Procedure for Producing

some Useful Result Example: Preparing a Sauce May Need and Involve Various

Ingredients, Cooking Equipment, Timing,… A Tool Is an Instrument or Automated System for Accomplishing

Something in a Better Way. “Better Way” : Tools Make Us More Accurate, More Efficient, or

More Productive, Or It Enhance the Quality of the Resulting Product. Examples: Typewriter, Scissors,… Tool Is Not Always Necessary for Making Something Well.

A Procedure Is a Combination of Tools and Techniques to Produce a Particular Product.

A Paradigm or Style Is a Particular Approach or Philosophy. Example: Chinese or French Cooking, Procedure or OO Programming

Where Does the SE Fit In ?

Computers and Programming Languages Are Tools They are used in design and implementing a solution

to a problem. Software engineers focus on the computer as a

problem-solving tool. Software engineers work with the functions of a

computer as part of a general solution, rather than with a the structure or theory of the computer itself.

See Fig. 1.3 (p.5)

1.2 How Successful Have We Been ?1.2 How Successful Have We Been ? Writing software is an art as well as a

science Computer scientists and software engineering

researchers study computer mechanisms and theorize about how to make them more productive or efficient.

They also design computer systems and write programs to perform tasks on these systems.

We need programs that may be more efficient, more precise, more robust, easier to use, easier to modify, easier to understand, easier to maintain.

That is, We need to produce quality programs. Writing Quality programs need both skills and

science

How Successful Have We Been ?

How Successful Have We Been ? Software has enabled us perform tasks more quickly

and effectively than ever before.Example: Word processing, electronic mail, life-sustaining

or life-saving in medicine, weather-forecasting, multimedia education, robotics, and more.

However, software does not always function exactly as expected.Example: failure on its maiden flight of Ariane-5 of Europe

an Space Agency, On June 4,1996. See p.37Faults in any program may : be merely annoying, or cost a

great deal of time and money, or life-threatening.Programs containing faults are not acceptable when develop

ing a system for delivery to a customer.

How Successful Have We Been ? Terminology for Describing bugs

A “bug” can be any mistake or error in coding. A Fault occurs when a human makes a mistake or

error, in performing some software activity.Example: a designer may misunderstand a requirement, and

create a design that does not match the actual intent of the requirement analyst and the user.

This design fault is an encoding of the error; It can lead to other faults, including errors in other coding

or user’s manual.

A Failure is a departure from the system’s required behavior, usually caused by faults. It can be discovered before or after system delivery, during

testing, or during operation or maintenance.Requirements documentation may contain faults.

How Successful Have We Been ? Terminology for Describing bugs

A Fault is an inside view of the system : problems seen by developers.

A Failure is an outside view : problems seen by users.

Not every fault corresponds to a failureExample : fault code never executed.

How human error causes a failure (Fig.1.4,p.6)

How Successful Have We Been ? Facts and Backgrounds

1980s: the $4-billion fiasco in USA An automated federal income tax form processing system

1985: Strategic Defense Initiative (SDI) heightened the public’s awareness of difficulty of producing a fault-free software.

Now, as U.S. Congress is asked to allocate funds to build a similar system, many computer scientists and software engineers continue to believe: there is no way to write and test the softeare to guarantee adequate reliability.

It is estimated that the system would require at least 10~100 million lines of code.

Further more, the reliability constraints would be impossible to test.

For typical safety-critical systems (any failure poses a threat to life or health), the reliability requirement would as high as at least 10-9

This means that it would run 109 hours (114,000 years) without failure.

How Successful Have We Been ? Facts and Backgrounds

Therac-25, a radiation therapy and X-ray machine, when malfunctioned because of its improperly design or programming, killed several patients.

Manufactures are striving for zero-defect software, in fact most software products are not fault-free.Market forces encourage developers deliver products quickl

y, with little time to test thoroughly.Users are wary of installing the first version of code.Modification needed to fix known faults sometime are so di

fficult to make.Lack of quality can be costly; the longer a fault goes undete

cted, the more expensive to correct it. correcting an error made during the initial analysis only cost

1/10 of after it is delivered to customer.

1.3 What is Good Software ?1.3 What is Good Software ?Different Perspectives on Quality

Transcendental view : quality is something we can recognize but not define.

User’s view : quality is the fitness for purpose.We can measure product quality such as defect

density or reliability.Manufacturing view : quality is the

conformance to software specification.Product view : quality is tied to inherent

product characteristics.Value-based view : quality depends on the

amount the customer is willing to pay for it.

What Is Good Software ? Consider Quality in at least 3-Ways

Context helps to determine the answer to software quality.

3-Ways to consider software qualityThe quality of product itself.The quality of the process that results in the product.The quality of the product in the context of the business

environment in which the product will be used.

What Is Good Software ? The Quality of Product

Quality and functionality of a system sometime may intertwined.

We try to measure software quality Identify particular aspects of a system that contribute to the

overall quality.

External characteristics as number of failures and type of failuresMinor Failures, major failures, catastrophic failuresWe expect only minor failures occur.

Internal characteristicsNumbers and types of faults to reflect the product qualityFaults found in requirements, design and code

McCall’s model of quality (see Fig 1.5,p.11)

What Is Good Software ? McCall’ product quality model

High Level Quality Measures:Correctness, Reliability, Efficiency, Integrity, Usability,

Maintainability, Testability, Flexibility, Portability, Reusability, Interoperability

Low Level Quality Measures:Trace-ability, Completeness, Consistency, Accuracy, Error

tolerance, Execution efficiency, Storage efficiency, Access control, Access audit, Operability, Training, Communicativeness, Simplicity, Conciseness, Expandability, Instrumentation, Self-descriptiveness, Expandability, Generality, Modularity, Software system independence, Machine independence, Communications commonality, Data commonality

What Is Good Software ? The Quality of Process

Product development activity may affect quality. Process modeling can help to find ways to improve quality. The concern about process is to Try to find answers to followin

g questions: Where and when to find a particular kind of faults ? How can find faults earlier ? How can build in fault tolerance to minimize the likelihood that a

fault will become a failure ? Can we find alternative activities to make the process more effecti

ve or efficient at assuring quality ?

Focus on process modeling and process improvement in SE. CMM : Capability Maturity Model ISO 9000 SPICE : Software Process Improvement and capability dEterminat

ion

What Is Good Software ? Quality in the business environment

Business value : Return On Investment (ROI) Including or considering : original funding, funds earned

and plus possible risk U.S. Government and U.S. industry interpret ROI in

different waysGovernment view : in terms of dollars, looking at reducing

operating costs, dollars savings and calculating the cost of employing new technologies

Industry view : in terms of effort, looking at saving time and using fewer people

Generally, ROI including : training, schedule, risk, quality, productivity, process, customer, costs, business (Fig 1.6,p.14)

Software technology return on investment is not the same as financial ROI.

To the former, effects to the main company business may be concerned.

1.4 Who Does SE?1.4 Who Does SE?

People involved in Software DevelopmentThe number of people working on software

development depends on the project’s size and degree of difficulty.

Roles played through out the life of a software projectFor a large project, one person or a group may be

assigned to each roles identified.

Who Does SE?Who Does SE?Roles played in the development

Customer : company, organization or person who is paying for the software to be developed.In control of the funds, will negotiate the contract

and sign the acceptance papers.

Developer : company, organization or person who is building the software for the customer.

User : person or people who will sit at the terminal and actually use the system.

Who Does SE?Who Does SE? The simple distinction may become

complex sometimes the customer is not a user. Sometimes an organization or division will at the same

time be the customer, developer and user. Sometimes, customers and users may have involved in

the development process in a variety of ways. A developer may choose to use additional developers,

called subcontractors.They build a subsystem and deliver it to the developer to be

included in the final product.The subsystem may be turnkey system, where the code is an

incorporated whole without additional code for integration.

1.5 A Systems Approach1.5 A Systems Approach

Knowing Boundaries of a projectSystem is set of components interrelated, and

it must interact with outside components as well.

Boundaries : what is included in the project or system and what is not.

The boundaries should also be found for each component of a system or component.

The Elements of a SystemThe Elements of a SystemSystem is described by its parts and

part-relationships (components)Activities and Objects

Objects or entities are the elements of a systemAn object has its own structure and activities

Objects are related with each other in some wayExample : objects arranged in a table or matrix

(collection), grouped as records (aggregate/composition)

Pay special attention to Similar but different objectsIndependent functioning objectsObjects as parameters of activity

The Elements of a SystemThe Elements of a System

Activities and ObjectsActivities are also the elements of a systemActivities transform one thing to another by

changing object characteristicsMoving from one location to anotherChanging values of objectsCombining objects to form new objectsActivities need parameters

Activities normally are attached to some objectsBut not necessarily

Relationships and System BoundaryRelationships and System Boundary Relationships among objects and

activities They are clearly and carefully defined. Object definition includes a description of where they

are originated or destined.Some items reside in other objects that already existOthers are created during some activitiesSome objects are used by activities outside the scope of the

system being examined.We can think of the system as having a border or boundary

A system is a collection of thingsA set of objects, a set of activitiesThe relationships among objects and activitiesDefinition of the boundary of system

Relationships and System BoundaryRelationships and System Boundary Interrelated System

Once the boundary of a system is described, we can easily find What is within, without and across the system boundary.

A Large system may be composed of with other systems, called sub-systemsTreatment of separate, smaller systems makes the system

understanding and construction much easierSub-system may be replaced with other similar ones

System is constructed in may different waysSystem may exist inside another systemSystem may be composed of in the form of layers or

aggregationSystem construction can be an incremental series of

intermediate system (incremental development approach)

1.6 An Engineering Approach1.6 An Engineering Approach

Engineering development is an artistic approach to use tools and techniques

The process of Building a HouseThe process of building a software

system

Building a HouseBuilding a House The process of building a house

The processDetermine and analyzing the requirementsProducing and documenting the overall designProducing the detailed specification Identifying and designing the componentsBuilding each componentsTesting each components Integrating the components to form a wholeMaintenance

Change of minds in the process is inevitableCome from both developer or customerSubject consideration or object constraintsWe can not prescribe the activities exactlyParticipants should remain flexible and allow changes

Building a Software SystemBuilding a Software System The process of building a software system

The progress is in a similar way to the house building Involves users, customers and developers

The processRequirements analysis and definitionSystem designProgram designWriting or implementing the programUnit testing Integration testingSystem testingSystem deliverymaintenance

In reality, many of the process steps are repeated.

1.7 Members of development team1.7 Members of development team Role of the members

Requirement analysts Designer

generate system-level description Programmer Tester Customer Trainer Maintainer Librarians

Prepare and store documents, manuals, test data, schedule and more.

Configuration managerMaintaining correspondence among the requirements, design,

code, tests.

1.8 How has SE Changed ?1.8 How has SE Changed ? Difference and difficulties in producing

quality software Customers are too often unhappy with the software. Change of minds is inevitable in every step The construction of a system is a process of re-

engineering of the users’ working environmentDetailed understanding, structure and relationships have their

own complexity, which both users and developers need time and effort to formulate them correctly.

Outside environment changes all the time. As various stages of a project unfold, constraints arise

that were not anticipated at the beginning. Most systems do not stand alone

They interface or coordinate with other systems in one way or another.

The Nature of ChangeThe Nature of Change The change of software’s environment

Advanced hardware entails sophisticated software structure and functionsToday’s software systems are far more complex.Graphic user interfaces, network, multi-processor, multi-tasks

7 key factors that have altered SE practice (Fig 1.12,p.29)Criticality of time-to-market for commercial productLower hardware costs and greater development and

maintenance costsRequirement of powerful desktop computingExtensive local- and wide-area networkingAdoption of object-oriented technologyGraphic user interfaces using windows, icons, menus and

pointer-devicesUnpredictability of the waterfall model of software

development

Wasserman’s Discipline of SEWasserman’s Discipline of SE

These are the fundamental notions in SE

AbstractionAbstraction is the description of the key aspects

of a problem without getting mired in details.Abstraction involves identifying classes of

objects and their relationshipsWe can deal with fewer things and concentrate on

the main commonalities or aspectsWe can form hierarchies of abstraction

Abstraction is different from transformation

Wasserman’s Discipline of SEWasserman’s Discipline of SEAnalysis and design methods and

notationsProject Engineering needs a particular approach

Including techniques and toolsNeeds a standard notation to help participants

communicate and document decisionsAnalysis and design methods offer us more than

a communication mediumAllow us to build models and check them for

completeness and consistencyHelp reuse requirements and design components

Open question :Different tools and techniques address different

aspects of a problem

Wasserman’s Discipline of SEWasserman’s Discipline of SE User interface prototyping

Prototyping : building a small and simple version of a system that can be used toHelp the user and customer to identify the key requirements of

a systemDemonstrate the feasibility of a design or approach

Prototyping is often used to design a good user interface

Software architecture The overall architecture of a system is important

To the ease of implementation and testing, to the speed and effectiveness of maintaining and changing

The quality of the architecture can make or break the system It reflect the principles of good design A system’s architecture describes the system in terms of

a set of architecture units

Wasserman’s Discipline of SEWasserman’s Discipline of SE Software architecture

Wasserman’s 5 ways to partition a systemModular decomposition based on assigning functionsData-oriented decomposition based on external data structureEvent-oriented decomposition based on eventsOutside-in design based on user input to the systemObject-oriented design

System architecture may be constructed by using architecture styles or design-patterns

Software process Different types of software need different development

processes (see Fig 1.14, p.33) Good tools help great deal in software development Large, complex systems need more structure, checks

and balances

Wasserman’s Discipline of SEWasserman’s Discipline of SEReuse

Reusing the successful products helps a great deal in software developmentCan gain quantifiable benefit both to the

development speed and product qualityHowever, several barriers exist

Sometime building a small one is faster than searching for an existing reusable one

It may take extra time to make a component more general enough to be reused in other context

It is difficult to document and assure the qualityIt can be costly and time-consuming to understand

and reuse a component written by othersThere is often a conflict between generality and

specificity

Wasserman’s Discipline of SEWasserman’s Discipline of SE

MeasurementA quantitative approach permit us to compare

different projects, products, processesSee Fig 1.15, p.35

Tools and integrated environmentsStandardized, integrated developments would

enhance software developmentBut, different developers use different processes,

methods and toolsFurther, venders of tools rarely address the entire

development lifecycle, making the use of tools limited within a or several stages.

What this chapter means ?What this chapter means ?

What means for you ?Problem breaking and synthesizing to find a

solution to the problemRequirements may change during a projectView quality from several different

perspectivesUse Abstraction and measurement to help

identify the essential aspects of the problem and solution

Identify System boundary

ExercisesExercises

On Page 43-44Problem 2Problem 3Problem 4