MODULE 1 Software Product and Process_ SW ENGG 22CSE141.pdf

MODULE 1 :
Software Product and Process
Introduction –FAQs About Software Engineering,
Definition Of Software Engineering,
Difference Between Software Engineering And Computer Science,
Difference Between Software Engineering And System Engineering,
Software Process,
Software Process Models,
The Waterfall Model,
Incremental Process Models,
Evolutionary Process Models
Spiral Development, Prototyping,
Component Based Software Engineering ,
The Unified Process, Attributes Of Good Software,
Key Challenges Facing By Software Engineering,
Verification – Validation,
Computer Based System,
Business Process Engineering,

1. SOFTWARE ENGINEERING
Course Code:22CSE141
MODULE 1 :
Software Product and Process

2. By
Dr. M.K. JayanthiKannan, M.E.,MS.,MBA., M.Phil., Ph.D.,
Professor and HOD ISE,
Faculty of Engineering & Technology,
JAIN Deemed To-Be University,
Bengaluru.
Staff Room: 324-8.
Office Hours : 8.30 AM -4 PM
Department of Computer Science and
Engineering,
FET Block,
Course Specification
Course: SOFTWARE ENGINEERING
Course Code:22CSE141

3. Module 1:Software Product and Process
•Introduction –FAQs About Software Engineering,
•Definition Of Software Engineering,
•Difference Between Software Engineering And Computer Science,
•Difference Between Software Engineering And System Engineering,
•Software Process,
•Software Process Models
•The Waterfall Model,
•Incremental Process Models,
•Evolutionary Process Models
•Spiral Development, Prototyping,
•Component Based Software Engineering ,
•The Unified Process, Attributes Of Good Software,
•Key Challenges Facing By Software Engineering,
•Verification –Validation
•Computer Based System
•Business Process Engineering.

4. What is Engineering?
What is Software?
What is Software Engineering?
What is Software Process?
Different types of Process models
Different models with strengths and weaknesses
AligeSoftware Development

5. INTRODUCTION
•Software:Computerprogramsandassociateddocumentation.
softwareproductsmaybedevelopedforaparticularcustomeror
maybedevelopedforageneralmarket.
•Software engineering : Software engineering is an engineering
discipline which is concerned with all aspects of software
production.
•The definition in IEEE Standard
–The application of a systematic, disciplined, quantifiable approach to the
development, operation, and maintenance of software, that is, the
application of engineering to software.
•Software process: A set of activities whose goal is the development
or evolution of software.

6. What is Engineering?
Engineeringis the application of scientificand
practicalknowledge in order to invent, design,
build, maintainandimprove systems,
processes,etc.

7. 4
What is Software?
The software is collection of integrated programs
The software consists of carefully—organized instructions and
code written by programmers in any of various special computer
languages
Computer programs and associated documentation such as
requirements, design models and user manuals.
Software engineering is an engineering discipline that is
concerned with all aspects of software production.
According to IEEE's definition software engineering can be defined
as the application of a systematic, disciplined, quantifiable
approach to the development, operation, and maintenance of
software, and the study of these approaches; that is, the
application of engineering to software.

8. What is Software Process?
A frameworkthat describes the activities performed
at each stage of a software development project.
A set of activities whose goal is the development or
evolution of software.
Generic activities in all software processes are:
Specification-what the system should do and its
development constraints
Development-production of the software system
Validation-checking that the software is what the
customer wants
Evolution-changing the software in response to changing
demands.

9. Software Engineering –Key
Challenges
Coping with legacy systems, coping with
increasing diversity and coping with
demands for delivery times.
Legacy systems-old, valuable systems must
be maintained and updated.
Heterogeneity-systems are distributed and
includes a mix of hardware and software
Delivery-there is increasing pressure for
faster delivery of software.

10. Software Engineering Paradigms and
Processes
In SE ‘Paradigm’ is heavily used:
Discussions of superiority “Object-oriented
paradigm is the best ever …”
Discussions of suitability “Object-oriented
paradigm is/isn’t suitable for x y z domain/tasks”
The meaning of paradigm is overloaded and vague
What exactly do we mean by paradigm?
Why and how a paradigm influences the process
and product of SE?

11. What is ‘paradigm’?
Etymologically: “para-” (alongside) + “-deiknunai” (to
show)
Greek: paradeigma= example
Works of Plato and Aristotle: a third form of reasoning
Induction, deduction, paradeigma(example)
One of the constituents is more “knowable”
Typical issues related to the category they define (e.g.
cheese paradigm)
Not very favoriteof philosophers until late 20th century
Modern meaning coined by Foucault, and esp.

12. SE Paradigms
Major paradigms in software
engineering/design:
the procedural paradigm (emphasis on algorithm),
the data-hiding paradigm (emphasis on data
organization),
the data-abstraction paradigm (emphasis on types
and operations),
and the object-oriented paradigm (emphasis on
commonality between types)

13. New approaches having potential to be regarded
as paradigms in the future:
The component-based paradigm (emphasis on reuse
through integration),
the aspect-oriented paradigm,
and the agent-oriented paradigm (emphasis on goal
oriented ness)
The choice of paradigm effects the quality of the process and
the product. Some apparent readings of quality parameters
might be related inherently to paradigms.

14. 13
Software Engineering process
Paradigms(SDLC)
SDLC: SDLC is a step by step
procedure or systematic
approach to develop software
and it is followed within a
software organization.
It consists of various phases
which describe how to design,
develop, enhance and
maintain particular software.

15. Attributes of good
software
•Thesoftwareshoulddelivertherequiredfunctionalityandperformanceto
theuserandshouldbemaintainable,dependableandusable.

17. What is the work Product?
•Fromthepointofviewofasoftwareengineer,theworkproductisthe
programs,documents,andcontent.
•Fromtheuser’sviewpoint,theworkproductistheresultantinformation
thatsomehowmakestheuser’sworldbetter.
•TheProduct
–Istheenginethatdrivesbusinessdecisionmaking.
–Softwareservesasthebasisformodernscientificinvestigationandengineeringproblem
solving.
–Itisembeddedinsystemsofallkinds:transportation,medical,telecommunications,
military,industrialprocesses,entertainment,officeproducts…

18. VERIFICATION AND VALIDATION
•Verification:"Arewebuildingtheproductright”,Thesoftwareshould
conformtoitsspecification.
•Validation:"Arewebuildingtherightproduct”.,Thesoftwareshoulddo
whattheuserreallyrequires.

19. These slides are designed to accompany Software Engineering:
A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides
copyright 2009 by Roger Pressman.
19
V & V
•Verificationreferstothesetoftasksthatensurethat
softwarecorrectlyimplementsaspecificfunction.
•Validationreferstoadifferentsetoftasksthatensurethat
thesoftwarethathasbeenbuiltistraceabletocustomer
requirements.Boehm[Boe81]statesthisanotherway:
–Verification:"Arewebuildingtheproductright?"
–Validation:"Arewebuildingtherightproduct?"

20. The V & V process
•Isawholelife-cycleprocess-V&Vmustbeappliedateach
stageinthesoftwareprocess.
•Hastwoprincipalobjectives
•Thediscoveryofdefectsinasystem;
•Theassessmentofwhetherornotthesystemisusefuland
useableinanoperationalsituation

21. V& V goals
•Verificationandvalidationshouldestablishconfidencethatthesoftwareis
fitforpurpose.
•ThisdoesNOTmeancompletelyfreeofdefects.
•Rather,itmustbegoodenoughforitsintendeduseandthetypeofusewill
determinethedegreeofconfidencethatisneeded.

22. SOFTWARE LIFE CYCLE
•Often used as another name for the software
process.
•Originally coined to refer to the waterfall
model of the software process.

25. •The Waterfall model sometimes called the classic life cycle, suggests a systematic,
sequential approach to software development.
•It is a oldest paradigm for software engineering.
•Most widely used though no longer state-of-art.
•Each step results in documentation.
•May be suited to for well-understood developments using familiar technology.
•Not suited to new, different systems because of specification uncertainty
•Difficulty in accommodating change after the process has started.
•Can accommodate iteration but indirectly.
•Working version not available till late in process.
•Often get blocking states.

26. THE INCREMENTAL PROCESS MODELS

27. •Therearemanysituationsinwhichinitialsoftwarerequirementsare
reasonablywelldefined,buttheoverallscopeofthedevelopmenteffort
precludesapurelylinearprocess.
•Inaddition,theremaybeacompellingneedtoprovidealimitedsetof
softwarefunctionalitytousersquicklyandthenrefineandexpandonthat
functionalityinlatersoftwarereleases.
•Insuchcases,aprocessmodelthatisdesignedtoproducethesoftware
inincrementsischosen.

28. The Incremental Model :
•Applies an iterative philosophy to the waterfall model.
•Divide functionality of system into increments and use a liner sequence of
development on each increment.
•First increment delivered is usually the core product, i.e. only basic
functionality.
•Reviews of each increment impact on design of later increments.
•Manages risk well.
•Extreme Programming (XP), and other Agile Methods, are incremental, but
they do not implement the waterfall model steps in the standard order.

29. The Rapid Application Development (RAD) Model

30. •Similar to waterfall but uses a very short development cycle (60to90
days to completion).
•Uses component-based construction and emphasizes reuse and
code generation.
•Use multiple teams on scalable projects.
•Requires heavy resource.
•Requires developers and customers who are heavily committed.
•Performance can be a problem.
•Difficult to use with new technology

31. EVOLUTIONARY MODELS
•Evolutionarymodelsareiterative.Theyarecharacterizedinamannerthatenables
softwareengineerstodevelopincreasinglymorecompleteversionsofthesoftware.
•PROTOTYPING :

32. PROTOTYPING :
•Ideally mock-up serves as mechanism for identifying requirements.
•Users like the method, get a feeling for the actual system.
•Less ideally may be the basis for completed.
•Prototypes often ignore quality/performance/maintenance issues.
•May create pressure from users on deliver earlier.
•May use a less-than-ideal platform to deliver e.gVisual Basic –excellent for
prototyping, may not be as effective in actual operation.
•Specifying requirements is often very difficult.
•Users don’t know exactly what they want until they see it.
•Prototyping involves building a mock-up of the system and using to obtain for user
feedback.
•Closely related to what are now called “Agile Methods”

33. The Spiral Model

34. Development cycles through multiple (3-6) task regions (6stage version).
• Customer communication
• Planning
• Risk analysis
• Engineering
• Construction and release
• Customer evaluation
Incremental releases :
•Early releases may be paper or prototypes.
•Later releases become more complicated
•Models software until it is no longer used
•Not a silver bullet, but considered to be one of the best approaches.
•Requires excellent management and risk assessment skills

35. Concurrent Development Model
•The concurrent development model, sometimes called concurrent engineering,
can be represented schematically as a series of framework activities, software
engineering actions and tasks, and their associated states.
•The concurrent process model defines a series of events that will trigger
transitions from state to state for each of the software engineering activities,
action, or tasks.
•The concurrent process model is applicable to all types of software development
and provides an accurate picture of the current state of a project.
•Rather than confining software engineering activities, actions, and tasks to a
sequence of events, it defines a network of activities.
•Each activity, action, or task on the network exists simultaneously with other
activities, actions, or tasks.
•Events generated at one point in the process network trigger transitions among
the states.

37. SPECIALIZED PROCESS MODELS
•Component based development—the process to
apply when reuse is a development objective.
•Formal methods—emphasize the mathematical
specification of requirements.
•AOSD—provides a process and methodological
approach for defining, specifying, designing, and
constructing aspects

39. THE UNIFIED PROCESS (UP)
•A “use-case driven, architecture-centric, iterative and incremental” software
process closely aligned with the Unified Modeling Language (UML)
Unified Process Phases
•The inception phases of the up encompass both customer communication and
planning activities and emphasize the development and refinement of use-
cases as a primary model.
•An elaboration phase that encompasses the customer’s communication and
modeling activities focusing on the creation of analysis and design models
with an emphasis on class definitions and architectural representations.
•A construction phase that refines and translates the design model into
implemented software components.
•A transition phase that transfers the software from the developer to the end-
user for beta testing and acceptance.
•A production phase in which on-going monitoring and support are conducted.

41. System engineering
•Systemsengineeringistheactivityofspecifying,designing,implementing,
validating,deployingandmaintainingsocio-technicalsystems.
•Systemsengineersarenotjustconcernedwithsoftwarebutalsowith
hardwareandthesystem'sinteractionswithusersanditsenvironment.
•Theymustthinkabouttheservicesthatthesystemprovides,theconstraints
underwhichthesystemmustbebuiltandoperatedandthewaysinwhich
thesystemisusedtofulfillitspurpose.
•Systemengineeringisconcernedwithallaspectsofcomputer-based
systemsdevelopment,includinghardware,softwareandprocess
engineering.Softwareengineeringispartofthisprocess.
•Systemengineeringisanolderdisciplinethansoftwareengineering.
•Peoplehavebeenspecifyingandassemblingcomplexindustrialsystems
suchasaircraftandchemicalplantsformorethanahundredyears.
•However,asthepercentageofsoftwareinsystemshasincreased,software
engineeringtechniquessuchasuse-casemodelingandconfiguration
managementarebeingusedinthesystemsengineeringprocess.

42. SYSTEM ENGINEERING PROCESSSystem
integration
Sub-system
development
System
design
Requirements
definition
System
installation
System
evolution
System
decommissioning

43. System design problems
•Requirements partitioning to hardware,
software and human components may involve a lot of negotiation
•Difficult design problems are often assumed to be readily solved using
software
•Hardware platforms may be inappropriate for
software requirements so software must compensate for this

44. Sub-system development
•Typically parallel projects developing the
hardware, software and communications
•May involve some COTS (Commercial Off-the-Shelf) systems
procurement
•Lack of communication across implementation
teams
•Bureaucratic and slow mechanism for
proposing system changes means that the development schedule may be
extended because of the need for rework

45. •The process of putting hardware, software and
people together to make a system
•Should be tackled incrementally so that sub-systems are integrated one at
a time
•Interface problems between sub-systems are usually found at this stage
•May be problems with uncoordinated deliveries
of system components
System integration

46. •Environmental assumptions may be incorrect
•May be human resistance to the introduction of
a new system
•System may have to coexist with alternative
systems for some time
•May be physical installation problems (e.g.
cabling problems)
•Operator training has to be identified
System installation

47. •Willbringunforeseenrequirementstolight
•Usersmayusethesysteminawaywhichis
notanticipatedbysystemdesigners
•May revealproblems in the interactionwith
othersystems
•Physicalproblemsofincompatibility
•Dataconversionproblems
•Increasedoperatorerrorratebecauseofinconsistentinterfaces
System operation

48. System evolution
•Largesystemshavealonglifetime.Theymustevolvetomeetchanging
requirements
•Evolutionisinherentlycostly
–Changesmustbeanalysedfromatechnicalandbusinessperspective
–Sub-systemsinteractsounanticipatedproblemscanarise
–Thereisrarelyarationalefororiginaldesigndecisions
–Systemstructureiscorruptedaschangesaremadetoit
•Existingsystemswhichmustbemaintainedaresometimescalledlegacy
systems

49. System decommissioning
•Takingthesystemoutofserviceafteritsusefullifetime
•Mayrequireremovalofmaterials(e.g.dangerouschemicals)whichpollute
theenvironment
–Shouldbeplannedforinthesystemdesignbyencapsulation
•Mayrequiredatatoberestructuredandconvertedtobeusedinsomeother
system

50. ATC System Engineering

51. computer-based systems
•Technicalcomputer-basedsystemsaresystemsthatinclude
hardwareandsoftwarecomponentsbutnotproceduresand
processes.
•Examplesoftechnicalsystemsincludetelevisions,mobile
phonesandmostpersonalcomputersoftware.
•Individualsandorganizationsusetechnicalsystemsforsome
purposebutknowledgeofthispurposeisnotpartofthe
system.
•Forexample,thewordprocessor

52. BUSINESS PROCESS ENGINEERING
•Businessprocessengineeringisastructuredapproachtoimprovingacompany’s
performanceinareassuchascost,service,quality,andspeedthroughchangesin
(appropriately)processes.
•Organize around the outcome, not the specific task. One person owns a whole
process, performing or coordinating all steps.
•Those closest to the process should perform the process. Instead of farming out
different types of easily managed work, the people who need the quick outcomes
from simple tasks take ownership.
•Have the people who produce the information process it. This streamlines the
outcome of the information gathered into usable data.
•Centralize resources. Databases and other technology systems can consolidate
resources to cut down on redundancies and increase flexibility.
•Integrate corresponding activities, not merely their results. This keeps the content
cohesive, without the gaps and miscommunication that could cause delays.
•Control the decision points and where the work is done. Built-in controls enable
the employees who perform the work to self-manage, so managers can become
supportive rather than directive.
•Information should be collected once and at the source. You can erase data
redundancies when processes are connected in a central database

53. Commonguidingprinciplesforthestagesareasfollows:
•Step0:PreparationandCoordination
•Step1:SettheVision
•Step2:AssembletheTeam
•Step3:DeterminetheProcesses
•Step4:Redesign

54. PRODUCT ENGINEERING
•ProductEngineeringistheprocessofinnovating,designing,developing,testingand
deployingasoftwareproduct.
•Thevariousphasesofproductengineeringare:
–Product Ideation
–Product Architecture
–Product Design
–Product Testing
–Product Migration and Porting
–Technical Support
–Sustaining Engineering
–Professional Services

55. SUMMARY
Module 1:Software Product and Process
In Module 1 we discussed the following topics like,
Introduction –FAQs About Software Engineering,
Definition Of Software Engineering,
Difference Between Software Engineering And Computer Science,
Difference Between Software Engineering And System Engineering,
Software Process,
Software Process Models
The Waterfall Model,
Incremental Process Models,
Evolutionary Process Models
Spiral Development, Prototyping,
Component Based Software Engineering ,
The Unified Process, Attributes Of Good Software,
Key Challenges Facing By Software Engineering,
Verification –Validation
Computer Based System
Business Process Engineering.