​SOFTWARE ENGINEERING​

​ NIT 1​
U
​Introduction to Software Engineering​

​ omputer​​software​​is​​the​​product​​that​​software​​professionals​​build​​and​​then​​support​​over​​the​
C
​long​ ​term.​ ​It​ ​encompasses​ ​programs​ ​that​ ​execute​ ​within​ ​a​ ​computer​ ​of​ ​any​ ​size​ ​and​
​architecture,​ ​content​ ​that​ ​is​ ​presented​ ​as​ ​the​ ​computer​ ​programs​ ​execute,​ ​and​ ​descriptive​
​information​ ​in​ ​both​ ​hard​ ​copy​ ​and​ ​virtual​ ​forms​ ​that​ ​encompass​ ​virtually​ ​any​ ​electronic​
​media.​ ​Software​ ​engineering​ ​encompasses​ ​a​ ​process,​​a​​collection​​of​​methods​​(practice)​​and​
​an​ ​array​ ​of​ ​tools​ ​that​​allow​​professionals​​to​​build​​high​​quality​​computer​​software.​​Software​

​
​engineers​​build​​and​​support​​software,​​and​​virtually​​everyone​​in​​the​​industrialized​​world​​uses​

G
​it either directly or indirectly.​

IN
​To build software, it is essential to recognize several fundamental realities:​
​●​ ​Widespread​ ​Impact​ ​and​ ​Diverse​ ​Stakeholders​​:​ ​Software​ ​is​ ​now​ ​embedded​ ​in​

R
​almost​ ​every​ ​part​ ​of​ ​life,​​attracting​​interest​​from​​many​​stakeholders.​​Each​​may​​have​
​different​ ​expectations,​ ​making​ ​it​ ​crucial​ ​to​ ​understand​ ​the​ ​problem​ ​clearly​ ​before​

EE
​developing a solution​​.​
​●​ ​Growing​ ​Complexity​​:​ ​As​ ​software​ ​systems​ ​become​ ​more​ ​sophisticated,​ ​they​ ​are​
IN
d​ eveloped​​by​​large​​teams​​and​​used​​in​​diverse​​environments​​(from​​medical​​devices​​to​
​weapons​ ​systems).​ ​This​ ​makes​ ​design​ ​a​ ​critical​ ​activity​ ​to​ ​manage​ ​interactions​ ​and​
​system integration.​
G
​●​ ​Reliance​ ​and​ ​Risk​​:​ ​Software​ ​plays​ ​a​ ​vital​ ​role​ ​in​ ​daily​ ​operations​ ​and​ ​strategic​
EN

​decisions.​
​●​ ​High​ ​quality​ ​is​​essential​​because​​failures​​can​​cause​​anything​​from​​inconvenience​​to​
​catastrophe.​
RE

​●​ ​Longevity​​and​​Change​​:​​Valuable​​software​​gains​​more​​users​​and​​lasts​​longer,​​leading​
​to​ ​greater​ ​demand​ ​for​ ​updates​ ​and​ ​improvements.​ ​Therefore,​ ​maintainability​ ​is​
e​ ssential.​
A
W

​ hese​ ​realities​ ​make​ ​it​ ​clear​ ​that​ ​software​ ​must​​be​​carefully​​and​​systematically​​engineered,​

T
​forming​ ​the​ ​foundation​ ​of​ ​software​ ​engineering.​ ​Software​ ​engineering​ ​is​ ​an​ ​engineering​
​discipline​ ​that​ ​is​ ​concerned​ ​with​ ​all​​aspects​​of​​software​​production​​from​​the​​early​​stages​​of​
FT

​system specification through to maintaining the system after it has gone into use.​

​ he IEEE has developed a more comprehensive definition which states:​

T
​SO

​Software​​Engineering​​is​​the​​application​​of​​a​​systematic,​​disciplined,​​quantifiable​​approach​​to​
​the​ ​development,​ ​operation,​ ​and​ ​maintenance​ ​of​ ​software;​ ​that​ ​is,​ ​the​ ​application​ ​of​
​engineering to software.​

​1.1 The Evolving Role of Software​

​ s​​technology​​advances,​​the​​expectations​​from​​software​​systems​​have​​increased​​significantly.​
A
​Users​​now​​demand​​intuitive​​interfaces,​​continuous​​availability,​​real-time​​responsiveness,​​data​
​security,​​and​​seamless​​integration​​with​​other​​platforms.​​To​​meet​​these​​expectations,​​software​

​Ms. Sthuthi Rai, Lecturer​ ​Department of Computer Science, YIASCM​

 ​SOFTWARE ENGINEERING​

e​ ngineers​​must​​not​​only​​write​​code​​but​​also​​consider​​long-term​​maintenance,​​scalability,​​user​
​needs, and system adaptability. Software is no longer just a product—it is a strategic asset.​

​Software’s Dual Role:​

​According to Roger Pressman, software plays two critical roles in modern systems:​

​1.​ ​Software as a Product​

​o​ ​It delivers computing potential directly to end users or organizations.​
​o​ ​It produces, manages, acquires, modifies, displays, or transmits information.​
​o​ ​Examples include word processors, mobile apps, and data analytics tools.​

​
G
​2.​ ​Software as a Vehicle for Delivering a Product​
I​ t​ ​supports​ ​or​ ​directly​ ​provides​ ​system​ ​functionality​ ​(e.g.,​ ​an​ ​operating​

IN
o​
​
​system).​
I​ t​ ​controls​ ​other​ ​programs,​ ​such​ ​as​ ​managing​ ​hardware​ ​through​ ​drivers​ ​or​

R
o​
​
​OS-level services.​

EE
o​
​ ​It facilitates communication, like networking software and web servers.​
o​
​ ​It also helps build other software, such as IDEs and compilers.​
IN
​ his​ ​dual​ ​nature​ ​shows​ ​that​ ​software​ ​is​ ​not​ ​only​ ​a​ ​standalone​ ​product​​but​​also​​an​​essential​
T
​enabler of other systems and services.​
G
EN

​Lehman’s Laws of Software Evolution​

I​ n​​the​​1970s,​​Manny​​Lehman​​introduced​​a​​set​​of​​empirical​​laws​​that​​describe​​how​​software​
RE

​evolves​ ​over​ ​time,​ ​especially​ ​in​ ​real-world,​ ​long-lived​ ​systems.​ ​These​ ​laws​ ​highlight​ ​the​
​inherent challenges of maintaining and evolving software.​
A

​1.​ L ​ aw of Continuing Change (1974)​

​Software that has been implemented in a real-world computing context and will​
W

​therefore evolve over time (called E-type systems) must be continually adapted else​
​they become progressively less satisfactory.​
FT

​2.​ ​Law of Increasing Complexity (1974)​

​As an E-type system evolves its complexity increases unless work is done to maintain​
​or reduce it.​
​SO

​3.​ L
​ aw of Self-Regulation (1974)​
​The E-type system evolution process is self-regulating with distribution of product​
​and process measures close to normal.​
​4.​ L
​ aw of Conservation of Organizational Stability (1980)​
​The average effective global activity rate in an evolving E-type system is invariant​
​over product lifetime.​
​5.​ L
​ aw of Conservation of Familiarity (1980)​
​As an E-type system evolves all associated with it, developers, sales personnel, users,​
​for example, must maintain mastery of its content and behavior to achieve satisfactory​
​evolution.​

​Ms. Sthuthi Rai, Lecturer​ ​Department of Computer Science, YIASCM​

 ​SOFTWARE ENGINEERING​

​6.​ L
​ aw of Continuing Growth (1980)​
​The functional content of E-type systems must be continually increased to maintain​
​user satisfaction over their lifetime.​
​7.​ L
​ aw of Declining Quality (1996)​
​The quality of E-type systems will appear to be declining unless they are rigorously​
​maintained and adapted to operational environment changes.​
​8.​ L
​ aw of Feedback System (1996)​
​E-type evolution processes constitute multi-level, multi-loop, multi-agent feedback​
​systems and must be treated as such to achieve significant improvement over any​
​reasonable base.​

​
G
​ hese​ ​laws​ ​emphasize​ ​that​ ​software​ ​is​ ​not​ ​static​​—​it​ ​must​ ​be​ ​actively​ ​managed​​,​ ​regularly​
T
​updated​​,​​and​​systematically improved​​to stay relevant​​and functional.​

R IN
​1.2 Changing Nature of Software​

EE
​ he​ ​role​ ​of​ ​computer​ ​software​ ​has​ ​undergone​ ​significant​ ​change​ ​over​ ​the​​last​​half-century.​
T
​Dramatic​ ​improvements​ ​in​ ​hardware​ ​performance,​ ​profound​ ​changes​ ​in​ ​computing​
IN
​architectures,​ ​vast​ ​increases​ ​in​ ​memory​ ​and​ ​storage​ ​capacity,​ ​and​ ​a​ ​wide​ ​variety​ ​of​ ​exotic​
​input​ ​and​ ​output​ ​options,​ ​have​ ​all​ ​precipitated​ ​more​ ​sophisticated​ ​and​ ​complex​
G
​computer-based systems.​
EN

​Software Application Domains​

​●​ ​System​ ​software​ ​refers​ ​to​ ​collections​ ​of​ ​programs​ ​designed​ ​to​ ​service​ ​other​
p​ rograms.​ ​This​ ​includes​ ​tools​ ​like​ ​compilers,​ ​editors,​ ​and​ ​file​ ​management​ ​utilities​
RE

​that​ ​deal​ ​with​ ​structured​ ​and​ ​predictable​ ​data,​ ​as​ ​well​ ​as​ ​operating​ ​systems,​ ​device​
​drivers,​ ​and​​networking​​components​​that​​handle​​unpredictable​​or​​indeterminate​​data.​
​System​ ​software​ ​typically​ ​interacts​ ​closely​ ​with​ ​hardware,​ ​supports​ ​multiple​
A

​concurrent​​users,​​manages​​resources​​and​​scheduling,​​and​​operates​​with​​complex​​data​
W

​and interfaces.​

​●​ ​Application​ ​software​​,​ ​on​ ​the​ ​other​ ​hand,​ ​comprises​ ​stand-alone​ ​programs​ ​that​
FT

a​ ddress​​specific​​business​​or​​technical​​problems.​​These​​applications​​facilitate​​business​
​operations​ ​and​ ​decision-making​ ​processes,​ ​often​ ​through​ ​real-time​ ​control​ ​systems​
​SO

​such as point-of-sale terminals or manufacturing control.​

​●​ ​Engineering​ ​and​ ​scientific​ ​software​ ​is​ ​traditionally​ ​associated​ ​with​ ​heavy​
c​ omputational​​tasks​​or​​"number​​crunching"​​across​​diverse​​fields—from​​astronomy​​to​
​molecular​ ​biology.​ ​While​ ​these​ ​applications​ ​once​ ​relied​ ​heavily​ ​on​ ​numerical​
​algorithms,​ ​many​ ​modern​ ​versions​ ​incorporate​ ​interactive,​ ​real-time​ ​features​ ​that​
​resemble system software behavior, such as in CAD or simulation systems.​

​●​ ​Embedded​ ​software​ ​is​ ​software​ ​integrated​ ​into​ ​hardware​ ​systems​ ​and​ ​devices,​
p​ roviding​ ​control​ ​and​ ​functionality​ ​for​ ​specific​​tasks.​​It​​ranges​​from​​simple​​routines​
​like​ ​microwave​ ​keypad​ ​control​ ​to​ ​complex​ ​functions​ ​in​ ​automobiles,​ ​including​ ​fuel​
​management and braking systems.​

​Ms. Sthuthi Rai, Lecturer​ ​Department of Computer Science, YIASCM​

 ​SOFTWARE ENGINEERING​

​●​ ​Web​ ​applications​​,​ ​or​ ​WebApps,​ ​are​ ​network-centric​ ​programs​ ​that​ ​began​ ​as​ ​basic​
h​ yperlinked​ ​documents​ ​but​ ​have​ ​evolved​ ​with​ ​Web​ ​2.0​ ​technologies​ ​into​ ​powerful​
​platforms​ ​offering​ ​full-fledged​ ​services,​ ​database​ ​connectivity,​ ​and​ ​business​ ​logic​
​integration.​

​●​ ​Artificial​​intelligence​​software​​departs​​from​​conventional​​numeric​​computation​​and​
e​ mploys​ ​symbolic​ ​or​ ​cognitive​ ​approaches​ ​to​ ​solve​ ​problems​ ​that​ ​are​ ​difficult​ ​to​
​define​ ​algorithmically.​ ​This​ ​category​ ​includes​ ​expert​ ​systems,​ ​robotics,​ ​natural​
​language​ ​processing,​ ​neural​ ​networks,​ ​pattern​ ​recognition,​ ​and​ ​intelligent​ ​game​
​systems.​

​
G
​Legacy Software​

IN
​ undreds​ ​of​ ​thousands​ ​of​ ​computer​ ​programs​ ​fall​ ​into​ ​one​ ​of​ ​the​ ​seven​ ​broad​ ​application​
H
​domains​ ​discussed​ ​in​ ​the​ ​preceding​ ​subsection.​ ​Some​ ​of​ ​these​ ​are​ ​state​ ​of-​ ​the-art​

R
​software—just​ ​released​ ​to​ ​individuals,​ ​industry,​ ​and​ ​government.​ ​But​ ​other​ ​programs​ ​are​

EE
​older,​ ​in​ ​some​ ​cases​ ​much​ ​older.​ ​These​ ​older​ ​programs—often​ ​referred​ ​to​ ​as​ ​legacy​
​software—have been the focus of continuous attention and concern since the 1960s.​

L IN
​ egacy​​software​​systems​​were​​developed​​decades​​ago​​and​​have​​been​​continually​​modified​​to​
​meet​ ​changes​ ​in​ ​business​ ​requirements​ ​and​ ​computing​ ​platforms.​ ​The​ ​proliferation​​of​​such​
​systems​ ​is​ ​causing​ ​headaches​ ​for​ ​large​ ​organizations​ ​who​ ​find​ ​them​​costly​​to​​maintain​​and​
G
​risky​​to​​evolve.​​Unfortunately,​​there​​is​​sometimes​​one​​additional​​characteristic​​that​​is​​present​
​in​ ​legacy​ ​software—poor​ ​quality.​ ​Legacy​ ​systems​ ​sometimes​ ​have​ ​inextensible​ ​designs,​
EN

​convoluted​ ​code,​ ​poor​ ​or​ ​non-existent​​documentation,​​test​​cases​​and​​results​​that​​were​​never​

​archived,​ ​a​ ​poorly​ ​managed​ ​change​ ​history—the​ ​list​ ​can​ ​be​ ​quite​ ​long.​ ​And​ ​yet,​ ​these​
​systems support “core business functions and are indispensable to the business.”​
RE

​1.3 Software Myths​

A

​ oftware​ ​myths—erroneous​ ​beliefs​ ​about​ ​software​ ​and​ ​the​ ​process​ ​that​ ​is​ ​used​ ​to​ ​build​
S
W

​it—can​ ​be​ ​traced​ ​to​ ​the​ ​earliest​ ​days​ ​of​ ​computing.​​Myths​​have​​a​​number​​of​​attributes​​that​

​make​ ​them​ ​insidious.​ ​For​ ​instance,​ ​they​ ​appear​ ​to​ ​be​ ​reasonable​ ​statements​ ​of​ ​fact​
FT

​(sometimes​ ​containing​ ​elements​ ​of​ ​truth),​ ​they​ ​have​ ​an​ ​intuitive​ ​feel,​ ​and​ ​they​ ​are​ ​often​
​promulgated by experienced practitioners who “know the score.”​
​SO

​ oday,​ ​most​ ​knowledgeable​ ​software​ ​engineering​ ​professionals​ ​recognize​ ​myths​ ​for​ ​what​
T
​they​ ​are—misleading​ ​attitudes​ ​that​ ​have​ ​caused​ ​serious​ ​problems​ ​for​ ​managers​ ​and​
​practitioners​​alike.​​However,​​old​​attitudes​​and​​habits​​are​​difficult​​to​​modify,​​and​​remnants​​of​
​software myths remain.​

​1.3.1 Management Myths​

​ anagers​ ​with​ ​software​ ​responsibility,​ ​like​ ​managers​ ​in​ ​most​ ​disciplines,​ ​are​ ​often​ ​under​
M
​pressure​ ​to​ ​maintain​ ​budgets,​ ​keep​ ​schedules​ ​from​ ​slipping,​ ​and​ ​improve​ ​quality.​ ​Like​ ​a​
​drowning​ ​person​ ​who​ ​grasps​ ​at​ ​a​ ​straw,​ ​a​ ​software​ ​manager​ ​often​ ​grasps​ ​at​ ​belief​ ​in​ ​a​
​software myth, if that belief will lessen the pressure (even temporarily).​

​Ms. Sthuthi Rai, Lecturer​ ​Department of Computer Science, YIASCM​

 ​SOFTWARE ENGINEERING​

​ yth:​​We​​already​​have​​a​​book​​that’s​​full​​of​​standards​​and​​procedures​​for​​building​​software.​
M
​Won’t that provide my people with everything they need to know?​
​Reality:​​The​​book​​of​​standards​​may​​very​​well​​exist,​​but​​is​​it​​used?​​Are​​software​​practitioners​
​aware​​of​​its​​existence?​​Does​​it​​reflect​​modern​​software​​engineering​​practice?​​Is​​it​​complete?​
​Is​ ​it​ ​adaptable?​ ​Is​ ​it​ ​streamlined​​to​​improve​​time-to-delivery​​while​​still​​maintaining​​a​​focus​
​on quality? In many cases, the answer to all of these questions is “no.”​

​ yth:​ ​If​ ​we​ ​get​ ​behind​ ​schedule,​ ​we​ ​can​​add​​more​​programmers​​and​​catch​​up​​(sometimes​

M
​called the “Mongolian horde” concept).​
​Reality:​​Software​​development​​is​​not​​a​​mechanistic​​process​​like​​manufacturing.​​In​​the​​words​

​
​of​ ​Brooks:​ ​“adding​ ​people​ ​to​ ​a​ ​late​ ​software​ ​project​​makes​​it​​later.”​​At​​first,​​this​​statement​

G
​may​ ​seem​ ​counterintuitive.​ ​However,​ ​as​ ​new​ ​people​ ​are​ ​added,​ ​people​ ​who​ ​were​ ​working​

IN
​must​ ​spend​ ​time​ ​educating​ ​the​ ​newcomers,​ ​thereby​ ​reducing​ ​the​ ​amount​ ​of​ ​time​ ​spent​ ​on​
​productive​ ​development​ ​effort.​ ​People​ ​can​ ​be​ ​added​ ​but​ ​only​ ​in​ ​a​ ​planned​ ​and​
​well-coordinated manner.​

R
​ yth:​​If​​I​​decide​​to​​outsource​​the​​software​​project​​to​​a​​third​​party,​​I​​can​​just​​relax​​and​​let​​that​
M

EE
​firm build it.​
​Reality:​​If​​an​​organization​​does​​not​​understand​​how​​to​​manage​​and​​control​​software​​projects​
​internally, it will invariably struggle when it outsources software projects.​
IN
​1.3.2 Customer Myths​
G
​ ​ ​customer​ ​who​ ​requests​ ​computer​ ​software​ ​may​ ​be​ ​a​ ​person​ ​at​ ​the​​next​​desk,​​a​​technical​
A
EN

​group​ ​down​ ​the​ ​hall,​ ​the​ ​marketing/sales​ ​department,​ ​or​ ​an​ ​outside​ ​company​ ​that​ ​has​
​requested​ ​software​ ​under​ ​contract.​ ​In​ ​many​ ​cases,​ ​the​ ​customer​ ​believes​ ​myths​ ​about​
​software​ ​because​ ​software​ ​managers​ ​and​ ​practitioners​ ​do​ ​little​ ​to​ ​correct​ ​misinformation.​
RE

​Myths​ ​lead​ ​to​ ​false​ ​expectations​ ​(by​ ​the​ ​customer)​ ​and,​ ​ultimately,​ ​dissatisfaction​ ​with​ ​the​
​developer.​

​ yth:​​A​​general​​statement​​of​​objectives​​is​​sufficient​​to​​begin​​writing​​programs—we​​can​​fill​
M
A

​in the details later.​

W

​Reality:​ ​Although​ ​a​ ​comprehensive​ ​and​ ​stable​ ​statement​ ​of​ ​requirements​ ​is​ ​not​ ​always​
​possible,​ ​an​ ​ambiguous​ ​“statement​ ​of​ ​objectives”​ ​is​ ​a​ ​recipe​ ​for​ ​disaster.​ ​Unambiguous​
FT

​requirements​ ​(usually​ ​derived​ ​iteratively)​ ​are​ ​developed​ ​only​ ​through​ ​effective​ ​and​
​continuous​
​communication between customer and developer.​
​SO

​ yth:​ ​Software​ ​requirements​ ​continually​ ​change,​ ​but​ ​change​ ​can​ ​be​ ​easily​​accommodated​
M
​because software is flexible.​
​Reality:​​It​​is​​true​​that​​software​​requirements​​change,​​but​​the​​impact​​of​​change​​varies​​with​​the​
​time​​at​​which​​it​​is​​introduced.​​When​​requirements​​changes​​are​​requested​​early​​(before​​design​
​or​​code​​has​​been​​started),​​the​​cost​​impact​​is​​relatively​​small.16​​However,​​as​​time​​passes,​​the​
​cost​ ​impact​ ​grows​ ​rapidly—resources​ ​have​ ​been​ ​committed,​ ​a​ ​design​ ​framework​ ​has​ ​been​
​established,​ ​and​ ​change​ ​can​ ​cause​ ​upheaval​ ​that​ ​requires​ ​additional​ ​resources​ ​and​ ​major​
​design modification.​

​Ms. Sthuthi Rai, Lecturer​ ​Department of Computer Science, YIASCM​

 ​SOFTWARE ENGINEERING​

​1.3.3 Practitioner’s Myths​

​ yths​​that​​are​​still​​believed​​by​​software​​practitioners​​have​​been​​fostered​​by​​over​​50​​years​​of​
M
​programming​ ​culture.​ ​During​ ​the​ ​early​ ​days,​ ​programming​ ​was​ ​viewed​​as​​an​​art​​form.​​Old​
​ways and attitudes die hard.​

​ yth:​​Once we write the program and get it to work,​​our job is done.​

M
​Reality:​ ​Someone​ ​once​ ​said​ ​that​ ​“the​ ​sooner​ ​you​​begin​​‘writing​​code,’​​the​​longer​​it’ll​​take​
​you​​to​​get​​done.”​​Industry​​data​​indicate​​that​​between​​60​​and​​80​​percent​​of​​all​​effort​​expended​
​on software will be expended after it is delivered to the customer for the first time.​

​
​ yth:​​Until I get the program “running” I have no​​way of assessing its quality.​
M

G
​Reality:​ ​One​ ​of​ ​the​ ​most​ ​effective​ ​software​ ​quality​ ​assurance​ ​mechanisms​ ​can​ ​be​ ​applied​

IN
​from​​the​​inception​​of​​a​​project—the​​technical​​review.​​Software​​reviews​​are​​a​​“quality​​filter”​
​that​​have​​been​​found​​to​​be​​more​​effective​​than​​testing​​for​​finding​​certain​​classes​​of​​software​
​defects.​

R
​Myth:​​The only deliverable work product for a successful​​project is the working program.​

EE
​Reality:​​A​​working​​program​​is​​only​​one​​part​​of​​a​​software​​configuration​​that​​includes​​many​
​elements.​ ​A​ ​variety​ ​of​​work​​products​​(e.g.,​​models,​​documents,​​plans)​​provide​​a​​foundation​
​for successful engineering and, more important, guidance for software support.​
IN
​ yth:​​Software​​engineering​​will​​make​​us​​create​​voluminous​​and​​unnecessary​​documentation​
M
​and will invariably slow us down.​
G
​Reality:​​Software​​engineering​​is​​not​​about​​creating​​documents.​​It​​is​​about​​creating​​a​​quality​
​product.​​Better​​quality​​leads​​to​​reduced​​rework.​​And​​reduced​​rework​​results​​in​​faster​​delivery​
EN

​times.​

​1.4 A Generic View of Process​

RE

​ ​​process​​is​​a​​collection​​of​​activities,​​actions,​​and​​tasks​​that​​are​​performed​​when​​some​​work​
A
A

​product​​is​​to​​be​​created.​​An​​activity​​strives​​to​​achieve​​a​​broad​​objective​​(e.g.,​​communication​
​with​ ​stakeholders)​ ​and​ ​is​ ​applied​ ​regardless​ ​of​ ​the​ ​application​ ​domain,​ ​size​ ​of​ ​the​ ​project,​
W

​complexity​​of​​the​​effort,​​or​​degree​​of​​rigor​​with​​which​​software​​engineering​​is​​to​​be​​applied.​
​An​ ​action​ ​(e.g.,​ ​architectural​ ​design)​ ​encompasses​ ​a​ ​set​​of​​tasks​​that​​produce​​a​​major​​work​
FT

​product​ ​(e.g.,​ ​an​ ​architectural​ ​design​ ​model).​ ​A​ ​task​ ​focuses​ ​on​ ​a​ ​small,​ ​but​ ​well-defined​
​objective (e.g., conducting a unit test) that produces a tangible outcome.​
​SO

I​ n​ ​the​ ​context​​of​​software​​engineering,​​a​​process​​is​​not​​a​​rigid​​prescription​​for​​how​​to​​build​
​computer​​software.​​Rather,​​it​​is​​an​​adaptable​​approach​​that​​enables​​the​​people​​doing​​the​​work​
​(the​ ​software​ ​team)​ ​to​ ​pick​ ​and​ ​choose​ ​the​ ​appropriate​ ​set​ ​of​ ​work​ ​actions​ ​and​ ​tasks.​ ​The​
​intent​ ​is​ ​always​ ​to​ ​deliver​​software​​in​​a​​timely​​manner​​and​​with​​sufficient​​quality​​to​​satisfy​
​those who have sponsored its creation and those who will use it.​

​Ms. Sthuthi Rai, Lecturer​ ​Department of Computer Science, YIASCM​

 ​SOFTWARE ENGINEERING​

​1.5 Software Engineering - A Layered Technology​

​ oftware​​engineering​​is​​a​​layered​​technology.​​The​​foundation​​for​​software​​engineering​​is​​the​
S
​process​ ​layer.​ ​The​ ​software​ ​engineering​​process​​is​​the​​glue​​that​​holds​​the​​technology​​layers​
​together​​and​​enables​​rational​​and​​timely​​development​​of​​computer​​software.​​Process​​defines​
​a​ ​framework​ ​that​ ​must​ ​be​ ​established​ ​for​ ​effective​ ​delivery​ ​of​ ​software​ ​engineering​
​technology.​

​ he​ ​software​ ​process​ ​forms​ ​the​ ​basis​ ​for​ ​management​ ​control​ ​of​ ​software​ ​projects​ ​and​
T
​establishes​ ​the​ ​context​ ​in​ ​which​ ​technical​ ​methods​ ​are​ ​applied,​ ​work​ ​products​ ​(models,​
​documents,​ ​data,​ ​reports,​ ​forms,​ ​etc.)​ ​are​ ​produced,​ ​milestones​ ​are​ ​established,​ ​quality​ ​is​

​
G
​ensured, and change is properly managed.​

R IN
EE
IN
G
EN

​ oftware​​engineering​​methods​​provide​​the​​technical​​how-to’s​​for​​building​​software.​​Methods​
S
​encompass​​a​​broad​​array​​of​​tasks​​that​​include​​communication,​​requirements​​analysis,​​design​
​modeling,​​program​​construction,​​testing,​​and​​support.​​Software​​engineering​​methods​​rely​​on​
RE

​a​ ​set​ ​of​ ​basic​ ​principles​ ​that​ ​govern​ ​each​ ​area​ ​of​ ​the​ ​technology​ ​and​ ​include​ ​modeling​
​activities and other descriptive techniques.​
A

​ oftware​​engineering​​tools​​provide​​automated​​or​​semiautomated​​support​​for​​the​​process​​and​
S
W

​the​​methods.​​When​​tools​​are​​integrated​​so​​that​​information​​created​​by​​one​​tool​​can​​be​​used​​by​
​another,​ ​a​ ​system​ ​for​ ​the​ ​support​ ​of​ ​software​ ​development,​ ​called​​computer-aided​​software​
​engineering, is established.​
FT

​1.6 A Process Framework​

​SO

​ ​​process​​framework​​determines​​the​​processes​​which​​are​​essential​​for​​completing​​a​​complex​
A
​software​ ​project.​ ​A​ ​process​ ​framework​ ​establishes​ ​the​ ​foundation​ ​for​ ​a​ ​complete​ ​software​
​engineering​​process​​by​​identifying​​a​​small​​number​​of​​framework​​activities​​that​​are​​applicable​
​to​ ​all​ ​software​ ​projects,​ ​regardless​ ​of​ ​their​ ​size​ ​or​ ​complexity.​ ​In​ ​addition,​ ​the​ ​process​
​framework​ ​encompasses​ ​a​ ​set​ ​of​ ​umbrella​ ​activities​ ​that​ ​are​ ​applicable​ ​across​ ​the​ ​entire​
​software process.​

​A generic process framework for software engineering encompasses five activities:​

​Ms. Sthuthi Rai, Lecturer​ ​Department of Computer Science, YIASCM​

 ​SOFTWARE ENGINEERING​

​1.​ ​Communication.​​Before​​any​​technical​​work​​can​​commence,​​it​​is​​critically​​important​
t​o​ ​communicate​ ​and​ ​collaborate​ ​with​ ​the​ ​customer​ ​(and​ ​other​ ​stakeholders.​ ​The​
​intent​ ​is​ ​to​ ​understand​ ​stakeholders’​ ​objectives​ ​for​ ​the​ ​project​ ​and​ ​to​ ​gather​
​requirements that help define software features and functions.​

​2.​ ​Planning.​ ​Any​ ​complicated​ ​journey​ ​can​ ​be​ ​simplified​ ​if​ ​a​ ​map​ ​exists.​ ​A​ ​software​
p​ roject​​is​​a​​complicated​​journey,​​and​​the​​planning​​activity​​creates​​a​​“map”​​that​​helps​
​guide​ ​the​ ​team​ ​as​ ​it​ ​makes​ ​the​ ​journey.​ ​The​ ​map—called​ ​a​ ​software​ ​project​
​plan—defines​ ​the​ ​software​ ​engineering​ ​work​ ​by​ ​describing​​the​​technical​​tasks​​to​​be​
​conducted,​ ​the​ ​risks​ ​that​ ​are​ ​likely,​ ​the​ ​resources​ ​that​ ​will​ ​be​ ​required,​ ​the​ ​work​
​products to be produced, and a work schedule.​

​
G
​3.​ ​Modeling.​​Whether​​you’re​​a​​landscaper,​​a​​bridge​​builder,​​an​​aeronautical​​engineer,​​a​

IN
c​ arpenter,​​or​​an​​architect,​​you​​work​​with​​models​​every​​day.​​You​​create​​a​​“sketch”​​of​
​the​ ​thing​ ​so​ ​that​ ​you’ll​ ​understand​ ​the​ ​big​ ​picture—what​ ​it​ ​will​ ​look​ ​like​
​architecturally,​ ​how​ ​the​​constituent​​parts​​fit​​together,​​and​​many​​other​​characteristics.​

R
​If​ ​required,​ ​you​ ​refine​ ​the​ ​sketch​​into​​greater​​and​​greater​​detail​​in​​an​​effort​​to​​better​
​understand​ ​the​ ​problem​ ​and​ ​how​ ​you’re​ ​going​​to​​solve​​it.​​A​​software​​engineer​​does​

EE
​the​​same​​thing​​by​​creating​​models​​to​​better​​understand​​software​​requirements​​and​​the​
​design that will achieve those requirements.​
IN
​4.​ ​Construction.​ ​This​ ​activity​ ​combines​ ​code​ ​generation​​(either​​manual​​or​​automated)​
​and the testing that is required to uncover errors in the code.​
G
​5.​ ​Deployment.​ ​The​ ​software​ ​(as​ ​a​ ​complete​ ​entity​ ​or​ ​as​ ​a​ ​partially​ ​completed​
EN

​increment)​ ​is​ ​delivered​ ​to​ ​the​ ​customer​ ​who​ ​evaluates​ ​the​ ​delivered​ ​product​ ​and​
p​ rovides feedback based on the evaluation.​

​ hese​​five​​generic​​framework​​activities​​can​​be​​used​​during​​the​​development​​of​​small,​​simple​
T
RE

​programs,​ ​the​ ​creation​ ​of​ ​large​ ​Web​​applications,​​and​​for​​the​​engineering​​of​​large,​​complex​

​computer-based​ ​systems.​ ​The​ ​details​ ​of​ ​the​ ​software​ ​process​ ​will​ ​be​​quite​​different​​in​​each​
​case, but the framework activities remain the same.​
A
W
FT
​SO

​Ms. Sthuthi Rai, Lecturer​ ​Department of Computer Science, YIASCM​

 ​SOFTWARE ENGINEERING​

​ oftware​ ​engineering​ ​process​ ​framework​ ​activities​ ​are​ ​complemented​ ​by​ ​a​ ​number​ ​of​
S
​umbrella​ ​activities.​ ​In​ ​general,​ ​umbrella​ ​activities​​are​​applied​​throughout​​a​​software​​project​
​and​ ​help​ ​a​ ​software​ ​team​ ​manage​ ​and​ ​control​ ​progress,​ ​quality,​ ​change,​ ​and​ ​risk.​ ​Typical​
​umbrella activities include:​

​●​ ​Software​​project​​tracking​​and​​control​​—allows​​the​​software​​team​​to​​assess​​progress​
​against the project plan and take any necessary action to maintain the schedule.​

​●​ ​Risk​ ​management​​—assesses​ ​risks​ ​that​​may​​affect​​the​​outcome​​of​​the​​project​​or​​the​

​quality of the product.​

​
​●​ ​Software​ ​quality​ ​assurance​​—defines​ ​and​ ​conducts​ ​the​​activities​​required​​to​​ensure​

G
​software quality.​

IN
​●​ ​Technical​ ​reviews​​—assesses​ ​software​ ​engineering​ ​work​ ​products​ ​in​ ​an​ ​effort​ ​to​
​uncover and remove errors before they are propagated to the next activity.​

R
​●​ ​Measurement​​—defines​ ​and​ ​collects​ ​process,​ ​project,​ ​and​ ​product​ ​measures​ ​that​

EE
a​ ssist​ ​the​ ​team​ ​in​ ​delivering​​software​​that​​meets​​stakeholders’​​needs;​​can​​be​​used​​in​
​conjunction with all other framework and umbrella activities.​
IN
​●​ ​Software​ ​configuration​ ​management​​—manages​ ​the​ ​effects​ ​of​ ​change​ ​throughout​
​the software process.​
G
​●​ ​Reusability​ ​management​​—defines​ ​criteria​ ​for​ ​work​ ​product​ ​reuse​ ​(including​
EN

​software components) and establishes mechanisms to achieve reusable components.​

​●​ ​Work​​product​​preparation​​and​​production​​—encompasses​​the​​activities​​required​​to​
​create work products such as models, documents, logs, forms, and lists.​
RE

​1.7 The Capability Maturity Model Integration (CMMI)​

A
W

​ he​ ​original​ ​CMM​ ​was​ ​developed​ ​and​ ​upgraded​ ​by​ ​the​ ​Software​ ​Engineering​ ​Institute​
T
​throughout​​the​​1990s​​as​​a​​complete​​SPI​​framework.​​Today,​​it​​has​​evolved​​into​​the​​Capability​
FT

​Maturity​​Model​​Integration​​(CMMI),​​a​​comprehensive​​process​​meta-model​​that​​is​​predicated​
​on​ ​a​ ​set​ ​of​ ​system​ ​and​ ​software​ ​engineering​ ​capabilities​ ​that​ ​should​ ​be​ ​present​ ​as​
​organizations reach different levels of process capability and maturity.​
​SO

​ he​​CMMI​​represents​​a​​process​​meta-model​​in​​two​​different​​ways:​ ​As​​a​​“continuous”​​model​
T
​and​ ​as​ ​a​ ​“staged”​ ​model.​ ​The​ ​continuous​ ​CMMI​ ​metamodel​ ​describes​ ​a​ ​process​ ​in​ ​two​
​dimensions.​ ​Each​ ​process​ ​area​ ​(e.g.,​ ​project​ ​planning​ ​or​ ​requirements​ ​management)​ ​is​
​formally​​assessed​​against​​specific​​goals​​and​​practices​​and​​is​​rated​​according​​to​​the​​following​
​capability levels:​

​Ms. Sthuthi Rai, Lecturer​ ​Department of Computer Science, YIASCM​

 ​SOFTWARE ENGINEERING​

​
G
R IN
EE
​ evel​ ​0:​ ​Incomplete—the​ ​process​ ​area​ ​(e.g.,​ ​requirements​ ​management)​ ​is​ ​either​ ​not​
L
​performed​ ​or​ ​does​ ​not​ ​achieve​ ​all​ ​goals​ ​and​ ​objectives​ ​defined​ ​by​ ​the​ ​CMMI​ ​for​ ​level​ ​1​
​capability for the process area.​ IN
​Level​​1:​​Performed—all​​of​​the​​specific​​goals​​of​​the​​process​​area​​(as​​defined​​by​​the​​CMMI)​
​have​ ​been​ ​satisfied.​ ​Work​ ​tasks​ ​required​ ​to​ ​produce​ ​defined​ ​work​ ​products​ ​are​ ​being​
G
​conducted.​
EN

​ evel​ ​2:​ ​Managed—all​ ​capability​ ​level​ ​1​ ​criteria​ ​have​ ​been​ ​satisfied.​ ​In​​addition,​​all​​work​
L
​associated​ ​with​ ​the​ ​process​ ​area​ ​conforms​ ​to​ ​an​ ​organizationally​ ​defined​ ​policy;​​all​​people​
​doing​ ​the​ ​work​ ​have​ ​access​ ​to​ ​adequate​ ​resources​ ​to​ ​get​ ​the​ ​job​ ​done;​ ​stakeholders​ ​are​
​actively​ ​involved​ ​in​ ​the​ ​process​ ​area​ ​as​ ​required;​ ​all​ ​work​ ​tasks​ ​and​ ​work​ ​products​ ​are​
RE

​“monitored,​ ​controlled,​ ​and​ ​reviewed;​ ​and​ ​are​ ​evaluated​ ​for​ ​adherence​ ​to​ ​the​ ​process​
​description”.​
A

​ evel​​3:​​Defined—all​​capability​​level​​2​​criteria​​have​​been​​achieved.​​In​​addition,​​the​​process​
L
W

​is​ ​“tailored​ ​from​​the​​organization’s​​set​​of​​standard​​processes​​according​​to​​the​​organization’s​

​tailoring​ ​guidelines,​ ​and​ ​contributes​ ​work​ ​products,​ ​measures,​ ​and​ ​other​
FT

​process-improvement information to the organizational process assets”.​

​ evel​ ​4:​ ​Quantitatively​ ​managed—all​ ​capability​ ​level​ ​3​ ​criteria​ ​have​ ​been​ ​achieved.​ ​In​
L
​SO

​addition,​ ​the​ ​process​ ​area​ ​is​ ​controlled​ ​and​ ​improved​ ​using​ ​measurement​ ​and​ ​quantitative​
​assessment.​​“Quantitative​​objectives​​for​​quality​​and​​process​​performance​​are​​established​​and​
​used as criteria in managing the process”.​

​ evel​ ​5:​ ​Optimized—all​ ​capability​ ​level​ ​4​ ​criteria​ ​have​ ​been​ ​achieved.​ ​In​ ​addition,​ ​the​
L
​process​​area​​is​​adapted​​and​​optimized​​using​​quantitative​​(statistical)​​means​​to​​meet​​changing​
​customer​ ​needs​ ​and​ ​to​ ​continually​ ​improve​ ​the​ ​efficacy​ ​of​ ​the​ ​process​ ​area​ ​under​
​consideration.​

​ he​​CMMI​​defines​​each​​process​​area​​in​​terms​​of​​“specific​​goals”​​and​​the​​“specific​​practices”​
T
​required​ ​to​ ​achieve​ ​these​​goals.​​Specific​​goals​​establish​​the​​characteristics​​that​​must​​exist​​if​

​Ms. Sthuthi Rai, Lecturer​ ​Department of Computer Science, YIASCM​

 ​SOFTWARE ENGINEERING​

t​he​​activities​​implied​​by​​a​​process​​area​​are​​to​​be​​effective.​​Specific​​practices​​refine​​a​​goal​​into​
​a set of process-related activities.​

​ or​ ​example,​ ​project​ ​planning​ ​is​ ​one​ ​of​ ​eight​ ​process​ ​areas​ ​defined​ ​by​ ​the​ ​CMMI​ ​for​
F
​“project​​management”​​category.​​The​​specific​​goals​​(SG)​​and​​the​​associated​​specific​​practices​
​(SP) defined for​​project planning​​are:​

​SG 1 Establish Estimates​

​SP 1.1-1 Estimate the Scope of the Project​
​SP 1.2-1 Establish Estimates of Work Product and Task Attributes​
​SP 1.3-1 Define Project Life Cycle​

​
​SP 1.4-1 Determine Estimates of Effort and Cost​

G
IN
​SG 2 Develop a Project Plan​
​SP 2.1-1 Establish the Budget and Schedule​
​SP 2.2-1 Identify Project Risks​

R
​SP 2.3-1 Plan for Data Management​
​SP 2.4-1 Plan for Project Resources​

EE
​SP 2.5-1 Plan for Needed Knowledge and Skills​
​SP 2.6-1 Plan Stakeholder Involvement​
​SP 2.7-1 Establish the Project Plan​
IN
G
​SG 3 Obtain Commitment to the Plan​
EN

​SP 3.1-1 Review Plans That Affect the Project​

​SP 3.2-1 Reconcile Work and Resource Levels​
​SP 3.3-1 Obtain Plan Commitment​
RE

​1.8 Process Patterns​

A

​ very​​software​​team​​encounters​​problems​​as​​it​​moves​​through​​the​​software​​process.​​It​​would​
E
W

​be​​useful​​if​​proven​​solutions​​to​​these​​problems​​were​​readily​​available​​to​​the​​team​​so​​that​​the​
​problems could be addressed and resolved quickly.​
FT

​ ​ ​process​ ​pattern​ ​describes​ ​a​ ​process-related​ ​problem​ ​that​​is​​encountered​​during​​software​

A
​engineering​​work,​​identifies​​the​​environment​​in​​which​​the​​problem​​has​​been​​encountered,​​and​
​SO

​suggests​ ​one​ ​or​ ​more​ ​proven​ ​solutions​ ​to​ ​the​ ​problem.​ ​Stated​ ​in​ ​more​ ​general​ ​terms,​ ​a​
​process​ ​pattern​ ​provides​ ​you​ ​with​ ​a​​template​​—a​​consistent​​method​​for​​describing​​problem​
​solutions​​within​​the​​context​​of​​the​​software​​process.​​By​​combining​​patterns,​​a​​software​​team​
​can solve problems and construct a process that best meets the needs of a project.​

​Ambler has proposed a template for describing a process pattern:​

​1.​ P​ attern​ ​Name:​ ​The​ ​pattern​ ​is​ ​given​ ​a​ ​meaningful​ ​name​ ​describing​ ​it​ ​within​ ​the​
​context of the software process (e.g., Technical Reviews).​

​Ms. Sthuthi Rai, Lecturer​ ​Department of Computer Science, YIASCM​

 ​SOFTWARE ENGINEERING​

​2.​ F​ orces:​​The​​environment​​in​​which​​the​​pattern​​is​​encountered​​and​​the​​issues​​that​​make​
​the problem visible and may affect its solution.​

​3.​ ​Type:​​The pattern type is specified. Ambler suggests​​three types:​

​a)​ S​ tage​ ​pattern:​ ​Defines​ ​a​ ​problem​ ​associated​ ​with​ ​a​ ​framework​ ​activity​ ​for​ ​the​
​process.​​Since​​a​​framework​​activity​​encompasses​​multiple​​actions​​and​​work​​tasks,​
​a​ ​stage​ ​pattern​ ​incorporates​ ​multiple​ ​task​ ​patterns​ ​(see​ ​the​ ​following)​ ​that​ ​are​
​relevant​​to​​the​​stage​​(framework​​activity).​​An​​example​​of​​a​​stage​​pattern​​might​​be​
​Establishing​ ​Communication.​ ​This​ ​pattern​ ​would​ ​incorporate​ ​the​ ​task​ ​pattern​
​Requirements Gathering and others.​

​
G
​b)​ T​ ask​​pattern:​​Defines​​a​​problem​​associated​​with​​a​​software​​engineering​​action​​or​

IN
​work​ ​task​ ​and​ ​relevant​ ​to​ ​successful​ ​software​ ​engineering​ ​practice​ ​(e.g.,​
​Requirements Gathering​​is a task pattern).​

R
​c)​ P​ hase​​pattern:​​Define​​the​​sequence​​of​​framework​​activities​​that​​occurs​​within​​the​
​process,​​even​​when​​the​​overall​​flow​​of​​activities​​is​​iterative​​in​​nature.​​An​​example​

EE
​of a phase pattern might be Spiral Model or Prototyping.​

​4.​ ​Initial​​context.​​Describes​​the​​conditions​​under​​which​​the​​pattern​​applies.​​Prior​​to​​the​
IN
​initiation of the pattern:​
​1)​ ​What organizational or team-related activities have already occurred?​
G
​2)​ ​What is the entry state for the process?​
​3)​ ​What software engineering information or project information already exists?​
EN

​5.​ ​Problem:​​The specific problem to be solved by the​​pattern.​

​6.​ ​Solution:​​Describes​​how​​to​​implement​​the​​pattern​​successfully.​​This​​section​​describes​
RE

h​ ow​ ​the​ ​initial​ ​state​ ​of​ ​the​ ​process​ ​(that​ ​exists​​before​​the​​pattern​​is​​implemented)​​is​

​modified​ ​as​ ​a​ ​consequence​ ​of​ ​the​ ​initiation​ ​of​ ​the​ ​pattern.​ ​It​ ​also​ ​describes​ ​how​
​software​ ​engineering​ ​information​ ​or​ ​project​ ​information​ ​that​ ​is​ ​available​ ​before​ ​the​
A

​initiation​​of​​the​​pattern​​is​​transformed​​as​​a​​consequence​​of​​the​​successful​​execution​​of​
W

​the pattern.​

​7.​ ​Resulting​​Context:​​Describes​​the​​conditions​​that​​will​​result​​once​​the​​pattern​​has​​been​
FT

​successfully implemented. Upon completion of the pattern:​

​1)​ ​What organizational or team-related activities must have occurred?​
​SO

​2)​ ​What is the exit state for the process?​

​3)​ ​What​ ​software​ ​engineering​ ​information​ ​or​ ​project​ ​information​ ​has​ ​been​
​developed?​

​8.​ ​Related​​Patterns:​​Provide​​a​​list​​of​​all​​process​​patterns​​that​​are​​directly​​related​​to​​this​
o​ ne.​​This​​may​​be​​represented​​as​​a​​hierarchy​​or​​in​​some​​other​​diagrammatic​​form.​​For​
​example,​ ​the​ ​stage​ ​pattern​ ​Communication​ ​encompasses​ ​the​ ​task​ ​patterns:​ ​Project​
​Team,​ ​Collaborative​ ​Guidelines,​ ​Scope​ ​Isolation,​ ​Requirements​ ​Gathering,​
​Constraint Description,​​and​​Scenario Creation.​

​9.​ ​Known​ ​Uses​ ​and​ ​Examples:​ ​Indicate​ ​the​ ​specific​ ​instances​ ​in​ ​which​​the​​pattern​​is​
​applicable.​ ​For​ ​example,​ ​Communication​ ​is​ ​mandatory​ ​at​ ​the​ ​beginning​ ​of​ ​every​

​Ms. Sthuthi Rai, Lecturer​ ​Department of Computer Science, YIASCM​

 ​SOFTWARE ENGINEERING​

s​ oftware​ ​project,​ ​is​ ​recommended​​throughout​​the​​software​​project,​​and​​is​​mandatory​

​once the deployment activity is under way.​

​ rocess​​patterns​​provide​​an​​effective​​mechanism​​for​​addressing​​problems​​associated​​with​​any​
P
​software​ ​process.​ ​The​ ​patterns​ ​enable​​you​​to​​develop​​a​​hierarchical​​process​​description​​that​
​begins​ ​at​ ​a​ ​high​ ​level​​of​​abstraction​​(a​​phase​​pattern).​​The​​description​​is​​then​​refined​​into​​a​
​set​ ​of​ ​stage​ ​patterns​ ​that​ ​describe​ ​framework​ ​activities​ ​and​ ​are​ ​further​ ​refined​ ​in​ ​a​
​hierarchical​ ​fashion​ ​into​ ​more​ ​detailed​ ​task​ ​patterns​ ​for​ ​each​ ​stage​ ​pattern.​ ​Once​ ​process​
​patterns​​have​​been​​developed,​​they​​can​​be​​reused​​for​​the​​definition​​of​​process​​variants—that​
​is,​ ​a​ ​customized​ ​process​ ​model​ ​can​ ​be​ ​defined​ ​by​ ​a​ ​software​ ​team​ ​using​ ​the​ ​patterns​ ​as​
​building blocks for the process model.​

​
G
IN
​1.9 Process Assessment​
​ he​ ​existence​ ​of​​a​​software​​process​​is​​no​​guarantee​​that​​software​​will​​be​​delivered​​on​​time,​
T

R
​that​​it​​will​​meet​​the​​customer’s​​needs,​​or​​that​​it​​will​​exhibit​​the​​technical​​characteristics​​that​

EE
​will​ ​lead​ ​to​ ​long-term​ ​quality.​ ​Process​ ​patterns​ ​must​ ​be​ ​coupled​ ​with​ ​solid​ ​software​
​engineering​ ​practice.​ ​In​ ​addition,​ ​the​​process​​itself​​can​​be​​assessed​​to​​ensure​​that​​it​​meets​​a​
​set​ ​of​ ​basic​ ​process​ ​criteria​ ​that​ ​have​ ​been​ ​shown​ ​to​ ​be​ ​essential​ ​for​ ​a​ ​successful​​software​
​engineering.​
IN
​ ​ ​number​ ​of​ ​different​ ​approaches​ ​to​ ​software​ ​process​ ​assessment​ ​and​ ​improvement​ ​have​
A
G
​been proposed over the past few decades:​
EN

​●​ S ​ tandard​ ​CMMI​ ​Assessment​ ​Method​ ​for​ ​Process​ ​Improvement​ ​(SCAMPI)​​:​

​Provides​ ​a​ ​five-step​ ​process​ ​assessment​ ​model​ ​that​ ​incorporates​ ​five​ ​phases:​
​initiating,​ ​diagnosing,​ ​establishing,​ ​acting,​ ​and​ ​learning.​ ​The​ ​SCAMPI​ ​method​ ​uses​
RE

​the SEI CMMI as the basis for assessment.​

​●​ ​CMM-Based​​Appraisal​​for​​Internal​​Process​​Improvement​​(CBA​​IPI):​​Provides​​a​
​diagnostic​ ​technique​ ​for​ ​assessing​ ​the​ ​relative​ ​maturity​ ​of​ ​a​ ​software​ ​organization;​
​uses the SEI CMM as the basis for the assessment.​
A
W

​●​ ​SPICE​ ​(ISO/IEC15504):​ ​A​ ​standard​​that​​defines​​a​​set​​of​​requirements​​for​​software​

​process​​assessment.​​The​​intent​​of​​the​​standard​​is​​to​​assist​​organizations​​in​​developing​
FT

a​ n objective evaluation of the efficacy of any defined software process.​

​●​ ​ISO​​9001:2000​​for​​Software​​:​​A​​generic​​standard​​that​​applies​​to​​any​​organization​​that​
​SO

​ ants​ ​to​ ​improve​ ​the​ ​overall​ ​quality​ ​of​ ​the​ ​products,​ ​systems,​ ​or​ ​services​ ​that​ ​it​
w
​provides.​ ​Therefore,​​the​​standard​​is​​directly​​applicable​​to​​software​​organizations​​and​
​companies.​

​1.10 Personal and Team Process Models​

​ he​​best​​software​​process​​is​​one​​that​​is​​close​​to​​the​​people​​who​​will​​be​​doing​​the​​work.​​If​​a​
T
​software​ ​process​ ​model​ ​has​ ​been​ ​developed​ ​at​​a​​corporate​​or​​organizational​​level,​​it​​can​​be​
​effective​​only​​if​​it​​is​​amenable​​to​​significant​​adaptation​​to​​meet​​the​​needs​​of​​the​​project​​team​
​that​ ​is​ ​actually​ ​doing​ ​software​ ​engineering​ ​work.​ ​In​ ​an​ ​ideal​ ​setting,​ ​you​ ​would​ ​create​ ​a​

​Ms. Sthuthi Rai, Lecturer​ ​Department of Computer Science, YIASCM​

 ​SOFTWARE ENGINEERING​

p​ rocess​ ​that​ ​best​ ​fits​​your​​needs,​​and​​at​​the​​same​​time,​​meets​​the​​broader​​needs​​of​​the​​team​

​and​​the​​organization.​​Alternatively,​​the​​team​​itself​​can​​create​​its​​own​​process,​​and​​at​​the​​same​
​time meet the narrower needs of individuals and the broader needs of the organization.​

​1.10.1 Personal Software Process (PSP)​

I​ n​ ​order​ ​to​ ​change​ ​an​ ​ineffective​ ​personal​ ​process,​ ​an​ ​individual​ ​must​ ​move​ ​through​ ​four​
​phases,​​each​​requiring​​training​​and​​careful​​instrumentation.​​The​​Personal​​Software​​Process​
​(PSP)​ ​emphasizes​ ​personal​ ​measurement​ ​of​​both​​the​​work​​product​​that​​is​​produced​​and​​the​
​resultant​​quality​​of​​the​​work​​product.​​In​​addition​​PSP​​makes​​the​​practitioner​​responsible​​for​
​project​ ​planning​ ​(e.g.,​ ​estimating​ ​and​ ​scheduling)​ ​and​ ​empowers​ ​the​ ​practitioner​​to​​control​

​
​the quality of all software work products that are developed.​

G
IN
​The PSP model defines five framework activities:​

​●​ ​Planning:​ ​This​ ​activity​ ​isolates​ ​requirements​ ​and​ ​develops​ ​both​ ​size​ ​and​ ​resource​

R
e​ stimates.​​In​​addition,​​a​​defect​​estimate​​(the​​number​​of​​defects​​projected​​for​​the​​work)​

EE
​is​ ​made.​ ​All​ ​metrics​ ​are​ ​recorded​ ​on​ ​worksheets​ ​or​​templates.​​Finally,​​development​
​tasks are identified and a project schedule is created.​
IN
​●​ ​High-level​ ​design:​ ​External​​specifications​​for​​each​​component​​to​​be​​constructed​​are​
d​ eveloped​ ​and​ ​a​ ​component​ ​design​ ​is​​created.​​Prototypes​​are​​built​​when​​uncertainty​
​exists. All issues are recorded and tracked.​
G
​●​ ​High-level​​design​​review:​​Formal​​verification​​methods​​are​​applied​​to​​uncover​​errors​
EN

​in the design. Metrics are maintained for all important tasks and work results.​

​●​ ​Development:​ ​The​ ​component-level​ ​design​ ​is​ ​refined​ ​and​ ​reviewed.​ ​Code​ ​is​
g​ enerated,​ ​reviewed,​ ​compiled,​ ​and​ ​tested.​ ​Metrics​ ​are​ ​maintained​ ​for​ ​all​ ​important​
RE

​tasks and work results.​

​ ​ ​Postmortem:​ ​Using​​the​​measures​​and​​metrics​​collected​​(this​​is​​a​​substantial​​amount​
●
​of​ ​data​ ​that​ ​should​ ​be​ ​analyzed​ ​statistically),​ ​the​ ​effectiveness​ ​of​ ​the​ ​process​ ​is​
A

​determined.​​Measures​​and​​metrics​​should​​provide​​guidance​​for​​modifying​​the​​process​
W

​to improve its effectiveness.​

FT

​ SP​​stresses​​the​​need​​to​​identify​​errors​​early​​and,​​just​​as​​important,​​to​​understand​​the​​types​​of​
P
​errors​ ​that​ ​you​ ​are​ ​likely​ ​to​ ​make.​ ​This​ ​is​ ​accomplished​ ​through​ ​a​ ​rigorous​ ​assessment​
​activity​ ​performed​ ​on​ ​all​ ​work​ ​products​ ​you​ ​produce.​ ​However,​ ​PSP​ ​has​ ​not​ ​been​ ​widely​
​SO

​adopted​​throughout​​the​​industry.​​The​​reasons,​​sadly,​​have​​more​​to​​do​​with​​human​​nature​​and​
​organizational​ ​inertia​ ​than​ ​they​ ​do​ ​with​ ​the​ ​strengths​​and​​weaknesses​​of​​the​​PSP​​approach.​
​PSP​ ​is​ ​intellectually​ ​challenging​ ​and​ ​demands​ ​a​ ​level​ ​of​ ​commitment​​(by​​practitioners​​and​
​their​ ​managers)​ ​that​ ​is​ ​not​ ​always​ ​possible​ ​to​ ​obtain.​ ​Training​ ​is​ ​relatively​ ​lengthy,​ ​and​
​training​ ​costs​ ​are​ ​high.​ ​The​ ​required​ ​level​ ​of​ ​measurement​ ​is​ ​culturally​ ​difficult​ ​for​ ​many​
​software people.​

​1.10.2 Team Software Process (TSP)​

​ ecause​ ​many​ ​industry-grade​ ​software​ ​projects​ ​are​ ​addressed​ ​by​ ​a​ ​team​ ​of​ ​practitioners,​
B
​Watts​ ​Humphrey​ ​proposed​ ​a​ ​Team​ ​Software​ ​Process​ ​(TSP).​ ​The​ ​goal​ ​of​ ​TSP​ ​is​ ​to​ ​build​ ​a​
​“self-directed” project team that organizes itself to produce high-quality software.​

​Ms. Sthuthi Rai, Lecturer​ ​Department of Computer Science, YIASCM​

 ​SOFTWARE ENGINEERING​

​The following are objectives for TSP:​

​●​ ​Build​​self-directed​​teams​​that​​plan​​and​​track​​their​​work,​​establish​​goals,​​and​​own​
​their​​processes​​and​​plans.​​These​​can​​be​​pure​​software​​teams​​or​​integrated​​product​
​teams (IPTs) of 3 to about 20 engineers.​
​●​ ​Show​ ​managers​ ​how​ ​to​ ​coach​ ​and​ ​motivate​ ​their​ ​teams​ ​and​ ​how​ ​to​ ​help​ ​them​
​sustain peak performance.​
​●​ ​Accelerate​ ​software​ ​process​ ​improvement​ ​by​ ​making​ ​CMM​ ​Level​ ​5​ ​behavior​
​normal and expected.​
​●​ ​Provide improvement guidance to high-maturity organizations.​
​●​ ​Facilitate university teaching of industrial-grade team skills.​

​
G
​ SP​ ​defines​ ​the​ ​following​ ​framework​ ​activities:​ ​project​ ​launch,​ ​high-level​ ​design,​
T

IN
​implementation,​ ​integration​ ​and​ ​test,​ ​and​ ​postmortem.​ ​Like​ ​their​ ​counterparts​ ​in​ ​PSP​​these​
​activities​ ​enable​ ​the​ ​team​ ​to​ ​plan,​ ​design,​ ​and​ ​construct​ ​software​ ​in​ ​a​ ​disciplined​ ​manner​
​while​​at​​the​​same​​time​​quantitatively​​measuring​​the​​process​​and​​the​​product.​​The​​postmortem​

R
​sets the stage for process improvements.​

EE
​1.11 Process Models​
IN
​ rocess​​models​​were​​introduced​​to​​impose​​structure​​and​​discipline​​on​​the​​inherently​​chaotic​
P
​nature​ ​of​ ​software​ ​development.​ ​While​ ​these​ ​traditional​ ​models​ ​have​ ​helped​ ​bring​
G
​consistency​ ​and​ ​order​ ​to​ ​software​ ​engineering,​ ​the​ ​field​ ​still​ ​operates​ ​on​ ​what​ ​researchers​
​describe​ ​as​ ​the​ ​"edge​ ​of​ ​chaos"—a​ ​dynamic​ ​balance​ ​between​ ​rigid​ ​structure​ ​and​ ​creative​
EN

​freedom.​ ​As​ ​Nogueira​ ​and​ ​colleagues​ ​explain,​ ​this​ ​edge​ ​is​ ​a​ ​partially​ ​ordered​ ​state​ ​where​
​innovation​ ​can​ ​flourish​ ​without​ ​descending​ ​into​ ​disorder.​ ​Operating​ ​too​ ​close​ ​to​ ​absolute​
​order​ ​can​ ​stifle​ ​adaptability,​ ​while​ ​too​ ​much​ ​chaos​​can​​disrupt​​coordination​​and​​coherence.​
RE

​This​ ​philosophical​ ​tension​ ​raises​ ​a​​critical​​question​​for​​software​​engineers:​​Are​​prescriptive​

​models—which​ ​define​ ​framework​ ​activities,​ ​engineering​ ​actions,​ ​tasks,​ ​quality​ ​assurance,​
​and​​control​​mechanisms—too​​rigid​​for​​the​​rapidly​​changing​​nature​​of​​software?​​Or​​are​​they​
​necessary​ ​to​ ​ensure​ ​project​ ​consistency​ ​and​ ​coordination?​ ​Although​ ​there​ ​is​ ​no​ ​definitive​
A

​answer,​ ​software​ ​engineers​ ​must​ ​weigh​ ​these​ ​considerations​ ​carefully.​ ​Each​ ​prescriptive​
W

​model​ ​offers​ ​a​ ​unique​ ​process​ ​flow,​ ​dictating​​how​​tasks​​are​​sequenced​​and​​how​​framework​

​activities​ ​are​ ​applied,​ ​thus​ ​offering​ ​structured​ ​pathways​ ​to​ ​manage​ ​development​ ​while​ ​still​
FT

​allowing room for adaptation and creativity.​

​ ​ ​process​ ​model​ ​is​ ​defined​ ​as​ ​a​ ​blueprint​ ​or​ ​framework​ ​that​ ​describes​ ​the​ ​order​ ​in​ ​which​
A
​SO

​these software activities are performed.​

​1.11.1 The Waterfall Model​

​ here​​are​​times​​when​​the​​requirements​​for​​a​​problem​​are​​well​​understood—when​​work​​flows​
T
​from​ ​communication​ ​through​ ​deployment​ ​in​ ​a​ ​reasonably​ ​linear​ ​fashion.​ ​This​​situation​​is​
​sometimes​​encountered​​when​​well-defined​​adaptations​​or​​enhancements​​to​​an​​existing​​system​
​must​​be​​made​​(e.g.,​​an​​adaptation​​to​​accounting​​software​​that​​has​​been​​mandated​​because​​of​
​changes​ ​to​ ​government​ ​regulations).​ ​It​ ​may​ ​also​ ​occur​ ​in​ ​a​ ​limited​ ​number​ ​of​ ​new​
​development efforts, but only when requirements are well defined and reasonably stable.​

​Ms. Sthuthi Rai, Lecturer​ ​Department of Computer Science, YIASCM​

 ​SOFTWARE ENGINEERING​

​ he​​waterfall​​model,​​sometimes​​called​​the​​classic​​life​​cycle,​​suggests​​a​​systematic,​​sequential​
T
​approach​ ​to​ ​software​ ​development​ ​that​ ​begins​ ​with​ ​customer​ ​specification​ ​of​ ​requirements​
​and​ ​progresses​ ​through​ ​planning,​ ​modeling,​ ​construction,​ ​and​ ​deployment,​ ​culminating​ ​in​
​ongoing support of the completed software.​

​
G
IN
​Waterfall Model Phases:​

R
EE
​Communication​
​●​ ​Meet with stakeholders​
​●​ ​Gather functional and non-functional requirements​

​Planning​
IN
​●​ ​Document requirements (SRS – Software Requirements Specification)​

​●​ ​Time and cost estimation​

G
​●​ ​Resource planning​
​●​ ​Scheduling tasks and activities​
EN

​Modeling​
​●​ ​High-Level Design: Architecture design, module breakdown, system flow​
​●​ ​Low-Level Design: Detailed design of each module, data structures, interfaces​
RE

​Construction​
​●​ ​Developers write code based on design documents​
​●​ ​Individual units are developed and tested​
​Deployment​
A

​●​ ​Installation on target environment​

W

​●​ ​User training, documentation handover​

​Maintenance​
FT

​●​ ​Fix bugs​

​●​ ​Add updates​
​●​ ​Adapt to changes​
​SO

​Limitations of Waterfall Model:​

​●​ ​May be suited 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.​

​Ms. Sthuthi Rai, Lecturer​ ​Department of Computer Science, YIASCM​

 ​SOFTWARE ENGINEERING​

​V- Model​

​ ​​variation​​in​​the​​representation​​of​​the​​waterfall​​model​​is​​called​​the​​V-model.​​The​​V-Model​​is​
A
​a​ ​sequential​ ​development​ ​model​ ​where​ ​each​ ​phase​ ​must​ ​be​ ​completed​ ​before​ ​the​ ​next​ ​one​
​begins,​ ​but​ ​testing​ ​activities​​are​​planned​​in​​parallel​​with​​development.​​The​​V-model​​depicts​
​the​ ​relationship​ ​of​ ​quality​ ​assurance​ ​actions​ ​to​ ​the​ ​actions​ ​associated​ ​with​ ​communication,​
​modeling, and early construction activities.​

​
G
R IN
EE
IN
G
EN
RE

​ s​​a​​software​​team​​moves​​down​​the​​left​​side​​of​​the​​V,​​basic​​problem​​requirements​​are​​refined​
A
​into​​progressively​​more​​detailed​​and​​technical​​representations​​of​​the​​problem​​and​​its​​solution.​
A

​Once​ ​code​ ​has​ ​been​ ​generated,​ ​the​ ​team​ ​moves​ ​up​ ​the​ ​right​ ​side​ ​of​ ​the​ ​V,​ ​essentially​
​performing​ ​a​ ​series​ ​of​ ​tests​ ​(quality​ ​assurance​ ​actions)​ ​that​ ​validate​ ​each​ ​of​ ​the​ ​models​
W

​created​​as​​the​​team​​moved​​down​​the​​left​​side.7​​In​​reality,​​there​​is​​no​​fundamental​​difference​
​between​ ​the​ ​classic​ ​life​ ​cycle​ ​and​ ​the​​V-model.​​The​​V-model​​provides​​a​​way​​of​​visualizing​
FT

​how verification and validation actions are applied to earlier engineering work.​

​1.11.2 Incremental Process Models​

​SO

​ here​​are​​many​​situations​​in​​which​​initial​​software​​requirements​​are​​reasonably​​well​​defined,​
T
​but​​the​​overall​​scope​​of​​the​​development​​effort​​precludes​​a​​purely​​linear​​process.​​In​​addition,​
​there​ ​may​ ​be​ ​a​ ​compelling​ ​need​ ​to​ ​provide​ ​a​ ​limited​ ​set​ ​of​ ​software​ ​functionality​ ​to​ ​users​
​quickly​ ​and​ ​then​ ​refine​ ​and​ ​expand​ ​on​ ​that​ ​functionality​ ​in​ ​later​ ​software​​releases.​​In​​such​
​cases, you can choose a process model that is designed to produce the software in increments.​

​ he​ ​incremental​ ​model​ ​combines​ ​elements​ ​of​ ​linear​ ​and​ ​parallel​ ​process​ ​flows.​ ​The​
T
​incremental​ ​model​ ​applies​ ​linear​ ​sequences​ ​in​ ​a​ ​staggered​ ​fashion​ ​as​ ​calendar​ ​time​
​progresses.​ ​Each​ ​linear​ ​sequence​ ​produces​ ​deliverable​ ​“increments”​ ​of​ ​the​ ​software​ ​in​ ​a​
​manner​ ​that​ ​is​ ​similar​ ​to​ ​the​ ​increments​ ​produced​ ​by​ ​an​ ​evolutionary​ ​process​ ​flow.​ ​For​
​example,​​word-processing​​software​​developed​​using​​the​​incremental​​paradigm​​might​​deliver​

​Ms. Sthuthi Rai, Lecturer​ ​Department of Computer Science, YIASCM​

 ​SOFTWARE ENGINEERING​

b​ asic​ ​file​ ​management,​ ​editing,​ ​and​ ​document​ ​production​ ​functions​ ​in​ ​the​ ​first​ ​increment;​
​more​ ​sophisticated​ ​editing​ ​and​ ​document​ ​production​ ​capabilities​ ​in​ ​the​ ​second​ ​increment;​
​spelling​​and​​grammar​​checking​​in​​the​​third​​increment;​​and​​advanced​​page​​layout​​capability​​in​
​the​ ​fourth​ ​increment.​ ​It​ ​should​ ​be​ ​noted​ ​that​ ​the​ ​process​ ​flow​ ​for​ ​any​ ​increment​ ​can​
​incorporate the prototyping paradigm.​

​
G
R IN
EE
IN
G
EN

​ hen​​an​​incremental​​model​​is​​used,​​the​​first​​increment​​is​​often​​a​​core​​product.​​That​​is,​​basic​
W
​requirements​​are​​addressed​​but​​many​​supplementary​​features​​(some​​known,​​others​​unknown)​
​remain​ ​undelivered.​ ​The​ ​core​ ​product​ ​is​ ​used​ ​by​ ​the​ ​customer​ ​(or​ ​undergoes​ ​detailed​
​evaluation).​​As​​a​​result​​of​​use​​and/or​​evaluation,​​a​​plan​​is​​developed​​for​​the​​next​​increment.​
RE

​The​ ​plan​ ​addresses​ ​the​ ​modification​ ​of​ ​the​ ​core​ ​product​ ​to​ ​better​ ​meet​ ​the​ ​needs​ ​of​ ​the​
​customer​ ​and​ ​the​ ​delivery​ ​of​ ​additional​ ​features​ ​and​ ​functionality.​ ​This​ ​process​​is​​repeated​
​following the delivery of each increment, until the complete product is produced.​
A

​ he​ ​incremental​ ​process​ ​model​ ​focuses​ ​on​​the​​delivery​​of​​an​​operational​​product​​with​​each​

T
W

​increment.​ ​Early​ ​increments​ ​are​ ​stripped-down​ ​versions​ ​of​ ​the​ ​final​ ​product,​ ​but​ ​they​ ​do​
​provide capability that serves the user and also provide a platform for evaluation by the user.​
FT

I​ ncremental​ ​development​ ​is​ ​particularly​ ​useful​ ​when​ ​staffing​ ​is​ ​unavailable​ ​for​ ​a​ ​complete​
​implementation​ ​by​ ​the​ ​business​ ​deadline​ ​that​ ​has​ ​been​ ​established​ ​for​ ​the​ ​project.​ ​Early​
​SO

​increments​​can​​be​​implemented​​with​​fewer​​people.​​If​​the​​core​​product​​is​​well​​received,​​then​
​additional​ ​staff​ ​(if​ ​required)​ ​can​ ​be​ ​added​ ​to​ ​implement​ ​the​ ​next​ ​increment.​ ​In​ ​addition,​
​increments can be planned to manage technical risks.​

​1.11.3 Evolutionary Process Models​

​ oftware,​ ​like​ ​all​ ​complex​ ​systems,​ ​evolves​ ​over​ ​a​ ​period​ ​of​ ​time.​ ​Business​ ​and​ ​product​
S
​requirements​ ​often​ ​change​ ​as​ ​development​ ​proceeds,​ ​making​ ​a​ ​straight​ ​line​ ​path​ ​to​ ​an​​end​
​product​ ​unrealistic;​ ​tight​ ​market​ ​deadlines​ ​make​ ​completion​ ​of​ ​a​ ​comprehensive​ ​software​
​product​​impossible,​​but​​a​​limited​​version​​must​​be​​introduced​​to​​meet​​competitive​​or​​business​
​pressure;​ ​a​ ​set​ ​of​ ​core​​product​​or​​system​​requirements​​is​​well​​understood,​​but​​the​​details​​of​

​Ms. Sthuthi Rai, Lecturer​ ​Department of Computer Science, YIASCM​

 ​SOFTWARE ENGINEERING​

p​ roduct​​or​​system​​extensions​​have​​yet​​to​​be​​defined.​​In​​these​​and​​similar​​situations,​​you​​need​
​a​ ​process​ ​model​ ​that​ ​has​ ​been​ ​explicitly​ ​designed​ ​to​ ​accommodate​ ​a​ ​product​ ​that​ ​evolves​
​over​​time.​​Evolutionary​​models​​are​​iterative.​​They​​are​​characterized​​in​​a​​manner​​that​​enables​
​you to develop increasingly more complete versions of the software.​

​1.11.3.1 Prototyping / Iterative Model​

​ ften,​ ​a​ ​customer​ ​defines​ ​a​ ​set​ ​of​ ​general​ ​objectives​ ​for​ ​software,​ ​but​ ​does​ ​not​ ​identify​
O
​detailed​​requirements​​for​​functions​​and​​features.​​In​​other​​cases,​​the​​developer​​may​​be​​unsure​
​of​ ​the​ ​efficiency​ ​of​ ​an​ ​algorithm,​ ​the​ ​adaptability​ ​of​ ​an​ ​operating​ ​system,​ ​or​ ​the​ ​form​ ​that​
​human-machine​ ​interaction​ ​should​ ​take.​ ​In​ ​these,​ ​and​ ​many​ ​other​ ​situations,​ ​a​ ​prototyping​

​
G
​paradigm may offer the best approach.​

IN
​ lthough​​prototyping​​can​​be​​used​​as​​a​​stand-alone​​process​​model,​​it​​is​​more​​commonly​​used​
A
​as​​a​​technique​​that​​can​​be​​implemented​​within​​the​​context​​of​​any​​one​​of​​the​​process​​models.​
​Regardless​ ​of​ ​the​ ​manner​ ​in​ ​which​ ​it​ ​is​ ​applied,​ ​the​ ​prototyping​ ​paradigm​ ​assists​ ​you​ ​and​

R
​other stakeholders to better understand what is to be built when requirements are fuzzy.​

EE
​ he​ ​prototyping​ ​paradigm​​begins​​with​​communication.​​You​​meet​​with​​other​​stakeholders​​to​
T
​define​​the​​overall​​objectives​​for​​the​​software,​​identify​​whatever​​requirements​​are​​known,​​and​
IN
​outline​ ​areas​ ​where​ ​further​ ​definition​ ​is​ ​mandatory.​ ​A​ ​prototyping​ ​iteration​ ​is​ ​planned​
​quickly,​​and​​modeling​​(in​​the​​form​​of​​a​​“quick​​design”)​​occurs.​​A​​quick​​design​​focuses​​on​​a​
​representation​ ​of​ ​those​ ​aspects​​of​​the​​software​​that​​will​​be​​visible​​to​​end​​users​​(e.g.,​​human​
G
​interface​ ​layout​ ​or​ ​output​ ​display​ ​formats).​ ​The​ ​quick​ ​design​ ​leads​ ​to​​the​​construction​​of​​a​
​prototype.​ ​The​ ​prototype​ ​is​ ​deployed​ ​and​ ​evaluated​ ​by​​stakeholders,​​who​​provide​​feedback​
EN

​that​​is​​used​​to​​further​​refine​​requirements.​​Iteration​​occurs​​as​​the​​prototype​​is​​tuned​​to​​satisfy​
​the​ ​needs​ ​of​ ​various​ ​stakeholders,​ ​while​​at​​the​​same​​time​​enabling​​you​​to​​better​​understand​
​what needs to be done.​
RE
A
W
FT
​SO

​Ms. Sthuthi Rai, Lecturer​ ​Department of Computer Science, YIASCM​

 ​SOFTWARE ENGINEERING​

​ oth​​stakeholders​​and​​software​​engineers​​like​​the​​prototyping​​paradigm.​​Users​​get​​a​​feel​​for​
B
​the​ ​actual​ ​system,​ ​and​ ​developers​ ​get​ ​to​​build​​something​​immediately.​​Yet,​​prototyping​​can​
​be problematic for the following reasons:​

​●​ ​Stakeholders​ ​appreciate​ ​being​ ​able​ ​to​ ​see​ ​and​ ​use​ ​a​ ​tangible​ ​model​ ​early​ ​in​ ​the​
p​ rocess,​ ​while​ ​engineers​ ​get​ ​a​ ​head​ ​start​ ​on​ ​system​ ​development.​ ​However,​ ​this​
​approach​ ​comes​ ​with​ ​significant​ ​risks.​ ​Users​ ​may​ ​mistakenly​ ​believe​ ​that​ ​the​
​prototype​ ​is​ ​nearly​ ​complete​ ​and​ ​ready​ ​for​ ​deployment,​ ​unaware​ ​that​ ​it​ ​may​ ​lack​
​critical​ ​considerations​ ​for​ ​long-term​ ​maintainability,​ ​performance,​ ​or​ ​quality.​ ​When​
​developers​ ​explain​ ​that​​the​​prototype​​needs​​to​​be​​rebuilt​​from​​scratch​​for​​production​
​use, stakeholders often resist, pressuring the team to “fix” the prototype instead.​

​
G
​●​ ​A​ ​software​ ​engineer​ ​may​ ​make​ ​expedient​ ​but​ ​poor​ ​technical​ ​choices​ ​during​

IN
p​ rototyping—such​ ​as​ ​using​ ​the​ ​wrong​ ​programming​ ​language​ ​or​ ​inefficient​
​algorithms—which,​ ​if​ ​carried​ ​forward,​ ​can​ ​compromise​ ​the​ ​integrity​ ​of​ ​the​ ​final​
​system.​

R
​ lthough​ ​problems​ ​can​ ​occur,​ ​prototyping​ ​can​ ​be​ ​an​ ​effective​ ​paradigm​ ​for​ ​software​
A

EE
​engineering.​ ​The​ ​key​ ​is​ ​to​ ​define​ ​the​ ​rules​ ​of​ ​the​ ​game​ ​at​ ​the​ ​beginning;​ ​that​ ​is,​ ​all​
​stakeholders​ ​should​ ​agree​ ​that​ ​the​ ​prototype​ ​is​ ​built​ ​to​ ​serve​ ​as​ ​a​ ​mechanism​ ​for​ ​defining​
​requirements.​ ​It​ ​is​ ​then​​discarded,​​and​​the​​actual​​software​​is​​engineered​​with​​an​​eye​​toward​
IN
​quality.​
G
​1.11.3.2 The Spiral Model​
EN

​ he​ ​spiral​​model​​is​​an​​evolutionary​​software​​process​​model​​that​​couples​​the​​iterative​​nature​
T
​of​​prototyping​​with​​the​​controlled​​and​​systematic​​aspects​​of​​the​​waterfall​​model.​​It​​provides​
​the potential for rapid development of increasingly more complete versions of the software.​
RE

​ he​ ​spiral​ ​development​ ​model​ ​is​ ​a​​risk-driven​​process​​model​​generator​​that​​is​​used​​to​

T
​guide​ ​multi-stakeholder​ ​concurrent​ ​engineering​ ​of​ ​software​ ​intensive​ ​systems.​ ​It​ ​has​
A

​two​​main​​distinguishing​​features.​​One​​is​​a​​cyclic​​approach​​for​​incrementally​​growing​​a​
W

​system’s​ ​degree​ ​of​ ​definition​ ​and​ ​implementation​ ​while​ ​decreasing​ ​its​ ​degree​ ​of​ ​risk.​
​The​ ​other​ ​is​ ​a​ ​set​ ​of​ ​anchor​ ​point​ ​milestones​​for​​ensuring​​stakeholder​​commitment​​to​
FT

​feasible and mutually satisfactory system solutions.​

​ sing​ ​the​ ​spiral​ ​model,​ ​software​ ​is​ ​developed​ ​in​ ​a​ ​series​ ​of​ ​evolutionary​ ​releases.​ ​During​
U
​SO

​early​ ​iterations,​ ​the​ ​release​ ​might​ ​be​ ​a​ ​model​ ​or​ ​prototype.​ ​During​ ​later​ ​iterations,​
​increasingly more complete versions of the engineered system are produced.​

​Ms. Sthuthi Rai, Lecturer​ ​Department of Computer Science, YIASCM​

 ​SOFTWARE ENGINEERING​

​
G
R IN
EE
IN
​ he​​spiral​​model​​has​​four​​phases.​​A​​software​​project​​repeatedly​​passes​​through​​these​​phases​
T
G
​in iterations called Spirals.​
EN

​1.​ ​Planning​​:​ ​In​ ​this​ ​phase,​ ​the​ ​goals​ ​for​ ​that​ ​particular​ ​iteration​ ​(spiral​ ​loop)​ ​are​
d​ efined.​ ​These​ ​include​ ​identifying​ ​the​ ​system's​ ​requirements,​ ​setting​ ​objectives,​
​understanding​​constraints,​​and​​listing​​available​​alternatives​​for​​development.​​Key​
​activities​ ​include​ ​requirement​ ​gathering,​ ​stakeholder​ ​discussion,​ ​and​ ​project​
RE

​planning for the next steps.​

​2.​ ​Risk​ ​Analysis:​ ​This​ ​is​ ​the​ ​most​ ​distinctive​ ​phase​ ​of​ ​the​ ​Spiral​ ​Model.​ ​Here,​
A

p​ otential​​risks​​(technical,​​operational,​​financial,​​etc.)​​are​​identified​​and​​analyzed.​
W

​Once​ ​identified,​ ​mitigation​ ​strategies​ ​are​ ​planned​ ​and​ ​sometimes​ ​prototyping​ ​is​
​done​​to​​reduce​​uncertainties.​​The​​goal​​is​​to​​ensure​​the​​development​​path​​chosen​​is​
FT

​the most stable and secure.​

​3.​ ​Engineering:​ ​In​ ​this​ ​phase,​ ​the​ ​actual​​development​​work​​is​​carried​​out.​​It​​could​

​SO

i​nvolve​​building​​a​​prototype,​​a​​component,​​or​​even​​a​​full​​system​​increment.​​Once​
​the​ ​component​ ​is​ ​developed,​ ​it​ ​is​ ​tested​ ​and​​validated​​against​​the​​objectives​​and​
​user requirements. This ensures any issues are detected early.​
​4.​ E​ valuation:​​The​​final​​phase​​of​​the​​cycle​​involves​​reviewing​​the​​current​​progress​
​with​ ​stakeholders​ ​and​ ​making​ ​decisions​ ​about​ ​the​ ​next​ ​iteration.​ ​Feedback​ ​is​
​collected,​​requirements​​may​​be​​refined,​​and​​the​​next​​cycle​​is​​planned​​based​​on​​the​
​insights gathered. This stage sets the path for the next loop of the spiral.​

​The typical uses of a Spiral Model​

​●​ ​When there is a budget constraint and risk evaluation is important.​
​●​ ​For medium to high-risk projects.​

​Ms. Sthuthi Rai, Lecturer​ ​Department of Computer Science, YIASCM​

 ​SOFTWARE ENGINEERING​

​●​ ​Long-term​ ​project​ ​commitment​ ​because​ ​of​ ​potential​ ​changes​ ​to​ ​economic​
​priorities as the requirements change with time.​
​​ C
● ​ ustomer is not sure of their requirements which is usually the case.​
​●​ ​Requirements are complex and need evaluation to get clarity.​
​●​ ​New​ ​product​ l​ ine​ ​which​ ​should​ ​be​ ​released​ ​in​ ​phases​ ​to​ ​get​ ​enough​ ​customer​
​feedback.​
​●​ ​Significant changes are expected in the product during the development cycle.​

​The advantages of the Spiral Model are as follows:​

​●​ ​Changing requirements can be accommodated.​
​●​ ​Allows extensive use of prototypes.​

​
​●​ ​Requirements can be captured more accurately.​

G
​●​ ​Users see the system early.​

IN
​●​ ​Development​ ​can​ ​be​ ​divided​ ​into​ ​smaller​ ​parts​ ​and​ ​the​ ​risky​ ​parts​ ​can​ ​be​
​developed earlier which helps in better risk management.​

R
​The disadvantages of the Spiral Model are as follows:​
​●​ ​Management is more complex.​

EE
​●​ ​End of the project may not be known early.​
​●​ ​Not suitable for small or low risk projects and could be expensive for small projects.​
​●​ ​Process is complex​ IN
​●​ ​Spiral may go on indefinitely.​
​●​ ​Large number of intermediate stages requires excessive documentation.​
G
EN

​1.12 The Unified Process​

​ he​ ​Unified​ ​Process​ ​is​ ​an​ ​attempt​ ​to​ ​draw​ ​on​ ​the​ ​best​ ​features​ ​and​ ​characteristics​ ​of​
T
RE

​traditional​​software​​process​​models,​​but​​characterize​​them​​in​​a​​way​​that​​implements​​many​​of​
​the​ ​best​ ​principles​ ​of​ ​agile​ ​software​ ​development.​ ​The​ ​Unified​ ​Process​ ​recognizes​ ​the​
​importance​ ​of​ ​customer​ ​communication​ ​and​ ​streamlined​ ​methods​ ​for​ ​describing​ ​the​
​customer’s​ ​view​ ​of​ ​a​ ​system.​ ​It​ ​emphasizes​ ​the​ ​important​ ​role​​of​​software​​architecture​​and​
A

​“helps​ ​the​ ​architect​ ​focus​ ​on​ ​the​ ​right​ ​goals,​ ​such​ ​as​ ​understandability,​ ​reliance​ ​to​ ​future​
W

​changes,​​and​​reuse.​​It​​suggests​​a​​process​​flow​​that​​is​​iterative​​and​​incremental,​​providing​​the​
​evolutionary feel that is essential in modern software development.​
FT
​SO

​Ms. Sthuthi Rai, Lecturer​ ​Department of Computer Science, YIASCM​

 ​SOFTWARE ENGINEERING​

I​ nception:​ ​The​ ​inception​ ​phase​​of​​the​​UP​​encompasses​​both​​customer​​communication​​and​

​planning​ ​activities.​ ​By​ ​collaborating​ ​with​ ​stakeholders,​ ​business​ ​requirements​ ​for​ ​the​
​software​ ​are​ ​identified;​ ​a​ ​rough​ ​architecture​ ​for​ ​the​ ​system​ ​is​ ​proposed;​ ​and​ ​a​ ​plan​ ​for​​the​
​iterative, incremental nature of the ensuing project is developed.​

​ lanning:​ ​Planning​ ​identifies​ ​resources,​ ​assesses​ ​major​ ​risks,​ ​defines​ ​a​ ​schedule,​ ​and​
P
​establishes​ ​a​ ​basis​ ​for​ ​the​ ​phases​ ​that​ ​are​ ​to​ ​be​ ​applied​ ​as​ ​the​ ​software​ ​increment​ ​is​
​developed.​

​ laboration:​ ​The​ ​elaboration​ ​phase​ ​encompasses​ ​the​ ​communication​ ​and​ ​modeling​

E
​activities​ ​of​ ​the​​generic​​process​​model.​​Elaboration​​refines​​and​​expands​​the​​preliminary​​use​

​
​cases​ ​that​ ​were​ ​developed​ ​as​ ​part​ ​of​ ​the​ ​inception​ ​phase​ ​and​ ​expands​ ​the​ ​architectural​

G
​representation​ ​to​ ​include​ ​five​ ​different​ ​views​ ​of​ ​the​ ​software—the​ ​use​ ​case​ ​model,​ ​the​

IN
​requirements​ ​model,​ ​the​ ​design​ ​model,​ ​the​ ​implementation​ ​model,​ ​and​ ​the​ ​deployment​
​model.​​Elaboration​​refines​​and​​expands​​the​​preliminary​​use​​cases​​that​​were​​developed​​as​​part​
​of​ ​the​ ​inception​ ​phase​ ​and​ ​expands​ ​the​ ​architectural​ ​representation​​to​​include​​five​​different​

R
​views​ ​of​ ​the​ ​software—the​ ​use​ ​case​ ​model,​ ​the​ ​requirements​ ​model,​ ​the​ ​design​​model,​​the​
​implementation model, and the deployment model.​

EE
​ onstruction:​ ​The​ ​construction​ ​phase​ ​of​ ​the​ ​UP​ ​is​ ​identical​ ​to​ ​the​ ​construction​ ​activity​
C
​defined​ ​for​ ​the​ ​generic​ ​software​ ​process.​ ​Using​ ​the​ ​architectural​ ​model​ ​as​ ​input,​ ​the​
IN
​construction​ ​phase​ ​develops​ ​or​ ​acquires​ ​the​ ​software​ ​components​ ​that​ ​will​ ​make​ ​each​ ​use​
​case​​operational​​for​​end​​users.​​To​​accomplish​​this,​​requirements​​and​​design​​models​​that​​were​
G
​started​​during​​the​​elaboration​​phase​​are​​completed​​to​​reflect​​the​​final​​version​​of​​the​​software​
​increment.​ ​All​ ​necessary​ ​and​ ​required​​features​​and​​functions​​for​​the​​software​​increment​​are​
EN

​then​ ​implemented​ ​in​ ​source​ ​code.​ ​As​ ​components​ ​are​ ​being​ ​implemented,​ ​unit​ ​tests​ ​are​
​designed​ ​and​ ​executed​ ​for​ ​each.​ ​In​ ​addition,​ ​integration​ ​activities​​are​​conducted.​​Use​​cases​
​are​ ​used​ ​to​ ​derive​ ​a​ ​suite​ ​of​ ​acceptance​ ​tests​ ​that​ ​are​ ​executed​ ​prior​​to​​the​​initiation​​of​​the​
​next unified process phase.​
RE

​ ransition:​ ​The​ ​transition​ ​phase​ ​of​ ​the​ ​UP​ ​encompasses​ ​the​ ​latter​ ​stages​ ​of​ ​the​ ​generic​
T
​construction​​activity​​and​​the​​first​​part​​of​​the​​generic​​deployment​​activity.​​y.​​Software​​is​​given​
A

​to​​end​​users​​for​​beta​​testing​​and​​user​​feedback​​reports​​both​​defects​​and​​necessary​​changes.​​In​
W

​addition,​​the​​software​​team​​creates​​the​​necessary​​support​​information​​that​​is​​required​​for​​the​
​release.​ ​At​ ​the​ ​conclusion​ ​of​ ​the​ ​transition​ ​phase,​​the​​software​​increment​​becomes​​a​​usable​
​software release.​
FT

​ roduction:​ ​The​ ​production​ ​phase​ ​of​ ​the​ ​UP​​coincides​​with​​the​​deployment​​activity​​of​​the​

P
​SO

​generic​​process.​​During​​this​​phase,​​the​​ongoing​​use​​of​​the​​software​​is​​monitored,​​support​​for​
​the​ ​operating​ ​environment​ ​(infrastructure)​ ​is​ ​provided,​ ​and​ ​defect​ ​reports​ ​and​ ​requests​ ​for​
​changes are submitted and evaluated.​

​Reference- Software Engineering A Practitioners Approach (Roger S Pressman) 7th edition​

​Ms. Sthuthi Rai, Lecturer​ ​Department of Computer Science, YIASCM​