Introduc)on  Info  320  Metal  Form  Project  Team  

Background  •  Located  in  Dannevirke  •  Specialised  in  Research  &  Development,  Design,  and  

engineering  metal  products  for  a  wide  range  of  industries  such  as  transport,  meat,  dairy,  hor)culture,  and  avia)on    

•  Supply  locally  (  NZ  only)  

 

Products  

Our  Role  •  To  set  up  a  network  database  –  for  the  tracking  and  ongoing  

management  of  sheet  and  sec)onal  raw  materials  from  arrival  on  site  to  complete  use  and  scrapping.    

•  NEED:  -­‐  Integrate  with  other  soRware    •  HAVE:  -­‐  Scope  for  con)nuous  improvement    and  development    •  MUST:  -­‐  Accessible  through  mul)ple  terminals  -­‐  User  friendly  interface  (  for  non-­‐computer  users)  

Deficiencies  with  Current  System    •  Excel  –  cannot  scale,  and  cannot  provide  enough  

func)onality.    •  IT  staff  could  not  convince  CEO  for  a  development    

 

 

Mee&ng  the  Client  

Storage  Racks   Off-­‐cuts  

Scrap  Laser-­‐Cu;er  

Benefits  of  Mee)ng  Client  -­‐  The  actual  process  was  quite  different  from  that  described  in  

the  documenta)on  -­‐  Gain  user-­‐  input  from  all  of  the  different  ‘programmers’.  -­‐  Simple  fact:  Face  to  face  communica)on  beats  e-­‐mail  when  

it  comes  to  requirements  elicita)on.  

 

Func)onal  Requirements  

 

Key  

                           Primary  Func&onali&es  

                         Secondary  Functionalities

Off-Cut Managment

System

9.3.2.1Administration

Functions

9.3.2.3Floor Personnel

Functions

9.3.2.2Normal User

Functions

9.3.2.1.1Enter New Material

9.3.2.2.2Update Job

Order Offcut

9.3.2.2.1New Job

9.3.2.2.3Generate

Report

Update Location

 •  3.2  Non  func)onal  requirements        •  Opera)onal  •  The  system  should  record  the  date  which  the  material  would  be  available  aFer  it  has  been  ordered.  •  The  default  loca&on  of  material  should  be  “in  transit”.  This  would  mi&gate  the  event  of  re-­‐ordering  an  off-­‐cut  

which  is  on  the  way  to  the  shop.  •  Log  in  –  This  provides  access  to  the  system  for  three  different  classes  of  users;  Administra&on,  Normal  User,  Floor  

Personnel.  Each  user  will  have  a  unique  ID  and  password.      •  Performance  •  Mul&ple  users  should  be  able  to  access  and  update  the  database  simultaneously.      •  Security  •  The  system  should  have  a  log  in  ID  for  each  user  so  the  system  keeps  a  record  of  who  made  par&cular  changes.  •  Floor  staff  should  only  have  access  to  the  “update  loca&on”  func&on.      •  Cultural/  poli)cal    •  No  special  cultural  or  poli&cal  requirements  are  an&cipated.        

 

Overview  of  The  Project  Limita)ons:    -­‐  The  dura)on  of  )me  -­‐  The  requirement  being  too  broad  -­‐  Lack  of  programming  (Ruby  on  Rails)  knowledge  -­‐  Client’s  being  long  distance  –  poor  communica)on  and  slow  

start.    

 

In  hindsight…  -­‐  More  synchronous  communica)on  such  as  conference  calls.  -­‐  Narrower  scope  from  the  outset  -­‐  Another  trip  to  Dannevirke  to  view  processes  in  ac)on.  -­‐  More  intensive  programming  training  or  more  developers  -­‐  And  of  course;  more  )me,  more  money  and  more  

manpower.