csc444h:& so(ware&engineering&i&matt/csc444/old/2014/lectures/00_introduction… ·...

csc444h:  so(ware  engineering  I  

matt medland

matt@cs.utoronto.ca http://www.cs.utoronto.ca/~matt/csc444

about  me  

•  undergrad in computer science •  graduate student here…twice! •  mix of academic & industry background

–  approximately 40% / 60% split •  developer, manager, director, consultant,

chief software architect •  small startup up to company of 4000+ •  mainframe, desktop, web, cloud, mobile,

embedded

your  TAs  

•  Narges Norouzi –  nnorouzi@comm.utoronto.ca –  Ph.D.  candidate    

•  Nitin Guleria –  ni-n.guleria@mail.utoronto.ca  – MEng.  candidate    

about  the  course    

•  home page: –  h7p://www.cs.utoronto.ca/~ma7/csc444  –  syllabus  &  marking  scheme  –  course  announcements  –  assignments  –  lecture  slides  will  be  posted  aCer  each  session  –  link  to  forum  on  piazza  –  etc.  

about  the  course  (2)  

•  textbook –  “The  Agile  Planning  Horizon  in  Professional  So3ware  Development”,  by  David  A.  Penny,  Ph.D.  

–  supplemental  material  provided  on  course  page  

about  the  course  (3)  

•  lectures, tutorials, labs, office hours –  lec:  monday  3-­‐6  in  WB219  –  lab:  T3-­‐6  &  F3-­‐6  –  GB251  

•  no  lab  this  week  –  tut:  T2  –  BA3012,  F11  –  BA3008  

•  no  tutorial  this  week  –  o/h:  monday  2:00  p.m.  BA5224    

about  the  course  (4)  

•  evaluation

course  evalua+on  

labs  &  assignments   30%  

midterm   20%  

final  exam   40%  

par-cipa-on     10%  

about  the  course  (5)  

•  topics chosen from: –  advanced  UML,  pa7erns,  architecture,  refactoring,  soCware  evolu-on,  reverse  eng.,  SDLC  models,  project  mgmt.  (planning,  risks,  es-ma-on,  priori-za-on),  requirements  analysis,  v&v,  tes-ng,  quality,  managing  a  team,  formal  methods,  etc.  

–  some  topics  will  get  more  a7en-on  than  others  

about  the  course  (6)  •  this course teaches you professional software

development practices. –  deals  mostly  with  process  and  related  tools,  rela-vely  li7le  with  specs/

designs/coding  –  if  you  have  the  ap-tude  and  inclina-on  of  becoming  a  professional  soCware  

engineer  you  will  find  the  course  interes-ng.  

•  applying these practices will help you avoid: –  missed  dates  –  defect-­‐ridden  soCware  –  badly-­‐designed  features  –  poor  architecture  leading  to  high  maintenance  costs  –  dysfunc-onal  professional  rela-onships  between  “the  business  side”  and  

soCware  development  (or  R&D)  

•  when software is built in a professional fashion in industry, this (more or less) is how it is consistently done.

course  policies  

•  re-grading –  requires written request to instructor with explanation –  will  be  done  by  the  Instructor,  mark  may  go  up  or  down!  

•  late assignments –  due  date/-me  posted  on  the  assignment  and  webpage  –  daily  penal-es  will  apply  to  late  work  (10%  per  day,  up  to  7  

days,  then  a  mark  of  0  will  be  assigned)  

•  academic integrity –  don’t  plagiarize.  ok  to  discuss,  but  don’t  take  notes.  –  properly  site  sources  in  your  reports  

•  communication –  only  email  me  if  it’s  confiden-al  –  put  csc444h  in  subject  –  use  discussion  forum  for  ques-ons,  answer  other’s  ques-ons!  

•  par-cipa-on  mark  includes  forum!  

why  do  we  need  a  course  on  engineering  so(ware  systems?  

moBvaBon  

moBvaBon  (2)  

•  historically, humans are very bad at engineering large software systems –  see “why software fails” under readings

•  how bad can we be? software is everywhere! some of us must be ok at it…right?

•  annually, $bn are wasted on failed or over-budget large software projects. –  lots  of  room  for  improvement!  

moBvaBon  (3)  

•  national programme for IT in the NHS (UK national health service) NPfIT: –  cancelled  project  took  9  years  and  cost  £12bn  –  from  computerworlduk.com,  11/09/2011:  

“The [UK] government will formally announce the scrapping of the National programme for IT in the NHS…to “urgently dismantle” the health service IT scheme comes after a series of damming reports…The final nail in the £12 billion scheme will be announced this morning…set up in 2002, is not fit to provide services to the NHS. ‘There can be no confidence that the programme has delivered or can be delivered as originally conceived,’”

moBvaBon  (4)  

•  is it because they didn’t use agile? •  agile projects can fail too! and just as bad

–  universal  credit  is  Bri-an’s  plan  to  consolidate  all  welfare  payments  into  one.  

–  touted  as  the  world’s  biggest  agile  soCware  project,  now  close  to  total  failure!  

–  original  budget  =  £2.2bn,  cost  so  far  =  £12.8bn  –  ar-cle:  

h7p://news.slashdot.org/story/13/05/25/139218/worlds-­‐biggest-­‐agile-­‐soCware-­‐project-­‐close-­‐to-­‐failure    

•  I bet the welfare recipients could have used that £12.8bn!

moBvaBon  (5)  

race condition on computer system in Ohio caused stalling of audio/visual alerts primary system failed, then shortly after, the backup also failed (d’oh!)

2003 blackout

moBvaBon  (6)  

$500m for a website? are you serious?!?!

healthcare.gov

moBvaBon  (7)  

•  author of Why Software Fails states that:

"Studies  indicate  that  large-­‐scale  projects  fail  three  to  five  -mes  more  oCen  than  small  ones.”  

•  article: h7p://spectrum.ieee.org/compu-ng/soCware/why-­‐soCware-­‐fails    

what  is  large?  

•  lots of talk about “large” systems •  what do we mean when we say a software

system is “large?” –  class  discussion  –  some  examples  –  largest  soCware  you  have  ever  worked  with?  

what  is  large?  (2)  

•  what makes a software system “large?” –  kloc?,  “what  about  comments?”,  ok,  fine,  executable  statements  when  compiled?  

–  number  of  bytes?  –  person-­‐hours,  or  some  other  effort  metric?  –  number  of  developers?  –  number  of  features?  –  number  of  processors  running  the  code?  –  number  of  users  of  the  soCware?  –  number  of  bugs?  

what  is  large?  (3)  

–  size  of  the  box?  number  of  floppy  disks,  and  hours  it  takes  to  install  it?  J  

what  is  large?  (4)  

•  answer (well at least my answer): –  something  that  is  not  a  “spike”  and  is  intended  for  users  other  than  developer  –  released  

–  can  benefit  from,  and  is  not  hindered  by,  proper  prac-ces  (modeling,  source  control,  automated  unit  tes-ng,  con-nuous  integra-on…)  

–  standard  development  tools  are  not  too  cumbersome  (ex.  making  an  eclipse  project  is  overkill  =>  not  “large”  for  our  purposes)  

–  so,  basically  anything  non-­‐trivial  

summary  

•  this course deals with the challenges of major software projects – working  with  legacy  code/systems  –  analyzing  problems  –  deciding  what  is  feasible,  with  the  given  team,  and  the  amount  of  -me  available  

– managing  next  release  development  –  delivering  quality  soCware  in  a  professional  soCware  environment  

10  minute  break!  

so(ware  engineering  

•  it’s all about matching process, tools, technology, and architecture to your situation. –  40  line  throwaway  python  script  for  your  own  use  

•  only  you  will  use  it  •  only  you  will  contribute  to  it  •  you  will  use  it  for  the  next  30  minutes  and  never  again  

–  a  soCware  product  you  are  building  a  company  around  

•  10’s  of  thousands  of  paying  customers  will  use  it  •  eventually  a  large  team  will  collaborate  on  it  •  it  will  survive  for  >  10  years  

–  and  everything  in  between  •  there is no one “right way” for any situation

new  vs.  established  product  

•  new product –  1  yr.  to  develop  –  3  coders,  1  tester,  1  documenter  –  cost  =  1  x  5  x  $100,000  =  $500,000  

•  established product –  5  years  later  –  20  coders,  10  testers/build,  5  documenters  –  cost  to  date  =  $10,000,000  –  ongoing  cost  =  $3,500,000  /  year  

•  improve productivity by 10% –  new  product:  save  $50,000  –  Established  product:  save  $1,000,000  to  date,  $350,000/year  

new  vs.  established  (2)  

•  next release development is more economically important.

•  learn how ‘next release’ is done to setup initial release properly

top-­‐10  essenBal  pracBces  

•  crystallized for me whenever I enter into a new engagement. •  if any of these are missing, I know I have something to fix. •  these are all important •  it will take more than this course to cover them all •  you will agree that all suggestions are sensible and will

probably vow to carry them out –  on  your  first  job,  you’ll  focus  on  code  and  test  and  forget  most  of  them  –  you’ll  be  bi7en  in  the  ass  –  you’ll  re-­‐commit  to  the  ideas  (if  you’re  good)  

•  simple but hard –  trust  me:  make  sure  these  things  are  done  and  everything  will  go  ok  –  very  hard  to  change  behaviour  –  need  to  be  dogged  and  determined  and  tricky  

•  geared more towards ‘next release’ than ‘new release’

top-­‐10  (2)  

infrastructure

control

refinement

source code control

defect/feature tracking

reproducible builds

automated regression

testing

Agile Horizon Planning

feature specifications architectural

control

business planning

effort tracking process

control

top-­‐10  (3)  

infrastructure

control

refinement

source code control

defect/feature tracking

reproducible builds

automated regression

testing

Agile Horizon Planning

feature specifications architectural

control

business planning

effort tracking process

control

1.  source  control  

•  central repository –  everybody  knows  where  to  find  what  they  are  looking  for  –  secure,  backed-­‐up  storage  

•  defines module architectural structure –  Hierarchy  

•  complete change history –  can  back  up  and  find  where  problems  are  first  introduced  

•  multiple maintenance streams –  work  on  next  release  while  maintaining  previous  releases  

•  patches –  Can  go  back  and  patch  any  release  in  the  field  

•  Enables team development •  “interface” to coordinate dev and QA/build •  “guard” against bad changes

2.  issue  tracking  

•  keeps track of all defects found or new features desired –  won’t  forget  any    

•  coordinates a workflow for writing / fixing them –  won’t  skip  steps    

•  provides management visibility into progress and enables metrics to be gathered

•  enables effective prioritization

3.  reproducable  builds  

•  check out of source control and one command to build the product

•  required for a consistent experience across all developers, QA/Build, customers

•  dev builds –  for  coding  and  tes-ng  

•  production builds –  includes  crea-on  of  install  image  –  and  crea-on  of  ISO-­‐Image  (if  s-ll  shipping  on  round  things)  –  should  also  be  fully  automated  

4.  automated  regression  tesBng  

•  scripts that run after every QA/Build dev build to test as much functionality as possible

•  critical to improving software quality

•  prevents errors with previously seen symptoms from recurring –  a  very  common  thing  to  happen  

•  enables coders to change tricky bits with confidence

•  enables finding problems closer to their injection –  earlier  you  can  find  an  issue  the  less  costly  it  is  to  fix.  

regression  tesBng  (2)  

•  enables fixing last problems prior to shipping

with confidence –  can  release  with  fewer  known  defects  –  can  release  on  -me  

•  includes automated unit testing –  developed  while  code  is  being  wri7en  –  tests  classes  and  modules  (collec-ons  of  classes).  –  good  design  +  dependency  injec-on  to  replace  surrounding  

infrastructure  without  recoding  

infrastructure

control

refinement

source code control

defect/feature tracking

reproducible builds

automated regression

testing

Agile Horizon Planning

feature specifications architectural

control

business planning

effort tracking process

control

5.  horizon  planning  

•  after the previous basics are in place this is the most important practice –  will  spend  rela-vely  more  of  the  course  on  this  

•  determining –  what  goes  into  the  soCware  –  by  when  will  it  will  be  done  –  using  what  resources  

•  tracking that throughout the time horizon

•  adjusting as necessary

horizon  planning  (2)  

•  enables business side to do their jobs –  good  rela-onships  

•  enables quality –  by  maintaining  necessary  non-­‐coding  periods  (e.g.,  stabiliza-on  

sprints)  

 •  provides elbow room

–  to  improve  produc-vity  

•  a weakness of many agile methods – end date prediction is somewhat an undefined thing!

release  planning  

•  book used to refer to this as “release planning” – you may find older references to that.

•  while the “big bang” release is still used and important, a lot of us are releasing software much more continuously. –  used  to  be  a  horrible  cowboy  hacker  sort  of  thing  –  if  following  good  prac-ces  is  now  a  preferred  method,  especially  

for  SoCware-­‐as-­‐a-­‐Service  

•  it is still critical to plan what features will be released by when over a convenient time horizon (e.g., 6 months, or quarterly) –  when  code  gets  pushed  to  produc-on  is  a  detail  –  how  customers  are  presented  with  the  new  features  is  a  detail  –  all  the  “release  planning”  principles  used  for  big  bang  releases  s-ll  

apply  

6.  feature  specificaBons  

•  complicated features require them –  need  to  make  this  determina-on  

•  needed to keep release plan on track –  be7er  es-mates  if  know  what  we  are  doing  in  more  detail  

•  enables a better end-user feature •  eliminates unanticipated integration problems •  best place to introduce reviews

•  The agile approach is to develop smaller units of user-visible functionality, and have constant user input. –  somewhat  suspect  

7.  architectural  control  

•  must maintain a clean architecture even in the face of –  many  coders  working  on  the  code  –  frequent  feature  addi-ons  

•  that  the  soCware  was  not  designed  for  ini-ally  –  frequent  defect  correc-ons  

•  by  inexperienced  coders  who  do  not  understand  the  architecture  

architecture  (2)  

•  architectural documentation •  review of designs and code for conformance •  chief architect (CSA) •  automated architectural checking tools

•  agile approach is not to document the architecture. the code should be sufficiently well-designed that the architecture is clear. –  somewhat  suspect  

infrastructure

control

refinement

source code control

defect/feature tracking

reproducible builds

automated regression

testing

Agile Horizon Planning

feature specifications architectural

control

business planning

effort tracking process

control

8.  effort  tracking  

•  need to know how much staff time is spent on –  each  new  feature  –  correc-ng  defects  –  Other  

•  can improve estimation accuracy •  can improve estimates of staff time available

for next release •  can monitor effectiveness of initiatives to free

up coder time for more coding

effort  tracking  (2)  

•  agile approach fixes the sprint length (e.g., 10 days), and looks at the number of “units” that were accomplished during that time. that establishes the number of “units” available for the next sprint of the same duration (velocity). –  simple  to  implement  –  can’t  really  say  “why”  and  improve  prac-ces  as  a  result  –  managers  don’t  trust  “units”  

9.  process  control  

•  written process for the release cycle •  gets everybody on the same page

–  can  train  new  staff  

•  enables systematic definition / collection of metrics

•  can monitor process for compliance •  can consider changes to the process from

a stable baseline

10.  business  planning  

•  development occurs within a business context

•  if not understood and managed, will sink the project more surely than technical shortcomings

•  writing effective proposals

•  integrating into the budget cycle.

•  (may not have to cover this year)

infrastructure

control

refinement

source code control

defect/feature tracking

reproducible builds

automated regression

testing

Agile Horizon Planning

feature specifications architectural

control

business planning

effort tracking process

control