Capstone

 Project-­‐I  

Slides  prepared  from  the  “Final  Project  

Deliverable  Guide”  available  at  
Department  of  Computer  Science,  
University  of  Sargodha    
 Chapter  2  
•  2.1.  Introduc2on  
–  Introduce  your  project  in  one  or  two  paragraphs  
–  Only  idea  is  not  enough  to  start  with.  It  needs  feasibility  study.  
•  2.2.  Project/Product  Feasibility  Report  
–  The  results  of  this  analysis  are  used  in  making  the  decision  whether  to  
proceed  with  the  project  or  not.  There  are  many  types  of  feasibiliHes:  
•  Technical  
•  OperaHonal  
•  Economic  
•  Schedule  
•  SpecificaHon  
•  InformaHon  
•  MoHvaHonal  
•  Legal  and  Ethical  
 Chapter  2  
•  2.2.1.  Technical  Feasibility  
–  The  technical  assessment  help  answer  the  quesHon  
such  as:    
•  Whether  the  technology  needed  for  the  system  exists?  
•  How  difficult  it  will  be  to  build?    
•  Whether  the  firm  has  enough  experience  using  that  
technology.    
•  In  developing  the  new  system,  one  has  to  invesHgate  and  
compare  technology  providers,  determine  reliability  and  
compeHHveness  of  that  system,  and  idenHfy  limitaHons  or  
constraints  of  technology,  as  well  as  the  risk  of  the  proposed  
system  that  is  depend  on  the  size  of  the  system,  structure,  
and  group’s  experience  with  the  similar  systems.  
 Chapter  2  
•  2.2.2.  Opera2onal  Feasibility  
–  How  the  new  systems  will  fit  into  the  current  day-­‐to-­‐day  
operaHons  of  the  organizaHon.  
–  Whether  the  current  work  pracHces  and  procedures  
support  a  new  system  or  not?  
–  how  the  organizaHonal  changes  will  affect  the  working  
lives  of  those  affected  by  the  system.  
•  ImplemenHng  the  new  IT/IS  project  may  cause  some  obstructs  and  
may  increase  difficulty  to  the  staffs  in  their  day-­‐to-­‐day  operaHon.  
–  EvaluaHon  of  technical  ability  of  the  staff  to  operate  the  
project  is  the  main  aim  of  operaHonal  feasibility.    
–  How  do  end  users  and  managers  feel  about  the  problem  
or  soluHon  is  another  query  to  be  answered.    
 Chapter  2  
•  2.2.3.  Economic  Feasibility  
–  Project  investments  involve  the  expenditure  of  capital  funds  
and  other  resources  to  generate  future  benefits,  whether  in  the  
form  of  profits,  cost  savings,  or  social  benefits.    
–  For  an  investment  to  be  worthwhile,  the  future  benefit  should  
compare  favorably  with  the  prior  expenditure  of  resources  need  
to  achieve  them.        
–  It  can  be  done  via  Cost/Benefit  Analysis.  
–  When  talking  about  the  cost  of  IT/IS  project,  one  would  first  
think  of  the  tangible  costs  that  are  easily  to  determine  and  
esHmate,  such  as  hardware  and  soZware  cost,  or  labor  cost.    
–  However,  in  addiHon  to  these  tangible  costs,  there  are  also  
some  intangible  costs,  such  as  loss  of  goodwill,  or  operaHonal  
inefficiency.  
 Chapter  2  
–  IT/IS  project  cost  may  involve  following  things:  
•  End-­‐user  computer  Hardware  purchase  costs,  SoZware  license  
purchase  costs,  Hardware  &  SoZware  deployment  costs,  
Hardware  warranHes  and  maintenance  costs,  SoZware  license  
tracking  costs,  OperaHons  Infrastructure  Costs,  Cost  of  Security  
Breaches  (in  loss  of  reputaHon  and  recovery  cost),  Cost  for  
electricity  and  cooling,  Network  hardware  and  soZware  costs,  
Server  hardware  and  soZware  costs,  Insurance  costs,  TesHng  
costs,  Cost  to  upgrade  or  scalability,  IT  Personnel  costs,  Backup  
and  Recovery  Process  costs,  Costs  associated  with  failure  or  
outage,  Diminished  performance  incidents  (i.e.  users  having  to  
wait),  Technology  training  costs  of  users  and  IT  staff,  Infrastructure  
(floor  space)  costs,  Audit  costs,  MigraHon  costs,  etc.  
 Chapter  2  
–  On  the  other  hand,  IT/IS  projects  can  provide  many  benefits,  both  
tangible  and  intangible,  to  an  organizaHon.  The  tangible  benefit,  such  
as  cost  saving  or  increasing  in  revenue,  would  be  easier  to  esHmate  
while  intangible  benefits  are  harder  to  quanHfy.    
•  Measures  existed  are  the  following  (Read  it  yourself):  
–  Time  Value  of  Money  
–  Net  Present  Value  (NPV)  &  Internal  Rate  of  Return  (IRR)  
–  Break-­‐Even  Analysis  
–  Return  on  investment  (ROI)    
–  Payback  period  (PP)    
–  Profitability  index  (PI)    
 Chapter  2  
•  2.2.4.  Schedule  Feasibility  
–  Assessing  schedule  feasibility  is  to  assess  the  duraHon  of  the  
project.  
–  How  long  the  system  will  take  to  develop,  and  whether  all  
potenHal  Hmeframes  and  the  compleHon  date  schedules  can  be  
met,  as  well  as  whether  meeHng  these  date  will  sufficient  for  
dealing  with  the  needs  of  the  organizaHon.  
–  One  needs  to  determine  whether  the  deadlines  are  mandatory  
or  desirable.  
–  Unless  the  deadline  is  absolute  mandatory,  it  is  preferable  to  
deliver  a  properly  funcHoning  informaHon  system  two  months  
late  than  to  deliver  an  error-­‐prone,  useless  informaHon  system  
on  Hme.    
 Chapter  2  
•  2.2.5.  Specifica2on  Feasibility  
– Requirements  are  the  features  that  the  
system  must  have  or  a  constraint  that  must  
be  accepted  for  the  customer.    
– Whether  the  requirements  are  clear  and  
definite.    
 Chapter  2  
•  2.2.6.  Informa2on  Feasibility  
–  InformaHon  can  be  gained  from  the  organizaHon,  
product,  staff,  end  users,  etc.  
–  The  quality  of  informaHon  must  be  assessed  
regarding  its  compleHon,  reliability,  and  
meaningfulness?  
 Chapter  2  
•  2.2.7.  Mo2va2onal  Feasibility  
–  EvaluaHon  of  the  organizaHonal  staff  regarding  
the  moHvaHon  to  perform  the  necessary  steps  
correctly  and  promptly  must  be  quanHfied  and  
assessed.  
 Chapter  2  
•  2.2.8.  Legal  &  Ethical  Feasibility  
–  Legal  feasibility  determines  whether  the  proposed  system  conflicts  
with  the  legal  requirement  or  not.    
–  A  project  may  face  legal  issues  aZer  compleHon  if  this  factor  is  not  
considered  at  the  first  stage.    
–  “The  European  Union  has  taken  quite  a  different  tack  from  American's  
market-­‐driven  approach  to  online  privacy.  The  EU's  1998  Data  
ProtacDon  DirecDve  basically  allows  individuals  to  decide  how  their  
collected  data  can  be  used.  Thus,  if  a  European  consumer  provieds  
personal  informaDon  such  as  an  address  when  buying  from  an  online  
store,  the  store  cannot  legally  send  an  ad  to  the  purchaser  without  first  
seeking  permission.  The  direcDve  also  prohibits  the  transfer  data  to  
countries  outside  the  European  Union  that  do  not  have  "adequate"  
provacy  rules."  (McAdams,  Neslund  N.,  and  Neslund  K.)  
 Chapter  2  
•  2.3.  Project/Product  Scope  
–  when  we  talk  about  defining  the  scope,  we  are  talking  about  
developing  a  common  understanding  as  to  what  is  included  in,  or  
excluded  from,  a  project.  We  are  not  talking  about  deciding  how  long  
it  will  take,  or  how  much  it  will  cost.  That  comes  aZer  the  scope  is  
defined.      
–  Scope  definiHons  oZen  account  for  a  paragraph  or  two.  OZen,  they  
are  qualitaHve  and/or  focus  on  general  statements.    
"We  will  improve  service  by  providing  an  informaHon  system  to  respond  to  
customer  inquiries."  Is  it  a  real  Hme  system?  Is  it  all  screen-­‐based?  What  
reports  can  be  produced?  Where  does  the  informaHon  come  from?  What  
manipulaHon  is  required  for  the  data?  Is  all  the  data  compaHble?  Do  you  
want  to  generate  standard  lecers?  How  many  lecers?  Do  you  want  to  store  
the  quesHons?  Do  you  want  to  store  the  answers?  Etc.  etc.  etc.    
–  See  example  at  :  hcp://www.brighthubpm.com/project-­‐planning/57950-­‐example-­‐and-­‐
evaluaHon-­‐of-­‐project-­‐scope-­‐statements/  
 
 Chapter  2  
•  2.4.  Project/Product  Cos2ng  
–  Most  of  the  work  in  the  cost  esHmaHon  field  has  
focused  on  algorithmic  cost  modeling.    
•  2.4.1.  By  FuncHon  Point  Analysis  (Total  Project  Cost  and  
Total  Project  Effort  )  
•  2.4.2.  Using  COCOMO’81  (Effort,  DuraHon,  resources,  
cost)  
•  2.4.3.  AcHvity  Based  CosHng  (Cost,  effort)  
 Chapter  2  
•  2.5.  Task  Dependency  Table  
–  Basically,  it  is  Work  Breakdown  Structure  (WBS).  
–  You  can  make  any  design  e.g.  tree  structure,  table  
lisHng,  etc.,  for  becer  understanding  
 Chapter  2  
•  2.6.  CPM  -­‐  Cri2cal  Path  Method  
–  Provides  a  graphical  view  of  the  project.  
–  Predicts  the  Hme  required  to  complete  the  project.  
–  Shows  which  acHviHes  are  criHcal  to  maintaining  the  
schedule  and  which  are  not.  
 Chapter  2  
•  2.7.  Gan>  chart  
•  2.8.  IntroducBon  to  Team  member  and  their  skill  set  
•  2.9.  Task  and  Member  Assignment  Table  
 

Task  Dura2ons  and  Dependencies  Table  

 Chapter  2  
14/7/99 15 days
15 days
M1 T3
8 days T9
T1 5 days 4/8/99 25/8/99
25/7/99
T6 M4 M6
4/7/99 M3
start 20 days 7 days
15 days
T7 T11
T2

25/7/99 10 days 11/8/99 5/9/99

10 days
M2 M7 M8
T4 T5 15 days
T10 10 days
18/7/99
T12
M5
25 days
T8 Finish
19/9/99

Task  Dura2ons  and  Dependencies  Flow  

 Chapter  2  
4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9
Start
T4
T1
T2
M1
T7
T3
M5
T8
M3
M2
T6
T5
M4
T9
M7
T10
M6
T11
M8
T12
Finish

Ac2vity  Bar  Chart  

 Chapter  2  

Alloca2on  of  People  to  Ac2vi2es    

Chapter  2  

Staff  Alloca2on  
 Chapter  2  
•  2.10.  Tools  and  Technology  with  reasoning  
–  The  applicaHon  tools,  which  are  to  be  used  on  
front  and  back  end  of  the  system  to  be  developed,  
should  be  listed.  The  reasons  for  these  tools  
should  also  be  described.  
–  IdenHfy  what  the  needs  for  tool  support  are,  and  
what  the  constraints  are,  by  looking  at  the  many  
points  described  in  the  guidebook.  
 Chapter  2  
•  2.11.  Vision  Document  
–  Example  can  be  seen  at  
hQp://www.trishmarie.com/vision.pdf  
–  IdenHfy  and  agree  on  the  problems  faced  by  end  users  and  
the  effects  of  those  problems  on  producHvity  and  
efficiency  
–  Gather  and  describe  customer  requests  for  soZware  
features    
–  Propose  a  soluHon  (new  development  or  alternaHve)  
–  IdenHfy  any  constraints  to  the  proposed  soluHon  
–  IdenHfy  stakeholders  and  users  
–  IdenHfy  the  soZware  development  team  
–  Etc.,  
 Chapter  2  
•  2.12.  Risk  List  
–  The  Risk  List  is  designed  to  capture  the  perceived  risks  to  
the  success  of  the  project.  It  idenHfies,  in  decreasing  order  
of  priority,  the  events  that  could  lead  to  a  significant  
negaHve  outcome.      
•  2.13.    Product  Features/  Product  DecomposiBon  
–  Product  funcHonal  features,  benefits,  etc.,  is  also  the  part  
of  document  vision.  
•  Features:  Fan  forced  cooking  system,  mini  turbine,  and  ring  heater  
element.  
•  Advantages:  Cooking  on  up  to  three  levels,  hot  air  forced  evenly  
through  the  interior.  
•  Benefits:  Reduced  cooking  Hme,  reduced  energy  consumpHon,  
perfectly  even  cooking  results.