Various Process of Software Engineering notes

Various Process of Software Engineering

1. Software Engineering
KCS-601, Unit-I, 1.2
Dr APJ Abdul KalamTechnical
University, Lucknow
By
Dr AnuranjanMisra
1
Dr AnuranjanMisra
innovation
Ambassador
Ministry of Education,
Government of India
& Professor & Dean,
GNIOT, Greater Noida

2. SOFTWAREPROCESS

3. THESOFTWAREPROCESS
•Aprocessisacollectionofactivities,actions,andtasksthatare
performedwhensomeworkproductistobecreated.
•Anactivitystrivestoachieveabroadobjective(e.g.,
communicationwithstakeholders)andisappliedregardlessof
theapplicationdomain,sizeoftheproject,complexityofthe
effort,ordegreeofrigorwithwhichsoftwareengineeringistobe
applied.
•Anactionencompassesasetoftasksthatproduceamajorwork•Anactionencompassesasetoftasksthatproduceamajorwork
product(e.g.,anarchitecturaldesignmodel).
•Ataskfocusesonasmall,butwell-definedobjective(e.g.,
conductingaunittest)thatproducesatangibleoutcome.
•Aprocessframeworkestablishesthefoundationforacomplete
softwareengineeringprocessbyidentifyingasmallnumberof
frameworkactivitiesthatareapplicabletoallsoftwareprojects,
regardlessoftheirsizeorcomplexity.Inaddition,theprocess
frameworkencompassesasetofumbrellaactivitiesthatare
applicableacrosstheentiresoftwareprocess.

4. THESOFTWAREPROCESS
Agenericprocessframeworkforsoftwareengineeringencompasses
fiveactivities:
Communication-Beforeanytechnicalworkcancommence,itis
criticallyimportanttocommunicateandcollaboratewiththe
customer(andotherstakeholdersTheintentistounderstand
stakeholders’objectivesfortheprojectandtogather
requirementsthathelpdefinesoftwarefeaturesandfunctions.
Planning-Anycomplicatedjourneycanbesimplifiedifamapexists.
Themap-calledasoftwareprojectplan-definesthesoftware
engineeringworkbydescribingthetechnicaltaskstobeconducted,
therisksthatarelikely,theresourcesthatwillberequired,thework
engineeringworkbydescribingthetechnicaltaskstobeconducted,
therisksthatarelikely,theresourcesthatwillberequired,thework
productstobeproduced,andaworkschedule.
Modeling-Asoftwareengineercreatingmodelstobetter
understandsoftwarerequirementsandthedesignthatwillachieve
thoserequirements.
Construction-Thisactivitycombinescodegeneration(eithermanualor
automated)andthetestingthatisrequiredtouncovererrorsinthe
code.
Deployment-Thesoftware(asacompleteentityorasapartially
completedincrement)isdeliveredtothecustomerwhoevaluates
thedeliveredproductandprovidesfeedbackbasedonthe
evaluation.

5. Softwareengineeringprocessframeworkactivitiesarecomplemented
byanumberofumbrellaactivities.Typicalumbrellaactivitiesinclude:
Softwareprojecttrackingandcontrol—allowsthesoftwareteamto
assessprogressagainsttheprojectplanandtakeanynecessaryactionto
maintaintheschedule.
Riskmanagement—assessesrisksthatmayaffecttheoutcomeofthe
projectorthequalityoftheproduct.
Softwarequalityassurance—definesandconductstheactivities
requiredtoensuresoftwarequality.
Technicalreviews—assessessoftwareengineeringworkproductsinan
efforttouncoverandremoveerrorsbeforetheyarepropagatedtothenext
activity.activity.
Measurement—definesandcollectsprocess,project,andproduct
measuresthatassisttheteamindeliveringsoftwarethatmeets
stakeholders’needs;canbeusedinconjunctionwithallother
frameworkandumbrellaactivities.
Softwareconfigurationmanagement—managestheeffectsofchange
throughoutthesoftwareprocess.
Reusabilitymanagement—definescriteriaforworkproductreuse
(includingsoftwarecomponents)andestablishesmechanismsto
achievereusablecomponents.
Workproductpreparationandproduction—encompassestheactivities
requiredtocreateworkproductssuchasmodels,documents,logs,forms,
andlists.

6. SOFTWAREENGINEERINGPRACTICES
The EssenceofPractice
•Understand the problem (communication and analysis)
•Plan a solution (software design)•Plan a solution (software design)
•Carry out the plan (code generation)
•Examine the result for accuracy (testing and quality
assurance)

7. SoftwareEngineeringPrinciples:
•TheReasonItAllExists-Asoftwaresystemexistsforonereason:to
providevaluetoitsusers.Alldecisionsshouldbemadewiththisinmind.
Beforespecifyingasystemrequirement,beforenotingapieceofsystem
functionality,beforedeterminingthehardwareplatformsordevelopment
processes,askyourselfquestionssuchas:“Doesthisaddrealvaluetothe
system?”Iftheansweris“no,”don’tdoit.
•Allotherprinciplessupportthisone.•Allotherprinciplessupportthisone.
•TheSecondPrinciple:(KeepItSimple,Stupid!)-Alldesignshouldbeas
simpleaspossible,butnosimpler.Thisisnottosaythatfeatures,even
internalfeatures,shouldbediscardedinthenameofsimplicity.
•TheThirdPrinciple:MaintaintheVision-Aclearvisionis
essentialtothesuccessofasoftwareProject.

8. •TheFourthPrinciple:WhatYouProduce,OthersWillConsume
Alwaysspecify,design,andimplementknowingsomeoneelse
willhavetounderstandwhatyouaredoing.Theaudiencefor
anyproductofsoftwaredevelopmentispotentiallylarge.
Specifywithaneyetotheusers.
•TheFifthPrinciple:BeOpentotheFuture-Asystemwitha
longlifetimehasmorevalue.thesesystemsmustbereadyto
adapttotheseandotherchanges.adapttotheseandotherchanges.
•TheSixthPrinciple:PlanAheadforReuse-Reusesavestime
andeffort.Thereuseofcodeanddesignshasbeenmajor
benefitofusingobject-orientedtechnologies.
•TheSeventhprinciple:Think!-Placingclear,completethought
beforeactionalmostalwaysproducesbetterresults.Whenyou
thinkaboutsomething,youaremorelikelytodoitright.You
alsogainknowledgeabouthowtodoitrightagain.Ifyoudo
thinkaboutsomethingandstilldoitwrong,itbecomesa
valuableexperience

9. SOFTWAREMYTHS
Softwaremyths—erroneousbeliefsaboutsoftwareandthe
processthatisusedtobuildit—canbetracedtotheearliestdays
ofcomputing.
Today,mostknowledgeablesoftwareengineeringprofessionals
recognizemythsforwhattheyare—misleadingattitudesthathaverecognizemythsforwhattheyare—misleadingattitudesthathave
causedseriousproblemsformanagersandpractitionersalike.
However,oldattitudesandhabitsaredifficulttomodify,and
remnantsofsoftwaremythsremain.
1)Managementmyths
2)Customermyths
3)Practitionermyths

10. Managementmyths.
Managerswithsoftwareresponsibility,likemanagersin
mostdisciplines,areoftenunderpressuretomaintain
budgets,keepschedulesfromslipping,andimprovequality.
Myth:Wealreadyhaveabookthat’sfullofstandardsand
proceduresforbuildingsoftware.Won’tthatprovidemy
people
witheverythingtheyneedtoknow?witheverythingtheyneedtoknow?
Reality:Thebookofstandardsmayverywellexist,butisit
used?Aresoftwarepractitionersawareofitsexistence?Does
itreflectmodernsoftwareengineeringpractice?Isit
complete?Isitadaptable?Isitstreamlinedtoimprovetime-
to-deliverywhilestillmaintainingafocusonquality?Inmany
cases,theanswertoallofthesequestionsis“no.”

11. Customermyths.
Acustomerwhorequestscomputersoftwaremaybea
personatthenextdesk,atechnicalgroupdownthehall,the
marketing/salesdepartment,oranoutsidecompanythathas
requestedsoftwareundercontract
Myth:Ageneralstatementofobjectivesissufficientto
beginwritingprograms—wecanfillinthedetailslater.beginwritingprograms—wecanfillinthedetailslater.
Reality:Althoughacomprehensiveandstablestatementof
requirementsisnotalwayspossible,anambiguous
“statementofobjectives”isarecipefordisaster.
Unambiguousrequirements(usuallyderivediteratively)are
developedonlythrougheffectiveandcontinuous
communicationbetweencustomeranddeveloper.

12. Practitioner’smyths.
Mythsthatarestillbelievedbysoftwarepractitioners
havebeenfosteredbyover50yearsofprogramming
culture.Duringtheearlydays,programmingwasviewed
asanartform.Oldwaysandattitudesdiehard.
Myth:Oncewewritetheprogramandgetittowork,our
jobisdone.jobisdone.
Reality:Someoneoncesaidthat“thesooneryoubegin
‘writingcode,’thelongerit’lltakeyoutogetdone.”
Industrydataindicatethatbetween60and80percentof
alleffortexpendedonsoftwarewillbeexpendedafterit
isdeliveredtothecustomerforthefirsttime.