Lecture 1 Slides 6
-
Upload
marlon-boucaud -
Category
Documents
-
view
215 -
download
0
Transcript of Lecture 1 Slides 6
-
8/16/2019 Lecture 1 Slides 6
1/7
ECNG-3023 Introduction to
Software Engineering(September 2009)
Dr. Sastry MKSDepartment of Electrical &
Computer Engg
University of West Indies
St. Augustine Campus
Trinidad & Tobago
The IEEE Computer Society defines software
engineering as:
• The application of a systematic,
disciplined, quantifiable approach to the
development, operation and maintenance of
software; that is, the application of
engineering to software.
• The study of approaches as above.
What is Software Engineering?
Problem solving (Analysis)
We typically solve a problem by analysing it,
that is by breaking it down into pieces.
Problem
14
32
14
32
Once we have analysed the problem, we must
construct our solution from components that
address the problem's various aspects
Solution
14
32
14
32
Problem solving (Synthesis)
• Invisibility
– No physical presence
• Flexibility – After all it's software
• Complexity
– no physical constraints, yet many possible paths
of solution flow depending on the logic for
decision making.
How are Software Projects different?
The
ProductWhat the customers see
Compilers, Operating Systems, Utilities
DBMSCASE
Configuration Management
Code
Data Definitions
Databases
Specifications
Plans
Standards & ProceduresManuals
Simulators
Development Systems
Automatic test Equipment
The Software Iceberg
What is CASE???
Computer Aided Software Engineering
Find out different CASE Tools!!!
-
8/16/2019 Lecture 1 Slides 6
2/7
• Unfulfilled demand
• Increasing complexity
• Greater customer expectations
• Rapid obsolescence
• Increasing competition
• Shorter product cycle times
• Producing more with less
• Evolving methods and tools
Key Issues Facing Software Developers
• A fault occurs when a human makes a mistake,
called an error in performing some software
activity.
• A failure is a departure from the systems
required behaviour It can be discovered before
or after system delivery or during operation and
maintenance. Since requirements documents
can contain faults, failures can exist even
though the system is performing as specified!
Terminology – “Bugs”
• Late delivery? No delivery at all?
• Not delivering what was agreed to
or what was announced?
• Over budget?
• Not meeting revenue expectations?
• Quality below expectations?
What Does Project Failure Mean??
• Not understanding what the product
must do
• Uncontrolled changes
• Optimistic thinking
• Insufficient resources
• Lack of disciplined development
• Confusion about what needs to be done
• Ineffective teamwork
• Failure to consider business needs
Some reasons why SW Projects Fail
• Price
• Mature market
• Lack of essential capabilities• Difficult to use
• Unreliable
• Poor developer reputations
• Poor product support
Some reasons why Products Fail
• Good understanding of the problem to solve
• Good planning and execution
• Extraordinary effort and commitment by
individuals• Luck
• Satisfy an unfulfilled need
• Novelty
• Value
• Marketing strategy
Reasons for Success
-
8/16/2019 Lecture 1 Slides 6
3/7
• Quality of the product?
• Quality of the process?• Quality in the context of the
Business Environment?
What is a good SW?
• Correctness
• Reliability• Efficiency
• Integrity
• Usability
• Maintainability
• Testability
• Flexibility• Portability
• Reusability
• Interoperability
Quality of SW Product
• Correctness
– extent to which program
fulfils its specification
• Reliability
– systems ability not tofail
• Efficiency
– use of resources, e.g. processor time, storage
• Integrity
– protection of programfrom unauthorisedaccess
• Usability
– ease of software
• Maintainability
– effort required to locateand fix a fault in
program within itsoperating environment
• Testability
– ease of testing program,
to ensure it is error-free
and meets its
specification
• Flexibility
– Ease of makingchanging required by
changes in the operatingenvironment
Quality of SW Product
• Portability
– Effort required to transfer a programfrom one environment to another
• Reusability
– Ease of reusing software in adifferent context
• Interoperability
– Effort required to couple system toanother system
Quality of SW Product
• many activities can affect ultimate product quality
• By modelling a process, we can examine it and look
for improvements
– Where and when are we likely to find a particular kind of
fault?
– How can we find faults earlier in the development process?
– How can we build in fault tolerance so that we canminimize the likelihood that a fault will become afailure?
– Are there alternative activities that can make our processmore effective or efficient at assuring quality?
Quality of SW Process
• A view in terms of the products and
services being provided by the business
in which the software is embedded.
– i.e., we look at the business value.
– can be as simple as Return On Investment
(ROI) or some more elaborate measure.
Quality from Business Point of View
-
8/16/2019 Lecture 1 Slides 6
4/7
CustomerSponsors systemdevelopment
DeveloperBuilds
system
UserUses
system
$$$,
needs
Contractual
obligation
Needs
Software system
Who does SWE?Systems Approach
• Elements of a system: – Activities and Objects
– Relationships and the System Boundary
• Nested systems and system interrelationships
Activities and Objects
• Distinguish between activities and objects:
– activity is something that happens in a system.
• Usually described as event initiated by trigger
• Transforms one thing to another by changing a characteristic,
e.g.
• data element moved from one location to another
• data element is changed from one value to another
• data element is combined with other data to supply input for yet
another activity
– object or entity is element involved in the activity.
• Usually related in some way: arranged in a table or grouped as
records with pre-defined format
Relationships and the System
Boundary• A system is defined as a collection of things:
– a set of entities,
– a set of activities,
– a description of the relationships among entities and
activities,
– and a definition of the boundary of the system.
• Boundary states what is included and what is not
Examples: the human respiratory system, a paycheck production system
Nested systems
• It is possible for one system to exist within
another system, e.g. sensor system
– One can have various functions of the sensors nes tedwithin each other.
• Boundary of system is important to see what is:
– within the system
– outside of the system
– what crosses the boundary of the system
An analogy of software
engineering
• Determining andanalysing
requirements• Producing and
documenting thedesign
• Detailedspecifications
• Identifying anddesigning components
• Requirements analysisand definition
• System design
• Program design
-
8/16/2019 Lecture 1 Slides 6
5/7
Analogy ...
•Building components
• Testing components
• Integratingcomponents
• Making finalmodifications
• Continuingmaintenance
•Writing programs
• Unit testing
• Integration testing
• System testing
• System delivery
• Maintenance
7 Factors Altering SW Engineering
1.Criticality of time to market for commercial products
Business must ready their new products and services before their competitors do
2.Shifts in the economics of computing
Lower hardware costs and greater development andmaintenance costs
3.Availability of powerful desktop computing
More development power in hands of users, thereforesoftware engineers are likely to be building morecomplex systems than before
4.Extensive networks available
Makes it easier for users to find information withoutspecial applications e.g. searching WWW is quick, easyand effective
Key Factors affecting SWE
5. Availability and adoption of object-orientedtechnology
Makes available reusable modules for immediate andspeedy inclusion in new applications
6. Graphical User Interfaces (GUIs)
Helps to put a friendly face (appearance) oncomplicated applications
7. Unpredictability of the waterfall method
Developing subsystems in parallel requiresdevelopment process very different from waterfall
model
Key Factors that changed SWE
• Abstraction
• Analysis and Design methods and Notations
• User Interface Prototyping• Software Architecture
• Software Process
• Reuse
• Measurement
• Tools and Integrated Environments
Discipline of SWE
Abstraction
• Abstraction is a description of the problem at somelevel of generalisation that allows us to concentrateon the key aspects of the problem without getting
involved in the difficulties of the details.
• Typically involves identifying classes of objectsthat allow us to group items together so we:
– Can deal with fewer things, and
– Concentrate on the commonalities of items in each class
-
8/16/2019 Lecture 1 Slides 6
6/7
Analysis and Design Methods and Notations
These offer a
• Communication medium
– Communication and documentation of decisions among
development team
• Ability to build models
• Ability to check models for completeness and
consistency
• Reuse requirements and design components from
previous projects
User interface Prototyping
• Prototyping is building a small version of a system,
usually with limited functionality• Prototypes can be used to:
– Help the user/customer identify the key requirements of asystem
– Demonstrate feasibility of a design or approach
• Usually an iterative process:
– Build prototype
– Evaluate it with user and customer feedback
– Consider how changes might improve product or design
– Build another prototype OR iteration ends whendeveloper and customer are satisfied with solution
Software architecture
• Importance of overall architecture of system is:
– ease of implementation and testing
– speed and effectiveness of maintenance and change.
• The quality of the architecture can make or break asystem.
• System’s architecture describes system in terms of:
– set of architectural units, and
– map of how units relate to each other
Software architecture (continued)
Five ways of decomposing a system
• Modular: based upon assigning functions to
modules
• Data-oriented: based upon external data structures
• Event-oriented: based upon events that the system
must handle
• Outside-in: based upon user inputs to the system
• Object-Oriented: based upon identifying classes of
objects and their interrelationships
Software processReuse
• We take advantage of commonalities acrossapplications by reusing items from previousdevelopment.
• Reuse pertains not only to code but to design, testdata, requirements etc.
-
8/16/2019 Lecture 1 Slides 6
7/7
Measurement
• Measurement is a driving force in softwareengineering research:
– improving our processes, resources and methods so thatwe produce and maintain better products.
– But sometimes we express measurements generally, withno quantitative description.
• We would like to quantify:
– where we can and what we can,
– describe our actions and outcomes in a commonmathematical language that allows us to compare
progress across disparate projects .
Tools and integrated environments
Issues in tool integration
• Platform: the ability of tools to interoperate on a
heterogeneous network • Presentation: commonality of the user interface
• Process: linkage between the tools and thedevelopment process
• Data: the way the tools share data
• Control: the ability of one tool to notify and initiateaction in another.
Computers are increasingly being introduced into safety-critical systems and as a consequence, have been involvedin accidents.
Some of the most widely cited software-related accidents insafety-critical systems involved a computerized radiationtherapy machine called the Therac-25.
The Therac-25 is a medical linear accelerator manufactured by AECL to treat Cancer Patients with radiation therapy.
Between June 1985 and January 1987, six known accidents
involving massive overdoses by the Therac-25 --- withresultant deaths and serious injuries.
Therac-25 (A SW Disaster) Therac-25 routines(from IEEE ComputerJuly 1993)
End of Lesson I
Thank you