Advice to 1968 Software Engineers

Transcription

1 Advice t 1968 Sftware Engineers Sftware Evlutin Prgram Understanding Security - Daniel, Brad, Dave, Gerge

2 Sftware Evlutin Sftware will have t g thrugh cntinual change in rder t adapt with its envirnment and previusly unknwn requirements, n system is ever finished (David) Failure t evlve will lead t system depreciatin ver time, and eventually t bslescence (Gerge) Machines must be able t cmmunicate with each ther in rder t dynamically adjust at runtime (failure f ne machine must nt cause whle system t crash) (Daniel) Organizatins will have huge investments in sftware systems. T maintain the value f these assets, they must be changed and updated ver time (Brad)

3 Prgram Understanding Multiple appraches: tp-dwn - use wn experience and try t cnfirm expectatins Bttm-up - iteratively abstract high-level understanding by reading cde, Opprtunistic - mix f bth strategies (Brad) Much mechnical and electrical engineering, diagrams must be used t shw sftware systems. Cde in backgrund, much like equatins (Daniel) There will be prgrams available fr yu t help analyse, dcument, and imprve previusly cnfusing cde. (Gerge) There will be a heavy emphasis n dcumentatin t aid with prgram understanding, ie: DON'T FORGET TO COMMENT YOUR CODE. (David)

4 Security Sftware engineers must spend 10% r mre f develpment time slely fcused n security t always stay ne step ahead f an attacks. (Daniel) Dependence n infrmatin technlgy makes sftware assurance a key element f business cntinuity, natinal security, and hmeland security (Brad) Peple will cntinually find and explit vulnerabilities in sftware systems as a lt f mney can be made in ding s. (David) One f the cmmnly used methds fr imprving sftware security is ethical hacking, where sftware engineers will purpsely try and find vulnerabilities s they can be fixed befre they are fund by malicius hackers. (Gerge)

5 Advice t Pineers Nichlas Guillemt, Vishwendra Gahlt, Richard McKenzie, Marcel Gmes

6 Nichlas Guillemt, Vishwendra Gahlt, Richard McKenzie, Marcel Gmes Sftware Evlutin Cde Written nw likely still used in 20 years Create a dcumentatin standard and prmte acrss industry Dcument fr future peple wrking n prject, nt just using it Keep Surce + Dcumentatin + Update

7 Sftware Engineering Educatin Practical Experience Case Studies f past failures & successes Encurage Industry Prfessinals teaching / guest lecturing mre ften Nichlas Guillemt, Vishwendra Gahlt, Richard McKenzie, Marcel Gmes

8 Nichlas Guillemt, Vishwendra Gahlt, Richard McKenzie, Marcel Gmes Open Surce Sftware Make Sftware public & allw cllabratin Wrking tgether fr betterment f industry Lwers entry barrier t industry Use pen surce license, alng with paid supprt, t still make mney but have mre accessible prduct

9 SENG 371 Dear Histry Justin, Adam, Geff, Sctt

10 Sftware Evlutin Sftware maintenance will grw t cnsume 40-60% f the sftware develpment cycle Strive t evlve sftware rather than create legacy systems with an finite life span. Sftware develpment will mve twards a decentralized system The days f mainframes are ver. Evlving systems must be cmpnentized.

11 Sftware Engineering Educatin Maintainability is extremely imprtant N prduct can be cnsidered cmpletely finished Antipatterns can be recgnized Lk fr cmmn slutins t prblems that dn't actually wrk Prmte cntinued learning Sftware changes quickly, current skills will be less applicable in 10 years. Axe the waterfall mdel N prject can perfectly fllw the waterfall mdel Yu will almst never define all requirements

12 Sftware Engineering Educatin (Cntinued) Reverse Engineering shuld be taught in schls Sftware engineers will ften have t wrk with undcumented legacy systems. Reverse engineering is a key cmpnent f prgram understanding. Reverse engineering cncepts shuld be taught t encurage the develpment f widely adpted and autmated RE tls.

13 Agile Develpment Static develpment methdlgies dn't wrk Requirements cannt all be knwn befre develpment begins Often requirements will change during develpment Clients like t see prttype sftware ver dcuments Initial system design may nt wrk. Instead develp in cycles Fcus n creating wrking sftware ver any dcumentatin. Wrk with the client instead f creating a cntract. Be pen t change instead f fllwing a plan.

14 Sftware Evlutin Ian Brwn Kai Fuglem Rb Hle Saleh Almuqbil Sftware effrts and csts will eventually be spent mstly in maintenance and evlutin phase Systems shuld be designed t be adaptable, maintainable and scalable. Systems will eventually require cnstant develpment and adjustment Start wrk early n making sftware evlutin mre cst and time effective

15 Sftware Architecture Ian Brwn Kai Fuglem Rb Hle Saleh Almuqbil Design fr expanding scale Scale f systems will grw expnentially Design systems with that in mind Imprtance f strng/stable architecture grws with the systems size Try t make designs functinally independent and able t wrk tgether Must find a way t encapsulate similar functinality r else maintainability f large systems becmes impssible

16 Interfaces Ian Brwn Kai Fuglem Rb Hle Saleh Almuqbil Develp standards early Investigate clear standards fr bth human cmputer interactin and cmputer-cmputer interactin Cnnectrs are imprtant Spend lts f time making cmputers wrk tgether Systems shuld abstract away functinality nt needed by the 'user'

17 Sftware Evlutin Aim t create systems that are easy t maintain and evlve Up t 90% f the sftware develpment is nw being used fr maintenance nw-a-days (in the future!). Make use f existing libraries when pssible Less in-huse surce cde t manage/maintain and saves yu frm reinventing the already existing wheel. Try t fllw the DRY and SOLID Principles in OO Design/Implementatin This will greatly increase the maintainability f yur applicatin/system Mikk, Allen, Curtis and Paul

18 Sftware Architecture A cherent architecture is key t any sftware system (design, design design) Withut it yu may incur additinal maintenance r refactring csts Make use f existing design patterns and watch fr the develpment f anti-patterns Design patterns prvide a framewrk t launch frm and are ften mre maintainable Be cnsistent in yur design at each level/layer f an applicatin and prefer cmpsitin t inheritance. Mikk, Allen, Curtis and Paul

19 Cntinuus Learning It is imprtant t remain up-t-date n emerging technlgies and cncepts Research is always being dne t slve existing prblems in sftware and develpment systems/methds f cnquering prblems Yu are nly wrth as much as yu knw The mre yu knw the better! S learn ALL OF IT! I knw yu guys are at the beginning f the 'internet' (arpanet), but when it ges public, adpt it and share yur knwledge with the wrld. It'll be like 1982, if histry repeats itself Mikk, Allen, Curtis and Paul

20 Slide 3 1 arpanet the precursr f the internet was built in 1968 Curtis St. Pierre, 1 Why yu n fix it then Paul Hunter, 2 I n knw what yu want Curtis St. Pierre, 1 idunn eitherr maybe n cursing? haha Mikk Sanchez,

21 What Advice Wuld We Give? T the 1968 NATO cnference in Garmisch Germany

22 Sftware Evlutin Standards Agile develpment methdlgies Reverse Engineering

23 Sftware Architecture Mdularity f sftware cmpnents Levels f abstractin Separatin f cncerns

24 Cpyright Hw d yu cpyright sftware? Can yu cpyright an API? Hw d yu patent a sftware user interface? Hw can sftware cmpanies prtect their assets?

25 Sftware Educatin K - 12 Educatin needs t be implemented Undergraduate Educatin effectiveness needs imprvement Undergraduate Educatin needs t fcus n industry needs Jeremy, Wes, Anita

26 Sftware Architecture Allws early analysis f a system Crucial design decisins are made early n Gives stakehlders an idea f what they will see Reduces verall csts Jeremy, Wes, Anita

27 Sftware Tls Invest in a gd interface. Sftware tls will have mre users in the future and the key t adptin is an interface that is easy t use. Fcus n simplicity, flexibility and extensibility. A successful tl des its jb well and can easily be integrated int cmmnly used platfrms and envirnments. Extensive evaluatin Jeremy, Wes, Anita

28 SENG 371 Dear Histry Justin, Adam, Geff, Sctt

29 Sftware Evlutin Sftware maintenance will grw t cnsume 40-60% f the sftware develpment cycle Strive t evlve sftware rather than create legacy systems with an finite life span. Sftware develpment will mve twards a decentralized system The days f mainframes are ver. Evlving systems must be cmpnentized.

30 Sftware Engineering Educatin Maintainability is extremely imprtant N prduct can be cnsidered cmpletely finished Antipatterns can be recgnized Lk fr cmmn slutins t prblems that dn't actually wrk Prmte cntinued learning Sftware changes quickly, current skills will be less applicable in 10 years. Axe the waterfall mdel N prject can perfectly fllw the waterfall mdel Yu will almst never define all requirements

31 Sftware Engineering Educatin (Cntinued) Reverse Engineering shuld be taught in schls Sftware engineers will ften have t wrk with undcumented legacy systems. Reverse engineering is a key cmpnent f prgram understanding. Reverse engineering cncepts shuld be taught t encurage the develpment f widely adpted and autmated RE tls.

32 Agile Develpment Static develpment methdlgies dn't wrk Requirements cannt all be knwn befre develpment begins Often requirements will change during develpment Clients like t see prttype sftware ver dcuments Initial system design may nt wrk. Instead develp in cycles Fcus n creating wrking sftware ver any dcumentatin.