Embed Size (px)
Citation preview
ECNG3023: Introduction to Software Engineering
Kevon Andrews
Rm. 329
Ph: 662-2002 x3156
Open Hours:
EE29B: Introduction to Software Engineering
• This course is examined by coursework (40%) and by examination (60%)
• There will be three mini-projects, the first one will be an individual project and the rest done in groups. Groups are to be 3-4 students.
What is Software Engineering?
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.
Problem solving (Analysis)We typically solve a problem by analysing it,
that is by breaking it down into pieces.
Problem
14
32
14
32
Problem solving (Synthesis)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
How are software projects different?
• Invisibility– No physical presence
• Flexibility– After all it's software
• Complexity– no physical constraints
The Software IcebergThe
ProductWhat the customers see
Compilers, Operating Systems, Utilities
DBMSCASE
Configuration Management
CodeData Definitions
Databases
SpecificationsPlans
Standards & ProceduresManuals
SimulatorsDevelopment Systems
Automatic test Equipment
Key Issues facing Software Developers
• Unfulfilled demand• Increasing complexity• Greater customer expectations• Rapid obsolescence• Increasing competition• Shorter product cycle times• Producing more with less• Evolving methods and tools
Terminology for describing “bugs”
• 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!
What does project failure mean?
• 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?
Some reasons projects fail• 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 products fail
• Price
• Mature market
• Lack essential capabilities
• Difficult to use
• Unreliable
• Poor developer reputations
• Poor product support
Some reasons projects succeed
• Good understanding of the problem to solve
• Good planning and execution
• Extraordinary effort and commitment by individuals
• Luck
Some reasons products succeed
• Satisfy an unfulfilled need
• Novelty
• Value
• Marketing strategy
What is good software?
• Quality of the product?
• Quality of the process?
• Quality in the context of the Business Environment?
Quality of the product
• Correctness
• Reliability
• Efficiency
• Integrity
• Usability
• Maintainability
• Testability
• Flexibility
• Portability
• Reusability
• Interoperability
Quality of the product• Correctness
– extent to which program fulfils its specification
• Reliability– systems ability not to fail
• Efficiency– use of resources, e.g. processor
time, storage
• Integrity– protection of program from
unauthorised access
• Usability– ease of software
• Maintainability– effort required to locate and
fix a fault in program within its operating environment
• Testability– ease of testing program, to
ensure it is error-free and meets its specification
• Flexibility– Ease of making changing
required by changes in the operating environment
Quality of the product
• Portability– Effort required to transfer
a program from one environment to another
• Reusability– Ease of reusing software
in a different context
• Interoperability– Effort required to couple
system to another system
Quality of the process
• 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 can
minimize the likelihood that a fault will become a failure?
– Are there alternative activities that can make our process more effective or efficient at assuring quality?
Quality in the context of the business environment
• 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.
Who does software engineering?
CustomerSponsors systemdevelopment
DeveloperBuildssystem
UserUsessystem
$$$,needs
Contractualobligation
Needs
Software system
Systems Approach
• Elements of a system:– Activities and Objects
– Relationships and the System Boundary
– Consider 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 nested
within 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 and analysing requirements
• Producing and documenting the design
• Detailed specifications• Identifying and
designing components
• Requirements analysis and definition
• System design
• Program design
Analogy ...
• Building components
• Testing components
• Integrating components
• Making final modifications
• Continuing maintenance
• Writing programs
• Unit testing
• Integration testing
• System testing
• System delivery
• Maintenance
7 Factors Altering S/ware Engineering
Key factors that changed SWE1.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 computingLower hardware costs and greater development and maintenance costs
3.Availability of powerful desktop computingMore development power in hands of users, therefore software engineers are likely to be building more complex systems than before
4.Extensive networks availableMakes it easier for users to find information without special applications e.g. searching WWW is quick, easy and effective
Key factors that changed SWE
5. Availability and adoption of object-oriented technology
Makes available reusable modules for immediate and speedy inclusion in new applications
6. Graphical User Interfaces (GUIs)Helps to put a friendly face (appearance) on complicated applications
7. Unpredictability of the waterfall methodDeveloping subsystems in parallel requires development process very different from waterfall model
Discipline of Software Engineering
• Abstraction
• Analysis and Design methods and Notations• User Interface Prototyping• Software Architecture• Software Process• Reuse• Measurement• Tools and Integrated Environments
Abstraction
• Abstraction is a description of the problem at some level of generalisation that allows us to concentrate on the key aspects of the problem without getting involved in the difficulties of the details.
• Typically involves identifying classes of objects that allow us to group items together so we:– Can deal with fewer things, and– Concentrate on the commonalities of items in each class
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 a system– 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 when developer 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 a system.
• 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 process
Reuse• We take advantage of commonalities across
applications by reusing items from previous development.
• Reuse pertains not only to code but to design, test data, requirements etc.
Measurement
• Measurement is a driving force in software engineering research: – improving our processes, resources and methods so that
we produce and maintain better products.– But sometimes we express measurements generally, with
no quantitative description.
• We would like to quantify:– where we can and what we can, – describe our actions and outcomes in a common
mathematical 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 the
development process• Data: the way the tools share data• Control: the ability of one tool to notify and initiate
action in another.
Therac-25 (from IEEE Computer July 1993)
Computers are increasingly being introduced into safety-critical systems and as a consequence, have been involved in accidents. Some of the most widely cited software-related accidents in safety-critical systems involved a computerized radiation therapy machine called the Therac-25.
Between June 1985 and January 1987, six known accidents involving massive overdoses by the Therac-25 --- with resultant deaths and seriious injuries.
Therac-25 routines(from IEEE Computer July 1993)
