Post on 14-Apr-2018
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 1/195
Good MorningGood Morning
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 2/195
Software EngineeringSoftware Engineering
Toady we will try to coverToady we will try to cover
Introduction to software engineeringIntroduction to software engineering
Various definitionsVarious definitions
Goals of software engineeringGoals of software engineering Software characteristicsSoftware characteristics
Various models used in softwareVarious models used in softwaredevelopmentdevelopment
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 3/195
What is SoftwareWhat is Software
Software is product that softwareSoftware is product that software
professional build and support overprofessional build and support overthe long term.the long term.
it affects nearly every aspect of ourit affects nearly every aspect of ourliveslives
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 4/195
Text book description of software isText book description of software is
It is instructions when executedIt is instructions when executed
provide desired features , functionprovide desired features , functionand performance.and performance.
programs to manipulate informationprograms to manipulate information
And descriptive information whichAnd descriptive information which
describes operations and use of describes operations and use of program.program.
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 5/195
Software CharacteristicsSoftware Characteristics
Software is developed it is notSoftware is developed it is not
manufactured in classical sensemanufactured in classical sense
Although the industry is moving towardAlthough the industry is moving towardcomponent based construction , mostcomponent based construction , mostsoftware continues to be custom buildsoftware continues to be custom build
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 6/195
Hardware failure graphHardware failure graph
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 7/195
Software failure graphSoftware failure graph
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 8/195
Actual software failure graphActual software failure graph
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 9/195
Software ComponentsSoftware Components
Software components are createdSoftware components are created
through a series of translations thatthrough a series of translations thatmap customers requirements tomap customers requirements to
..
Reusability is an importantReusability is an importantcharacteristic of high quality softwarecharacteristic of high quality software
componentcomponent
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 10/195
Software application DomainsSoftware application Domains
System softwareSystem software
Application softwareApplication software
Engineering & scientific softwareEngineering & scientific software
Embedded softwareEmbedded software Product line softwareProduct line software
Web ApplicationsWeb Applications Artificial intelligence softwareArtificial intelligence software
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 11/195
System softwareSystem software System software is computerSystem software is computer
software designed to operate thesoftware designed to operate thecomputer hardware,computer hardware,
to rovide basic functionalit and toto rovide basic functionalit and to
provide a platform for runningprovide a platform for runningapplication software.application software.
System software includes deviceSystem software includes device
drivers, operating systems, servers,drivers, operating systems, servers,utilities, and window systems.utilities, and window systems.
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 12/195
Application softwareApplication software
Standalone program that solvesStandalone program that solves
specific business needspecific business need
eg. Point of sale system (POS)eg. Point of sale system (POS)
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 13/195
Engineering & scientific softwareEngineering & scientific software
These has been characterized byThese has been characterized by
"number cruncher" ie. A software"number cruncher" ie. A softwarewhich is able to perform complex,which is able to perform complex,
--Applications range from astronomyApplications range from astronomyto volcanologyto volcanology
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 14/195
Embedded softwareEmbedded software
Embedded software is computerEmbedded software is computer
software, written to control machinessoftware, written to control machinesor devices that are not typicallyor devices that are not typically
..
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 15/195
Product line softwareProduct line software
These software can focus on aThese software can focus on a
limited and esoteric (Understood bylimited and esoteric (Understood byonly a particular group) marketplaceonly a particular group) marketplace
..
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 16/195
Web ApplicationsWeb Applications
it is more than set of links thatit is more than set of links that
present information using text andpresent information using text andgraphicsgraphics
environment but integrate corporateenvironment but integrate corporatedatabase and business applicationsdatabase and business applications
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 17/195
Artificial intelligence softwareArtificial intelligence software
software used in robotics neuralsoftware used in robotics neural
networks.networks.
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 18/195
Many of software engineers workMany of software engineers work
hard to develop s/w in one of thesehard to develop s/w in one of thesecategories. some develop new wherecategories. some develop new where
..
Tomorrow it might possible you areTomorrow it might possible you areworking on software that is olderworking on software that is older
than youthan you
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 19/195
lets understand what is Legacylets understand what is Legacy
softwaresoftware Legacy software systems are programs that are oftenLegacy software systems are programs that are often
critical to the operation of companies.critical to the operation of companies.
These programs were developed years ago and, in manyThese programs were developed years ago and, in manycases, use early programming languages such as COBOLcases, use early programming languages such as COBOLand FORTRAN.and FORTRAN.
In addition, these programs have been maintained forIn addition, these programs have been maintained forman ears b various ro rammers.man ears b various ro rammers.
Because of the years of changes that have been made toBecause of the years of changes that have been made tothe software, supporting documentation may not be currentthe software, supporting documentation may not be currentand the authors may no longer be available.and the authors may no longer be available.
Without either the full documentation, or the personnel whoWithout either the full documentation, or the personnel whounderstand the code, changes to these programs can beunderstand the code, changes to these programs can behard to accomplish, expensive, and should not be takenhard to accomplish, expensive, and should not be takenlightly.lightly.
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 20/195
Reason why we have LegacyReason why we have Legacy
softwaresoftware The system requires constant availability,The system requires constant availability,
so it cannot be taken out of service, andso it cannot be taken out of service, andthe cost of designing a new system with athe cost of designing a new system with asimilar availability level is high. Examplessimilar availability level is high. Examples
''
accounts in banks, computer reservationaccounts in banks, computer reservationsystems, air traffic control,systems, air traffic control,
The system works satisfactorily, and theThe system works satisfactorily, and the
owner sees no reason for changing itowner sees no reason for changing it --The costs of redesigning or replacing theThe costs of redesigning or replacing the
system are prohibitive because it is largesystem are prohibitive because it is large
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 21/195
Old school view of software isOld school view of software is –– you buy it / you own it andyou buy it / you own it and
its your job to manage software.its your job to manage software.
This approach is coming to an end due to web basedThis approach is coming to an end due to web basedapproach.approach.
Now days we see completely different generation of Now days we see completely different generation of software it will be delivered via internet and it looks exactlysoftware it will be delivered via internet and it looks exactlylike it is residing on each users computer but in actual it willlike it is residing on each users computer but in actual it willbe reside on a far away server.be reside on a far away server.
If we look at user of software life is much sim ler.If we look at user of software life is much sim ler.
Once update is made on server it will be available to allOnce update is made on server it will be available to alluser at same time , but if there is mistake in update it willuser at same time , but if there is mistake in update it willalso impact to everyone.also impact to everyone.
If we look at all above conditions if we need fast and rightIf we look at all above conditions if we need fast and rightsoftware we need 'Software Engineering'.software we need 'Software Engineering'.
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 22/195
Goals of Software EngineeringGoals of Software Engineering To create systems that are ReliableTo create systems that are Reliable -- system to performsystem to perform
and maintain its functions in routine circumstances, as welland maintain its functions in routine circumstances, as well
as hostile or unexpected circumstances.as hostile or unexpected circumstances.
To create systems that are EfficientTo create systems that are Efficient -- Achieving maximumAchieving maximumproductivity with minimum wasted effort or expense.productivity with minimum wasted effort or expense.
MaintainableMaintainable -- easy to Maintaineasy to Maintain
Meet the needs of the customersMeet the needs of the customers
To produce the system On scheduleTo produce the system On schedule
To produce the system Under budgetTo produce the system Under budget
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 23/195
Various models of softwareVarious models of software
developmentdevelopment
Waterfall Model of SDLCWaterfall Model of SDLC
Prototype ModelPrototype Model
Spiral ModelSpiral Model
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 24/195
Waterfall Model of SDLCWaterfall Model of SDLC
Waterfall Model is one of the most widely used SoftwareWaterfall Model is one of the most widely used Software
Development Process.Development Process.
It is also called as "Linear Sequential model" or the "classicIt is also called as "Linear Sequential model" or the "classiclife cycle"life cycle"
It is widely used in the commercial development projects.It is widely used in the commercial development projects.
It is called so because here, we move to next phase (step)It is called so because here, we move to next phase (step)after getting input from previous phase, like in a waterfall,after getting input from previous phase, like in a waterfall,water flows down to from the upper steps.water flows down to from the upper steps.
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 25/195
Development process is dividedDevelopment process is divided
into five phases:into five phases:--
a) Software Requirementa) Software RequirementSpecificationsSpecifications
ys em es gn an o wareys em es gn an o wareDesignDesign
c) Implementation and Unit testingc) Implementation and Unit testing
d) Integration and System Testingd) Integration and System Testing
e) Operation and Maintenancee) Operation and Maintenance
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 26/195
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 27/195
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 28/195
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 29/195
Software RequirementsSoftware Requirements
Specifications:Specifications: This is the most crucial phase for the whole project, here projectThis is the most crucial phase for the whole project, here project
team along with the customer makes a detailed list of userteam along with the customer makes a detailed list of userrequirements.requirements.
The project team chalks out the functionality and limitations (if The project team chalks out the functionality and limitations (if there are any) of the software they are developing, in detail.there are any) of the software they are developing, in detail.
e ocumen w c con a ns a s n orma on s ca e ,e ocumen w c con a ns a s n orma on s ca e ,
and it clearly and unambiguously indicates the requirements.and it clearly and unambiguously indicates the requirements.
A small amount of topA small amount of top--level analysis and design is alsolevel analysis and design is alsodocumented.documented.
This document is verified and certified by the customer beforeThis document is verified and certified by the customer beforestarting the project.starting the project.
SRS serves as the input for further phases.SRS serves as the input for further phases.
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 30/195
System Design and SoftwareSystem Design and Software
DesignDesign Using SRS as input, system design is done.Using SRS as input, system design is done.
System design included designing of software and hardwareSystem design included designing of software and hardwarei.e. functionality of hardware and software is separatedi.e. functionality of hardware and software is separated--out.out.
After separation design of software modules is done.After separation design of software modules is done.,,
The design process translates requirements intoThe design process translates requirements intorepresentation of the software that can be assessed forrepresentation of the software that can be assessed forquality before generation of code begins.quality before generation of code begins.
At the same time test plan is prepared, test plan describesAt the same time test plan is prepared, test plan describesthe various tests which will be carried out on the systemthe various tests which will be carried out on the systemafter completion of development.after completion of development.
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 31/195
Implementation and Unit Testing:Implementation and Unit Testing: Now that we have system design, codeNow that we have system design, code
generation begins. Code generation is conversiongeneration begins. Code generation is conversionof design into machineof design into machine--readable form.readable form.
If designing of software and system is done well,If designing of software and system is done well,code generation can be done easily.code generation can be done easily.
Software modules are now further divided intoSoftware modules are now further divided intounits.units.
A unit is a logically separable part of theA unit is a logically separable part of thesoftware.software.
Testing of units can be done separately. In thisTesting of units can be done separately. In thisphase unit testing is done by the developer itself,phase unit testing is done by the developer itself,to ensure that there are no defects.to ensure that there are no defects.
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 32/195
Integration and System testing:Integration and System testing: Now the units of the software areNow the units of the software are
integrated together and a system is built.integrated together and a system is built.So we have a complete software at handSo we have a complete software at handwhich is tested to check if it meets thewhich is tested to check if it meets the
of the customer.of the customer. Testing is done, as per the steps definedTesting is done, as per the steps defined
in the test plan, to ensure defined inputin the test plan, to ensure defined input
produces actual results which agree withproduces actual results which agree withthe required results. A test report isthe required results. A test report isgenerated which contains test results.generated which contains test results.
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 33/195
Operation & maintenance:Operation & maintenance: Now that we have completed theNow that we have completed the
tested software, we deliver it to thetested software, we deliver it to theclient.client.
--changes, if required, are made in thischanges, if required, are made in thisphase. This phase goes on till thephase. This phase goes on till the
software is retired.software is retired.
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 34/195
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 35/195
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 36/195
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 37/195
AdvantagesAdvantages Simple and easy to use.Simple and easy to use.
Easy to manage due to the rigidity of Easy to manage due to the rigidity of the modelthe model –– each phase has specificeach phase has specific
ases are processe an comp e eases are processe an comp e eone at a time.one at a time.
Works well for smaller projectsWorks well for smaller projects
where requirements are very wellwhere requirements are very wellunderstood/stable.understood/stable.
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 38/195
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 39/195
Prototype ModelPrototype Model After waterfall model, lets discuss what isAfter waterfall model, lets discuss what is
prototyping model in Software Development is.prototyping model in Software Development is.
Here, a prototype is made first and based on itHere, a prototype is made first and based on itfinal product is developed.final product is developed.
A prototype is a model or a program which is notA prototype is a model or a program which is not,,
approximation of the final product or softwareapproximation of the final product or softwaresystem.system. A prototype acts as a sample to test the process.A prototype acts as a sample to test the process.
From this sample we learn and try to build aFrom this sample we learn and try to build abetter final product.better final product.
Please note that this prototype may or may notPlease note that this prototype may or may notbe completely different from the final system webe completely different from the final system weare trying to develop.are trying to develop.
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 40/195
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 41/195
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 42/195
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 43/195
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 44/195
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 45/195
Spiral ModelSpiral Model The Spiral Life Cycle Model is a typeThe Spiral Life Cycle Model is a type
of iterative software developmentof iterative software developmentmodel which is generallymodel which is generallyimplemented in high risk projects.implemented in high risk projects.
This model combine the features of This model combine the features of both, waterfall model and prototypeboth, waterfall model and prototypemodel.model.
In Spiral model we can arrange allIn Spiral model we can arrange allthe activities in the form of a spiral.the activities in the form of a spiral.
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 46/195
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 47/195
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 48/195
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 49/195
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 50/195
Disadvantages of Spiral ModelDisadvantages of Spiral Model
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 51/195
Disadvantages of Spiral ModelDisadvantages of Spiral Model
Cost involved in this model is usually high.Cost involved in this model is usually high. It is a complicated approach especially for projects with aIt is a complicated approach especially for projects with a
clear SRS.clear SRS. Skills required, to evaluate and review project from time toSkills required, to evaluate and review project from time to
time, need expertise.time, need expertise. Rules and protocols should be followed properly toRules and protocols should be followed properly to
--. ,. ,span of project is tough.span of project is tough.
Due to various customizations allowed from the client,Due to various customizations allowed from the client,using the same prototype in other projects, in future, isusing the same prototype in other projects, in future, isdifficult.difficult.
It is not suitable for low risk projects.It is not suitable for low risk projects.
Meeting budgetary and scheduling requirements is tough if Meeting budgetary and scheduling requirements is tough if this development process is followed.this development process is followed. Amount of documentation required in intermediate stagesAmount of documentation required in intermediate stages
makes management of project very complex affair.makes management of project very complex affair.
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 52/195
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 53/195
In simple words, software testing isIn simple words, software testing is
an activity to check whether thean activity to check whether theactual results match the expectedactual results match the expected
software system is defect free.software system is defect free.
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 54/195
The Major Objectives of Software Testing:
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 55/195
The Major Objectives of Software Testing:
Uncover as many as errors (or bugs) as possible in a given timeline.
Demonstrate a given software product matching its requirement specifications.
Validate the quality of a software testing using the minimum cost and efforts.
Generate high quality test cases, perform effective tests, and issue correct and
helpful problem reports.
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 56/195
Consider a scenario where you are moving a file from folderConsider a scenario where you are moving a file from folderA to FolderA to Folder B.ThinkB.Think of all the possible ways you can testof all the possible ways you can test
this.this. Apart from the usual scenarios, you can also test theApart from the usual scenarios, you can also test the
following conditionsfollowing conditions
You do not have the security rights to paste the file inYou do not have the security rights to paste the file inFolder BFolder B
Folder B is on a shared drive and storage capacity is full.Folder B is on a shared drive and storage capacity is full.
Folder B already has a file with the same name,Folder B already has a file with the same name, infactinfact thethe
list is endlesslist is endless
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 57/195
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 58/195
how do you determine this risk?how do you determine this risk? To answer this lets do an exerciseTo answer this lets do an exercise
In your opinion, Which operations is most likelyIn your opinion, Which operations is most likelyto cause your Operating system to fail?to cause your Operating system to fail?
Open IEOpen IE
pen wor ocumenpen wor ocumen
Open 10 applications at one timeOpen 10 applications at one time
I am sure most of you would have guessed,I am sure most of you would have guessed,Opening 10 different application all at the sameOpening 10 different application all at the same
time.time.
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 59/195
So if you were testing this Operating system youSo if you were testing this Operating system youwould realize that defects are likely to be foundwould realize that defects are likely to be found
in multiin multi--tasking and needs to be testedtasking and needs to be testedthoroughly which brings us to our next principlethoroughly which brings us to our next principleDefect ClusterinDefect Clusterin
Defect ClusteringDefect Clustering -- states that a small number of states that a small number of modules contain most of the defects detected.modules contain most of the defects detected.
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 60/195
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 61/195
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 62/195
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 63/195
And the last principle of testingAnd the last principle of testing
states that the Testing is contextstates that the Testing is contextdependent which basically meansdependent which basically means
--
site will be different from the waysite will be different from the wayyou test a commercial off the shelf you test a commercial off the shelf applicationapplication
Software Testing Principles
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 64/195
g p
Testing shows presence of defects
Exhaustive testing is impossible Early Testing
Defect Clustering Pesticide Paradox
Testing is context dependent
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 65/195
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 66/195
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 67/195
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 68/195
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 69/195
Assessments of thousands of projects have shownthat defects introduced during requirements & designmake up close to half of the total number of defects
Also, the costs of fixing a defect increases across thedevelopment life cycle. The earlier in life cycle adefect is detected, the cheaper it is to fix it.
To address this concern , the V model of testing wasdeveloped where for every phase , in the Developmentlife cycle there is a corresponding Testing phase
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 70/195
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 71/195
Who does Software Testing- Test manager
- manage and control a software test project
- supervise test engineers
- define and specify a test plan
- Software Test Engineers and Testers
- define test cases, write test specifications, run tests
- Development Engineers
- Only perform unit tests and integration tests
- Quality Assurance Group and Engineers
- Perform system testing
- Define software testing standards and quality control process
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 72/195
Verification and Validation
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 73/195
Verification and Validation
• Validation refers to a different set of activities that ensure that the softwarethat has been built is traceable tocustomer requirements.
Validation: “Are we building the rightproduct?”
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 74/195
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 75/195
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 76/195
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 77/195
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 78/195
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 79/195
Testing will not catch every error in theprogram, since it can not evaluate everyexecution path in any programs.
The same is true for unit testing.Additionally, unit testing by definition onlytests the functionality of the unitsthemselves.
Therefore, it will not catch integrationerrors or broader system-level errors
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 80/195
Integration Testing Integration testing becomes necessary to
verify the software project work in unity
In this phase individual modules arecombined and tested as group
Data transfer between modules is testedthoroughly
Integration testing is carried out by
testers
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 81/195
strategies to execute Integration
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 82/195
testing Big Bang Approach
• Here all component are integrated together at once, andthen tested.
Incremental Approach:• In this approach, testing is done by joining two or more
modules that are logically related. Then the otherre a e mo u es are a e an es e or e properfunctioning. Process continues until all of the modulesare joined and tested successfully.
which is further divided into following• Top Down Approach• Bottom Up Approach
• Sandwich Approach - Combination of Top Down andBottom Up
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 83/195
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 84/195
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 85/195
Test Scenario
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 86/195
A Scenario is any functionality that can betested. It is also called Test Condition ,orTest Possibility
For the College admin Application a fewscenarios would be
• Check the Login Functionality
• Attendance functionality
• Salary processing functionality
• Check help functionality
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 87/195
Apart from these four scenarios try
and list all the other possiblescenarios for the application.
,
• Delete student/staff data ,• Check Reports ,
• Check Graphs ,and so on
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 88/195
• Check the Login Functionality
• Attendance functionality
• Salary processing functionality
• Check help functionality
since 4th functionalityis not the core
functionality of the application we canignore that .
This is nothing but Test Prioritization.
Test Cases
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 89/195
Test scenario Check Login Functionality - there manypossible cases like• Check response on entering valid User Name & Password
• Check response on entering invalid User Name & Password• Check response when User Name is Empty & Login Button is
pressed, and many moreThis is nothing but Test Case.
Now just Consider the test case , Check response on
entering valid User Name and password. Its obvious thatthis test case needs input values i.e User Name & Passwordthis is nothing but Test Data.
Identifying test data can be time-consuming and may sometimes require creating test data afresh(again but in a newor different way). The reason it needs to be documented
For our test case, expected result would be , Login shouldbe successful
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 90/195
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 91/195
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 92/195
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 93/195
This entire table may be created in Word , Excel or anyother Test management
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 94/195
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 95/195
White-box test design techniquesinclude:
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 96/195
include: Control flow testing
• refers to the order in which the individual statements, instructions or functioncalls of an program are executed or evaluated.
Data flow testing
• Data flow testing is a technique used to detect improper use of data in aprogram.
Branch testing• This technique checks every possible path (if-else and other conditional loops) of
a software a lication
Statement coverage• This technique requires every possible statement in the code to be tested
at least once during the testing process. Decision coverage
• READ XREAD YIF "X > Y"PRINT X is greater that YENDIF
• TEST CASE 1: X=10, Y=5TEST CASE 2: X=2, Y=10
• TEST CASE 3: X=10, Y=10
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 97/195
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 98/195
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 99/195
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 100/195
RISK ANALYSIS ANDMANAGEMENT
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 101/195
Risk, like death and taxes
Risk concerns future happenings.
Today and yesterday are beyond active
was previously sowed by our past actions.
The question is, can we, therefore, bychanging our actions today, create anopportunity for a different and hopefullybetter situation for ourselves tomorrow
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 102/195
In the context of software engineering –
The future is our concern— what risks might
cause the software project to go wrong? Change is our concern—how will changes in
customer requirements, developmenttechnologies, target computers, and all other
entities connected to the project affect timelinessand overall success?
Last, we must grapple (struggle without weapons)with choices—what methods and tools should we
use, how many people should be involved, howmuch emphasis on quality is "enough"?
What is Risk analysis and
management ?
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 103/195
management ? Risk analysis and management are a
series of steps that help a software team
to understand and manage uncertainty. Many problems can plague a software
project. A risk is a potential problem it might
happen, it might not. But, regardless of the outcome, it’s a
really good idea to identify it, assess itsprobability of occurrence, estimate itsimpact, and establish a plan should whichcan be used when problem actually occur
Who does it?
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 104/195
Everyone involved in the softwareprocess
managers, software engineers, and
and management.
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 105/195
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 106/195
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 107/195
How do I ensure that I’ve done
it right?
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 108/195
it right? The risks that are analyzed and managed
should be derived from thorough study of
the people, the product, the process, andthe project.
The RMMM should be revisited as the proj-
ect proceeds to ensure that risks are keptup to date.
Future plans for risk management should
be realistic.
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 109/195
Proactive risk management
A id bl i t lli t t t f i k
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 110/195
A considerably more intelligent strategy for riskmanagement is to be proactive
A proactive strategy begins long before technicalwork is initiated.
Potential risks are identified, their probability and,
importance.
Then, the software team establishes a plan formanaging risk.
The primary objective is to avoid risk, butbecause not all risks can be avoided, the team
works to develop a future plan that will enable itto respond in a controlled and effective manner.
Definition of Risk
k l bl h h
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 111/195
A risk is a potential problem – it might happenand it might not
Two characteristics of risk Uncertainty – the risk may or may not happen,
that is, there are no 100% risks (those, instead,are called constraints)
Loss – the risk becomes a reality and unwantedconsequences or losses occur
When risks are analyzed, it is important toquantify the level of uncertainty and the degree
of loss associated with each risk. To accomplishthis, different categories of risks are considered.
P j i k
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 112/195
Project risks• They threaten the project plan
• If they become real, it is likely that theproject schedule will slip and that costswill increase
• Project risks identify potentialbudgetary, schedule, personnel (staffingand organization), resource, customer,
and requirements problems and theirimpact on a software project.
Technical risks
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 113/195
Technical risks• They threaten the quality and timeliness of the
software to be produced• If they become real, implementation may
become difficult or impossible • ec n ca r s s en y po en a es gn,
implementation, interface, verification, andmaintenance problems.
• In addition, specification ambiguity, technicaluncertainty, technical obsolescence, and"leading-edge" technology are also risk factors.
• Technical risks occur because the problem isharder to solve than we thought it would be.
Business risks
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 114/195
Business risks• threaten the viability of the software to be built.
• Candidates for the top five business risks are building a excellent product or system that no one really
wants (market risk),
business strategy for the company (strategic risk),
building a product that the sales force doesn't understandhow to sell,
losing the support of senior management due to a changein focus or a change in people (management risk),
losing budgetary or personnel commitment (budget risks).
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 115/195
One method for identifying risks is to create a risk item checklist.
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 116/195
y g The checklist can be used for risk identification and focuses on some subset of known
and predictable risks in the following generic subcategories: Product size
• risks associated with the overall size of the software to be built or modified.
Business impact• risks associated with constraints imposed by management or the marketplace.
Customer characteristics• risks associated with the sophistication of the customer and the developer's ability to
.
Process definition• risks associated with the degree to which the software process has been defined and is
followed by the development organization. Development environment
• risks associated with the availability and quality of the tools to be used to build the product.
Technology to be built• risks associated with the complexity of the system to be built and the "newness" of the
technology that is packaged by the system.
Staff size and experience
• risks associated with the overall technical and project experience of the software engineerswho will do the work.
The risk item checklist can be organized in
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 117/195
The risk item checklist can be organized indifferent ways.
Questions relevant to each of the topicscan be answered for each software
.
The answers to these questions allow theplanner to estimate the impact of risk.
A different risk item checklist formatsimply lists characteristics that arerelevant to each generic subcategory.
Assessing Overall Project Risk
The following questions have derived from risk data obtained by surveying
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 118/195
g q y y gexperienced software project managers in different part of the world
The questions are ordered by their relative importance to the success of aproject.
• Have top software and customer managers formally committed to support theproject?• Are end-users enthusiastically committed to the project and the system/product
to be built?• Are re uirements full understood b the software en ineerin team and their
customers?• Have customers been involved fully in the defination of requirements?
• Do end-users have realistic expectations?• Is project scope stable?• Does the software engineering team have the right mix of skills?• Are project requirements stable?• Does the project team have experience with the technology to be implemented?• Is the number of people on the project team adequate to do the job?• Do all customer/user constituencies agree on the importance of the project and
on the requirements for the system/product to be built?
If any one of these questions is
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 119/195
If any one of these questions isanswered negatively, mitigation,monitoring, and management steps
.
The degree to which the project is atrisk is directly proportional to thenumber of negative responses to
these questions.
Steps for Risk Management
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 120/195
Identify possible risks; recognize what can go
wrong Analyze each risk to estimate the probability that
it will occur and the impact (i.e., damage) that itwill do if it does occur
Rank the risks by probability and impact- Impact may be negligible, marginal, critical,and catastrophic
Develop a future plan to manage those risks
having high probability and high impact
Risk Components and DriversRisk Components and Drivers
The project manager identifies theThe project manager identifies the risk driversrisk drivers that affectthat affect
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 121/195
p j gp j gthe following risk componentsthe following risk components•• Performance riskPerformance risk -- the degree of uncertainty that thethe degree of uncertainty that the
product will meet its requirements and be fit for its intendedproduct will meet its requirements and be fit for its intendeduseuse
•• Cost riskCost risk -- the degree of uncertainty that the project budgetthe degree of uncertainty that the project budget
•• Support riskSupport risk -- the degree of uncertainty that the resultantthe degree of uncertainty that the resultant
software will be easy to correct, adapt, and enhancesoftware will be easy to correct, adapt, and enhance•• Schedule riskSchedule risk -- the degree of uncertainty that the projectthe degree of uncertainty that the project
schedule will be maintained and that the product will beschedule will be maintained and that the product will bedelivered on timedelivered on time
The impact of each risk driver on the risk component isThe impact of each risk driver on the risk component is
divided into one of divided into one of four impact levelsfour impact levels•• Negligible, marginal, critical, and catastrophicNegligible, marginal, critical, and catastrophic
Risk Projection (Estimation)Risk Projection (Estimation)
Risk projection (or estimation) attempts toRisk projection (or estimation) attempts to raterate each risk ineach risk intt
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 122/195
two waystwo ways•• TheThe probabilityprobability that the risk is realthat the risk is real•• TheThe consequenceconsequence of the problems associated with the risk,of the problems associated with the risk,
should it occurshould it occur
The project planner, managers, and technical staff performThe project planner, managers, and technical staff performfour risk ro ection ste sfour risk ro ection ste s 1)1) Establish a scale that reflects theEstablish a scale that reflects the likelihoodlikelihood of a risk (e.g., 1of a risk (e.g., 1--low,low,
1010--high)high)
2)2) Describe theDescribe the consequencesconsequences of the riskof the risk3)3) Estimate theEstimate the impactimpact of the risk on the project and productof the risk on the project and product
4)4) Note theNote the overall accuracyoverall accuracy of the risk projection so that there will beof the risk projection so that there will beno misunderstandingsno misunderstandings
The intent of these steps is to consider risks in a mannerThe intent of these steps is to consider risks in a manner
that leads to prioritizationthat leads to prioritization Be prioritizing risks, the software team can allocate limitedBe prioritizing risks, the software team can allocate limited
resources where they will have the most impactresources where they will have the most impact
Contents of a Risk TableContents of a Risk Table
A risk table provides a project manager with a simpleA risk table provides a project manager with a simple
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 123/195
p p j g pp p j g ptechnique for risk projectiontechnique for risk projection
It consists of five columnsIt consists of five columns
•• Risk SummaryRisk Summary –– short description of the riskshort description of the risk
•• Risk CategoryRisk Category –– one of seven risk categoriesone of seven risk categories
•• ro a yro a y –– es ma on o r s occurrence ase on groupes ma on o r s occurrence ase on groupinputinput
•• ImpactImpact –– (1) catastrophic (2) critical (3) marginal (4)(1) catastrophic (2) critical (3) marginal (4)negligiblenegligible
•• RMMMRMMM –– Pointer to a paragraph in the Risk Mitigation,Pointer to a paragraph in the Risk Mitigation,Monitoring, and Management PlanMonitoring, and Management Plan
Risk Summary Risk Category Probability Impact RMMM
Developing a Risk TableDeveloping a Risk Table
ListList all risks in the first column (by way of the help of theall risks in the first column (by way of the help of the
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 124/195
risk item checklists)risk item checklists)
MarkMark the category of each riskthe category of each risk
EstimateEstimate thethe probabilityprobability of each risk occurringof each risk occurring AssessAssess thethe impactimpact of each risk based on an averaging of theof each risk based on an averaging of the
four risk com onentsfour risk com onents to determine an overall im act valueto determine an overall im act value
SortSort the rows by probability and impact inthe rows by probability and impact in descendingdescending orderorder
DrawDraw a horizontal cutoff line in the table that indicates thea horizontal cutoff line in the table that indicates therisks that will be given further attentionrisks that will be given further attention
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 125/195
Assessing Risk ImpactAssessing Risk Impact
Three factors affect the consequences that are likely if a risk doesThree factors affect the consequences that are likely if a risk doesi i d i i ii i d i i i
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 126/195
occur: its nature, its scope, and its timing.occur: its nature, its scope, and its timing.
TheThe nature of the risk indicates the problems that are likely nature of the risk indicates the problems that are likely if itif it
occurs. For example, a poorly defined external interface tooccurs. For example, a poorly defined external interface tocustomer hardware (a technical risk) will preclude early designcustomer hardware (a technical risk) will preclude early designand testing and will likely lead to system integration problems lateand testing and will likely lead to system integration problems laten a pro ec .n a pro ec .
TheThe scope of a risk combines the severity (just scope of a risk combines the severity (just how serious is it?)how serious is it?)
with its overall distribution (how much of the project will bewith its overall distribution (how much of the project will beaffected or how many customers are harmed?).affected or how many customers are harmed?).
Finally, theFinally, the timing of a risk considers whentiming of a risk considers when and for how long theand for how long theimpact will be felt. In most cases, a project manager might wantimpact will be felt. In most cases, a project manager might wantthe “bad news” to occur as soon as possible, but in some cases,the “bad news” to occur as soon as possible, but in some cases,the longer thethe longer the delay,thedelay,the better.better.
The overallThe overall risk exposure, RE, is determined using the followingrisk exposure, RE, is determined using the followingl ti hil ti hi
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 127/195
relationshiprelationship
RE =RE = P x C P x C
wherewhere P is the probability of occurrence for a risk, and C is theP is the probability of occurrence for a risk, and C is the thethecost to the project cost to the project should the risk occur.should the risk occur.
For exam le assume that the software team defines a ro ect riskFor exam le assume that the software team defines a ro ect riskin the followingin the following
manner:manner:
Risk identification. Only 70 percent of the softwareRisk identification. Only 70 percent of the softwarecomponents scheduled for reusecomponents scheduled for reuse will, in fact, be integratedwill, in fact, be integratedinto the application. The remaining functionality will have to beinto the application. The remaining functionality will have to becustom developed.custom developed.
Risk probability. 80% (likely).Risk probability. 80% (likely).
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 128/195
Risk impact. 60 reusable software components wereRisk impact. 60 reusable software components wereplanned. If only 70 percent can beplanned. If only 70 percent can be used, 18 componentsused, 18 components
would have to be developed from scratch (in addition to otherwould have to be developed from scratch (in addition to othercustom software that has been scheduled for development).custom software that has been scheduled for development).
Since the average component is 100 LOC and local data indicateSince the average component is 100 LOC and local data indicatethat the software engineering cost for each LOC is $14.00,that the software engineering cost for each LOC is $14.00,
the overall cost (impact) to develop the components would be 18the overall cost (impact) to develop the components would be 18
x 100 x 14 = $25,200.x 100 x 14 = $25,200.
Risk exposure.Risk exposure. RE = 0.80 x 25,200 ~ $20,200.RE = 0.80 x 25,200 ~ $20,200.
Risk Mitigation, Monitoring, andRisk Mitigation, Monitoring, and
ManagementManagement An effective strategy for dealing with risk must considerAn effective strategy for dealing with risk must consider
thth ii
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 129/195
threethree issuesissues
•• Risk mitigation (i.e., avoidance)Risk mitigation (i.e., avoidance)
•• Risk monitoringRisk monitoring
•• Risk management and contingency planningRisk management and contingency planning
Risk mitigationRisk mitigation (avoidance(avoidance)) is the primary strategy and isis the primary strategy and isachie ed th o gh a planachie ed th o gh a plan
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 130/195
achieved through a planachieved through a plan
•• Example: Risk of high staff turnoverExample: Risk of high staff turnover
trategy or e uc ng tatrategy or e uc ng taTurnoverTurnover
MeetMeet with current staff towith current staff to determine causesdetermine causes for turnover (e.g.,for turnover (e.g.,poor working conditions, low pay, competitive job market)poor working conditions, low pay, competitive job market)
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 131/195
poor working conditions, low pay, competitive job market)poor working conditions, low pay, competitive job market)
MitigateMitigate those causes that are under our control before the projectthose causes that are under our control before the projectstartsstarts
Once the project commences,Once the project commences, assumeassume turnover will occur andturnover will occur anddevelopdevelop techniques to ensure continuity when people leavetechniques to ensure continuity when people leave
development activity isdevelopment activity is widely dispersedwidely dispersed
DefineDefine documentation standards anddocumentation standards and establishestablish mechanisms tomechanisms toensure that documents are developed in a timely mannerensure that documents are developed in a timely manner
ConductConduct peer (peer ( People who are equal in such respects as work)People who are equal in such respects as work)reviews of all work (so that more than one person is "up toreviews of all work (so that more than one person is "up tospeed")speed")
AssignAssign a backup staff member for every critical technologista backup staff member for every critical technologist
The RMMM planThe RMMM plan
The RMMM plan may be a part of the software developmentThe RMMM plan may be a part of the software developmentplan orplan or may be a separate documentmay be a separate document
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 132/195
plan orplan or may be a separate documentmay be a separate document
Once RMMM has been documented and the project hasOnce RMMM has been documented and the project has
begun, the risk mitigation, and monitoring steps beginbegun, the risk mitigation, and monitoring steps begin•• RiskRisk mitigationmitigation is a problemis a problem avoidanceavoidance activityactivity
•• RiskRisk monitoringmonitoring is a projectis a project trackingtracking activityactivity
Risk monitoring hasRisk monitoring has threethree objectivesobjectives•• ToTo assessassess whether predicted risks do, in fact,whether predicted risks do, in fact, occuroccur
•• ToTo ensureensure that risk aversion steps defined for the risk arethat risk aversion steps defined for the risk arebeing properlybeing properly appliedapplied
•• ToTo collectcollect information that can be used forinformation that can be used for futurefuture risk analysisrisk analysis
The findings from risk monitoring may allow the projectThe findings from risk monitoring may allow the project
manager to ascertain what risks caused which problemsmanager to ascertain what risks caused which problemsthroughout the projectthroughout the project
Seven Principles of RiskSeven Principles of Risk
ManagementManagement Maintain a global perspectiveMaintain a global perspective
•• View software risks within the context of a system and theView software risks within the context of a system and the
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 133/195
•• View software risks within the context of a system and theView software risks within the context of a system and thebusiness problem that is intended to solvebusiness problem that is intended to solve
Take a forwardTake a forward--looking viewlooking view•• Think about risks that may arise in the future; establishThink about risks that may arise in the future; establish
contingency planscontingency plans
Encourage open communicationEncourage open communication•• Encourage all stakeholders and users to point out risks at anyEncourage all stakeholders and users to point out risks at any
timetime
Integrate risk managementIntegrate risk management•• Integrate the consideration of risk into the softwareIntegrate the consideration of risk into the software
processprocess
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 134/195
Emphasize a continuous process of riskEmphasize a continuous process of riskmanagementmanagement•• Modify identified risks as more becomes known and addModify identified risks as more becomes known and add
new risks as better insight is achievednew risks as better insight is achieved
134134
•• A shared vision by all stakeholders facilitates better riskA shared vision by all stakeholders facilitates better risk
identification and assessmentidentification and assessment Encourage teamwork when managing riskEncourage teamwork when managing risk
•• Pool the skills and experience of all stakeholders whenPool the skills and experience of all stakeholders whenconducting risk management activitiesconducting risk management activities
User interface designUser interface design
Blueprint for a house (architecturalBlueprint for a house (architectural
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 135/195
design) is not complete without adesign) is not complete without a
representation of doors, windows,representation of doors, windows,,,
electricity, and telephoneelectricity, and telephone The “doors, windows, and utilityThe “doors, windows, and utility
connections” for computer softwareconnections” for computer software
make up the interface design of amake up the interface design of asystem.system.
Interface design focuses on three areas of Interface design focuses on three areas of concern:concern:
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 136/195
concern:concern:
the design of interfaces between softwarethe design of interfaces between softwarecomponents,components,
and other nonhuman producers and consumers of and other nonhuman producers and consumers of
information (i.e. other external entities),information (i.e. other external entities),
the design of the interface between a humanthe design of the interface between a human(i.e., the user) and the computer.(i.e., the user) and the computer.
we focus exclusively on the third interface designwe focus exclusively on the third interface designcategorycategory——user interface design.user interface design.
What is User interface design?What is User interface design?
User interface design creates anUser interface design creates an
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 137/195
effective communication mediumeffective communication medium
between a human and a computer.between a human and a computer.
design principles, design identifiesdesign principles, design identifiesinterface objects and actions andinterface objects and actions andthen creates a screen layout thatthen creates a screen layout that
forms the basis for a user interfaceforms the basis for a user interfaceprototype.prototype.
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 138/195
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 139/195
What are the steps?What are the steps?
User interface design begins with the identification of User interface design begins with the identification of user, task, and environmental requirements.user, task, and environmental requirements.
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 140/195
user, task, and environmental requirements.user, task, and environmental requirements.
Once user tasks have been identified, user scenariosOnce user tasks have been identified, user scenariosare created and analyzed to define a set of interfaceare created and analyzed to define a set of interfaceobjects and actions.objects and actions.
These form the basis for the creation of screen layoutThese form the basis for the creation of screen layout
that depicts graphical design and placement of icons,that depicts graphical design and placement of icons,definition of descriptive screen text, specification anddefinition of descriptive screen text, specification andtitling for windows, and specification of major andtitling for windows, and specification of major andminor menu items.minor menu items.
Tools are used to prototype and ultimately implementTools are used to prototype and ultimately implementthe design model, and the result is evaluated forthe design model, and the result is evaluated forquality.quality.
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 141/195
ow o ensure t at ve one tow o ensure t at ve one tright?right?
The prototypes “test driven” by theThe prototypes “test driven” by thed f db k f th t td f db k f th t t
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 142/195
users and feedback from the testusers and feedback from the test
drive is used for the next iterativedrive is used for the next iterative..
It is true that graphical user interfaces, windows,It is true that graphical user interfaces, windows,icons, and mouse picks have eliminated many of icons, and mouse picks have eliminated many of
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 143/195
co s, a d ouse p c s a e e a ed a y oco s, a d ouse p c s a e e a ed a y othe most horrific interface problems.the most horrific interface problems.
But even in a “Windows world,” we all haveBut even in a “Windows world,” we all have
learn, difficult to use, confusing, unforgiving, andlearn, difficult to use, confusing, unforgiving, and
in many cases, totally frustrating.in many cases, totally frustrating. Yet, someone spent time and energy buildingYet, someone spent time and energy building
each of these interfaces, and it is not likely thateach of these interfaces, and it is not likely thatthe builder created these problems purposely.the builder created these problems purposely.
User interface design has as much to do with the study of User interface design has as much to do with the study of people.people.
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 144/195
Who is the user?Who is the user?
How does the user learn to interact with a new computerHow does the user learn to interact with a new computer--based system?based system?
ow oes e user n erpre n orma on pro uce y eow oes e user n erpre n orma on pro uce y esystem?system?
What will the user expect of the system?What will the user expect of the system?
These are only a few of the many questions that must beThese are only a few of the many questions that must beasked and answered as part of user interface design.asked and answered as part of user interface design.
THE GOLDEN RULESTHE GOLDEN RULES
Place the user in control.Place the user in control.
R d th ’ l dR d th ’ l d
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 145/195
Reduce the user’s memory load.Reduce the user’s memory load.
Make the interface consistent.Make the interface consistent.
Place the user in controlPlace the user in control
“What I really would like, is a system “What I really would like, is a systemthat reads my mind It knows what Ithat reads my mind It knows what I
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 146/195
that reads my mind. It knows what Ithat reads my mind. It knows what I
want to do before I need to do it andwant to do before I need to do it and
done. That’s all, just that.” done. That’s all, just that.” --expectation of userexpectation of user
wanted to control the computer, notwanted to control the computer, not
have the computer control him/her.have the computer control him/her.
Most interface constraints and restrictions thatMost interface constraints and restrictions thatare imposed by a designer are intended toare imposed by a designer are intended to
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 147/195
simplify the mode of interaction.simplify the mode of interaction.
But for whom?But for whom?
,,constraints and limitations to simplify theconstraints and limitations to simplify the
implementation of the interface. The result mayimplementation of the interface. The result maybe an interface that is easy to build, butbe an interface that is easy to build, butfrustrating to use.frustrating to use.
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 148/195
Provide for flexible interaction.Provide for flexible interaction.•• Because different users have different interactionBecause different users have different interaction
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 149/195
Because different users have different interactionBecause different users have different interaction
preferences, choices should be provided.preferences, choices should be provided.•• For example, software might allow a user to interact viaFor example, software might allow a user to interact via
ke board commands mouse movement a di itizer enke board commands mouse movement a di itizer enor voice recognition commands. But every action is notor voice recognition commands. But every action is notamenable to every interaction mechanism.amenable to every interaction mechanism.
•• Consider, for example, the difficulty of using keyboardConsider, for example, the difficulty of using keyboardcommand (or voice input) to draw a complex shape.command (or voice input) to draw a complex shape.
Allow user interaction to beAllow user interaction to beinterruptible and undoableinterruptible and undoable
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 150/195
interruptible and undoable.interruptible and undoable.
•• Even when involved in a sequence of Even when involved in a sequence of ,,
interrupt the sequence to do somethinginterrupt the sequence to do something
else (without losing the work that hadelse (without losing the work that hadbeen done). The user should also bebeen done). The user should also beable to “undo” any action.able to “undo” any action.
Streamline interaction as skill levelsStreamline interaction as skill levelsadvance and allow the interaction toadvance and allow the interaction to
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 151/195
advance and allow the interaction toadvance and allow the interaction to
be customized.be customized.
same sequence of interactionssame sequence of interactions
repeatedly. It is worthwhile to design arepeatedly. It is worthwhile to design a “macro” mechanism that enables an “macro” mechanism that enables anadvanced user to customize theadvanced user to customize the
interface to facilitate interaction.interface to facilitate interaction.
Hide technical internals from the casualHide technical internals from the casualuser.user.
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 152/195
•• The user interface should move the user into the virtualThe user interface should move the user into the virtualworld of the application.world of the application.
,,file management functions, or other arcane computingfile management functions, or other arcane computingtechnology.technology.
•• In essence, the interface should never require that theIn essence, the interface should never require that theuser interact at a level that is “inside” the machine (e.g.,user interact at a level that is “inside” the machine (e.g.,a user should never be required to type operatinga user should never be required to type operatingsystem commands from within application software).system commands from within application software).
Design for direct interaction withDesign for direct interaction withobjects that appear on the screen.objects that appear on the screen.
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 153/195
objects that appear on the screen.objects that appear on the screen.
•• For example, an application interfaceFor example, an application interface “ ” “ ”
(scale it in size) is an implementation of (scale it in size) is an implementation of
direct manipulation.direct manipulation.
Reduce the User’s MemoryReduce the User’s Memory
LoadLoad The more a user has to remember, theThe more a user has to remember, the
more errormore error--prone will be the interactionprone will be the interaction
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 154/195
with the system. It is for this reason thatwith the system. It is for this reason thata wella well--designed user interface does notdesigned user interface does nottax the user’s memory.tax the user’s memory.
Whenever possible, the system shouldWhenever possible, the system should “remember” information and assist the “remember” information and assist theuser with an interaction scenario thatuser with an interaction scenario that
assists recall.assists recall.
Reduce demand on shortReduce demand on short--termtermmemory.memory.
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 155/195
yy
•• The interface should be designed toThe interface should be designed to
past actions and results.past actions and results.
•• This can be accomplished by providingThis can be accomplished by providingvisual cues that enable a user tovisual cues that enable a user torecognize past actions, rather thanrecognize past actions, rather than
having to recall them.having to recall them.
Establish meaningful defaults.Establish meaningful defaults.
•• The initial set of defaults should makeThe initial set of defaults should make
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 156/195
e t a set o de au ts s ou d a ee t a set o de au ts s ou d a e
sense for the average user, but a usersense for the average user, but a usershould be able to s ecif individualshould be able to s ecif individualpreferences.preferences.
•• However, a “reset” option should beHowever, a “reset” option should beavailable, enabling the redefinition of available, enabling the redefinition of original default values.original default values.
Define shortcuts that are intuitive.Define shortcuts that are intuitive.
•• system function (e.g., altsystem function (e.g., alt--P to invokeP to invoke
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 157/195
y ( g ,y ( g ,
the print function)the print function)
The visual layout of the interfaceThe visual layout of the interfaceshould be based on a real worldshould be based on a real world
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 158/195
image.image.•• ,,
a check book and check register metaphor toa check book and check register metaphor to
guide the user through the bill paying process.guide the user through the bill paying process.•• This enables the user to rely on wellThis enables the user to rely on well--
understood visual cues, rather thanunderstood visual cues, rather thanmemorizing an arcane interaction sequence.memorizing an arcane interaction sequence.
Disclose information in a progressiveDisclose information in a progressivefashion. The interface should befashion. The interface should be
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 159/195
organized hierarchically.organized hierarchically., ,, ,
object, or some behavior should beobject, or some behavior should be
presented first at a high level of presented first at a high level of abstraction. More detail should beabstraction. More detail should bepresented after the user indicatespresented after the user indicates
interest with a mouse pick.interest with a mouse pick.
Make the Interface ConsistentMake the Interface Consistent
The interface should present and acquireThe interface should present and acquireinformation in a consistent fashion.information in a consistent fashion.
This implies thatThis implies that
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 160/195
This implies thatThis implies that
•• (1) all visual information is organized according to a(1) all visual information is organized according to adesi n standard that is maintained throu hout all screendesi n standard that is maintained throu hout all screendisplays,displays,
•• (2) input mechanisms are constrained to a limited set(2) input mechanisms are constrained to a limited setthat are used consistently throughout the application,that are used consistently throughout the application,andand
•• (3) mechanisms for navigating from task to task are(3) mechanisms for navigating from task to task areconsistently defined and implemented.consistently defined and implemented.
Allow the user to put the current taskAllow the user to put the current taskinto a meaningful context.into a meaningful context.
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 161/195
•• Many interfaces implement complex layers of Many interfaces implement complex layers of interactions with dozens of screen images.interactions with dozens of screen images.
•• s mpor an o prov e n ca ors e.g., w n ow es,s mpor an o prov e n ca ors e.g., w n ow es,graphical icons, consistent color coding) that enable thegraphical icons, consistent color coding) that enable the
user to know the context of the work at hand.user to know the context of the work at hand.•• In addition, the user should be able to determine whereIn addition, the user should be able to determine where
he has come from and what alternatives exist for ahe has come from and what alternatives exist for atransition to a new task.transition to a new task.
Maintain consistency across aMaintain consistency across afamily of applications.family of applications.
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 162/195
A set of applications (or products)A set of applications (or products)
design rules so that consistency isdesign rules so that consistency ismaintained for all interaction.maintained for all interaction.
Interface Design ModelsInterface Design Models
Four different models come into play when a user interfaceFour different models come into play when a user interfaceis analyzed and designedis analyzed and designed•• User profile modelUser profile model –– Established by a human engineer orEstablished by a human engineer or
software engineersoftware engineer
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 163/195
gg
•• Design modelDesign model –– Created by a software engineerCreated by a software engineer
•• Implementation modelImplementation model –– Created by the softwareCreated by the software
•• User's mental modelUser's mental model –– Developed by the user when interactingDeveloped by the user when interactingwith the applicationwith the application
The role of the interface designer is to reconcile theseThe role of the interface designer is to reconcile thesedifferences and derive a consistent representation of thedifferences and derive a consistent representation of theinterfaceinterface
User Profile ModelUser Profile Model
Establishes the profile of the endEstablishes the profile of the end--users of the systemusers of the system•• Based on age, gender, physical abilities, education, cultural orBased on age, gender, physical abilities, education, cultural or
ethnic background, motivation, goals, and personalityethnic background, motivation, goals, and personality
ConsidersConsiders syntacticsyntactic knowledge of the userknowledge of the user
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 164/195
ConsidersConsiders syntacticsyntactic knowledge of the userknowledge of the user•• The mechanics of interaction that are required to use theThe mechanics of interaction that are required to use the
interface effectivelyinterface effectively
ConsidersConsiders semanticsemantic knowledge of the userknowledge of the user•• The underlying sense of the application; an understanding of The underlying sense of the application; an understanding of
the functions that are performed, the meaning of input andthe functions that are performed, the meaning of input andoutput, and the objectives of the systemoutput, and the objectives of the system
Categorizes users asCategorizes users as•• NovicesNovices
No syntactic knowledge of the system, little semantic knowledge of No syntactic knowledge of the system, little semantic knowledge of
the application, only general computer usagethe application, only general computer usage•• Knowledgeable, intermittent(not steady) usersKnowledgeable, intermittent(not steady) users
Reasonable semantic knowledge of the system, low recall of Reasonable semantic knowledge of the system, low recall of syntactic information to use the interfacesyntactic information to use the interface
•• Knowledgeable, frequent usersKnowledgeable, frequent users
Design ModelDesign Model
Derived from the analysis model of the requirementsDerived from the analysis model of the requirements
Incorporates data, architectural, interface, and proceduralIncorporates data, architectural, interface, and proceduralrepresentations of the softwarerepresentations of the software
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 165/195
Constrained by information in the requirementsConstrained by information in the requirementsspecification that helps define the user of the systemspecification that helps define the user of the system
Consists of the look and feel of theConsists of the look and feel of theinterface combined with allinterface combined with all
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 166/195
supporting information (books,supporting information (books,videos, help files) that describevideos, help files) that describesystem syntax and semanticssystem syntax and semantics
Serves as a translation of the designServes as a translation of the designmodel by providing a realization of model by providing a realization of the information contained in the userthe information contained in the user
profile model and the user’s mentalprofile model and the user’s mentalmodelmodel
User's Mental ModelUser's Mental Model
Often called the user's systemOften called the user's systemperceptionperception
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 167/195
Consists of the image of the systemConsists of the image of the system
Accuracy of the description dependsAccuracy of the description dependsupon the user’s profile and overallupon the user’s profile and overallfamiliarity with the software in thefamiliarity with the software in the
application domainapplication domain
User Interface AnalysisUser Interface Analysis
To perform user interface analysis, the practitioner needs toTo perform user interface analysis, the practitioner needs tostudy and understand four elementsstudy and understand four elements
•• TheThe usersusers who will interact with the system through thewho will interact with the system through the
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 168/195
interfaceinterface•• TheThe taskstasks that end users must perform to do their workthat end users must perform to do their work
••
•• TheThe work environmentwork environment in which these tasks will be conductedin which these tasks will be conducted
User Analysis QuestionsUser Analysis Questions
1)1) Are the users trained professionals, technicians, clerical orAre the users trained professionals, technicians, clerical ormanufacturing workers?manufacturing workers?
2)2) What level of formal education does the average userWhat level of formal education does the average userhave?have?
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 169/195
3)3) Are the users capable of learning on their own fromAre the users capable of learning on their own fromwritten materials or have they expressed a desire forwritten materials or have they expressed a desire forclassroom training?classroom training?
4)4) Are the users expert typists or are they keyboard phobic?Are the users expert typists or are they keyboard phobic?
5)5) What is the age range of the user community?What is the age range of the user community?6)6) Will the users be represented predominately by oneWill the users be represented predominately by one
gender?gender?
7)7) How are users compensated for the work they perform orHow are users compensated for the work they perform orare they volunteers?are they volunteers?
User Analysis QuestionsUser Analysis Questions
1)1) Do users work normal office hours, or do they workDo users work normal office hours, or do they workwhenever the job is required?whenever the job is required?
2)2) Is the software to be an integral part of the work usersIs the software to be an integral part of the work usersdo, or will it be used only occasionally?do, or will it be used only occasionally?
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 170/195
3)3) What is the primary spoken language among users?What is the primary spoken language among users?
44 What are the conse uences if a user makes a mistakeWhat are the conse uences if a user makes a mistakeusing the system?using the system?
5)5) Are users experts in the subject matter that is addressedAre users experts in the subject matter that is addressed
by the system?by the system?6)6) Do users want to know about the technology that sitsDo users want to know about the technology that sits
behind the interface?behind the interface?
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 171/195
Content AnalysisContent Analysis
1)1) Are various types of data assigned to consistent locationsAre various types of data assigned to consistent locationson the screen (e.g., photos always in upper right corner)?on the screen (e.g., photos always in upper right corner)?
2)2) Are users able to customize the screen location forAre users able to customize the screen location forcontent?content?
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 172/195
3)3) Is proper onIs proper on--screen identification assigned to all content?screen identification assigned to all content?
44 Can lar e re orts be artitioned for ease of Can lar e re orts be artitioned for ease of understanding?understanding?
5)5) Are mechanisms available for moving directly to summaryAre mechanisms available for moving directly to summary
information for large collections of data?information for large collections of data?6)6) Is graphical output scaled to fit within the bounds of theIs graphical output scaled to fit within the bounds of the
display device that is used?display device that is used?
7)7) How is color used to enhance understanding?How is color used to enhance understanding?
8)8) How are error messages and warnings presented in orderHow are error messages and warnings presented in orderto make them quick and easy to see and understand?to make them quick and easy to see and understand?
Work Environment AnalysisWork Environment Analysis
Software products need to be designed to fit into the workSoftware products need to be designed to fit into the workenvironment, otherwise they may be difficult or frustratingenvironment, otherwise they may be difficult or frustratingto useto use
Factors to consider includeFactors to consider includeT f li htiT f li hti
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 173/195
•• Type of lightingType of lighting
•• Display size and heightDisplay size and height
•• Keyboard size, height and ease of useKeyboard size, height and ease of use
•• Mouse type and ease of useMouse type and ease of use
•• Surrounding noiseSurrounding noise•• Space limitations for computer and/or userSpace limitations for computer and/or user
•• Weather or other atmospheric conditionsWeather or other atmospheric conditions
•• Temperature or pressure restrictionsTemperature or pressure restrictions
•• Time restrictions (when, how fast, and for how long)Time restrictions (when, how fast, and for how long)
USER INTERFACE DESIGN PROCESSUSER INTERFACE DESIGN PROCESS
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 174/195
The design process for user interfaces is iterative and canThe design process for user interfaces is iterative and canbe represented using a spiral modelbe represented using a spiral model
interface design process encompasses four distinctinterface design process encompasses four distinct
framework activitiesframework activities
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 175/195
framework activitiesframework activities 1. User, task, and environment analysis and modeling1. User, task, and environment analysis and modeling
. n er ace es gn. n er ace es gn
3. Interface construction3. Interface construction
4. Interface validation4. Interface validation The spiral shown in Figure implies that each of these tasksThe spiral shown in Figure implies that each of these tasks
will occur more than once, with each pass around the spiralwill occur more than once, with each pass around the spiralrepresenting additional elaboration of requirements and therepresenting additional elaboration of requirements and the
resultant design.resultant design.
Design Issues to ConsiderDesign Issues to Consider
Four common design issues usually surface in any userFour common design issues usually surface in any userinterfaceinterface•• System response time (both length and variability)System response time (both length and variability)
•• User help facilitiesUser help facilities When is it available how is it accessed how is it represented toWhen is it available how is it accessed how is it represented to
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 176/195
When is it available, how is it accessed, how is it represented toWhen is it available, how is it accessed, how is it represented tothe user, how is it structured, what happens when help is exitedthe user, how is it structured, what happens when help is exited
How meaningful to the user, how descriptive of the problemHow meaningful to the user, how descriptive of the problem
•• Menu and command labelingMenu and command labeling Consistent, easy to learn, accessibility, internationalizationConsistent, easy to learn, accessibility, internationalization
Many software engineers do not address these issues untilMany software engineers do not address these issues untillate in the design or construction processlate in the design or construction process•• This results in unnecessary iteration, project delays, andThis results in unnecessary iteration, project delays, and
customer frustrationcustomer frustration
ObjectObject--oriented Designoriented Design
ObjectObject--oriented analysis, design and programming areoriented analysis, design and programming arerelated but distinct.related but distinct.
OOA is concerned with developing an object model of theOOA is concerned with developing an object model of the
application domainapplication domain
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 177/195
application domain.application domain. OOD is concerned with developing an objectOOD is concerned with developing an object--orientedoriented
..
OOP is concerned with realising an OOD using an OOOOP is concerned with realising an OOD using an OO
programming language such as Java or C++.programming language such as Java or C++.
Characteristics of OODCharacteristics of OOD
Objects are abstractions of realObjects are abstractions of real--world or systemworld or systementities and manage themselves.entities and manage themselves.
Objects are independent and encapsulate stateObjects are independent and encapsulate stateand representation informationand representation information
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 178/195
and representation information.and representation information.
object services.object services.
Shared data areas are eliminated. ObjectsShared data areas are eliminated. Objectscommunicate by message passing.communicate by message passing.
Objects may be distributed and may executeObjects may be distributed and may executesequentially or in parallel.sequentially or in parallel.
Advantages of OODAdvantages of OOD
Easier maintenance. Objects may beEasier maintenance. Objects may beunderstood as standunderstood as stand--alone entities.alone entities.
Objects are potentially reusableObjects are potentially reusable
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 179/195
Objects are potentially reusableObjects are potentially reusable..
For some systems, there may be anFor some systems, there may be anobvious mapping from real worldobvious mapping from real worldentities to system objects.entities to system objects.
Objects and object classesObjects and object classes
Objects are entities in a softwareObjects are entities in a softwaresystem which represent instances of system which represent instances of
realreal world and system entitiesworld and system entities
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 180/195
realreal--world and system entities.world and system entities.
objects. They may be used to createobjects. They may be used to createobjects.objects.
Object classes may inherit attributesObject classes may inherit attributes
and services from other objectand services from other objectclasses.classes.
An An object object is an entity that has a state and ais an entity that has a state and adefined set of operations which operate on that defined set of operations which operate on that state. The state is represented as a set of object state. The state is represented as a set of object
attributes The operations associated with theattributes The operations associated with theobject provide services to other objects (clients)object provide services to other objects (clients)
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 181/195
attributes. The operations associated with theattributes. The operations associated with theobject provide services to other objects (clients)object provide services to other objects (clients)
computation is required.computation is required.
Objects are created according to someObjects are created according to some object object classclass definition. An object class definition servesdefinition. An object class definition servesas a template for objects. It includes declarationsas a template for objects. It includes declarationsof all the attributes and services which should beof all the attributes and services which should be
associated with an object of that class.associated with an object of that class.
The UnifiedThe Unified ModelingModeling LanguageLanguage
Several different notations forSeveral different notations fordescribing objectdescribing object--oriented designs wereoriented designs wereproposed in the 1980s and 1990s.proposed in the 1980s and 1990s.
Th U ifi dTh U ifi d M d liM d li L iL i
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 182/195
The UnifiedThe Unified ModelingModeling Language is anLanguage is anintegration o t ese notations.integration o t ese notations.
It describes notations for a number of It describes notations for a number of different models that may be produceddifferent models that may be producedduring OO analysis and design.during OO analysis and design.
It is now aIt is now a de factode facto standard for OOstandard for OOmodelling.modelling.
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 183/195
Object communicationObject communication
Conceptually, objects communicate byConceptually, objects communicate bymessage passing.message passing.
MessagesMessages
•• The name of the service requested by the calling object;The name of the service requested by the calling object;
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 184/195
The name of the service requested by the calling object;The name of the service requested by the calling object;
and the name of a holder for the result of the service.and the name of a holder for the result of the service.
In practice, messages are often implementedIn practice, messages are often implementedby procedure callsby procedure calls
•• Name = procedure name;Name = procedure name;
•• Information = parameter list.Information = parameter list.
Message examplesMessage examples
// // CallCall aa methodmethod associatedassociated withwith aa bufferbuffer // // objectobject thatthat returnsreturns thethe nextnext valuevalue
//// inin thethe bufferbufferi l B ffi l B ff G tG t
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 185/195
// // inin thethe bufferbuffervv == circularBuffercircularBuffer..GetGet
// // CallCall thethe methodmethod associatedassociated withwith aa // // thermostatthermostat objectobject thatthat setssets thethe // // temperaturetemperature toto bebe maintainedmaintained
thermostatthermostat..setTempsetTemp ((2020)) ;;
Generalisation and inheritanceGeneralisation and inheritance
Objects are members of classes that defineObjects are members of classes that defineattribute types and operations.attribute types and operations.
Classes may be arranged in a classClasses may be arranged in a class
hierarchyhierarchywhere one class (a superwhere one class (a super class) is aclass) is a
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 186/195
hierarchyhierarchywhere one class (a superwhere one class (a super--class) is aclass) is agenera sa on o one or more o er c assesgenera sa on o one or more o er c asses(sub(sub--classes).classes).
A subA sub--class inherits the attributes andclass inherits the attributes andoperations from its super class and may addoperations from its super class and may addnew methods or attributes of its own.new methods or attributes of its own.
Generalisation in the UML is implemented asGeneralisation in the UML is implemented as
inheritance in OO programming languages.inheritance in OO programming languages.
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 187/195
Advantages of inheritanceAdvantages of inheritance
It is an abstraction mechanism whichIt is an abstraction mechanism whichmay be used to classify entities.may be used to classify entities.
It is a reuse mechanism at both theIt is a reuse mechanism at both the
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 188/195
It is a reuse mechanism at both theIt is a reuse mechanism at both the..
The inheritance graph is a source of The inheritance graph is a source of organisational knowledge aboutorganisational knowledge aboutdomains and systems.domains and systems.
Problems with inheritanceProblems with inheritance
Object classes are not self Object classes are not self--contained.contained.they cannot be understood withoutthey cannot be understood withoutreference to their superreference to their super--classes.classes.
Designers have a tendency to reuse theDesigners have a tendency to reuse the
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 189/195
g yg y
analysis. Can lead to significantanalysis. Can lead to significant
inefficiency.inefficiency. The inheritance graphs of analysis,The inheritance graphs of analysis,
design and implementation havedesign and implementation havedifferent functions and should bedifferent functions and should be
separately maintained.separately maintained.
UML associationsUML associations
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 190/195
An objectAn object--oriented designoriented designprocessprocess
Define the context and modes of useDefine the context and modes of useof the systemof the system
Design the system architectureDesign the system architecture
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 191/195
g yg y en y e pr nc pa sys em o ec sen y e pr nc pa sys em o ec s
Develop design modelsDevelop design models Specify object interfacesSpecify object interfaces
Weather system descriptionWeather system description
A weather data collection system is required to generate weatherA weather data collection system is required to generate weathermaps on a regular basis using data collected from remote,maps on a regular basis using data collected from remote,unattended weather stations and other data sources such as weatherunattended weather stations and other data sources such as weatherobservers, balloons and satellites. Weather stations transmit theirobservers, balloons and satellites. Weather stations transmit their
data to the area computer in response to a request from thatdata to the area computer in response to a request from thatmachine.machine.
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 192/195
The area computer validates the collected data and integrates it withThe area computer validates the collected data and integrates it withthe data from different sources. The integrated data is archived and,the data from different sources. The integrated data is archived and,
using data from this archive and a digitised map database a set of using data from this archive and a digitised map database a set of local weather maps is created. Maps may be printed for distributionlocal weather maps is created. Maps may be printed for distributionon a specialon a special--purpose map printer or may be displayed in a number of purpose map printer or may be displayed in a number of different formats.different formats.
Weather station descriptionWeather station description
A weather station is a package of software controlledA weather station is a package of software controlledinstruments which collects data, performs some datainstruments which collects data, performs some dataprocessing and transmits this data for further processing.processing and transmits this data for further processing.The instruments include air and ground thermometers, anThe instruments include air and ground thermometers, an
anemometer, a wind vane, a barometer and a rain gauge.anemometer, a wind vane, a barometer and a rain gauge.Data is collected ever five minutesData is collected ever five minutes
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 193/195
Data is collected ever five minutes.Data is collected ever five minutes.
When a command is issued to transmit the weather data, theWhen a command is issued to transmit the weather data, theweather station processes and summarises the collectedweather station processes and summarises the collecteddata. The summarised data is transmitted to the mappingdata. The summarised data is transmitted to the mappingcomputer when a request is received.computer when a request is received.
«subsystem»
«subsystem»Data display
Data archiving layer where objects
Data display layer where objects areconcerned with preparing andpresenting the data in a human-readable form
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 194/195
«subsystem»
«subsystem»Data collection
«subsystem»Data processing
a a arc v ng
Data collection layer where objectsare concerned with acquiring datafrom remote sources
Data processing layer where objectsare concerned with checking andintegrating the collected data
for future processing
System context and models ofSystem context and models ofuseuse
Develop an understanding of the relationshipsDevelop an understanding of the relationshipsbetween the software being designed and itsbetween the software being designed and itsexternal environmentexternal environment
System contextSystem context
7/30/2019 UMIT - Software Engineering
http://slidepdf.com/reader/full/umit-software-engineering 195/195
environment. Use a subsystem model to show otherenvironment. Use a subsystem model to show othersystems. Following slide shows the systems around thesystems. Following slide shows the systems around the
weather station system.weather station system.
Model of system useModel of system use
•• A dynamic model that describes how the systemA dynamic model that describes how the systeminteracts with its environment. Useinteracts with its environment. Use useuse--cases to showcases to show
interactionsinteractions