Software Development Plan of Fixed Asset Management System


Published on

Published in: Technology, Business
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Software Development Plan of Fixed Asset Management System

  1. 1.   Software Development Plan for ASK (MIS) Prepared for Ain o Salish Kendra (ASK) Prepared by Md. Nasiruddin Juel
  2. 2. Software Development Plan for ASK (MIS)  2   PREFACE    This  document  describes  how  this  software  development  project  of  ASK  will  be  conducted. Committing this plan to writing allows all of the stakeholders to refer to the  plan throughout the project. This development plan is a living document and is updated  at  the  end  of  each  stage  or  phase  of  development.  This  plan  includes  schedules,  estimates, and milestones.                                                                
  3. 3. Software Development Plan for ASK (MIS)  3 OVERVIEW    The process of building and monitoring schedules for software development projects.  To build complex software systems, many engineering tasks need to occur in parallel  with  one  another  to  complete  the  project  on  time.  The  output  from  one  task  often  determines when another may begin. Software engineers need to build activity networks  that take these task interdependencies into account. Managers find that it is difficult to  ensure that a team is working on the most appropriate tasks without building a detailed  schedule and sticking to it. This requires that tasks are assigned to people, milestones  are created, resources are allocated for each task, and progress is tracked.      PROJECT ORGANIZATION    The six stages of the SDLC (Software Development Life Cycle) are designed to build on  one another, taking the outputs from the previous stage, adding additional effort, and  producing  results  that  leverage  the  previous  effort  and  are  directly  traceable  to  the  previous stages. This top-down approach is intended to result in a quality product that  satisfies the original intentions of the ASK.                                         
  4. 4. Software Development Plan for ASK (MIS)  4 Too  many  software  development  efforts  go  wrong  when  the  development  team  and  customer personnel get caught up in the possibilities of automation. Instead of focusing  on high priority features, the team can become mired in a sea of ìnice to haveî features  that are not essential to solve the problem, but in themselves are highly attractive. This  is the root cause of a large percentage of failed and/or abandoned development efforts,  and is the primary reason the development team utilizes the Waterfall SDLC.     PLANNING STAGE    The planning stage establishes a bird's eye view of the intended software product, and  uses  this  to  establish  the  basic  project  structure,  evaluate  feasibility  and  risks  associated  with  the  project,  and  describe  appropriate  management  and  technical  approaches.  The  most  critical  section  of  the  project  plan  is  a  listing  of  high-level  product  requirements, also referred to as goals. All of the software product requirements to be  developed  during  the  requirements  definition  stage  flow  from  one  or  more  of  these  goals. The minimum information for each goal consists of a title and textual description,  although additional information and references to external documents may be included.                                           
  5. 5. Software Development Plan for ASK (MIS)  5 The outputs of the project planning stage are the configuration management plan, the  quality  assurance  plan,  and  the  project  plan  and  schedule,  with  a  detailed  listing  of  scheduled activities for the upcoming Requirements stage, and high-level estimates of  effort for the out stages.    REQUIREMENTS DEFINITION STAGE    The requirements gathering process takes as its input the goals identified in the high- level requirements section of the project plan. Each goal will be refined into a set of one  or more requirements.    These  requirements  define  the  major  functions  of  the  intended  application,  define  operational  data  areas  and  reference  data  areas,  and  define  the  initial  data  entities.  Major  functions  include  critical  processes  to  be  managed,  as  well  as  mission  critical  inputs, outputs  and  reports.  A user  class hierarchy  is  developed and associated  with  these major functions, data areas, and data entities.    Each  of  these  definitions  is  termed  a  Requirement.  Requirements  are  identified  by  unique requirement identifiers and, at minimum, contain a requirement title and textual  description.                                   
  6. 6. Software Development Plan for ASK (MIS)  6 These  requirements  are  fully  described  in  the  primary  deliverables  for  this  stage:  the  Requirements  Document  and  the  Requirements  Traceability  Matrix  (RTM).  The  requirements document contains complete descriptions of each requirement, including  diagrams  and  references  to  external  documents  as  necessary.  Note  that  detailed  listings of database tables and fields are not included in the requirements document.    DESIGN STAGE    The design stage takes as its initial input the requirements identified in the approved  requirements document. For each requirement, a set of one or more design elements  will be produced as a result of interviews, workshops, and/or prototype efforts.    Design elements describe the desired software features in detail, and generally include  functional  hierarchy  diagrams,  screen  layout  diagrams,  tables  of  business  rules,  business process diagrams, pseudo code, and a complete entity-relationship diagram  with a full data dictionary. These design elements are intended to describe the software  in  sufficient  detail  that  skilled  programmers  may  develop  the  software  with  minimal  additional input.                                           
  7. 7. Software Development Plan for ASK (MIS)  7 When  the  design  document  is  finalized  and  accepted,  the  RTM  -  Requirements  Traceability Matrix is updated to show that each design element is formally associated  with a specific requirement. The outputs of the design stage are the design document,  an updated RTM, and an updated project plan.    DEVELOPMENT STAGE    The development stage takes as its primary input the design elements described in the  approved design document. For each design element, a set of one or more software  artifacts  will  be  produced.  Software  artifacts  include  but  are  not  limited  to  menus,  dialogs,  data  management  forms,  data  reporting  formats  and  specialized  procedures  and  functions.  Appropriate  test  cases  will  be  developed  for  each  set  of  functionally  related software artifacts, and an online help system will be developed to guide users in  their interactions with the software.                                                       
  8. 8. Software Development Plan for ASK (MIS)  8 The  outputs  of  the  development  stage  include  a  fully  functional  set  of  software  that  satisfies the requirements and design elements previously documented, an online help  system  that  describes  the  operation  of  the  software,  an  implementation  map  that  identifies the primary code entry points for all major system functions, a test plan that  describes the test cases to be used to validate the correctness and completeness of the  software, an updated RTM - Requirements Traceability Matrix, and an updated project  plan.    INTEGRATION & TEST STAGE    During the integration and test stage, the software artifacts, online help, and test data  are migrated from the development environment to a separate test environment. At this  point, all test cases are run to verify the correctness and completeness of the software.  Successful  execution  of  the  test  suite  confirms  a  robust  and  complete  migration  capability.                                                   
  9. 9. Software Development Plan for ASK (MIS)  9 The outputs of the integration and test stage include an integrated set of software, an  online help system, an implementation map, a production initiation plan that describes  reference data and production users, an acceptance plan which contains the final suite  of test cases, and an updated project plan.    INSTALLATION & ACCEPTANCE STAGE    During  the  installation  and  acceptance  stage,  the  software  artifacts,  online  help,  and  initial production data are loaded onto the production server. At this point, all test cases  are  run  to  verify  the  correctness  and  completeness  of  the  software.  Successful  execution  of  the  test  suite  is  a  prerequisite  to  acceptance  of  the  software  by  the  customer.                                                               
  10. 10. Software Development Plan for ASK (MIS)  10 After customer personnel have verified that the initial production data load is correct and  the test suite has been executed with satisfactory results, the customer formally accepts  the delivery of the software.    PRE-DEFINED STRUCTURE    Each stage has a pre-defined set of standard processes, such as Informal Iteration and  In-stage  Assessment.  The  project  participants  quickly  grow  accustomed  to  this  repetitive  pattern  of  effort  as  they  progress  from  stage  to  stage.  In  essence,  these  processes establish a common rhythm, or culture, for the project.    This  pre-defined  structure  for  each  stage  allows  the  project  participants  to  work  in  a  familiar environment, where they know what happened in the past, what is happening in  the present, and have accurate expectations for what is coming in the near future. This  engenders a high comfort level, which in turn generates a higher level of cooperation  between participants. Participants tend to provide needed information or feedback in a  timelier manner, and with fewer miscommunications. This timely response pattern and  level of communications quality becomes fairly predictable, enhancing the ability of the  level of effort for future stages.    In this Waterfall SDLC, the project planning effort is restricted to gathering metrics on  the current stage, planning the next stage in detail, and restricting the planning of later  stages, also known as Out Stages, to a very high level. The project plan is updated as  each stage is completed; current schedule to date are combined with refined estimates  for activities and level of effort for the next stage.    The activities and tasks of the next stage are defined only after the deliverables for the  current  stage  are  complete  and  the  current  metrics  are  available.  This  allows  the  planner  to  produce  a  highly  accurate  plan  for  the  next  stage.  Direct  experience  has  shown  that  it  is  very  difficult  to  develop  more  than  a  cursory  estimate  of  anticipated  structure and level of effort for out stages. 
  11. 11.                     Define the Problem                                       Create Solution to Requirements             Solution Release PPrree--DDeeffiinneedd  SSttrruuccttuurree  ooff  WWaatteerrffaallll  SSDDLLCC  ((SSyysstteemm  DDeevveellooppmmeenntt  LLiiffee--CCyyccllee)) Release Acceptance  Tests High-Level  Design Identify Business  Objectives  Software   Concept  Development  Requirements Stage 1   Stage n   Detailed  Design  Code Test  Release Documentation Acceptance  Tests  Detailed  Design  Code Test  Release Documentation Acceptance  Tests 
  12. 12.                       EEssttiimmaattiinngg SSooffttwwaarree DDeevveellooppmmeenntt SSiizzee,, EEffffoorrtt,, SScchheedduulliinngg bbaasseedd oonn UUssee CCaasseess  
  13. 13. Software Development Plan for ASK (MIS)  13 ABSTRACT    Use case models are used in object-oriented analysis for capturing and describing the  functional  requirements  of  a  system.  Several  methods  for  estimating  software  development effort are based on attributes of a use case model. This paper reports the  results of three system development project case studies on the application of a method  for effort estimation based on use case points. Our experience is also that the design of  the use case models has a strong impact on the estimates.                                                 
  14. 14. Software Development Plan for ASK (MIS)  14 INTRODUCTION    Use case modeling is a popular and widely used technique for capturing and describing  the functional requirements of a software system. The designers of UML recommend  that  developers  follow  a  use  case  driven  development  process  where  the  use  case  model is used as input to design, and as a basis for verification, validation and other  forms of testing.    A  use  case  model  defines  the  functional  scope  of  the  system  to  be  developed.  The  functional scope subsequently serves as a basis for top-down estimates1 . However, we  have been unable to find studies that describe the use case points estimation process in  details. This paper describes a pilot study on three system development projects. The  aim  of  this  paper  is  to  provide  a  detailed  description  of  the  method  used  and  experiences from applying it.    We compared estimates based on use case points for three development projects with  estimates  obtained  by  experts,  in  this  case  senior  members  of  the  development  projects, and actual effort. Our results support findings reported elsewhere in that use  case  models  may  be  suitable  as  a  basis  for  effort  estimation  models.  In  addition  to  supporting other studies, we have experienced that the guidance provided by the use  case points method appears to reduce the need for expert knowledge in the estimation  process.                  1 In general, a top-down estimate is produced applying an estimation method to factors believed to influence the  effort necessary to implement a system. The estimation method gives the total software development effort, which  may then be divided on the different activities in the project according to a given formula. Adding up expected effort  for all the activities planned in a project, on the contrary, produces a bottom-up estimate.       
  15. 15. Software Development Plan for ASK (MIS)  15 THE USE CASE POINTS METHOD    This  section  gives  a  brief  overview  of  the  steps  in  the  use  case  points  method  as  described  in. This  estimation  method  requires  that  it  should  be  possible  to  count  the  number of transactions in each use case. A transaction is an event occurring between  an  actor  and  the  system,  the  event  being  performed  entirely  or  not  at  all.  The  three  steps of the use case points method are as follows:    1. The actors in the use case model are categorized as simple, average or complex. A  simple actor represents another system with a defined API; an average actor is another  system interacting through a protocol such as TCP/IP; and a complex actor may be a  person interacting through a graphical user interface or a web-page. A weighting factor  is assigned to each actor category:    Simple: Weighting factor 1    Average: Weighting factor 2    Complex: Weighting factor 3  The total unadjusted actor weight (UAW) is calculated counting the number of actors in  each category, multiplying each total by its specified weighting factor, and then adding  the products.    2. The use cases are also categorized as simple, average or complex, depending on  the number of transactions, including the transactions in alternative flows. Included or  extending use cases are not considered. A simple use case has 3 or fewer transactions;  an average use case has 4 to 7 transactions; and a complex use case has more than 7  transactions. A weighting factor is assigned to each use case category:    Simple: Weighting factor 5    Average: Weighting factor 10    Complex: Weighting factor 15  The  unadjusted  use  case  weights  (UUCW)  is  calculated  counting  the  number  of  use  cases  in  each  category,  multiplying  each  category  of  use  case  with  its  weight  and  adding the products. The UAW is added to the UUCW to get the unadjusted use case  points (UUPC). 
  16. 16. Software Development Plan for ASK (MIS)  16 3.  The  use  case  points  are  adjusted  based  on  the  values  assigned  to  a  number  of  technical factors (Table 1) and environmental factors (Table 2).                                                          Table 1. Technical complexity factors                            Table 2. Environmental factors    Each factor is assigned a value between 0 and 5 depending on its assumed influence  on the project. A rating of 0 means the factor is irrelevant for this project; 5 means it is  essential.  The Technical Factor (TCF) is calculated multiplying the value of each factor (T1 ñ T13)  in Table 1 by its weight and then adding all these numbers to get the sum called the  TFactor. Finally, the following formula is applied:    TCF = 0.6 + (.01*TFactor)    Factor  Description weight  T1  Distributed system  2  T2  Response or throughput performance objectives  5  T3  End-user efficiency  2  T4  Complex internal processing  5  T5  Reusable code  1  T6  Easy to install  0.5  T7  Easy to use  0.5  T8  Portable  2  T9  Easy to change  1  T10  Concurrent  1  T11  Includes security features  2  T12  Provides access for third parties  1  T13  Special user training facilities are required  2  Factor  Description weight  F1  Familiar with Rational Unified Process  2  F2  Application experience  2  F3  Object-oriented experience  2  F4  Lead analyst capability  1  F5  Motivation  1  F6  Stable requirements  0.5  F7  Part-time workers  0.5  F8  Difficult programming language  2 
  17. 17. Software Development Plan for ASK (MIS)  17 The  Environmental  Factor  (EF)  is  calculated  accordingly  by  multiplying  the  value  of  each factor (F1 ñ F8) in Table 2 by its weight and adding all the products to get the sum  called the Efactor. The formula below is applied:  EF = 1.4+(-0.03*EFactor)  The adjusted use case points (UCP) are calculated as follows:  UCP = UUCP*TCF*EF      RELATED WORK    This  section  reports  two  experiences  with  estimation based  on use  case  points. Two  alternative  methods  and  one  tool  for  estimation  based  on  use  cases  are  described.  Finally, use case points are compared to function points.    USE CASE POINTS AND FUNCTION POINTS    The number of function points measures the size of a software application in terms of its  user  required  functionality.  Although  the  calculation  of  use  case  points  has  been  strongly influenced by function points, there are several important differences leading to  different strengths and weaknesses:  •  The  function  point  standards  do  not  require  that  the  input  documents  follow  a  particular  notation.  Use  case  points  are  based  on  the  use  case  model.  This  means that it is easier to develop estimation tools that automatically count use  case points; the counting is based on available documents (use case models).  This is an important difference, since counting function points frequently requires  much effort and skill.  •  There are international standards on how to count function points. The concept of  use  case  points,  on  the  other  hand,  has  not  yet  reached  the  level  of  standardization. Without a standard describing the appropriate level of detail in  the requirement description, i.e., the use case model, there may be very large  differences in how different individuals and organizations count use case points.  Hence, it may currently be difficult to compare use case point values between  companies.  
  18. 18. Software Development Plan for ASK (MIS)  18   DATA COLLECTION    Table 3 shows some characteristics of the three software development projects used in  our case studies.    Three Software Development Project are follows:    •  Project ñ A :Fixed Asset Management System   •  Project ñ B :Payroll Management System   •  Project ñ C :Provident Fund Management System     Characteristic  Project A  Project B  Project C  Size  23 months elapsed time,  2760 staff hours      Software  architecture  N-tier, established  before the project  As Project A  As Project A  Programming  environment  Visual Studio 2010, C# .net,, SQLServer 2008  As Project A  As Project A  Project members  1developers with 0 to  4 years experience  As Project A  As Project A  Application  domain  Finance,  part of a larger  solution  As Project A  As Project A        Our research project was conducted in parallel with project A during a period of Twenty  Three Months. Projects B and C, on the other hand, were finished before the start of our  research.  We  collected  information  about  the  requirements  engineering  process  and  about how the expert estimates were produced. We also collected information about the  use case models and actual development effort.      PROJECT EFFORT DISTRIBUTION    •  The 40-20-40 rule:  o  40% front-end analysis and design  o  20% coding  o  40% back-end testing  •  Generally accepted guidelines are:  o  02-03 % planning  o  10-25 % requirements analysis    o  20-25 % design  o  15-20 % coding  o  30-40 % testing and debugging 
  19. 19. Software Development Plan for ASK (MIS)  19   SOFTWARE PRODUCTION PROCESS    Various activities that take place during typical software development life cycle stages  need different process definition. Typical lifecycle activities are     •  Requirement analysis and specification  •  Architecture  •  Detailed design  •  Build and unit test  •  System and integration test    PRODUCTIVITY MEASUREMENT     Among  the  three  ingredients  that  impact  software  development  productivity  (the  product, the development resources and processes and the environment), the output is  the software product and input is the effort spent during software production stages. The  environment,  under  which  the  production  takes  place,  controls  the  variation  in  input  efforts.                              Figure: Productivity Parameters     
  20. 20. Software Development Plan for ASK (MIS)  20