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

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

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