Engineering I

7/21/2019 Engineering I

1/84

06/30/09 Mzuzu university 1

SoftwareEngineering

SoftwareEngineering

Introduction


2/84


Topics

Understanding software

Issues in software industry

Software engineering conceptsEthics in software engineering


3/84


software

Software is a combination of

computer program

data

documentation(system,user)

Types of software

Generic

Custom

Embedded


4/84


Categories ofSoftware

By dee!opment

Generic

Custom

Embedded

"rocessing focus#ata processing$Transforming,arranging and storingdata

%ea! Time "rocessing$Contro! processes&deices inrea! time


5/84


Issues in software

System Software

'pp!ication software

Embedded software

"roduct ine Software

eb 'pp!ications

'rtificia! Inte!!igence

Scientific software

*et Sourcing

+pen source

Ubiuitous computing


6/84


7/84


Software Crisis

Symptoms

Unmanageab!e

+er budget

ate"oor ua!ity


8/84


Software Engineering

'dances in hardware capabi!ity hae enab!ed increasing!ycomp!e- software/ +ur abi!ity to inte!!ectua!!y manage thiscomp!e-ity has a!ways !agged the adances in softwarecomp!e-ity/

Software engineers continua!!y reuire better too!s/C'SE (Computer 'ssisted Software Engineering) too!s/

Inte!!ectua! too!s $$ Software engineering techniues/


9/84


#efinition

The estab!ishment and use of soundengineeringprincip!esin order to obtain economica!!ysoftware thatis re!iab!eand wor.s efficient!yon rea! machines/ (0rit1Bauer, at the 0irst *'T+ Conference on Software

Engineering, 2343)engineering princip!es $ it is a discip!ined effort

economica!!y /// re!iab!e //// efficient!y /// it has bui!t inua!ity

rea! machines 5 so!es a user prob!em


10/84


S+0T'%E E*GI*EE%I*G IS ///

engineering princip!es

It is a discip!ined effort that6systematica!!y uses methodo!ogies, techniues and too!s, and astore of re!eant .now!edge, architectures and components

uses a modu!ar approach to system bui!ding

app!ies appropriate pro7ect management techniues

economica!!y///re!iab!e///efficient!y

It has bui!t$in ua!ity that6

8eets cost, time and other constraints5 has meaningfu! ua!ityassurance (e/g/, standards

does forma! testing of modu!es and the system as a who!e

rea! machines

It so!es a rea! user prob!em (imp!ied), therefore6

dee!opment is focused on meeting user reuirements


11/84


Goa!s of software Engineering

8aintainabi!ity 5 the abi!ity to easi!y ma.e changes, enhancements, orimproements/

#ependabi!ity 5 the abi!ity to re!y on the software to function proper!ywhen needed/

Efficiency 5 the abi!ity for software to use computing resourceseffectie!y (main!y space and time)/

Usabi!ity 5 the abi!ity for the end user to easi!y and effectie!y put thesoftware to proper use/


12/84


"rincip!es of software engineering

8odu!arity 5 diide and conuer/

Encapsu!ation 5 hide the imp!ementation/

oca!i1ation 5 co!!ect simi!ar things together/

'bstraction 5 proide an i!!usion/

Uniformity 5 ma.e eerything !oo. simi!ar/

Comp!eteness 5 do eerything reuired/

Confirm abi!ity 5 be ab!e to proe that the softwarewor.s proper!y/


13/84


Software Engineering Ethics

"rincip!es

"ub!ic

S&w engineers sha!! act consistent!y with the pub!icinterest/

C!ient and emp!oyer

S& engineers sha!! act in a manner that is in the bestinterests of their c!ient and emp!oyer and that isconsistent with the pub!ic interest/

"roduct

s&w engineers sha!! ensure that their products andre!ated modifications meet the highest professiona!standards possib!e/


14/84



"rincip!es9udgement

S& engineer sha!! maintain integrity andindependence in their professiona! 7udgement

8anagement

S& engineer managers and !eaders sha!! subscribe toand promote an ethica! approach to the managementof s&w dee!opment and maintenance/

"rofession

S& engineers sha!! adance the integrity andreputation consistent with the pub!ic interest/


15/84



"rincip!e

Co!!eagues

S&w engineers sha!! be fair to and supportie

of their co!!eague/

Se!f

S& engineers sha!! participate in !ife!ong!earning regarding the practice of the

profession and promote an ethica! approachto the practice of the profession/


16/84


Summary

Software engineering ino!es mode!!ing anddocumenting system reuirements and so!utions/


17/84


Software EngineeringSoftware Engineering

Software ProcessSoftwareProcess


18/84


Software "rocess

+b7ecties

Understanding software process

'ctiities present in eery softwareprocess

"rocess mode!s, and their strengths andwea.nesses


19/84


"rocess 8ode!

' software process mode! is anabstract representation of thedee!opment process/

Consists of a structured set of actiitiesreuired to bui!d software/

It presents a description of a process

from a particu!ar perspectie/


20/84


Types of 8ode!s

#escriptie

#escribes the history of how a particu!arsystem was dee!oped/

Used as a basis for understanding andimproing s&w process/

Used for bui!ding prescriptie mode!s/


21/84


"rescriptie 8ode!

"rescribes how software shou!d bedee!oped/

Used as guide!ines to organi1e and

structure how s&w actiities shou!d beperformed, and in what order/


22/84


Generic Software 8ode!sThe waterfa!! 8ode!

Separate and distinct phases of specification anddee!opment/

Eo!utionary dee!opment

Specification, dee!opment and a!idation are

inter!eaed/

Specia!ised 8ode!s

Component based software EngineeringThe system is assemb!ed from e-isting components/

'gi!e 8ode!s

Emphasises on customer co!!aboration, incrementa!de!iery, sma!! dee!opment teams/


23/84


Bui!d and 0i-

Bui!d systems without specification/

Bui!d first ersion and repeat maintenanceunti! customer is satisfied/

'd#oes not waste time in p!anning anddocumentation/

#is

Underestimation of pro7ect attributes/


24/84


aterfa!! 8ode!

'!so ca!!ed C!assic ifecyc!e/

%euirements we!!defined(fi-ed) and stab!e/

"hases%euirements Engineering

software design

Imp!ementation and unit testing

Integration and system testing

8aintenance

RequirementsEngineering

Maintenance

Im!ementati"n an# $nit%esting

&"'t(are)esign

Integrati"n an# system testing


25/84


#rawbac.s

%ea! pro7ects are iteratie/#ifficu!t for customer to state a!!reuirements e-p!icit!y/

%euires customer patience/B!oc.ing state/


26/84


#rawbac.s

Inf!e-ib!e partitioning of the pro7ect into distinct stagema.es it difficu!t to respond to changing customerreuirements/

Therefore, this mode! is on!y appropriate when the

reuirements are we!!$understood and changes wi!! befair!y !imited during the design process/

0ew business systems hae stab!e reuirements/

The waterfa!! mode! is most!y used for !arge systems

engineering pro7ects/


27/84


Eo!utionary "rocess 8ode!sIteratie

"rototyping

Throw away prototyping or e-p!oratory

+b7ectie is to understand the system reuirements/

Shou!d start with poor!y understood reuirements to c!arifywhat is rea!!y needed/

Eo!utionary prototype

+b7ectie is to wor. with customers and to eo!e a fina!system from an initia! out!ine specification/ Shou!d start

with we!!$understood reuirements and add new featuresas proposed by the customer/


28/84


"rototyping

Customer defines a genera! ob7ectie of the software withoutidentifying detai!s/

0eedbac. from prototypes is used to refine reuirements forthe software/

Iteration is used to tune prototypes to satisfy customer needs,whi!e enab!ing the dee!oper to better understand what needsto be done/

Used with systems with a considerab!e emphasis on userinterface and user interaction/

Users and designers must be we!! aware of the prototypingapproach and its pitfa!!s/

shou!d be p!anned and contro!!ed/


29/84


*r"t"tying

&eci'icati"n

+a!i#ati"n

Interme#iate+ersi"n

,ut!ine#escriti"n

)eve!"ment

-ina! versi"n

Initia! +ersi"n


30/84


"rototypes'dantages

The resu!ting system is easy to use and maintain/

User needs are better accommodated

The design is of higher ua!ity

The dee!opment incurs !ess effort/

"rob!ems are detected ear!ier

#isadantages

The resu!ting system harder to maintain/

The performance of the resu!ting system is worse/

The design is of !ess ua!ity

The dee!opment incurs more effort/

The approach reuires more e-perienced team members


31/84


Spira! 8ode!

"roposed be Boehm (B+E::)/

Eo!utionary mode! with iteratie nature of prototyping and systematicaspects of waterfa!! mode!/

"rocess is represented as a spira! rather than as a seuence ofactiities with bac.trac.ing/

Each !oop in the spira! represents a phase in the process/

*o fi-ed phases such as specification or design $ !oops in the spira!are chosen depending on what is reuired/

%is.s are e-p!icit!y assessed and reso!ed throughout the process/


32/84


8ode! sectors

+b7ectie setting

Specific ob7ecties for the phase are identified/

%is. assessment and reduction

%is.s are assessed and actiities put in p!ace to

reduce the .ey ris.s/ #ee!opment and a!idation

' dee!opment mode! for the system is chosenwhich can be any of the generic mode!s/

"!anningThe pro7ect is reiewed and the ne-t phase of thespira! is p!anned/


33/84


&ira! M"#e!


34/84


Incrementa! "rocess 8ode!

Combines e!ements of waterfa!! mode! app!ied in iteratie

fashion/

Each !inear seuence produce de!ierab!e increments ofthe software/

The first increment ca!!ed the core product addresses

basic reuirements/

#e!iers a wor.ing product with each increment/


35/84


+a!i#ate&ystem

)e'ine "ut!ine&eci'icati"n

IntegrateIncrement

+a!i#ateincrement

)eve!"systemincrement

)esign &ystem.rcitecture

.ssignrequirementst"increments

&ystem Inc"m!ete


36/84


The %apid 'pp!ication #ee!opment (%'#)8ode!

Incrementa! mode! that emphasi1es on shortdee!opment !ife cyc!e/

;igh speed waterfa!! using component basedconstruction/

It emphasi1es user ino!ement, prototyping, reuse, theuse of automated too!s and sma!! dee!opment teams/

Emp!oys time bo-, a fi-ed time frame within whichactiities are done/


37/84


%'# 8ode!

ife cyc!e actiities

%euirements p!anning

User design

ConstructionCut oer

Use 9oint reuirements p!anning and 9oint app!ication #esign

9oint reuirements p!anning wor.shops

to get reuirements

9oint app!ication #esign wor.shops

To bui!d the initia! design of the system


38/84


%'# 8ode!

#isadantages

%euires sufficient human resources

%euires dedication

System need to be proper!y modu!arised*ot for high performance systems

Shou!d not be used when technica! ris.s are high/


39/84


Component based #ee!opment

Based on systematic reuse where systems areintegrated from e-isting components or C+TS(Commercia!$off$the$she!f) components/

"rocess stages

%euirements Engineering

System design with reuse

Component ana!ysis&


40/84


0orma! 8ode!

The approach fo!!ows the waterfa!! mode!but use forma! !anguage to engineer thesoftware/

%euirements Engineering/

0orma! Specification 5 %euirements arespecified mathematica!!y/

0orma! Transformation 5 The reuirementsare refined unti! conerted to a rea!program/


41/84


SoftwareEngineeringSoftware

Engineering

ProcessActivities


42/84


Software "rocess

' set of actiities whose goa! is thedee!opment or eo!ution of software/

Software Specification$what the systemshou!d do and constraints/

Software design and Imp!ementation$production of the software/

Software =a!idation$Chec.ing if what thecustomer needs/

Software Eo!ution$Changing the s&w inresponse to changing demands/


43/84


Software Specification

"rocess of estab!ishing what serices are reuired and

the constraints on the systems operation anddee!opment/

%euirements Engineering

0easibi!ity study>

%euirements e!icitation and ana!ysis>%euirements documentation>

%euirements a!idation/


44/84


-easii!ity &tu#y

Requirements+a!i#ati"n

Requirements&eci'icati"n

RequirementsE!icitati"n an#

.na!ysis

-easii!ityRe"rt

Requirements)"cument

$ser an# Requirements&eci'icati"n

&ystem M"#e!s

&"'t(are Engineering


45/84


Software #esign and Imp!ementation

The process of conerting the systemspecification into an e-ecutab!e system/

Software design

#esign a software structure that rea!ises the

specification>Imp!ementation

Trans!ate this structure into an e-ecutab!eprogram>

The actiities of design and imp!ementationare c!ose!y re!ated and may be inter$!eaed/


46/84


Software #esign 'ctiities

'rchitectura! design 'bstract specification

Interface design

Component design

#ata structure design

'!gorithm design


47/84


.rcitectura!)esign

.!g"ritm)esign

Inter'ace)esign

)ata

structure)esign

"m"nent)esign

.stract)esign

Requirements&eci'icati"n

.!g"ritm&eci'icati"n

Inter'aceseci'icati"n

)ata&tructure

&eci'icati"n"m"nentseci'icati"n

.stract&eci'icati"n

.rcitectura!seci'icati"n

&"'t(are )esign .ctivities


48/84


"rogramming

Trans!ating a design into a program andremoing errors from that program/

"rogramming is a persona! actiity $ thereis no generic programming process/

"rogrammers carry out some programtesting to discoer fau!ts in the programand remoe these fau!ts in the debugging

process/


49/84


Software =a!idation

=erification and a!idation (= ? =) isintended to show that a system conforms toits specification and meets the reuirementsof the system customer/

Ino!es chec.ing and reiew processes andsystem testing/

System testing ino!es e-ecuting thesystem with test cases that are deried from

the specification of the rea! data to beprocessed by the system/


50/84


Testing Stages

Component or unit testingIndiidua! components are tested independent!y>Components which may be functions or ob7ectsor coherent groupings of these entities/

System testingTesting of the system as a who!e/ Testing ofemergent properties is particu!ar!y important/

'cceptance testing

Testing with customer data to chec. that thesystem meets the customer@s needs/


51/84


Software Eo!ution

Software is f!e-ib!e and can change/

's reuirements change throughchanging business circumstances,

the software that support thebusiness must change/


52/84


&"'t(are Ev"!uti"n

)e'ine &ystemRequirements

M"#i'y &ystem*r""se &ystem

anges.ssess

Eisting &ystem

Eisting &ystem e( &ystem


53/84

06/30/09 53

'gi!e Software "rocesses


54/84

06/30/09 54

Agile Software Development

an a!ternatie to conentiona! software engineering

for certain c!asses of software and certain types of

software pro7ects

de!ier successfu! systems uic.!y

Encourages continuous communication and

co!!aboration among dee!opers and customers


55/84

06/30/09 55

'gi!e Software #ee!opment

'gi!e software engineering embraces a phi!osophy

that encourages customer satisfaction, incrementa!

software de!iery, sma!! pro7ect teams (composed of

software engineers and sta.eho!ders), informa!methods, and minima! software engineering wor.

products

'gi!e software engineering dee!opment guide!ines

stress on$time de!iery of an operationa! softwareincrement oer ana!ysis and design


56/84

06/30/09 56

The agi!e #ee!opment 8anifesto

The four core a!ues6

Indiidua!s and interactions oer processes

and too!sor.ing software oer comprehensie

documentation

Customer co!!aboration oer contract

negotiation

%esponding to change oer fo!!owing a p!an


57/84

06/30/09 57

hat is agi!ity

Agility is dynamic, content specific, aggressively changeembracing and growth oriented [Steven Goldman et al]

'n agi!e team is ab!e to respond to changesduring pro7ect dee!opment

'gi!e dee!opment recogni1es that pro7ect p!ansmust be f!e-ib!e

'gi!ity encourages team structures and attitudesthat ma.e communication among dee!opers and

customers more faci!eE!iminates the separation between customers anddee!opers


58/84

06/30/09 58

hat is agi!ityA

'gi!ity emphasi1es the importance of rapid

de!iery of operationa! software and de$

emphasi1es importance of intermediate wor.products

'gi!ity can be app!ied to any software process

as !ong as the pro7ect team is a!!owed to

stream!ine tas.s and conduct p!anning in waythat e!iminate non$essentia! wor. products


59/84

06/30/09 59

'gi!ity "rincip!es $ 2;ighest priority is to satisfy customer through ear!y

and continuous de!iery of a!uab!e software

e!come changing reuirements een !ate in

dee!opment, accommodating change is iewed as

increasing the customer@s competitie adantage

#e!iering wor.ing software freuent!y with a

preference for shorter de!iery schedu!es (e/g/ eery

or wee.s)

Business peop!e and dee!opers must wor. together

dai!y during the pro7ect


60/84

06/30/09 60

'gi!ity "rincip!es $

Bui!d pro7ects around motiated indiidua!s, gien

them the enironment and support they need, trust

them to get the 7ob done

0ace$to$face communication is the most effectiemethod of coneying information within the

dee!opment team

or.ing software is the primary measure of progress

'gi!e processes support sustainab!e dee!opment,dee!opers and customers shou!d be ab!e to continue

dee!opment indefinite!y


61/84

06/30/09 61

'gi!e "rocess

Based on three .ey assumptions

2/ It is difficu!t to predict in adance which

reuirements or customer priorities wi!! change

and which wi!! not

/ 0or many types of software design and

construction actiities are inter!eaed

(construction is used to proe the design)

/ 'na!ysis, design, construction and testing are not

as predictab!e from a p!anning perspectie as

one might !i.e them to be


62/84

06/30/09 62

'gi!e "rocess

'gi!e processes must be adapted

incrementa!!y to manage

unpredictabi!ityIncrementa! adaptation reuires

customer feedbac. based on ea!uation

of de!iered software increments(e-ecutab!e prototypes) oer short time

periods


63/84

06/30/09 63

'gi!ity "rincip!es $ Continuous attention to technica! e-ce!!enceand good design enhances agi!ity

Simp!icity (defined as ma-imi1ing the wor.not done) is essentia!

The best architectures, reuirements, anddesign emerge from se!f$organi1ing teams

't regu!ar intera!s teams ref!ects how to

become more effectie and ad7usts itsbehaiour according!y


64/84

06/30/09 64

Traits of 'gi!e Team 8embers

Competence

Common focus

Co!!aboration

#ecision$ma.ing abi!ity

0u11y$prob!em so!ing abi!ity

8utua! trust and respect

Se!f$organi1ation


65/84

06/30/09 65

'gi!e "rocess 8ode!s

E-treme "rogramming (D")

'daptie Software #ee!opment ('S#)

#ynamic Systems #ee!opment 8ethod(#S#8)

Scrum

0eature #rien #ee!opment (0##)

'gi!e 8ode!ing ('8)


66/84

06/30/09 66

E-treme 'ctiities

0ramewor. actiities

"!anning

user stories created and ordered by customer a!ue

#esign

simp!e ++ designs preferred

#ifficu!t design prob!em is so!ed using spi.e so!ution/

C%C cards and design prototypes are on!y wor. products

encourages use of refactoring

Codingemphasi1es use of pairs programming to create story

code

continuous integration and smo.e testing is uti!i1ed


67/84

06/30/09 67

D" 'ctiities

Testing

focuses on unit tests to e-ercise stories

unit tests created before coding are imp!ementedusing an automated testing framewor. to

encourage use of regression testing

integration and a!idation testing done on dai!y

basis

acceptance tests focus on system features and

functions iewab!e by the customer


68/84

06/30/09 68

D" "rocess

%est

*!anning

)esign

"#ing

$ser st"riesva!ues.ccetance test criteriaiterati"n !an

&im!e #esignR ar#s

*air r"gramming

$nit testing"ntinu"us integrati"n

.ccetance test

&"'t(areincrement+e!"cityc"mute#

Release

Re'act"ring


69/84

06/30/09 69

'daptie Software #ee!opment

0eatures

Se!f$organi1ation arises when independentagents cooperate to create a so!ution to aprob!em that is beyond the capabi!ity of any

indiidua! agent'daptie cyc!e characteristics

8ission$drien

Component$based

Iteratie

Time$bo-ed

%is. drien and change$to!erant


70/84

06/30/09 70

'daptie Software #ee!opment $ 2

Specu!ation

pro7ect initiated

ris. drien adaptie cyc!e p!anning ta.es p!ace

Co!!aboration

reuires teamwor. from a 7e!!ed team

7oint app!ication dee!opment is preferred

reuirements gathering approachminispecs created


71/84

06/30/09 71

'daptie Software #ee!opment $

earning

components imp!emented and tested

focus groups proide feedbac.forma! technica! reiews

postmortems

#ynamic Systems #ee!opment


72/84

06/30/09 72

#ynamic Systems #ee!opment

8ethod

"roides a framewor. for bui!ding and maintaining

systems which meet tight time constraints using

incrementa! prototyping in a contro!!ed enironment

Uses "areto princip!e (:F of pro7ect can bede!iered in F reuired to de!ier the entire pro7ect)

Each increment on!y de!iers enough functiona!ity to

moe to the ne-t increment

Uses time bo-es to fi- time and resources todetermine how much functiona!ity wi!! be de!iered in

each increment

#ynamic Systems #ee!opment 8ethod ife


73/84

06/30/09 73

#ynamic Systems #ee!opment 8ethod ife

Cyc!e $ 2

0easibi!ity study

estab!ishes reuirements and constraints

Business studyestab!ishes functiona! and information

reuirements needed to proide business a!ue

0unctiona! mode! iteration

produces set of incrementa! prototypes todemonstrate functiona!ity to customer

D i S t D l t M th d Lif


74/84

06/30/09 74

Dynamic Systems Development Method Life

Cycle !

#esign and bui!d iteration

reisits prototypes to ensure they proide

business a!ue for end usersmay occur concurrent!y with functiona!

mode! iteration

Imp!ementation!atest iteration p!aced in operationa!

enironment


75/84

06/30/09 75

Scrum "rincip!es

Sma!! wor.ing teams used to ma-imi1ecommunication and minimi1e oerhead

"rocess must be adaptab!e to both technica! and

business cha!!enges to ensure best product produced"rocess yie!ds freuent increments that can beinspected, ad7usted, tested, documented and bui!t on

#ee!opment wor. and peop!e performing it arepartitioned into c!ean, !ow coup!ing partitions

Testing and documentation is performed as theproduct is bui!t

'bi!ity to dec!are the product done wheneer reuired


76/84

06/30/09 76

Scrum $ 2

Bac.!og

prioriti1ed !ist of reuirements or features that

proide business a!ue to customer

items can be added at any time

Sprints

wor. units reuired to achiee one of the bac.!og

itemsmust fit into a predefined time$bo-( days)

affected bac.!og item are fro1en/


77/84

06/30/09 77

Scrum $

Scrum meetings

2 minute dai!y meetings

what was done since !ast meetingAwhat obstac!es were encounteredA

what wi!! be done by the ne-t meetingA

#emos

de!ier software increment to customer forea!uation


78/84

06/30/09 78


79/84

06/30/09 79

0eature #rien "hi!osophy

Emphasi1es co!!aboration among team members

8anages prob!em and pro7ect comp!e-ity using

feature$based decomposition fo!!owed by integration

of software increments

Technica! communication using erba!, graphica!, and

te-tua! means

Software ua!ity encouraged by using incrementa!

dee!opment, design and code inspections, S


80/84

06/30/09 80

0eature #rien #esign $ 2

#ee!op oera!! mode!

contains set of c!asses depicting business mode! of

app!ication to be bui!t

Bui!d features !istfeatures e-tracted from domain mode!

features are categori1ed and prioriti1ed

wor. is bro.en up into two wee. chun.s

"!an by featurefeatures assessed based on priority, effort, technica! issues,

schedu!e dependencies


81/84

06/30/09 81

0eature #rien #esign $

#esign by feature

c!asses re!eant to feature are chosen

c!ass and method pro!ogs are written

pre!iminary design detai! dee!opedowner assigned to each c!ass

owner responsib!e for maintaining design document for his

or her own wor. pac.ages

Bui!d by featurec!ass owner trans!ates design into source code and performsunit testing

integration performed by chief programmer


82/84

06/30/09 82

0## "rocess


83/84

06/30/09 83

'gi!e 8ode!ing $ 2

"ractice$based methodo!ogy for effectie mode!ing

and documentation of software systems in a !ight$

weight manner

8ode!ing princip!es8ode! with a purpose

Use mu!tip!e mode!s

Trae! !ight (on!y .eep mode!s with !ong$term a!ue)

Content is more important than representationHnow the mode!s and too!s you use to create them

'dapt !oca!!y


84/84

'gi!e 8ode!ing $

%euirements gathering and ana!ysis mode!ing

or. co!!aboratie!y to find out what customer wants to do

+nce reuirements mode! is bui!t co!!aboratie ana!ysis

mode!ing continues with the customer

'rchitectura! mode!ing

#eries pre!iminary architecture from ana!ysis mode!

'rchitectura! mode! must be rea!istic for the enironment and

must be understandab!e by dee!opers

Engineering I

Documents

Transcript of Engineering I