Download Software's Dual Role in Advanced Software Engineering | CS 430 and more Study notes Software Engineering in PDF only on Docsity!
These courseware materials are to be used in conjunction withwith permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 Software Engineering: A Practitioner’s Approach, 6/e and are provided 1
West Virginia University West Virginia University
CS 430, Fall 2004CS 430, Fall 2004
copyrightcopyright ©© 1996, 2001, 20051996, 2001, 2005 R.S. Pressman & Associates, Inc.R.S. Pressman & Associates, Inc.
For review purposes ONLY by potential adopters ofFor review purposes ONLY by potential adopters of Software Engineering: A Practitioner's Approach.Software Engineering: A Practitioner's Approach. Any other reproduction or use is expressly prohibited.Any other reproduction or use is expressly prohibited.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 2
SoftwareSoftware’’s Dual Roles Dual Role
Software is a productSoftware is a product
^ Delivers computing potentialDelivers computing potential Produces, manages, acquires, modifies, displays, or transmitsProduces, manages, acquires, modifies, displays, or transmits informationinformation
Software is a vehicle for delivering a productSoftware is a vehicle for delivering a product
Supports or directly provides system functionalitySupports or directly provides system functionality Controls other programs (e.g., an operating system)Controls other programs (e.g., an operating system) Effects communications (e.g., networking software)Effects communications (e.g., networking software) Helps build other software (e.g., software tools)Helps build other software (e.g., software tools)
Wear vs. DeteriorationWear vs. Deterioration
idealized curve
change
actual curve
Failure rate
Time
increased failure rate due to side effects
These courseware materials are to be used in conjunction withwith permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 Software Engineering: A Practitioner’s Approach, 6/e and are provided 4
Legacy Software Legacy Software
software must besoftware must be adaptedadapted to meet the needs of newto meet the needs of new computing environments or technology.computing environments or technology. software must besoftware must be enhancedenhanced to implement newto implement new business requirements.business requirements. ^ software must besoftware must be extended to make it interoperableextended to make it interoperable with other more modern systems or databases.with other more modern systems or databases. software must besoftware must be rere--architectedarchitected to make it viableto make it viable within a network environmentwithin a network environment.
Why must it change?
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 5
Software Myths Software Myths
Affect managers, customers (and other nonAffect managers, customers (and other non--technicaltechnical
stakeholders) and practitionersstakeholders) and practitioners
Are believable because they often have elements ofAre believable because they often have elements of
truth,truth,
but … but…
Invariably lead to bad decisions,Invariably lead to bad decisions,
therefore … therefore…
Insist on reality as you navigate your way throughInsist on reality as you navigate your way through
software engineeringsoftware engineering
A Layered Technology A Layered Technology
Software Engineering
aa ““qualityquality”” focusfocus
process modelprocess model
methodsmethods
toolstools
These courseware materials are to be used in conjunction withwith permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 Software Engineering: A Practitioner’s Approach, 6/e and are provided 10
Evolutionary Models: PrototypingEvolutionary Models: Prototyping
Com m unicat ion
Qu ick p l an
Const r uct ion of pr ot ot ype
Mo d e l i n gQ u i ck d e si g n
De live r y & Fe e dback
Deployment
communication
Quick plan
Modeling Quick design
Construction of prototype
Deployment delivery & feedback
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 11
The Manifesto forThe Manifesto for
Agile Software DevelopmentAgile Software Development
““We are uncovering better ways of developingWe are uncovering better ways of developing software by doing it and helping others do it.software by doing it and helping others do it. Through this work we have come to value:Through this work we have come to value:
- • Individuals and interactionsIndividuals and interactions over processesover processes and toolsand tools
- • Working softwareWorking software over comprehensiveover comprehensive documentationdocumentation
- • Customer collaborationCustomer collaboration over contractover contract negotiationnegotiation
- • Responding to changeResponding to change over following a planover following a plan That is, while there is value in the items on theThat is, while there is value in the items on the right, we value the items on the left more.right, we value the items on the left more.””
Kent Beck et alKent Beck et al
An Agile ProcessAn Agile Process
Is driven by customer descriptions of what isIs driven by customer descriptions of what is
required (scenarios)required (scenarios)
Recognizes that plans are shortRecognizes that plans are short--livedlived
^ Develops software iteratively with a heavyDevelops software iteratively with a heavy
emphasis on construction activitiesemphasis on construction activities
Delivers multipleDelivers multiple ‘‘software incrementssoftware increments’’
Adapts as changes occurAdapts as changes occur
These courseware materials are to be used in conjunction withwith permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 Software Engineering: A Practitioner’s Approach, 6/e and are provided 13
Extreme Programming (XP) Extreme Programming (XP)
unit t est cont inuous int egrat ion
accept ance t est ing
pair programming
Release
user st ories values accept ance t est crit eria it erat ion plan
simple design CRC cards
spike solut ions prot ot ypes
ref act oring
sof t ware increment project velocit y comput ed
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 14
Core Software EngineeringCore Software Engineering
PrinciplesPrinciples
Provide value to the customer and the userProvide value to the customer and the user
KISKIS——keep it simple!keep it simple!
Maintain the product and projectMaintain the product and project ““visionvision””
What you produce, others will consumeWhat you produce, others will consume
Be open to the futureBe open to the future
^ Plan ahead for reusePlan ahead for reuse
Think!Think!
System EngineeringSystem Engineering
^ Elements of a computer-Elements of a computer-based systembased system
SoftwareSoftware HardwareHardware PeoplePeople DatabaseDatabase DocumentationDocumentation ProceduresProcedures
SystemsSystems
A hierarchy of macroA hierarchy of macro--elementselements
These courseware materials are to be used in conjunction withwith permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 Software Engineering: A Practitioner’s Approach, 6/e and are provided 19
Analysis ModelAnalysis Model --> Design Model> Design Model
Analysis Model
use-cases - textuse-case diagrams activity diagramsswim lane diagrams
data flow diagramscontrol-flow diagrams processing narratives
f l ow- o r i e nt e de l e m e nt s
c l a ss- ba se de l e m e nt s b e ha v i or a le l e m e nt s
sc e na r i o- ba se de l e m e nt s
class diagramsanalysis packages CRcollaboration diagramsC models
state diagramssequence diagrams D a t a / Cl a ss D e si g n
A r c h it e c t u r a l D e si g n
I n t e r f a c e D e si g n
Co m p o n e n t - L e v e l D e si g n
Design Model
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 20
Design PrinciplesDesign Principles
^ The design process should not suffer fromThe design process should not suffer from ‘‘tunnel vision.tunnel vision.’’ The design should be traceable to the analysis model.The design should be traceable to the analysis model. The design should not reinvent the wheel.The design should not reinvent the wheel. The design shouldThe design should ““minimize the intellectual distanceminimize the intellectual distance”” [DAV95] between[DAV95] between the software and the problem as it exists in the real world.the software and the problem as it exists in the real world. The design should exhibit uniformity and integration.The design should exhibit uniformity and integration. The design should be structured to accommodate change.The design should be structured to accommodate change. The design should be structured to degrade gently, even when abeThe design should be structured to degrade gently, even when aberrantrrant data, events, or operating conditions are encountered.data, events, or operating conditions are encountered. Design is not coding, coding is not design.Design is not coding, coding is not design. The design should be assessed for quality as it is being createdThe design should be assessed for quality as it is being created, not after, not after the fact.the fact. The design should be reviewed to minimize conceptual (semantic)The design should be reviewed to minimize conceptual (semantic) errors.errors. From Davis [DAV95]
Fundamental Concepts Fundamental Concepts
abstractionabstraction——data, procedure, controldata, procedure, control ^ architecturearchitecture——the overall structure of the softwarethe overall structure of the software patternspatterns——””conveys the essenceconveys the essence”” of a proven design solutionof a proven design solution modularitymodularity——compartmentalization of data and functioncompartmentalization of data and function hidinghiding——controlled interfacescontrolled interfaces Functional independenceFunctional independence——singlesingle--minded function and low couplingminded function and low coupling refinementrefinement——elaboration of detail for all abstractionselaboration of detail for all abstractions (^) RefactoringRefactoring——a reorganization technique that simplifies the designa reorganization technique that simplifies the design
These courseware materials are to be used in conjunction withwith permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 Software Engineering: A Practitioner’s Approach, 6/e and are provided 22
Testing StrategyTesting Strategy
We begin byWe begin by ‘‘testingtesting--inin--thethe--smallsmall’’ and move towardand move toward
‘‘testingtesting--inin--thethe--largelarge’’
For conventional softwareFor conventional software
The module (component) is our initial focusThe module (component) is our initial focus Integration of modules followsIntegration of modules follows
For OO softwareFor OO software
our focus whenour focus when ““testing in the smalltesting in the small”” changes from an individualchanges from an individual module (the conventional view) to an OO class thatmodule (the conventional view) to an OO class that encompasses attributes and operations and impliesencompasses attributes and operations and implies communication and collaborationcommunication and collaboration
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 23
Strategic IssuesStrategic Issues
(^) State testing objectives explicitly.State testing objectives explicitly.
Understand the users of the software and develop a profile for eUnderstand the users of the software and develop a profile for each userach user category.category. Develop a testing plan that emphasizesDevelop a testing plan that emphasizes ““rapid cycle testing.rapid cycle testing.”” BuildBuild ““robustrobust”” software that is designed to test itselfsoftware that is designed to test itself Use effective formal technical reviews as a filter prior to testUse effective formal technical reviews as a filter prior to testinging Conduct formal technical reviews to assess the test strategy andConduct formal technical reviews to assess the test strategy and test casestest cases themselves.themselves. Develop a continuous improvement approach for the testing procesDevelop a continuous improvement approach for the testing process.s.
TestabilityTestability
OperabilityOperability——it operates cleanlyit operates cleanly ObservabilityObservability——the results of each test case are readilythe results of each test case are readily observedobserved ControllabilityControllability——the degree to which testing can be automatedthe degree to which testing can be automated and optimizedand optimized DecomposabilityDecomposability——testing can be targetedtesting can be targeted SimplicitySimplicity——reduce complex architecture and logic to simplifyreduce complex architecture and logic to simplify teststests StabilityStability——few changes are requested during testingfew changes are requested during testing UnderstandabilityUnderstandability——of the designof the design
These courseware materials are to be used in conjunction withwith permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 Software Engineering: A Practitioner’s Approach, 6/e and are provided 28
Measures, Metrics and Indicators Measures, Metrics and Indicators
AA measuremeasure provides a quantitative indication of theprovides a quantitative indication of the
extent, amount, dimension, capacity, or size of someextent, amount, dimension, capacity, or size of some
attribute of a product or processattribute of a product or process
The IEEE glossary defines aThe IEEE glossary defines a metricmetric asas ““a quantitativea quantitative
measure of the degree to which a system, component, ormeasure of the degree to which a system, component, or
process possesses a given attribute.process possesses a given attribute.””
AnAn indicatorindicator is a metric or combination of metrics thatis a metric or combination of metrics that
provide insight into the software process, a softwareprovide insight into the software process, a software
project, or the product itselfproject, or the product itself
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 29
Measurement PrinciplesMeasurement Principles
The objectives of measurement should be established beforeThe objectives of measurement should be established before data collection begins;data collection begins; Each technical metric should be defined in an unambiguousEach technical metric should be defined in an unambiguous manner;manner; Metrics should be derived based on a theory that is valid for thMetrics should be derived based on a theory that is valid for thee domain of application (e.g., metrics for design should draw upondomain of application (e.g., metrics for design should draw upon basic design concepts and principles and attempt to provide anbasic design concepts and principles and attempt to provide an indication of the presence of an attribute that is deemedindication of the presence of an attribute that is deemed desirable);desirable); Metrics should be tailored to best accommodate specific productsMetrics should be tailored to best accommodate specific products and processes [BAS84]and processes [BAS84]
Goal- Goal-Oriented Software MeasurementOriented Software Measurement
The Goal/Question/Metric ParadigmThe Goal/Question/Metric Paradigm (1) establish an explicit measurement(1) establish an explicit measurement goalgoal that is specific to the processthat is specific to the process activity or product characteristic that is to be assessedactivity or product characteristic that is to be assessed (2) define a set of(2) define a set of questionsquestions that must be answered in order to achieve thethat must be answered in order to achieve the goal, andgoal, and (^) (3) identify well(3) identify well--formulatedformulated (^) metricmetricss (^) that help to answer these questions.that help to answer these questions. Goal definition templateGoal definition template AnalyzeAnalyze {the name of activity or attribute to be measured}{the name of activity or attribute to be measured} ^ for the purpose offor the purpose of {the overall objective of the analysis}{the overall objective of the analysis} with respect towith respect to {the aspect of the activity or attribute that is considered}{the aspect of the activity or attribute that is considered} from the viewpoint offrom the viewpoint of {the people who have an interest in the measurement}{the people who have an interest in the measurement} in the context ofin the context of {the environment in which the measurement takes place}.{the environment in which the measurement takes place}.
These courseware materials are to be used in conjunction withwith permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 Software Engineering: A Practitioner’s Approach, 6/e and are provided 31
Software TeamsSoftware Teams
How to lead? How to organize?
How to motivate?
How to collaborate?
How to create good ideas?
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 32
The Project
(^) Projects get into trouble whenProjects get into trouble when ……
^ Software people donSoftware people don’’t understand their customert understand their customer’’s needs.s needs. ^ The product scope is poorly defined.The product scope is poorly defined. Changes are managed poorly.Changes are managed poorly. The chosen technology changes.The chosen technology changes. Business needs change [or are illBusiness needs change [or are ill--defined].defined]. ^ Deadlines are unrealistic.Deadlines are unrealistic. Users are resistant.Users are resistant. Sponsorship is lost [or was never properly obtained].Sponsorship is lost [or was never properly obtained]. The project team lacks people with appropriate skills.The project team lacks people with appropriate skills. Managers [and practitioners] avoid best practices and lessons leManagers [and practitioners] avoid best practices and lessons learned.arned.
A Good Manager Measures A Good Manager Measures
measurementmeasurement
What do weWhat do we
use as ause as a
basis?basis?
• • size?size?
• • function?function?
project metricsproject metrics
process metricsprocess metrics
processprocess
productproduct
product metricsproduct metrics
These courseware materials are to be used in conjunction withwith permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 Software Engineering: A Practitioner’s Approach, 6/e and are provided 37
Timeline ChartsTimeline Charts
Tasks (^) Week 1 Week 2 Week 3 Week 4 Week n
Task 1 Task 2 Task 3 Task (^4) Task 5 Task 6 Task 7 Task 8 Task 9 Task 10 Task 11 Task 12
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 38
Software Quality AssuranceSoftware Quality Assurance
Formal Technical Reviews
Test Planning Measurement & Review
Analysis & Reporting
Process Definition & Standards
Importance of Software- Importance of Software-RevisitedRevisited
In Chapter 1, software was characterized as a differentiator.
The function delivered by software differentiates products, systems, and services and provides competitive advantage in the marketplace.
But software is more that a differentiator.
The programs, documents, and data that are software help to
generate the most important commodity that any individual,
business, or government can acquire—information.
These courseware materials are to be used in conjunction withwith permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 Software Engineering: A Practitioner’s Approach, 6/e and are provided 40
Software Engineering EthicsSoftware Engineering Ethics--II
An ACM/IEEEAn ACM/IEEE--CS Joint Task Force has produced aCS Joint Task Force has produced a SoftwareSoftware
Engineering Code of Ethics and Professional PracticesEngineering Code of Ethics and Professional Practices
(Version 5.1). The code [ACM98] states:(Version 5.1). The code [ACM98] states:
^ Software engineers shall commit themselves to making the analysiSoftware engineers shall commit themselves to making the analysis,s, specification, design, development, testing and maintenance of sspecification, design, development, testing and maintenance of softwareoftware a beneficial and respected profession. In accordance with theira beneficial and respected profession. In accordance with their commitment to the health, safety and welfare of the public, softcommitment to the health, safety and welfare of the public, softwareware engineers shall adhere to the following Eight Principles:engineers shall adhere to the following Eight Principles:
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 41
Software Engineering EthicsSoftware Engineering Ethics--II
1. PUBLIC1. PUBLIC -- Software engineers shall act consistently with the public interSoftware engineers shall act consistently with the public interest.est. 2. CLIENT AND EMPLOYER2. CLIENT AND EMPLOYER -- Software engineers shall act in a manner that is in the bestSoftware engineers shall act in a manner that is in the best interests of their client and employer consistent with the publiinterests of their client and employer consistent with the public interest.c interest. 3. PRODUCT3. PRODUCT -- Software engineers shall ensure that their products and relatedSoftware engineers shall ensure that their products and related modifications meetmodifications meet the highest professional standards possible.the highest professional standards possible. 4. JUDGMENT4. JUDGMENT -- Software engineers shall maintain integrity and independence inSoftware engineers shall maintain integrity and independence in theirtheir professional judgment.professional judgment. (^) 5. MANAGEMENT5. MANAGEMENT -- Software engineering managers and leaders shall subscribe to anSoftware engineering managers and leaders shall subscribe to and promoted promote an ethical approach to the management of software development anan ethical approach to the management of software development and maintenance.d maintenance. 6. PROFESSION6. PROFESSION -- Software engineers shall advance the integrity and reputation oSoftware engineers shall advance the integrity and reputation of the professionf the profession consistent with the public interest.consistent with the public interest. (^) 7. COLLEAGUES7. COLLEAGUES -- Software engineers shall be fair to and supportive of their colSoftware engineers shall be fair to and supportive of their colleagues.leagues. 8. SELF8. SELF -- Software engineers shall participate in lifelong learning regarSoftware engineers shall participate in lifelong learning regarding the practice of theirding the practice of their profession and shall promote an ethical approach to the practiceprofession and shall promote an ethical approach to the practice of the profession.of the profession.
