So#ware  as  an  Engineering  Discipline  

So#ware  engineering  

•  The  economies  of  ALL  developed  na;ons  are    dependent  on  so#ware  

•  More  and  more  systems  are  so#ware  controlled  •  So#ware  engineering  is  concerned  with  theories,  methods  and  tools  for  professional  so#ware  development  

•  So#ware  engineering  expenditure  represents  a  significant  frac;on  of  GNP  in  all  developed  countries  

What  is  the  difference  between  so#ware  engineering  and  computer  science?  

•  Computer  science  is  concerned  with  theory  and  fundamentals;  so#ware  engineering  is  concerned  with  the  prac;cali;es  of  developing  and  delivering  useful  so#ware  

•  Computer  science  theories  are  currently  insufficient  to  act  as  a  complete  underpinning  for  so#ware  engineering  

What  is  the  difference  between  so#ware  engineering  and  system  engineering?  

•  System  engineering  is  concerned  with  all  aspects  of  computer-­‐based  systems  development  including  hardware,  so#ware  and  process  engineering.  So#ware  engineering  is  part  of  this  process  

•  System  engineers  are  involved  in  system  specifica;on,  architectural  design,  integra;on  and  deployment  

Programming  vs.  Engineering    

Programming Engineering

Small project You Build what you want One product Few sequential changes Short-lived Cheap Small consequences

Huge project Teams

Build what they want Family of products

Many parallel changes Long-lived

Costly Large consequences

These courseware materials courtesy of Andre van der Hoeke, Copyright ©2001, André van der Hoek

From  Programming  to  Engineering  •  People  – Who  else  would  do  the  work?  –  Range  from  novice  to  very  experienced  

•  Processes  –  To  organize  and  manage  the  efforts  of  individuals  –  Range  from  informal  to  very  formal  – Deal  with  all  aspects  of  producing  so#ware,  not  just  coding  

•  Tools  –  To  support  the  people  and  the  processes  –  Range  from  simple  to  very  advanced  

People + Processes + Tools a Product

These courseware materials courtesy of Andre van der Hoeke, Copyright ©2001, André van der Hoek

People,  Processes,  Tools,  Products  

•  Products  are  always  the  eventual  goal  –  Selling  products  creates  revenue  –  Selling  good  products  creates  lots  of  revenue  –  Selling  bad  products  creates  liTle  revenue  

•  People,  processes,  and  tools  are  retained  by  an  organiza;on  –  Build  a  reputa;on  through  the  quality  of  products  –  Create  organiza;onal  culture  –  Important  to  keep  the  team  intact  

These courseware materials courtesy of Andre van der Hoeke, Copyright ©2001, André van der Hoek

People + Processes + Tools a Product

People  •  The  single  most  important  factor  in  the  success/failure  of  

a  product  •  Scarce  resource  

–  Quality  –  Suitability  –  Cost  

•  Many  different  kinds  of  people  –  Managers  –  Programmers  –  Technical  writers  –  Requirements  Analysts  –  Quality  Assurance  Engineers  

These courseware materials courtesy of Andre van der Hoeke, Copyright ©2001, André van der Hoek

Process  •  Ins;tute  processes  through  which  so#ware  is  engineered  –  Cover  all  steps  from  ini;al  idea  and  requirements  to  delivery,  maintenance,  and  final  re;rement  

– Make  sure  we  do  the  right  things/things  right  – Make  sure  we  do  not  forget  to  do  anything  – Different  processes  for  different  kinds  of  so#ware  

•  Not  a  silver  bullet  [Brooks  “No  Silver  Bullet”]  –  So#ware  is  s;ll  intrinsically  difficult  to  deal  with  –  Processes  help,  but  cannot  guarantee  anything  

These courseware materials courtesy of Andre van der Hoeke, Copyright ©2001, André van der Hoek

People + Processes + Tools a Product

Tools  

•  Needed  to  support  people  and  processes  •  Scarce  resource  –  Quality  –  Suitability  –  Cost  

•  Many  different  kinds  of  tools  –  Visual  Modeling  –  Analysis  –  Project  management  &  Cost  Es;ma;on  –  Source  code  management  

These courseware materials courtesy of Andre van der Hoeke, Copyright ©2001, André van der Hoek

Product  •  The  so#ware  should  deliver  the  required  func;onality  and  

performance  to  the  user  in  a  cost-­‐effec;ve  manner  

•  The  “-­‐ili)es”  of  So/ware  Engineering:  •  Availability  

–  So#ware  should  be  reliable  –  not  break  down  •  Maintainability  

–  So#ware  must  evolve  to  meet  changing  needs  •  Scalability  

–  So#ware  should  “gracefully  degrade”  under  heavy  loads  •  Dependability  

–  So#ware  must  be  trustworthy  •  Efficiency  

–  So#ware  should  not  make  wasteful  use  of  system  resources  •  Usability  

–  So#ware  must  be  usable  by  the  users  for  which  it  was  designed  

Building  a  house  vs.  so#ware  •  Determining  and  analyzing  requirements  •  Producing  and  documen;ng  the  design  •  Detailed  specifica;ons  •  Iden;fying  and  designing  components  •  Building  components  •  Tes;ng  components  •  Integra;ng  components  •  Making  final  modifica;ons  •  Con;nuing  maintenance  

•  Requirements  analysis  and  defini;on  

•  System  design  •  Program  design  •  Wri;ng  programs  •  Unit  tes;ng  •  Integra;on  tes;ng  •  System  tes;ng  •  System  delivery  •  Maintenance  

These courseware materials courtesy of Sara L. Pfleeger

Visibility  vs…  

These courseware materials courtesy of Andre van der Hoeke, Copyright ©2001, André van der Hoek

…Invisibility  •  So#ware  as  is  cannot  be  viewed  meaningfully  –  Stack  of  paper  –  Set  of  files  

•  So#ware  cannot  be  interpreted  easily  – How  to  read  source  code?  – How  to  read  a  million  lines  of  source  code?  – How  to  read  a  part  of  source  code?  

•  Invisibility  affects  process  – How  to  measure  progress?  

•  Is  a  bigger  stack  of  paper  closer  to  the  end-­‐result  than  a  smaller  stack  of  paper?  

These courseware materials courtesy of Andre van der Hoeke, Copyright ©2001, André van der Hoek

Manageable  Complexity  vs…  

These courseware materials courtesy of Andre van der Hoeke, Copyright ©2001, André van der Hoek

…Unmanageable  Complexity  •  So#ware  cannot  be  easily  abstracted  –  Formulas    

•  Only  in  very  few  domains  – Diagrams,  graphs,  and  other  representa;ons  

•  Typically  non-­‐hierarchical  •  Far  too  many  cross-­‐references  

–  Few  concepts  are  available  to  use  in  an  abstrac;on  •  Tension  between  high-­‐level  understanding  and  low-­‐level  detailed  specifica;on  – High-­‐level  understanding  leaves  out  important  details  

– Aggrega;on  o#en  does  not  work  

These courseware materials courtesy of Andre van der Hoeke, Copyright ©2001, André van der Hoek

Environment  Can  Be  Changed  vs…  

These courseware materials courtesy of Andre van der Hoeke, Copyright ©2001, André van der Hoek

…Environment  Cannot  Be  Changed  

•  So#ware  has  to  adhere  to  the  “world”  it  is  placed  in  – Cannot  change  the  hardware  – Cannot  change  the  way  people  do  business  

•  The  “world”  is  o#en  not  clearly  specified  – How  can  you  change  something  that  you  cannot  specify?  

– Leads  to  many  so#ware  changes  •  Percep;on  is  that  so#ware  is  easier  to  change  

These courseware materials courtesy of Andre van der Hoeke, Copyright ©2001, André van der Hoek

No  Major  Changes  vs…  

These courseware materials courtesy of Andre van der Hoeke, Copyright ©2001, André van der Hoek

…Major  Changes  •  So#ware  is  remarkably  easy  to  change  –  Change  the  source  code,  recompile,  rerun  –  “One  line  here,  one  line  there”  

•  Unfortunately,  even  small  changes  can  have  disastrous  consequences  –  A  single  wrong  character  can  surrep;;ously  change  the  behavior  of  the  so#ware  •  The  effects  of  most  changes  are  only  visible  in  certain  circumstances  

•  Some;mes,  the  environment  does  change  –  So#ware  is  used  in  different  organiza;ons  –  So#ware  is  used  for  different  purposes  

These courseware materials courtesy of Andre van der Hoeke, Copyright ©2001, André van der Hoek

Dras;c  Consequences  

•  Deceased  pa;ents  –  X-­‐ray  machine  delivered  very  high  doses  because  of  a  ;ming  problem  in  its  control  so#ware  

•  Crashed  planes  –  So#ware  prevented  pilots  from  performing  emergency  maneuvers  

–  So#ware  had  similar  codes  for  different  airports  •  Decreased  na;onal  security  – NSA  computers  down  for  four  days  due  to  a  “so#ware  problem”  

These courseware materials courtesy of Andre van der Hoeke, Copyright ©2001, André van der Hoek

Summary  •  New  graduates  seeking  employment  typically  want  a  ;tle  “so#ware  engineer”  not  “computer  scien;st”  

•  So#ware  engineering  is  the  process  and  prac;ces  of  engineering  applied  to  crea;ng  so#ware  products  

•  So#ware  products  have  unique  proper;es  that  impact  these  processes  and  prac;ces  

•  Next  week  we  will  discuss  various  so#ware  lifecycle  process  models  –  the  process  part  

•  The  course  will  cover  prac;ces  in  a  specific  aspect  of  those  processes,  namely  requirements  engineering