+ All Categories
Home > Documents > © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 1 Slide 1 Chap 1. An Introduction...

© Ian Sommerville 2006Software Engineering, 8th edition. Chapter 1 Slide 1 Chap 1. An Introduction...

Date post: 27-Dec-2015
Category:
Upload: tracy-nichols
View: 219 times
Download: 0 times
Share this document with a friend
Popular Tags:
87
©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 1 Chap 1. An Introduction to Software Engineering
Transcript

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 1

Chap 1. An Introduction to Software Engineering

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 2

Objectives

l To introduce software engineering and to explain its importance

l Know the answers to key questions that provide an introduction to software engineering;

l Understand some ethical (moral) and professional issues that are important for software engineers.

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 3

Topics covered

l FAQ (Frequently Asked Questions ) about software engineering

l Professional and ethical responsibility

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 4

Software engineering

l The economies of ALL developed nations are dependent on software.

l More and more systems are software controlledl Software engineering is concerned with theories,

methods and tools for professional software development.

l Expenditure on software represents a significant fraction of GNP (Gross National Product) in all developed countries.

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 5

Rely on computer-based systems

l Mostly all countries now depend on complex computer-based systems• National infrastructures (foundation or basic framework) and

public utilities rely (trust) on computer-based systems and most electrical products include a computer and controlling software.

• Industrial manufacturing and distribution is completely computerized. Same is the financial system.

• Therefore, producing and maintaining software cost-effectively is essential for the functioning of national and international economics.

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 6

New techniques to control complexity software

l Early experience in building these systems showed that informal (casual) software development was not good enough.• Major projects were sometimes years late.• The software cost much more than predicted (that it was planed).• Was unreliable, was difficult to maintain and performed poorly.• Although Hardware cost were keep fall down, but software

costs were rising rapidly. • New techniques and methods were needed to control the

complexity in large software systems.• This techniques have become part of software Engineering.

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 7

Software produce ability increased but same to his complexity.

l However, as our ability to produce software has increased, so too has the complexity of the software systems that we need. • For instance, new technologies resulting from the

merge of computers and communication systems and complex graphical user interfaces .

• As many companies still do not apply software engineering techniques effectively (efficient).

• too many companies still produce software that is unreliable, delivered late and over budget.

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 8

No single “perfect” approach

l We know now that there is no single “perfect” approach to software engineering.• The wild diversity (variety) of different types of

systems and have variety organizations (company) that use these systems means that we need a software development in variety of approaches.

• However, fundamental notions (conception) of system process and system organization underlie all of these techniques, and these are the essence of software engineering.

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 9

Software engineers can proud of their achievements

l Software engineers can be rightly proud of their achievements.• Without complex software we could not have

explored (travel in and discover) space, would not have the internet and modern telecommunications, and all forms of travel would be more dangerous and expensive. (air craft need complex computer control)

• Software engineering has contributed a great deal, and I am convinced (believe) that, depend to the technologies is more matures, its contributions in the 21st century will be even greater.

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 10

Software costs

l Software costs often dominate (control) computer system costs. The costs of software on a PC are often greater than the hardware cost.

l Software it costs more in maintain system than it does to develop. For systems with a long life, maintenance costs may be several times development costs.

l Software engineering is concerned with cost-effective software development.

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 11

1.1 FAQ about software engineering

l This section is designed to answer some fundamental questions about software engineering and to give you some impression of the views of the discipline.

l (FAQ) Frequently Asked Questions1. What is software?

2. What is software engineering?

3. What is the difference between software engineering and computer science?

4. What is the difference between software engineering and system engineering?

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 12

FAQs about software engineering

• What is a software process?• What is a software process model?• What are the costs of software engineering?• What are software engineering methods?• What is CASE (Computer-Aided Software

Engineering)• What are the attributes of good software?• What are the key challenges facing software

engineering?

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 13

1.1.1 What is software?

l Software system is not equate with computer programs:• Which usually consists of a number of separate

programs, configuration or data files, which are used to set up these programs, system documentation, which describes the structure of the system, and user documentation (user menu), which explains how to use the system and web sites for users to download recent product information.

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 14

1.1.1 two fundamental types of software product

l There are two fundamental types of software product:• Generic (general) products: these are stand-alone (solitary)

system that are produced by a development organization and sold on the open market to any customer who is able to buy them. Example, word processors, Excel, Access, databases, drawing packages tools etc...

• Customize products: these are systems which are commissioned (ordered) by a particular customer. Example, control systems for electronic devices systems written to support a particular business process, like as customer order system, university of administration system.

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 15

1.1.1 difference between Generic and Customer products

l An important difference between these types of software is that,• In generic products: the organization (company) that develops

the software controls the software specification.• For customer products: the specification is usually developed

and controlled by the buyer (or market). • However, the line between these types of products is becoming

increasingly blurred (indistinct). And more software companies are starting with a generic system and customizing it to the needs of a particular customer. Enterprise Resource Planning (ERP) systems is a good examples.

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 16

1.1.2 What is software engineering?

l Software engineering is an engineering discipline that is concerned with all aspects of software production from the early stages of system specification to maintaining the system after it has gone into use.

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 17

1.1.2 Two key fundamental types

l In the definition, there are two key fundamental types:• Engineering discipline:

• Engineers make things work. They apply appropriately theories, methods and tools to try to discover solutions to problems even when there are no applicable theories and methods.

• Engineers also understand that they must followed the company financial constraints, so they look for solutions within these constraints (ex. financial budget).

• All aspects of software production: • Software engineering is not just concerned with the technical

processes of software development, but also with activities such as software project management and with the development of tools, methods and theories to support software production.

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 18

1.1.2 What is software engineering?

l Software engineering is an engineering discipline that is concerned with all aspects of software production.

l Software engineers should adopt (accept and do) a systematic and organised approach (method) to their work and use appropriate tools and techniques depending on the problem to be solved, as this often the most effective way to produce high-quality software.

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 19

1.1.3 What is the difference between software engineering and computer science?

l Computer science is concerned with theory and fundamentals (primary principle); software engineering is concerned with the practicalities of developing and delivering (produce) useful software.

l Some knowledge of computer science is essential for software engineers. In the same way that some knowledge of physics is essential for electrical engineers.

l Ideally, all of software engineering should be supported by theories of computer science, but in reality this is not the case. Computer science theories are still insufficient to act as a complete underpinning (supported) for software engineering (unlike e.g. physics and electrical engineering).

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 20

1.1.4 What is the difference between software engineering and system engineering?

l System engineering is concerned with all aspects of computer-based systems development including hardware, software and process engineering. • Software engineering is part of this process concerned with

developing the software infrastructure (foundation), control, applications and databases in the system.

• System engineers are involved in system specification, architectural design, integrating the different parts to create the finished system and deployment (spread out).

• System engineering are less concerned with the engineering of the system components (hardware, software, etc.)

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 21

1.1.5 What is a software process ?

l A software process is the set of activities to produce software products.

l Four fundamental process activities in all software processes are:1. Specification – Customers or engineers define the software’s

specification to be produced and the constraints on its operation.2. Development - Production of the software system, as structure

or programmed.3. Validation - checking that the software is what the customer

requires.4. Evolution - changing the software in response to changing

demands (from customer or market requirements).

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 22

1.1.5 Need different development processes

l Different types of systems need different development processes.

• In e-commerce systems, the specification and the program are usually developed together.

• However, use of an inappropriate software process may reduce the quality or cause usefulless software product to be developed and increase the development costs.

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 23

1.1.6 What is a software process model?

l A simplified representation of a software process, presented from a specific perspective.

l Examples of types of software process model that may be produced as followed:1. Workflow model or process model – shows the sequence of

activities in the process along with their inputs, outputs and dependencies, the activities in this model represent human actions. (figure 8.2)

2. Data-flow or activity model – it shows how the input to the process, such as specification, is transformed to an output, such as design. The activities here may represent transformations carried out by people or by computers. (figure 8.3)

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 24

Equipment procurement (obtain) process

Get costestimates

Acceptdelivery ofequipment

Checkdelivered

items

Validatespecification

Specifyequipmentrequired

Choosesupplier

Placeequipment

order

Installequipment

Findsuppliers

Supplierdatabase

Acceptdelivered

equipment

Equipmentdatabase

Equipmentspec.

Checkedspec.

Deliverynote

Deliverynote

Ordernotification

Installationinstructions

Installationacceptance

Equipmentdetails

Checked andsigned order form

Orderdetails plusblank order

form

Spec. +supplier +estimate

Supplier listEquipment

spec.

Figure 8.2 process model of equipment procurement

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 25

Order processing DFD

Completeorder form

Orderdetails +

blankorder form

Validateorder

Recordorder

Send tosupplier

Adjustavailablebudget

Budgetfile

Ordersfile

Completedorder form

Signedorder form

Signedorder form

Checked andsigned order

+ ordernotification

Orderamount

+ accountdetails

Signedorder form

Orderdetails

Figure 8.3 Data flow diagrams

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 26

1.1.6 waterfall approach

l Most software process models are based on one of three general models : (Generic process models)1. Waterfall approach;

• Represents process as separate process phases such as requirements specification, software design, implementation, testing, and operation and maintenance, after each stage is defined and ‘signed off’, (have signed) then development goes on to the following stage. (figure 4.1)

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 27

Waterfall model

Requirements

definition

System andsoftware design

Implementationand unit testing

Integration andsystem testing

Operation and

maintenanceFigure 4.1 the software life cycle

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 28

1.1.6 Iterative development

2. Iterative (repeating) development; (Evolutionary development); (figure 4.2)• This approach is repeating the activities of specification,

development and validation.• An initial system is rapidly developed from abstract

specifications.• Then refined with customer required to produce a system

that satisfies customer’s required, then delivered.

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 29

Evolutionary development

Concurrentactivities

ValidationFinal

version

DevelopmentIntermediate

versions

SpecificationInitial

version

Outlinedescription

Figure 4.2Evolutionary development

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 30

1.1.6 Component-based software

3. Component-based software engineering. This approach is based on the existence of reusable

components. The system development process focuses on integrating these components into a system rather than developing them from scratch (beginning). (figure 4.3)

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 31

Reuse-oriented development

Requirementsspecification

Componentanalysis

Developmentand integration

System designwith reuse

Requirementsmodification

Systemvalidation

CBSE : Component-based software engineering

Figure 4.3component-based software engineering

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 32

1.1.7 What are the costs of software engineering?

l There is no simple answer to this question • as the distribution of costs depends on the different

software process used and the type of software that is being developed.

• For example: real-time software usually requires more extensive (comprehensive) validation and testing than web-based systems.

• Different software development has a different cost across the software process activities.

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 33

1.1.7 costs of waterfall approach

l We can assume that the total cost of developing a complex software system is 100 cost units then figure 1.2 illustrates how these are spent on different process activities. 1. In the waterfall approach, the costs of specification,

design, implementation and integration are measured separately.• The system integration and testing is the most expensive

development activity, normally, this is about 40% of the total development costs but will at least 50% for some critical system.

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 34

Activity cost distribution

Waterfall model

Iterative development

Component-based software engineering

Development and evolution costs for long-lifetime systems

System evolution

10 200 30 4000

System development

Specification Design Development Integration and testing

25 50 75 1000

Specification Development Integration and testing

25 50 75 1000

Specification Iterative development System testing

25 50 75 1000

Figure 1.2software engineering activity cost distribution

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 35

1.1.7 cost of iterative approach

2. In the iterative approach, there is no hard line between specification, design and development.• Specification costs are reduced because only a high-level

(roughly) specification is produced before development.• All the activities, specification, design, implementation,

integration and testing are carried out in parallel within a development activity.

• However, you still need and independent system testing activity once the initial implementation is complete.

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 36

1.1.7 cost of Component-based software

3. Component-based software engineering has only been widely used for a short time.• We don’t have accurate figures for the costs of different

software development activities in this approach.• Development costs are reduced, because we can use exist

component .• But integration and testing costs are increased because

you have to ensure that the components that you use actually meet their specification and work as expected required.

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 37

1.1.7 Cost of long-lifetime software

l On top of development costs, costs are also incurred in changing the software after it has gone into use.• For long-lifetime software systems, such as command

and control systems that may be used for 10 years or more, these costs are likely to exceed the development costs by 3 or 4 times. (figure 1.2)

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 38

1.1.7 Cost of PC software products

l Above cost distributions hold for customized software that is specified by a customer and developed by a contractor.

l For software products that are sold for PCs, the cost profile is likely to be different. • Usually developed from an outline specification using an

evolutionary development approach.• So specification costs are relatively low, however, because

intended for use on a range of different configurations, so must be extensively tested.

• Figure 1.3 shows the type of costs profile.

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 39

Product development costs

Specification Development System testing

25 50 75 1000

Figure 1.3Pc software product development costs

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 40

1.1.8 What are software engineering methods?

• is a structured approach to software development • whose aim is to facilitate (easy) to produce the high-quality

software in a cost-effective way.• 1970s, methods such as Structured Analysis have been

issued by (DeMarco,1978) and (Jackson, 1983), these methods attempted to identify the basic functional components of a system. Is called Function-oriented methods.

• 1980s and 1990s Function-oriented methods were supplemented by Object-oriented (OO) methods such as those proposed.

• These different approaches have now been integrated into a single unified (form into one) approach, call the Unified Modeling Language (UML).

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 41

1.1.8 What are software engineering methods?

l These is no ideal method, and different methods have different areas where they are applicable. • For example, object-oriented methods are often appropriate for

interactive systems but not for stringent (strict) real-time requirements.

l All methods that be represented graphically and using these models as a system specification or design.

l Methods include a number of different components; System model descriptions, Rules, Recommendations, Process Guidance. (figure 1.4)

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 42

Figure 1.4

Component Description Example

System model descriptions

1. Descriptions of the system models which should be developed 2. and the notation used to define these models.

Object models, data-flow models, state machine models, etc (Chat 8, p176)

Rules Constraints which always apply to system models.

Every entity in the system model must have a unique name.

Recommendations (design)

Experience advice on good design practice. Followed these recommendation should lead to a well-organized system model.

No object should have more than seven sub-objects associated with it.

Process guidance

Descriptions of the activities in the system model and organization of these activities.

Object attributes should be documented before defining the operations associated with an object.

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 43

1.1.8 Conclusion

l Structured approaches to software development which include system models, rules, design advice and process guidance.

l Model descriptions• Descriptions of graphical models (notation) which should be

produced;l Rules

• Constraints applied to system models;l Recommendations (Design)

• Advice on good design practice;l Process guidance

• What activities to follow.

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 44

1.1.9 What is CASE (Computer-Aided Software Engineering)

l Software systems that are intended to provide automated support for software process activities.

l CASE systems are often used to support software process activities such as requirements analysis, system modelling, debugging and testing.

l All methods now come with associated CASE technology such as: • Editors for the notations used in the method.• Analysis modules which check the system model according to the

method rules.• Report generators to help create system documentation• Code generators that automatically generates source code.• Some process guidance for software engineers.

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 45

1.1.9

l Upper-CASE• Tools to support the early process activities of

requirements and design;l Lower-CASE

• Tools to support later activities such as programming, debugging and testing.

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 46

1.1.10 What are the attributes of good software?

l The software should deliver the required functionality and performance to the user.

l Some other attributes are not directly concerned with what the software does. We call these kind of attributes is non-functional attributes, example:• Software’s response time to a user query.• Understandability of the program code.• Banking system must be 100% security.• Interactive game must be real-time responsive.• Telephone switching system must be reliable.

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 47

1.1.10 What are the attributes of good software?

l The essential characteristics of a well-designed software system can be generalized into the set of attributes show as followed;

1. Maintainability• Software should be written in such a way that it may develop to meet

the changing needs of customers.• This is a critical attribute because software change is an inevitable

(unavoidable) consequence of a changing business environment.

2. Dependability (reliable)• Software dependability has a range of characteristics, including

reliability, security (avoid hacker) and safety. • Dependable software should not cause physical or economic

damage in the event of system failure.

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 48

1.1.10

3. Efficiency• Software should not make wasteful use of system

resources such as memory and processor cycles.• Efficiency therefore includes responsiveness, processing

time, memory utilization (useful) rate, budget control, etc.

4. Usability (Acceptability)• Software must be usable and accepted by the users for

which it was designed. This means it must be understandable (adequate documentation), usable and compatible with other systems (appropriate user interface).

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 49

1.1.11 What are the key challenges facing software engineering?

l Software engineering in the 21st century faces three key challenges : Heterogeneity (different in kind), delivery (production time) and trust.

1. Heterogeneity Challenge (dissimilarity)

• The software system are become as distributed system across networks that include different types of computer.

• It is often necessary to integrate new software with older exist systems that written in different programming languages.

• The heterogeneity challenge is to build up a dependable software that is flexible enough to cope with this heterogeneity.

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 50

1.1.11

2. Delivery Challenge (production time)• Traditional software engineering techniques are time-

consuming, the reason for time taken is required to achieve software quality.

• However, businesses today must be responsive and change very rapidly, so their supporting software must change equally rapidly.

• The delivery challenge is how to shorten delivery times for large and complex systems without compromising system quality.

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 51

1.1.11

3. Trust• As software is beside us with all aspects of our lives:

• It is essential that we can trust that software.• This is especially true for remote software systems

accessed through a web page or web service interface.• The trust challenge is to develop techniques that

demonstrate that software can be trusted by its users.

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 52

1.2 Professional and ethical responsibility

l Software engineering is carried out within a legal and social framework.• Accept that their job involves wider responsibilities

than simple application of technical skills.• Must behave in an ethical and morally responsible

way if they are to be respected as professionals.• You should always own normal standards of honesty

and integrity (uprightness, honesty ). • You should not use your skills and abilities to behave

in a dishonest way or in a way that will bring disrepute (loss of good reputation) to your profession area.

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 53

1.2

l There are some areas where standards of acceptable behavior are not bounded by laws but by the more tenuous (unclear) area of professional responsibility. There are : 1. Confidentiality

2. Competence (ability)

3. Intellectual property rights

4. Computer misuse

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 54

1.2 Issues of professional responsibility

l Confidentiality • Engineers should normally respect the confidentiality

of their employers or clients, doesn’t matter whether or not a formal confidentiality agreement has been signed.

l Competence (ability)

• Engineers should not misrepresent their level of competence. They should not accept work which is outside their competence. (Mean’s sometime you talk too big).

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 55

1.2 Issues of professional responsibility

l Intellectual (intelligence) property rights • Engineers should be aware of local laws governing the use of

intellectual property such as patents (sole right to make), copyright, etc. They should be careful to ensure that the intellectual property of employers and clients is protected.

l Computer misuse • Software engineers should not use their technical skills to

misuse other people’s computers. Computer misuse ranges from relatively trivial (little important) (game playing on an employer’s machine) to extremely serious (spread of viruses).

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 56

1.2 ACM/IEEE Code (regulation) of Ethics

l Professional societies and institutions have an important role to play in setting ethical standards.

l ACM, and IEEE ( Institute of Electrical and Electronic Engineers) and British Computer Society publish a code of professional conduct (behave) or code of ethics.

l Members of these organizations undertake to follow that code when they sign up for membership.

l These codes of conduct (behavior) are generally concerned with fundamental ethical behavior.

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 57

ACM/IEEE Code of Ethics

l The Code contains eight Principles related to the behaviour of and decisions made by professional software engineers, including practitioners, educators, managers, supervisors and policy makers, as well as trainees and students of the profession.

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 58

ACM/IEEE Code of Ethics

l ACM/IEEE-CS Joint Task Force on Software Engineering Ethics and professional Practices

l Preamble (introduction)• The short version of the code summarizes aspirations (desire for

something better or higher, ambition) at a high level of the abstraction; the clauses that are included in the full version give examples and details of how these aspirations change the way we act as software engineering professionals. Without the aspirations, the details can become legalistic (according to letter rather than the spirit) and tedious (tiresome); without the details, the aspirations can become high sounding but empty; together, the aspirations and the details form a cohesive (stick together) code.

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 59

Code of ethics - principles

• Software engineers shall commit (pledge) themselves to making the analysis, specification, design, development, testing and maintenance of software a beneficial and respected profession. In accordance with their commitment (promise) to the health, safety and welfare of the public, software engineers shall adhere (devote) to the following Eight Principles:

1. PUBLIC• Software engineers shall act consistently with the public interest.

2. CLIENT AND EMPLOYER • Software engineers shall act in a manner that is in the best interests of

their client and employer consistent (unchanging) with the public interest.

3. PRODUCT • Software engineers shall ensure that their products and related

modifications meet the highest professional standards possible.

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 60

Code of ethics - principles

4. JUDGMENT • Software engineers shall maintain integrity (honesty) and

independence in their professional judgment.

5. MANAGEMENT • Software engineering managers and leaders shall support and

promote an ethical approach to the management of software development and maintenance.

6. PROFESSION • Software engineers shall promote the integrity and reputation

of the profession consistent (unchanging) with the public interest.

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 61

Code of ethics - principles

7. COLLEAGUES • Software engineers shall be fair to and supportive of

their colleagues.

8. SELF • Software engineers shall participate in lifelong

learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession.

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 62

Ethical dilemmas

l Disagreement in principle with the policies of senior management.• Your employer acts in an unethical way and releases a safety-

critical system, because of time-pressure, the safety validation records. without finishing the testing of the system.

• Your responsibility to maintain confidentiality or alert the customer, in some way, that delivered system may be unsafe?

• The system may actually operate safely throughout its lifetime. It is also the case that, even when properly validated, a system may fail and cause an accident.

• Early disclosure of problems may result in damage to the employer and other employees; failure to disclose problems may result in damage to others.

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 63

Ethical dilemmas

l Participation in the development of military weapons systems or nuclear systems.• In this situation it is important that both employers

and employees should make their views known to each other in advance.

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 64

Key points

l Software engineering is an engineering discipline that is concerned with all aspects of software production.

l Software products consist of developed programs and associated documentation. Essential product attributes are maintainability, dependability, efficiency and usability.

l The software process consists of activities that are involved in developing software products. Basic activities are software specification, development, validation and evolution.

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 65

Key points

l Methods are organised ways of producing software. They include; (figure 1.4)• System model descriptions;

• To description the system model by notation way to define these model.

• Rules;• Constraints which always apply to system models.

• Recommendations; • Followed experience and good recommendation should lead to a

well-organized system model.• Process guidance.

• Descriptions of the activities in the system model and organization of these activities.

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 66

Key points

l CASE tools are software systems which are designed to support routine activities in the software process such as editing design diagrams, checking diagram consistency and keeping track of program tests which have been run.

l Software engineers have responsibilities to the engineering profession and society. They should not simply be concerned with technical issues.

l Professional societies publish codes of conduct which set out the standards of behaviour expected of their members. (ACM/IEEE-CS joint Task Force on Software Engineering Ethics and Professional Practices)

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 67

Exercise 1.2

l What are the differences between generic software product development and custom software development?

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 68

1.2 Answer

l The essential difference is that in generic software product development, the specification is owned by the product developer. For custom product development, the specification is owned by the customer. (p5)

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 69

Exercise 1.3

l what are the four important attributes which all good software products should have? Suggest four other attributes that may sometimes be significant. (p13)

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 70

1.3 Answer

l For important attributes are maintainability, dependability, efficiency and usability (p13). Other attributes that may be significant could be 1. reusability (can it be reused in other applications),

2. distributability (can it be distributed over a network of processors),

3. portability (can it operate on multiple platforms, ie different operation system)

4. inter-operability (can it work with a wide range of other software systems, ie different program language).

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 71

Exercise 1.4

l what are the difference between a software process model and a software process? Suggest two ways in which a software process model might be helpful in identifying possible process improvements.

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 72

1.4 Answer (a)

l A software process is what actually goes on when software is developed for produce a software product, there are four fundamental process activities : (1.1.5 p8)

• Software specification: Customer requirement.• Software development: designed and programmed.• Software validation: check and make sure it is customer

require• Software evolution: adapt (make suitable) for changing

customer and market require

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 73

1.4 Answer (b)

l A software process model is an abstraction and simplification of a process. Process models can be used to help understand real processes and to identify which aspects of these processes model could be supported by CASE tools. For examples as : (1.1.6 p9)

• Workflow model, Dataflow model, Role model.• They are based on three general models, as :• Waterfall approach, Iterative development,

Component-based software engineering.

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 74

Exercise 1.6

l Software engineering methods became widely used only when CASE technology became available to support them. Suggest five types of method support that can be provided by CASE tools. (1.1.9)

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 75

1.6 Answer

l Method support provided by CASE tools: (1.1.9)

• Editors for specific graphical notations used• Checking of the 'rules' and guidelines of the method• Advice to tool users on what to do next• Maintenance of a data dictionary - all names used in

the system• Automatic generation of skeleton code from the

system models• Generation of reports documentation on the design

(p12)

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 76

Exercise 1.7

l Apart from the challenges of heterogeneity, rapid delivery and trust, identify other problems and challenges that software engineering is likely to face in the 21st century. (1.1.11)

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 77

1.7 Answer

l Problems and challenges for software engineering (p13)

• Developing systems for multicultural use• Developing systems that can be adapted (make suitable) quickly

to new business needs (or market requirement)• Designing systems for outsourced development (maybe Oral)• Developing systems that are resistant to attack (information

security) • Developing systems that can be adapted and configured by

end-users (user can design or assemble what they want)

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 78

Exercise 1.9

l For each of the clauses in the ACM/IEEE code of Ethics shown in Figure 1.6, suggest an appropriate example that illustrates that clause.

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 79

1.9 Answer

Advantages of certificationl Certification is a signal to employers of some minimum level of

competence. (2,3)l Certification improves the public image of the profession. (1,5)l Certification generally means establishing and checking educational

standards and is therefore a mechanism for ensuring course quality. (3,8)

l Certification implies responsibility in the event of disputes (argue). (4)l Certifying body is likely to be accepted at a national and international

level as ‘speaking for the profession’. (6)l Certification may increase the status of software engineers and

attract particularly able people into the profession. (1)

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 80

1.9 Answer

Disadvantages of certificationl Certification tends to lead to protectionism where certified

members tend not to protect others from criticism.l Certification does not guarantee competence merely that

a minimum standard was reached at the time of certification.

l Certification is expensive and will increase costs to individuals and organisations.

l Certification tends to failure change. This is a particular problem in an area where technology developments are very rapid.

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 81

Exercise 1.10

l To help counter terrorism, many countries are planning the development of computer systems that track large numbers of their citizens and their actions. Clearly this has privacy implications (twist together) , discuss the ethics of developing this type of system.

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 82

End

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 83

Test 1 (for week 1)

l There are two fundamental types of software product, Generic and Customer products. Please explain what important difference between these two types of products?

l And why the line between these two types of products is becoming increasingly blurred?

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 84

Ans: difference between Generic and Customer products

l An important difference between these types of software is that,• In generic products: the organization (company) that develops

the software controls the software specification.• For customer products: the specification is usually developed

and controlled by the buyer (or market). • However, the line between these types of products is becoming

increasingly blurred (indistinct). And more software companies are starting with a generic system and customizing it to the needs of a particular customer. Enterprise Resource Planning (ERP) systems is a good examples.

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 85

Test 2 (for week 2)

l Please give three type of software process model? And what the software development model that most software process models are base on ?

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 86

Ans:

1. Workflow model, dataflow/activity model and role/action model.

2. Waterfall approach, Iterative development, and Component-based software engineering.

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 1 Slide 87

End


Recommended