Software Development Plan of Fixed Asset Management System

Software Development Plan for ASK (MIS)
Prepared for
Ain o Salish Kendra (ASK)
Prepared by
Md. Nasiruddin Juel

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
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
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
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
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
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
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
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
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.

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

EEssttiimmaattiinngg SSooffttwwaarree DDeevveellooppmmeenntt
SSiizzee,, EEffffoorrtt,, SScchheedduulliinngg bbaasseedd oonn UUssee CCaasseess

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
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
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
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
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

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,
ASP.net, SQLServer 2008
Project members 1developers with 0 to
4 years experience
Application
domain
Finance,  part of a larger
solution

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

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

Software Development Plan of Fixed Asset Management System

More Related Content

What's hot (20)

Viewers also liked (6)

Similar to Software Development Plan of Fixed Asset Management System (20)

Recently uploaded (20)

Software Development Plan of Fixed Asset Management System