software engineering – i cscs 300 – fall 2009 ms. saira anwar
Post on 19-Jan-2016
216 Views
Preview:
TRANSCRIPT
SOFTWARE ENGINEERING – I
CSCS 300 – Fall 2009
Ms. Saira Anwar
SOFTWARE Definition Computer software is the product that software
engineers design, build and support. Software is
Most widely used in all fields Medical Telecommunication Military Industry etc
When executed provide desired
features, functions and performance
Enable to adequately manipulate information
Describe operation and use of programs
DUAL ROLE OF A SOFTWARE
A product itself Computing Potential Information transformer
Managing, Producing, Acquiring, Modifying, Displaying
Vehicle to deliver a product Control of computer
Operating Systems
Communication of information Networks
Creation of programs Software tools and environments
TYPES OF SOFTWARE
Generic software Stand-alone systems produced by a development
organization and sold on the open market to any customer
for example word processors, spreadsheets and games
Customized software Systems commissioned by a particular customer. for example web sites, air-traffic control
systems and software for managing the finances of large organizations
Some Software Characteristics Software is engineered or developed, not manufactured
in the traditional sense.Software does not wear out in the same sense as hardware.
Some Software Characteristics In theory, software does not wear out at all.
BUT,
Hardware upgrades.Software upgrades.
Some Software CharacteristicsThus, reality is more like this.
Most serious corporations control and constrain changes
Most software is custom built, and customer never really knows what she/he wants.
ENGINEERING
Definition Implementation of a solution to a
practical problem activity which aims at
solving a problem completing a task (definition, design, and specification)
Analysis, design, construction, verification, and management of technical (or social) entities.
11
WHAT IS SOFTWARE ENGINEERING? Engineering approach to develop
software. Building Construction Analogy.
Systematic collection of past experience: techniques, methodologies, guidelines.
SOFTWARE ENGINEERING Definition
Establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines.
WHY SOFTWARE ENGINEERING
Organized, systematic, and controlled software development
Software engineering is concerned with theories, methods and tools for professional software development
Customer wants low cost and short time for software development
14
Why study software engineering?
To acquire skills to develop large programs. Exponential growth in complexity
and difficulty level with size.
15
Why study software engineering?
Ability to solve complex programming problems: How to break large projects into
smaller and manageable parts? Learn techniques of:
specification, design, interface development, testing, project management, etc.
16
Why study software engineering?
To acquire skills to be a better programmer:
Higher Productivity Better Quality Programs
IMPORTANCE OF SOFTWARE ENGINEERING
Software crisis Software quality
18
SOFTWARE CRISIS Software products:
fail to meet user requirements. frequently crash. expensive. difficult to alter, debug, and
enhance. often delivered late. use resources non-optimally.
19
FACTORS CONTRIBUTING TO THE SOFTWARE CRISIS
Larger problems, Lack of adequate training in
software engineering, Increasing skill shortage, Low productivity improvements.
DIFFERENCE
Software Engineering Concerned with the
practicalities of developing and delivering useful software
A field of study deals with practicalities of software development
Computer science Concerned with theory
and fundamentals
A field of study deals with theories and practices of computation, communication, automation, coordination and data manipulation.
DIFFERENCE System engineering
Concerned with all aspects of computer-based systems development, including hardware, software, and process engineering
Software engineering Part of system
engineering Deals with
software only
COMPARING SOFTWARE ENGINEERING AND RELATED FIELDS For further information, check this link
http://en.wikipedia.org/wiki/Comparing_software_engineering_and_related_fields
SOFTWARE MYTHS (MANAGEMENT PERSPECTIVES)
SOFTWARE MYTHS (MANAGEMENT PERSPECTIVES)As long as there are good standards and clear procedures in my company, I shouldn’t be too concerned.
But the proof of the pudding is in the eating;
not in the Recipe !
SOFTWARE MYTHS (MANAGEMENT PERSPECTIVES)
SOFTWARE MYTHS (MANAGEMENT PERSPECTIVES)As long as my software engineers(!) have access to the fastest and the most sophisticated computer environments and state-of-the-art software tools, I shouldn’t be too concerned.
The environment is only one of the several factors
that determine the quality of the end software product!
SOFTWARE MYTHS (MANAGEMENT PERSPECTIVES)
SOFTWARE MYTHS (MANAGEMENT PERSPECTIVES)When my schedule slips, what I have to do is to start a fire-fighting operation: add more software specialists, those with higher skills and longer experience - they will bring the schedule back on the rails! (Mongolian Horde Concept)
Unfortunately, software business does not
entertain schedule compaction beyond a limit!
Adding people to a late software projectsMake it later
SOFTWARE MYTHS(CUSTOMER PERSPECTIVES)
SOFTWARE MYTHS(CUSTOMER PERSPECTIVES) A general statement of objectives is
sufficient to get started with the development of software. Missing/vague requirements can easily be incorporated/detailed out as they get concretized.
Application requirements can never be stable; software can be and has to be made flexible enough to allow changes to be incorporated as they happen.
SOFTWARE MYTHS(DEVELOPER PERSPECTIVES)SOFTWARE MYTHS(DEVELOPER PERSPECTIVES)
Once the software is demonstrated, the job is done.
Usually, the problems just begin!
Until the software is coded and is available for testing, there is no way for assessing its quality.
Usually, there are too many tiny bugs inserted at every stage that grow in size and complexity
as they progress thru further stages!
SOFTWARE MYTHS(DEVELOPER PERSPECTIVES)
SOFTWARE MYTHS(DEVELOPER PERSPECTIVES)
The only deliverable for a software development project is the tested code.
The code is only the externally visible component
of the entire software complement!
SOFTWARE MYTHS(DEVELOPER PERSPECTIVES)SOFTWARE MYTHS(DEVELOPER PERSPECTIVES)
SOFTWARE PRODUCTSOFTWARE PRODUCT
is a product designated for delivery to the user
sourcecodes
sourcecodes
objectcodes
objectcodes
plansplans
reportsreports
manualsmanuals
documentsdocuments
test suitestest suitesprototypesprototypes
datadata
test resultstest results
Software Myths Myth: It’s in the software. So, we can easily change it.
Reality: Requirements changes are a major cause of software degradation.
Myth: We can solve schedule problems by adding more programmers.
Reality: Maybe. It increases coordination efforts and may slow things down.
Myth: While we don’t have all requirements in writing yet, we know what we want and can start writing code.
Reality: Incomplete up-front definition is the major cause of software project failures.
Software Myths Myth: Writing code is the major part of creating a
software product.Reality: Coding may be as little as 10% of the effort, and 50 - 70% may occur after delivery.
Software MythsMyth: I can’t tell you how well we are doing until I get parts of it running.
Reality: Formal reviews of various types both can give good information and are critical to success in large projects.
Myth: The only deliverable that matters is working code.
Reality: Documentation, test history, and program configuration are critical parts of the delivery.
Myth: I am a (super) programmer. Let me program it, and I will get it done.
Reality: A sign of immaturity. A formula for failure. Software projects are done by teams, not individuals, and success requires much more than just coding.
BOEHM’S TOP TENINDUSTRIAL SOFTWARE METRICS
BOEHM’S TOP TENINDUSTRIAL SOFTWARE METRICS
BOEHM’S TOP TENINDUSTRIAL SOFTWARE METRICS
BOEHM’S TOP TENINDUSTRIAL SOFTWARE METRICS
Finding and fixing a software problem after delivery of the product is 100 times more expensive than defect removal during requirements and early design phases.
11
EFFORT TO REPAIR SOFTWARE(WHEN DEFECTS ARE DETECTED AT DIFFERENT STAGES)
EFFORT TO REPAIR SOFTWARE(WHEN DEFECTS ARE DETECTED AT DIFFERENT STAGES)
0.15 0.5 12
5
20
0
5
10
15
20
rela
tive
effo
rt to
re
pa
ir
Reqmts Coding Acc. Test
Nominal software development schedules can be compressed up to 25% (by adding people, money, etc.) but no more.
22
BOEHM’S TOP TENINDUSTRIAL SOFTWARE METRICS
BOEHM’S TOP TENINDUSTRIAL SOFTWARE METRICS
Maintenance costs twice what the development costs. 33
BOEHM’S TOP TENINDUSTRIAL SOFTWARE METRICS
BOEHM’S TOP TENINDUSTRIAL SOFTWARE METRICS
Development and maintenance costs are primarily a function of the size. 44
BOEHM’S TOP TENINDUSTRIAL SOFTWARE METRICS
BOEHM’S TOP TENINDUSTRIAL SOFTWARE METRICS
Variations in humans account for the greatest variations in productivity. 55
BOEHM’S TOP TENINDUSTRIAL SOFTWARE METRICS
BOEHM’S TOP TENINDUSTRIAL SOFTWARE METRICS
The ratio of software to hardware costs has gone from 15:85 in 1985 and continues to grow in favor of software as the dominant cost.
66
BOEHM’S TOP TENINDUSTRIAL SOFTWARE METRICS
BOEHM’S TOP TENINDUSTRIAL SOFTWARE METRICS
HARDWARE VS SOFTWARE COSTSHARDWARE VS SOFTWARE COSTS
0
20
40
60
80
100
1960 1970 1980 1990
Hardware
Software
Only about 15% of the development effort is in coding. 77
BOEHM’S TOP TENINDUSTRIAL SOFTWARE METRICS
BOEHM’S TOP TENINDUSTRIAL SOFTWARE METRICS
DISTRIBUTION OF EFFORTACROSS PHASES
DISTRIBUTION OF EFFORTACROSS PHASES
2030
4515
30
40
20
15
545
2510
T raditionalenvironment
Structuredtechniques
CASE environment
Analysis Design Coding Testing
Testing
Coding
Design
Analysis
Applications products cost three times as much per instruction as individual programs; system software products cost nine times as much.
88
BOEHM’S TOP TENINDUSTRIAL SOFTWARE METRICS
BOEHM’S TOP TENINDUSTRIAL SOFTWARE METRICS
Walkthroughs catch 60% of the errors. 99
BOEHM’S TOP TENINDUSTRIAL SOFTWARE METRICS
BOEHM’S TOP TENINDUSTRIAL SOFTWARE METRICS
DISTRIBUTION OF ACTIVITIESIN DEFECT REMOVAL
DISTRIBUTION OF ACTIVITIESIN DEFECT REMOVAL
65
10
10 5 10
walkthru
unit test
evaluation
integration
other
20%20%modules modules
80%80%cost cost
Many software processes obey a Pareto distribution.1010
BOEHM’S TOP TENINDUSTRIAL SOFTWARE METRICS
BOEHM’S TOP TENINDUSTRIAL SOFTWARE METRICS
Many software processes obey a Pareto distribution.1010
20%20%modules modules
80%80%errors errors
BOEHM’S TOP TENINDUSTRIAL SOFTWARE METRICS
BOEHM’S TOP TENINDUSTRIAL SOFTWARE METRICS
20%20%modules modules
80%80%cost cost to fix to fix
Many software processes obey a Pareto distribution.1010
BOEHM’S TOP TENINDUSTRIAL SOFTWARE METRICS
BOEHM’S TOP TENINDUSTRIAL SOFTWARE METRICS
20%20%modules modules
80%80%exec time exec time
Many software processes obey a Pareto distribution.1010
BOEHM’S TOP TENINDUSTRIAL SOFTWARE METRICS
BOEHM’S TOP TENINDUSTRIAL SOFTWARE METRICS
20%20%tools tools
80%80%useuse
Many software processes obey a Pareto distribution.1010
BOEHM’S TOP TENINDUSTRIAL SOFTWARE METRICS
BOEHM’S TOP TENINDUSTRIAL SOFTWARE METRICS
54
SYMPTOM OF SOFTWARE CRISIS
10% of client/server apps are abandoned or restarted from scratch
20% of apps are significantly altered to avoid disaster
40% of apps are delivered significantly late
Source: 3 year study of 70 large c/s apps 30 European firms. Source: 3 year study of 70 large c/s apps 30 European firms. Compuware (12/95)Compuware (12/95)
PROGRAMS VERSUS SOFTWARE PRODUCTS
Programs Software Products
Usually small in size Large number of users
Author himself is sole userSingle developer
Team of developersWell-designed interface
Lacks proper user interfaceLacks proper documentation
Well documented & user-manual prepared
Ad hoc development. Systematic development
top related