Ppsp Group 5

7/31/2019 Ppsp Group 5

1/67

Principles & Practices of Software Production Group Assignment Page 1 of 67

Level 2 Asia Pacific Institute of Information Technology 2011

GROUP ASSIGNMENT

CE00003-2

PRINCIPLES & PRACTICES OF SOFTWAREPRODUCTION

PT0981 [CSE]

ASSIGNMENT TITLE: A2 DRIVING SCHOOL

GROUP NO. 5

Hand out date: 17th

Aug 2011

Hand in date: 14th

Nov 2011

Submitted by: Submitted to:

Akhilesh Bamhore (PT0981105)[GL] Mr. Prateek Mishra

Durgesh Kumar (PT0981128) Module Lecturer

Ravi Kumar (PT0981123)

Yogesh Kumar Yadav (PT0981121)


2/67



ASIA PASIFIC INSTITUTE OF INFORMATION TECHNOLOGY

PANIPAT

(Affiliated to Staffordshire university & Approved by AICTE)

CERTIFICATE

This is to certify that Akhilesh Bamhore, Durgesh Kumar, Ravi Kumar and Yogesh Kumar

Yadav of Software branch (Level-2) have completed their assignment and submitted it in due

time and have followed the appropriate steps which are prescribed by the University.

NameAkhilesh Bamhore

(Group Leader )Durgesh Kumar Ravi Kumar Yogesh Kumar

Yadav

Intake No PT0981105 PT0981111 PT0981126 PT0981109

Signature

Branch : Software, Level-2, Sem-5

Module : PPSP

Mr. Prateek Mishra

Signature of Module Lecturer


3/67



ACKNOWLEDGEMENT

We a re g r a t e f u l t o o u r a c a d e m y A P I I T S D I N D I A t o g i v e u s t h i s

a s s i g n m e n t . F i r s t o f a l l w e w o u l d l i k e t o t h a n k e v e r yb o d y w h o h a s h e l p e d u s

i n c o m p l e t i n g o u r a s s i g n m e n t . We a r e v e r y t h a n k f u l t o Mr. Prateek Mishra w h o

i s o u r l e c t u r e r . H i s t i m e l y g u i d a n c e a n d s u p p o r t a t c r u c i a l j u n c t u r e s m a d e

t h e u n d e r t a k i n g o f t h i s p r o j e c t a n e n r i c h i n g l e a r n i n g e x p e r i e n c e .

T h e l e a r n i n g e x p e r i e n c e w h i l e d o i n g t h i s p r o j e c t w a s a g r e a t

a c h i e v e m e n t f o r us . A n d f i n a l l y h e a r t f e l t a p p r e c i a t i o n t o f a c u l t i e s a n d o u r

m a t e s o f A P I I T , w h o h a v e s u p p o r t e d u s i n a l l t h e s t e p s w e h a d u n d e r g o n e i n

c o m p l e t i n g o u r p r o j e c t .

Thanking You,

Akhilesh Bamhore (Group Leader)

Durgesh Kumar

Ravi Kumar

Yogesh Kumar Yadav


4/67



TABLE OF CONTENTS

S.NO. CHAPTERS PAGENUMBER

1 Introduction 6

2 Problem Background 8

3 Proposed Solution 8

4 Project Planning Control 10

5 Project Management 13

6 Schedule Planning 17

7 Selection of Methodology 21

8 Cost Estimation 23

9 Risk Management 26

10 Requirement Analysis 34

11 Process Modeling 38

Context diagram 38

1. Level 0 DFD 39

2. Level 1 DFDs for the Level 0 processes 40

12 Process Specification 41

1. Structured English 41

13 Data Modeling 43

14 Logical Data Models: 44

1. Entity Relationship Diagram

2. Entity Life History

46

15 Data Dictionary for Proposed Systems 47

1. Data flows 47

2. Data Stores 47


5/67



3. Processes 47

4. Source and Sink 47

16 Design Principles and Concepts 52

17 Architectural Design 55

18 Interactive Screen Design 57

19 Programming Environment 62

20 Testing 63

21 Conclusion 66

22 References


6/67


7/67



client. This interview session is created to make both the trainer and trainee

comfortable for the other sessions.

2.2 In this step the main work begins for the training session. The instructor has the

authority to use the car for the personal work also. The trainee is given the training

lesson by lesson.

2.3 Once the training is over the client will ask for the exam to be conducted. The trainer

will prepare the trainee for the both exam written as well as practical.

Task: As a software engineer we are assigned to make an efficient computer based system

which will carry on the day to day task of the A2 motor driving school.

Scope of the Proposed System: This system can be deployed on the server and can be used

by the remote system to access the files and upload their data as well. This system can be

used by all those driving schools which do not have their computer based database and are

working on the file based system today also. The scope of this project is very large as

compared to others similar type of project.

Objectives: this system will add the details of the new student, instructor details, lesson

details, add new branch (only admin has this privilege), change the instructor in between the

course(Student has this option), schedule the lesson etc.


8/67



Chapter 02-Problem Background

A2 Driving School was established in Delhi in 2002. Since then, the school has grown

steadily and now it has several offices in most of the main cities of India. The administrative

staffs from different branches need to communicate very often which is tedious. Also there is

no such method from which the director can view the details of the students studying in his

company and he is not able to find out daily progress on time. To monitor the whole

organisation there is a need of developing a efficient system. The working of the system is as

follow:

1. Register the client

2. Schedule Interview

3. Take Interview and check for the valid provisional driving licence of student

4. Book lesson

5. Schedule training

6. Record day to day progress of student

7. Register student for driving test

8. Record the result and if student fails give the reason for it (for instructor only).

Chapter 03-Proposed Solution

A2 Driving School is facing a lot of problems related with the system e.g. the people from

different branches are not able to contact with each other in an efficient way. They are not

able to provide an up to date system to a client who are willing to learn motor driving. So the

director of the A2 motor Mr. Shiv Chand has hired us as software engineer. So as to develop

software which will help the A2 motors running in a good manner this system has been

developed. As the system is being developed for a new system so there is a need of

registering each and every component of the driving school. E.g. the system has to register a

lesson before scheduling lesson, register an instructor, register a branch etc. the access

privilege has been given accordingly to the user of the system. The module for each and

every components of the system along with their accessibility is given below.

Administrator (Director): Mr Shiv Chand is the director of A2 motor school and he has the

highest access privilege. He can view all the reports generated in the system.


9/67



Branch Manager (Senior Instructor): This is usually the senior instructor of the system.

He/she will have the highest access privilege for that particular branch only where he/ she is

assigned to do the work. E.g. he/ she can see the instructor details, add or modify lessons,

costs, vehicles etc. Further he/she is responsible for the day-to-day running of the office.

Instructor: Instructor has the authority to view the details of only those clients who are

under their guidance. View the schedule of the lessons. Register the student for the test. Give

the feedback for the student and take the interview of the client i.e. student.

Receptionist: He/she has the very low priority but very important work to do i.e. to register a

student for the driving lesson, book a lesson, change the instructor on the demand of student,

and schedule a lesson.

Student: He/ she have the lowest priority and can only view his/ her details and result only.

To obtain a full driving license the client must pass both the practical and theoretical parts of

the test. It is the responsibility of the Instructor to ensure that the client is best prepared for all

part of the test. The Instructor is not responsible for testing the client. If a client fails to clear

the test for the driving license, instructor must record the reasons for the failure.

To do all these activities the system is developed on asp.net platform with MS access

database. This is software with many forms and links with a normalized database which has

been shown in the ER diagram.


10/67



Chapter 04-Project Planning Control

Planning any software means identifying each element of the specific tasks that must be

accomplished to complete that particular task. Division of works must be done so that who

and when that work will be done. Planning also comes handy in deciding and identifying the

activities and the outcomes or the deliverables of the project. Good project planning means

identifying, early and continuously, the specific tasks that must be achieved; considering the

resources in money, personnel, facilities, and time available. Project planning is necessary to

keep a control on the various factors affecting the project so as to deliver the project on time

within the constraints of cost and risk. The quality management also plays an important role

in any project planning and control keeping the documentation standards high and accurate.

Management expects and demands that technical work be administered and controlled

effectively. The planning done in this system is as follow:

Understood the scope of the system i.e. A2 Driving motor school. This provided the

destination in terms of the solution to the current problems.

Various entities (Vehicles, branches, fares, etc.) in are covered under planning

activity and it helped the system to define priorities and the project constraints.

The student has the facility to change the instructor in between the course and opt for

a particular instructor.

This system is intended to identify how it can ensure quality in terms of Software

quality Assurance Plan, Documentation standards, Programming standards all of

which are discussed later.

Risks have been considered at all the stages of the planning and the risks that will

have high impact and high probability in the development and delivery of the system.

This system is made more realistic in terms of software development process.

For the final plan of the project, the system has undergone Boehms W5HH Principle. It

follows as:-

1. Why is the system being developed: This system is being developed to help A2

motor driving school in an easy and efficient way. This will help in running the

organisation in a successful way.

2. What will be done: The different functionalities have been listed down as proposed

solution for the current system. This includes the functionality to be built and the


11/67



tasks required to meet the needs of the Driving school and the work would be done as

per the prepared format. The reports of the system will be generated in efficient way.

3. When will it be accomplished: The scheduling of the project is covered under the

topic schedule planning of the project.

4. Who is responsible for a function: A rough Work break Down Structure was made

and distributed among the group members each being assigned some common and

some specific functions.

5. Where they are organizationally located: the identification of branches of the

driving school and the developers location, the same was studied for other

stakeholders like members, non-members, branches etc.

6. How will the job be done technically and managerially: After establishing the

scope for the project, a management and technical strategy for the project has been

decided.

7. How much of each resource is needed: Keeping resource allocation in mind the

costs planning has been done.

The other Project Control activities have been mentioned below:

1. Software Configuration Management: Configuration Management is unique

identification, controlled storage, change control, and status reporting of selected

intermediate work products, product components, and products during the life system.

Following are the features of SCM:

a) Versioning: As this project progresses, many versions of individual work products has

been created. The repository is there to save all of these versions to enable effective

management of all product releases and to permit the system to go back to previous versions

during testing and debugging.

b) Dependency tracking and change management: The relationships between the

enterprise entities and processes have been made and all these are stored in the repository.

c) Requirements tracing: This special function provides the system the ability to track all

the design and construction and deliverables that result from a specific requirements

specification (forward tracing). It also provides the ability to identify which requirement has

been generated and what are the given work product. (Backward tracing)

d) Configuration Management: This facilitates us to keep a track of a series of

configurations representing specific project milestones and product releases.


12/67



e) Audit Trails: It helped the system to establish additional information about when, why,

and by whom changes are made. All the information about changes can be entered as

attributes of specific objects in the repository.

By implementing the SCM in this project the system got a series of tasks like identifying all

the items that collectively define the software configuration, to manage the changes on one or

more of these items, to facilitate construction of different versions of this A2 motor driving

school and to ensure that the software quality is maintained as the configuration evolves over

time.

2). Software Quality Assurance Plan: its an umbrella activity, incorporating both quality

control and assurance that is applied at each step in the software process.

a) The system has focused in maintaining the standards of ISO 9126, a quality standard since

1980 which consists of attributes like functionality (Suitability, Accuracy, Interoperability,

Security), reliability (Maturity, fault tolerance, recoverability), usability (Understandability,

learnability, operability), efficiency, maintainability, portability.

b) A SQA plan has been made and reviewed by the system and other suitable stakeholders

and all the quality assurance activities were performed by the system and governed by the

plan.

c) Any process that the system has taken has been reviewed in compliance with the A2 Motor

Driving policy, internal software standards, and externally imposed ISO 9126 standard.

2. Documentation Standards: The complete system has been reviewed in adherence to

high quality standard and will be handed to the A2 Motor Driving School at the time

of software delivery. This will involve the documentation to match to the standards of

ISO 9001:2000 fulfilling effectively all the 20 requirements that must be present for

an effective quality assurance system. A set of policies and procedures are to be

established to address each of the 20 requirements as per the ISO 9001:2000 standard.

3. Risk Management Plan: The system has its own risk management plan where the

software risks have been be viewed within the context of the system only in which it

is a component of the A2 Motor Driving School so that the problem is intended to be

solved. The system also thought and still thinking about the risks that may arise in the

future such that all of them are manageable. Planning to integrate any risk

consideration in this software development has been undertaken. The system

encourages open communication from all the stakeholders to suggest risks at any time

in a formal or informal manner. The main risk related with any system is the risk of


13/67



not being developed on time, for this system has already prepared a demo of the

software.

4. Programming Standards: The system has maintained good programming practices

in this software development process. The documentation has gone parallel to

programming. All the indentation rules will be followed and the variable names have

been taken as that of a meaningful one to the attribute its focusing on in the system.

Proper validations have been added when and where required for all the fields in any

form.

Chapter 05-Project Management

Project Management involves the planning, monitoring, and control of the people, process

and events that occur as software evolves from a preliminary concept to an operational

implementation.

It is a carefully planned and organized effort to accomplish a specific goal. It includes

developing a project plan, which includes defining project goals and objectives, specifying

tasks or how goals will be achieved, what resources are need, and associating budgets and

timelines for completion. Implementing the project plan, along with careful controls to stay

on the "critical path", that is, to ensure the plan is being managed according to plan. Project

management usually follows major phases, such as feasibility study, project planning,

implementation, evaluation and support/maintenance.

The distinctive characteristics of the project management are:

Scope: It defines what will be covered in a project (already defined in the chapter 1).

Resource: It defines the objects or the equipments required to complete the project.

Time: It describes the tasks to be performed according to the schedule and the period

for which the work will continue.

Quality: It is the spread or deviation allowed from a desired standard.

Risk: It defines what threats a system can face and search for a prior solution to

manage all the risks.


14/67



Resources required: Needful action is very much important in developing any software

projects along with the proper allocation and management of the resources available.

Different hardware resources required for developing the system are:

1. Hardware Requirement: Computer for each developer members equipped with

keyboard and mouse, So that every developer member can parallel work upon

coding, testing, documentation and other software development component.

2. Software Requirement: For the development process

i. ASP.net (platform for developing code and design of the system),

ii. MS Access (Back End for storing data)

iii. MS Word (documentation purpose),

iv. MS Access (creating and maintaining database),

v. MS Visio (DFD designing),

vi. Web browser (to gather necessary details).

Besides these human resources is also important and its the job of group leader to assign the

task of each of the group members based upon the skills of the individuals. The percentage of

the work done by each member has been discussed in the workload matrix section.

Major tasks performed by the team:

Each group member was assigned to do a particular task and every task and the main task

performed by the team as a whole are as follows and the explanation of each of the task is

being taken care of in the further part of the documentation:

Project planning and scheduling

Requirement analysis

Selection of methodology

Cost estimation Risk management

Process modelling

Architectural Design

Project monitoring and reviews

System testing

Project planning: It is probably the most time consuming project management activity

and is a continuous activity from initial concept through to system delivery. Plans must be


15/67



regularly revised as new information becomes available. It is a part of project

management which relates to the use of schedules such as Gantt charts to plan and

subsequently report progress within the project environment. Types of project plan are as

follows:-

Plan Description

Quality plan Describes the quality procedures and standards that will be used in

the project. In our project the team tried to maintain the consistency

in each form by designing the master page.

Validation plan Explain the approach, resources and schedule used for system

validation. During the project the team strictly followed the

validation for each of the unit and application wherever necessary.

Configuration

management plan

Express the configuration management procedures and structures to

be used. For more detail refer to project planning control.

Maintenance plan Predicts the maintenance requirements of the system, maintenance

costs and effort required. Flexibility has been provided to set the

rules & regulation and coding will be done in such a way that the

enhancement can take place anytime whenever required.

Staff development

plan

Elucidate how the skills and experience of the project team

members will be developed. Work divided according to the

experience, capability and talents among the team members.

Project planning process:

Table 1

Establish the project constraints: Project constraints can be proposal writing, project

planning & scheduling, project costing, project monitoring

& reviews, personnel selection & evaluation, report

writing & presentations and etc.

Make initial assessments of the project parameters: Prepare task schedule chart and

follow the schedule strictly. Keep monitoring and

reviewing of the project after a regular interval of time.

Distribute the work among the team members according to

the talent and experience of each individual.


16/67



Define project milestones and deliverables: Milestones are the end points of any project

which must be completed within the specified frame of

time in order to make the project a successful one.

Different activities along with the deadline have been

mentioned in the Gantt chart.

While project has not been completed or cancelled loop: Perform the understanding

activity till the condition become false.


17/67



Chapter 06-Schedule Planning

GANTT CHART


18/67



PERT CHART

Data

GatheringA3

Database

Design

A1 A5

Systems

Design

Project

Initiation

A2Coding

Construction

A7

Start

Requirements A6Analysis Implementation

Planning

Testing A8

A4

Maintenance Documentation

Finish


19/67



Start

Wed8/17/11

PERT CHART (Network Diagram)

Introduction ProblemBackground ProposedSolution SchedulePlanning SelectionofMethodology

1 2DAYS 2 2Days 3 3Day 4 2DAYS 5 5Days

Wed8/17/Thu8/18/11

11 Fri8/19/11 Sat8/20/11Mon8/22/11

Wed8/24/11

Thu8/25/11 Fri8/26/11 Thu8/25/11Wed8/31/

11

ProjectPlanningControl CostEstimation RiskManagement ProjectManagement RequirementAnalysis

6 3Days 7 3Days 8 5Days 9 2days 10 5Days

Thu9/1/11 Mon9/5/11 Thu9/1/11 Fri9/2/11 Tue9/6/11 Mon9/12/11 Thu9/8/11 Fri9/9/11 Tue9/13/11Mon9/19/11

ProcessModeling DataModeling DataDictionaryDesignPrinciplesand

ConceptsArchitecturalDesign

11 5Days 12 3Days 13 5Days 14 11Days 15 6Days

Tue9/20/11Mon9/26/11 Tue9/27/11Thu9/29/11 Fri9/30/11 Thu10/6/11 Thu9/29/11Thu10/13/

11Fri10/14/11Fri10/21/11

InteractiveScreen

Design

ReportDesignProgramming

Environment

TestingOverallDocumentation

(Layout)16 4Days 17 4Days 18 3Days 19 5Days 20 5Days

Mon10/24/ Thu10/27/ Tue10/25/ Sun11/13/

11 11 11Fri10/28/11

Fri10/28/11Tue11/1/11 Tue11/1/11Mon11/7/11Tue11/8/11

11

Finish

Wed11/13/11


20/67



WORKLOAD MATRIX

No. Components Max

MarkAkhilesh

Bamhore

Durgesh

Kumar

Ravi

Kumar

Yogesh

Kumar

Yadav

1 Introduction 2 20% 40% 20% 20%

2 Problem Background 2 40% 20% 20% 20%

3 Proposed Solution 4 25% 25% 25% 25%

4 Schedule Planning 2 20% 20% 40% 20%

5 Selection of Methodology 5 20% 40% 20% 20%

6 Project Planning Control 5 20% 20% 20% 40%

7 Cost Estimation 5 20% 20% 40% 20%

8 Risk Management 5 40% 20% 20% 20%

9 Project Management 5 20% 20% 40% 20%

10 Requirement Analysis 5 40% 20% 20% 20%

11 Process Modeling 10 25% 25% 25% 25%

12 Data Modeling 5 20% 40% 40% 20%

13 Data Dictionary 5 20% 20% 20% 40%

14 Design Principles & Concepts 8 25% 25% 25% 25%

15 Architectural Design 8 25% 25% 25% 25%

16 Interactive Screen Design 5 40% 20% 20% 20%

17 Report Design 5 20% 20% 20% 40%

18 Programming Environment 2 20% 20% 20% 40%

19 Testing 7 25% 25% 25% 25%

20 Overall Documentation

(Layout)

5 25% 40% 25% 25%

Signature


21/67



Chapter 07-Selection of Methodology

Its very important to go through a series of predictable steps, whenever we are going to build

a system- a road map that helps us to create a timely, high-quality result and the road map

that we follow throughout our project is known as a system methodology.

Why selection of any methodology?

It is advised to adopt a specific methodology to develop a system because of the following

reasons:

Provides stability to the system development process.

Provides greater control over the system development.

For allocating the right resources at right place.

The focus remains clear and time estimation can be made which can be followed

throughout the project.

Every methodology has its own characteristics and scope, so its very important to select the

best suitable methodology based upon the nature of the system and its respective parameters.

These parameters can include resources available, stipulated time estimation, budget, risks

involved and etc. Various system methodology persists in todays world are;

waterfall(lifecycle) model, prototyping model, rapid application development(RAD)

model, incremental model, spiral model, hybrid model and etc. Out of these model Hybrid

model has been selected for the development of the system keeping in view of the various

parameters that can affect the system development.

Methodology Selected: This system has adopted the hybrid model of system development.

Purpose of selected methodology:

Hybrid model is basically a mixture of waterfall and spiral model which encompasses nearly

the best features of these models. It makes the use of a structured method for the requirement

analysis and specification stages. It follows waterfall model till the requirement analysis

phase and further the spiral model comes into the picture for physical designing and

construction phases. Finally waterfall is being followed for implementation and operation &

maintenance phase.


22/67



Reasons to select Hybrid Model:

Provides flexibility in meeting the user requirements which is a very difficult scenario

in waterfall model.

Less time consuming as it doesnt follow the approach of throwing and rebuilding the

prototype.

It doesnt require ample of human resources to work on the project simultaneously.

Ensures requirements analysed and well documented.

Ensures rapid user-driven software delivery.

Useful and is mostly used model where implementation is a prototype.

Scope of Hybrid Model:

Documentation takes place in parallel with the system development; if any change

arises in the requirement then the whole documentation may needs to be modified,

which results in an expensive and time taking documentation.

The attainments of ultimate goal of the project that is to learn the software

engineering concepts as well as completion of the project on time.

Determine and understanding well in advance the appropriate flow of the project how

sequence of the progress will flow.


23/67



Chapter 08-Cost Estimation

Software cost estimation is the process of predicting the effort required to develop software

System .Software cost estimation is not an exact science. Variables like human, technical,

environmental, and political, etc. affects the ultimate pricing of the software. However, many

cost estimation techniques each having its own set of distinctive strength and weaknesses

have been proposed in the last 30 years, which have transformed cost estimation from a black

art to a series of systematic steps that provides estimates with acceptable risk. The various

cost estimation techniques available today are:

Expert judgment: One or more experts in both software development and the

application domain use their experience to predict software costs. Process iterates

until some consensus is reached.

Estimation by analogy: The cost of a project is computed by comparing the project

to a similar project in the same application domain.

Top-down estimation: Start at system level and work out how the system

functionality is provided. It takes into account costs such as integration, configuration

management and documentation.

Bottom-up estimation: Start at the lowest system level. The cost of each component

is estimated individually. These costs are summed to give final cost estimated.

Algorithmic Cost Modelling: Cost is estimated as a mathematical function of

product, project and process attributes whose values are estimated by project

managers.

Parkinsons Law: The project costs whatever resources are available

Pricing to win: The project costs whatever the customer has available to spend on it.

Constructive Cost Model: The model was first published by Dr. Barry Boehm in

1981, and reflected the software development practices of these days. This is

described below.

Selected model: For this system COCOMO Model has been selected and its reason for

selection is given below.

COCOMO MODEL:

The original COCOMO stands for Constructive Cost Model. The word "constructive" implies

that the complexity of the model can be understood because of the openness of the model,


24/67


25/67



a and c, b and d are developed by Boehms own experience and judgement rather than

statistical analysis, depend on the development mode of the project.

2. No. of People, N=E/D

COST ESTIMATION IN A2 MOTOR DRIVING SCHOOL

1. Calculating Adjustment Multiplier, m(X):

Cost Driver(Xi ) Rating Value

Required Software

Reliability

High 1.15

Size of the Database Low 0.94

Complexity of the System Low 0.85

Computer Turnaround

Time

Low 0.87

Capability of Analysts High 0.86

Applications Experience Nominal 1.00

Capability of Programmers Nominal 1.00

Programming Language

Experience

High 0.95

User of Software

Development Tools

Very low 1.24

Existence of Required

Development Schedule

Very High 1.10

Now, m(X)=m(Xi)

Table 2

=1.15*0.94*0.85*0.87*0.86*1.00*1.00*0.95*1.24*1.10

=0.891

Estimated Lines of Codes: 3500Lines of Codes=3.5LOC

Therefore, Development Effort, E=aSbm(X)

In this case,

a = 3.2 (for Intermediate Organic COCOMO)

b=1.05

S=3.5

m(X)=0.891


26/67



Thus, E=3.2*3.51.05

*0.891=10.6=11 person-months

Development Time, D=c*Ed

Here, c= 2.5

D=0.38

Therefore, D=2.5*110.38

=6 Months

Number of people, N=E/D=11/6=2 persons (approx.)

Therefore, the project can be finished within 3 months by a group of 4 persons this is what

required by the A2 motors driving school.

Chapter 09-Risk Management

Risk management is a project management tool to assess & mitigate events that might

adversely impact a project, thereby increasing the likelihood of success.

RiskManagement

RiskAssessment

Risk control

RiskIdentification

Risk AnalysisRisk

Prioritization

Riskmanagement

Planning

RiskResolution

Riskmonitoring

Fig 4:- Risk Management Activities


27/67


28/67



Gold plating 2

P=0.5

L= Rs. 15,000

R.E. = 7,500

First of all the entire criteria of

project specification to be fulfilled

and further the additional features

will be met. Each of the team

members will be aware of the system

requirements.

Poor understanding

of the system

development tool

3

P=0.4

L= Rs. 7,500

R.E. = 3,000

All the group members gone with the

concepts of PHP and its

implementation for better

understanding of the system

development tool.

Continuing stream

of requirements

changes

4

P=0.2

L= Rs. 8,500

R.E. = 1,700

Hybrid model has been followed to

overcome this risk.

Personnel shortfalls 5

P=0.4

L= Rs. 5,800

R.E. = 2,320

Assigning the task according to the

talent of the group members and

rotate the system deliverables among

the members.

Risks associated

with incorrect &

optimistic status

reporting

6

P=0.3

L= Rs. 7,000

R.E. = 2,100

Regular monitoring of project and its

respective module assigned to

responsible group member is to be

taken care of.

Developing the

wrong functions

and user interface

7

P=0.15

L= Rs. 9,000

R.E. = 1,350

Analyzing the meaning of each line

given in the project specification and

concentrate on what is required by

the user of the system. We will

strictly follow the design principals

Table 3

Risk management is a central part of any organizations strategic management. It is the

process whereby organizations methodically address the risks attaching to their activities with

the goal of achieving sustained benefit within each activity and across the portfolio of all

activities. The focus of good risk management is the identification and treatment of theserisks. Its objective is to add maximum sustainable value to all the activities of the


29/67



organization. It marshals the understanding of the potential upside and downside of all those

factors which can affect the organization. It increases the probability of success, and reduces

both the probability of failure and the uncertainty of achieving the organizations overall

objectives. Risk management should be a continuous and developing process which runs

throughout the organizations strategy and the implementation of that strategy. It should

address methodically all the risks surrounding the organizations activities past, present and

in particular, future. It must be integrated into the culture of the organization with an effective

policy and a program led by the most senior management. It must translate the strategy into

tactical and operational objectives, assigning responsibility throughout the organization with

each manager and employee responsible for the management of risk as part of their job

description. It supports accountability, performance measurement and reward, thus promoting

operational efficiency at all levels.

The software risk components are as given below:

Performance Risk

Cost Risk

Support Risk

Schedule Risk

Technology Risk

Types of Risk Management

Performance risk: - It is the risk which might be thought like whether the system will

perform well or not. This risk has been discarded as before developing the system. The

developers have gone through the analysis and planning phase in a good manner.

Cost Risk:-At the time of planning the system we estimate a budget that will decide the cost

expenditure of project, but when system completed and cost came more than estimated cost,

so, we have to manage it, this is called Cost Risk like. In A2 motor driving school only the

basic functionalities have been provided so there is no fear of cost risk

Support risk: - It suggest that different type of supporting tool which will apply to develop

the system, if it will not work properly at the time of implementation so this type of risk

called as support risk, it generally happens when we make the program of system but at the

time of debugging it shows errors which makes the system halt, so that working of system get


30/67



stop, this risk called as support risk. This risk was sort out during the development as there

were two systems in back up.

Schedule risk:-It suggest that activities which will perform on system on given time , it

didnt completed successfully on the scheduled time , it cause delay of project completion for

any organisation such risk called is known as schedule risk , this risk has been avoided by

completing the projects individual tasks on time.

Technology Risk: - This Risk factor come, when we will develop new features for our

system but it will not work well at the time of implementation thus it causes some technical

error on the system, so system software working became stop and hang the system .such risk

are known as Technology Risk.

Risk Identification

A checklist of the risks that may arise during the development of this system are identified as

under-

Schedule Slippage-. The delivery date of the software may vary due to the delays in

developing the system. Unfortunately the customer may have to wait for a period in

order to receive the system

Poor design- A private software company is adopted for the development of this

system there is every possibility the designer has rushed through the design process in

order to get the coding started quickly.

Competitive risk- Existing system in the market pose a great risk towards other

newly implemented systems. Motor Driving School Systems are being developed on

daily basis; hence the system which will be implemented will depend on how

competitive it is in the market.

Substandard quality- The programmer got behind schedule and desperately needed

to catch up. To catch up, the programmer decided to quickly code the next feature

and not spend the time testing the feature as they should have. Once the feature went

to the. Testing team, a lot of bugs were found, causing the testing / fix cycle to extend

far beyond what was originally expected.


31/67



Project cancelled- after numerous schedule slips the customer loses confidence that

the project can never be completed. Another reason might be that the Business

process changes, which leaves the software incapable of solving the new business

problems. So the customer decides to cancel the whole project.

System built with basic feature- there are very few advanced features used in the

system as a result customer is not satisfied with the system.

False feature rich- the system has great feature but unfortunately they are not useful

according to the customer but the programmer thinks they are great feature.

System crash- there is a possibility of a hardware failure during the development of

the system.

Over budget- Chances that the system will cost more than the estimated budget is

considered.

Risk Analysis

After identifying the possible risks there analysis starts in two phases, one the possibility of

its occurring and the second is the consequences of them. Here is the analysis done by the

team after identification-

Schedule slippage- The risk of having a schedule slippage is not so high. However

the consequence caused by it is very high. The customer can lose faith in the team; he

can abandon the system also.

Poor design- There is a high possibility of a poor design due to the adoption

Waterfall methodology. This causes problem for the programmer while coding and a

design which is reusable allows changes to be made quickly and also lessens testing.

Competitive risk- this is the biggest risk in front of the development team. There is a

high possibility that customer switches over to some other system if he comes to

know that a better system is present there in the market.

Substandard quality- to add some advanced features programmer lags behind in the

schedule and there is a moderate possibility that such a thing can happen. This result

in the development of a very ordinary quality system due to which the competitors


32/67



gets an edge. It also increases the work of testing team as they are busy in removing

bugs of the system.

Project cancelled- it is not a high risk however there is possibility if the customer

loses faith in the development team. This will result in the loss of customer by the

team as well as the reputation of the team. It will also lead to wastage of all the work

and the cost that the team has already put into the development of the system.

System build with basic feature- There is a high possibility of this risk due to the

lack of time. This will result in the dissatisfaction of the customer and the next time

he needs a system he might not call us.

False feature risk- there is a slightly less chance of occurrence of this risk. This will

result in the false advertisement of the system and also the customer might not use the

system to its full potential.

System crash- this is possibly the least probable risk that might occur during the

development of the system. This will result in losing up of all the data and also all the

work that has been contributed in it.

Over budget- it has a moderate risk of occurrence but if it happens then the client

may not buy the system and the team will incur a heavy loss not only in terms of

money but also in terms of work.

Risk Assessment

The following things need to be done to remove or reduce the risk that has been identified:-

Schedule slippage- The project is split into small release cycles. In each cycle

something valuable to the customer is implemented as a result even if the project gets

late, the most important and valuable parts would be working.

Poor design- The only way to overcome this risk in not to rush through the design

phase in order to get the coding and starting connectivity of databases with Webpages.

Competitive risk- knowledge about the competitor should be kept in order to be

competitive in the market.


33/67



Substandard quality- first all the required features of the project will be done and

then only work on some advanced features will be started in order to increase the

quality of the project.

Project cancelled- the A2 Motor Driving School is involved in each of the release

cycle so that he has an idea about the project in which way it is headed. This will help

him change the direction of the project as his business need changes. Also if the

project gets late he has the most important parts working so he will be less inclined in

cancelling the project.

System build with basic feature- proper planning about the development of the

project will reduce this risk to a great extent as now the team will have sufficient time

to add extra features to the project.

False feature rich- in each release cycle, the customer will be allowed to pick

features that are important to him - he will be picking features that are relevant to his

business process and not the processes that are a programming challenge.

System crash- A backup of all the work will be made at the end of each release cycle

so that if the system crashes programmer will have all the data of the previous release

cycles.

Risk prioritization

The risk based prioritization using the core set of information has been carried out during the

registration phase and result in easy registration for substances shown to be of low concern.

Only if a concern has been identified and if safe use cannot be demonstrated should the

natural progression be to move on to the evaluation phase and subsequently to the

restriction/authorization procedure.

Prioritization based on risks will help focus the use of resources on hot spots:

Time and (limited) financial resources that would have been devoted to the collection of

data on lower risk substances (as in the current draft) with little if no improvement of

health and environmental protection, can be saved or better redirected to address higher

priorities. The system is made more cost effective for all.


34/67


35/67



Details of Instructors as well as branch manager

No. of students registered per day.

They can easily generate reports.

He has the highest access privilege.

4. Instructors:

Can view the details of student under his/her guidance

Can give feedback to the system about the students progress.

View Scheduled lessons

Register the student for the test

Register the student as pass or fail after the exam.

5. System Developers: The requirements of the developer team to make the system are

as follows.

Proper software and hardware availability.

Proper preparation of milestones.

Proper work scheduling.

Co-relation between the team members.

Functional requirements from the system: It describes the functionalities and performanceof the A2 Motor Driving School system. We have found the requirements based on our

software.

Record of all staffs as well as the students.

Instant report Generation for all the functionality

Payment and billing records.

Day to day reports of all fields

Interface Specification: The system which we are developing for this assignment is based on

client server architecture. Following are the hardware and the software requirements for this

system.

Hardware Interface: P4 processor.

Software Interface: ASP.net.


36/67



Communications Interface: Screen, Keyboard

Memory Constraints: 128 MB.

Data Requirements:

INPUT- Data input comprises of data being entered in

Student Registration Input

Admin Registration Info

Schedule Interview

Book Lessons for a particular student

Register a particular lesson

Register an Instructor

Feedback from the instructor

Change of an Instructor as on demand of student

Register a new Vehicle

Modify the above records

OUTPUT- Data out will provide information in form of output

Student Details(By student, all)

Instructor details (for admin access only by all or by branch)

Slip of payment with lessons details for student purpose.

Vehicle details

All other details from the above input fields


37/67



Techniques used in Requirements Elicitation, Analysis and Requirement Validation

Elicitation Techniques

The various elicitation techniques used in our project are brainstorming session (a meeting is

held where every member gives there idea and does a brainstorming), storyboarding (It

clearly explains the series of steps needed to complete the business event to the

customer/user), Prototyping/Mock-up (It is built for developers, users, and customers to

better understand system requirement).

Requirement Analysis

It basically deals with the relationships among various requirements and shaping those

relationships to achieve a successful result. The various requirement techniques used in our

project are Define the system, specify the goals, constraints and boundaries of the system.

Requirement Validation

It ensures that the requirement satisfies the condition of the system. The various requirement

validation techniques are Requirements reviews, Prototyping and Test-case generation. It is

always found that the longer the error is undetected the more the cost of correcting it .So, it

was very important to detect errors in the requirements before actual designing of A2 Motor

Driving School System could start. The work product that we got after requirement

engineering was accessed for quality here. Under this stage we examined all the gathered

information to insure that all software requirements have been stated unambiguously and

errors were gathered and corrected. The whole process was divided into primary and

secondary levels. The primary level consists of formal technical review team consisting of

group members and some end users who looked for areas where further modifications can be

done. In order to do this we came up with validation checklist that had subsets like:-

Are requirements stated clearly? Can it be misunderstood?

Is each requirement testable?

Is the initial state of the system defined?

Are the responses to exceptional conditions specified?

Are possible future modifications specified?


38/67


39/67



LEVEL 0 DFD

Examination

Customer

Give Money

4.0

Generate

Bill

Request for test

Request for register

Monitor exam

9.0

Conduct

exam

Send Result

Give Report

Manager

Book Lesson

Save Report

Send Invoice

Send account Report8.0

GenerateSend exam Schedule/

Send Result

5.0

Report

2.0

Conduct

Create

Invoice Send Report

Interview

Send Report

Send report

Take

Interview

Lesson Report

Book Lesson

3.0

Book

Lesson

Lesson Report

7.0

Conduct

Training

Train Client

Schedule Interview

1.0 6.0Schedule Training

Booking

Dept.Book Client Register

ClientDriving Service

Schedule

DriveInstructor

Client Info.

Car

Scheduling drive


40/67


41/67



Chapter 12-Process Specification

This includes description of data structure for some of the important processes in the A2

Motor Driving School System. Each of the records mentioned below corresponds to a table in

a central database. It gives information of the necessary and optional fields in the processing

of required data for the process fulfillment. Some of the processes are shown below and for

more details please look at the Level 0 and Level 1 diagram.

Using Structured English

Process: View Reports

Authorization = ID + Password

The reports will be shown according to the authorization. E.g. Manager can view details of

each and every instructor but vice- versa is not true.

Process: Student Info

Customer Record = Id+ Provisional Driving License No.+ Name+ Fathers Name+ Date of

Birth+ Permanent Address + Address of Correspondence+ Email + Instructor Id + Contact

no. + Date of joining the institution.

Process: Vehicles

Vehicle Record=Vehicle No. + Vehicle Model

Process: Lesson Cost

Cost=Type of lesson + discount.

Fare Record = Rout Number + Business Class (Fare) + Economy Class (Fare)

Process: Change Instructor

Record=Instructor Change no. + Old Instructor Name+ New Instructor+ Student Id

Process: Register Lesson

Record=Lesson No. + Lesson Cost+ Lesson Details


42/67


43/67


44/67



ER Diagram(A2 Motor Driving School)

Manager_I

d

NameDate of

Promotion

Inst_id

(Optional)

Stud_id

Date

Name

Stud_pdno

Inst_id*

Feedback_no*

Vehicle_no V_model

Manager

Stud_dob

Stud_padd

Stud_cadd

Booking_no*

Change_no*

has Rides

Vehicles

contains

Booking Dept. Schedules

Primary Key Stud_id

Booking_

no

Lesson_c

ost InstructorsForeign Key Inst_id*

Stud_id Date

Inst_id

Lesson_i

d

Inst_id

Inst_name

Inst_dob

Gender

Relation

Atribute

Inst_fnameInst_drevingln

o.Entity

Inst_mob Inst_payment

Page 1


45/67


46/67


47/67



Chapter 15-Data Dictionary

The data dictionary of the proposed system consists of 4 elements.

1. Data Flows

2. Data Stores

3. Processes

4. External entities (Source & Sink)

Data Flow: - Data Flow are groups of data that move and flow through a system from

one place to another. It Include names of all individual elements of data moving. Data

flow is represented by arrow arrows depicting movement of data

E.g. Status of student

Current Status, Test status, Final grade

Data store: - Data Store refers to data at rest that may represent one or many physical

locations. Each data store has a label and number (number of files location). Data

store is represented by a rectangle

E.g. data about students

D1 Exam/grad file

Processes: - Process are the action performed on data so that they are transformed

(manual or automatic), stored or distributed, each process includes a name & processnumber. It is represented by rectangle with rounded corners or a circle as shown in the

level 0 diagram.

E.g. Register Student

1.

Register


48/67



Source and Sink: - Source and Sink are the origin (sources) and/or destinations

(sink) of the data i.e. that supplies or receive data. They refer to external entities (or

outside) to a system; boundaries of the system; boundaries. Each source/ sink has a

name that states what the external agent is, e.g. students

Students

Data Dictionary (LEVEL 0) for A2 Motor Driving School

Name Student

Description Student is the most important entity of the system. Student has

to be registered to the A2 motor driving system firstly to

obtain training.

Input data flow Student gives all required information about his/her name,

address, contact no, Email ID etc.

Output data flow Scheduling of the interview is done.

Table 4

Name Administrator

Description Shiv Chand is the administrator of the system one who is

responsible for registering the Branches, branch managers,

view payment and billing information and Maintenance of the

system.Input data flow View, Update and Insert.

Output data flow Request for report.

Table 5


49/67


50/67



Name Lesson Booking

Description Before the lesson starts the student has to book the lesson.

Input data flow Student id, instructor id, lesson id, date etc.

Output data flow Booking Confirmed.

Data structure Student id[Number], Instructor Id[Number], Lesson

Id[Number], Date[number/text]

Table 9

Data stores:

Name Login record

Description Stores information of user name and password.

Input data flow Stores login details

Output data flow Provides user name and password

Table 10

Name Student Record

Description Store Student information

Input data flow Student id

Output data flow Student details

Table 11

Name Instructor Record

Description Stores the information of instructor

Input data flow Instructor id

Output data flow Instructor details, schedule details etc.

Table 12


51/67


52/67


53/67



5. The design should exhibit uniformity and integration The system developed

follows this principle. We have followed Hierarchy model which so whenever the

system found that it should change its master page according to the new ideas, the

designed has been changed accordingly. A design is integrated if care is taken in

defining interfaces between design components.

6. The design should be reviewed to minimize conceptual (semantic) errors there

is sometimes the tendency to focus on minute details when the design is reviewed,

missing the forest for the trees. Design is not coding, coding is not design Even

when detailed designs are created for program components, and the level of

abstraction of the design model is higher than source code.

7. The design should be structured to accommodate change The design should be

assessed for quality as it is being created

in the design concept we are shows the process of work how it fallow. There are

seven concepts which this system is using to justify the design.

The seven concepts of design are -

1) Abstraction: - It allows designers to focus on solving a problem without being concerned

about irrelevant lower level details (procedural abstraction - named sequence of events,

data abstraction - named collection of data objects). We have used control abstraction in

our design that means that our program control is flowing without showing its internal

working to its users. It allows designers to focus on solving a problem on a generalised

standard without being concerned about irrelevant lower level details. The designer

analyse the problem related to the interface design of the system i.e. button, menus and

other visual design elements.

2) Refinement: - It is process of elaboration where the designer provides successively more

detail for each design component. According to the three steps system has done the

refinement concept. The three steps are:

1st refinement: In this we refine the problem in the system. According to

requirement analysis and data gathering we found some problems faced by the current

system.

2nd refinement: After finding out the problems we are going to identify what the

user actually needs. This was carried out by the data gathering technique.


54/67


55/67


56/67



The design of client-server systems should reflect the logical structure of application that is

being developed. The client-server architecture can either be of 2-tier or 3-tier.

2-tier architecture is a client-server architecture where the server is versatile, i.e. it is

capable of directly responding to all of the client's resource requests.

In 3-tier architecture however, the server-level applications are remote from one

another, i.e. each server is specialized with a certain task (for example: web

server/database server).

The 3-tier architecture distributes processing is more effective than 2-tier architecture.

However system management is more complex as application functionality is spread

across many different computers. So, the implementation of this architecture was not

economically feasible for this system which has a limited number of users.

Selected Architecture: [2-tier approach of client-server architecture]

So, the 2-tier approach of client-server architecture has been adopted for the implementation

of the system for the application. The user requirements as well as the database requirements

are very limited in this system. So, the database and the application are deployed in the same

server. The user interface for these systems is migrated to PCs and the application itself acts

as a server and handles all processing and data management. The results are then displayed in

the presentation layer as per user requirements.

ADVANTAGES:

1. Easier to maintain

2. Cost Effective

3. Suitable for small applications where the number of users are limited and also the

database requirements is minimum.

ARCHITECTURE PATTERN

BROKER PATTERN

(DISTRIBUTION PROBLEM)

DMS PATTERN

(FOR PERSISTENCE)


57/67


58/67


59/67



Student

Register

form

Scheduling

Interview


60/67



Dashboard


61/67



Crystal

Report of

system


62/67



Chapter 19-Programming Environment

A2 Motor Driving School System is purely developed on ASP.Net platform. The backend is

Microsoft Access for storing the data. ASP.Net is a sophisticated program for creating,

editing, and testing web pages.

Why ASP.Net?

ASP.Net allows creating dynamic web pages i.e., web pages whose contents are

generated dynamically and can be easily customized.

It provides user controls it gave the system developers flexibility to add own feature,

methods and event handlers.

Its session state provided security as Session variables can be set to be automatically

destroyed after a defined time of inactivity, even if the session does not end.

It provides performance benefit over other script based technology as it compiles

server side code to one or more DLL files or web Server.

It also drastically reduces the amount of code to build large applications.

Its more secure than any other platform for webpage.

Tools used to develop the system

PURPOSE TOOLS

DESIGN TOOLS DREAMWEAVER

MARKUP & PROTOTYPE HTML,CSS

PROGRAMING PLATFORM ASP.Net

DATABASE USED MICROSOFT ACCESS 2007

OS PLATFORM WINDOWS 7BROWSER INTERNETEXPLORER, FIREFOX,

SAFARI, GOOGLE CROME

Table 15


63/67



Chapter 20-Testing

Testing the system means finding out the errors and components that are missing which isspecified in project specification and is not followed. Software testing is a critical element of

software quality assurance and represents the ultimate review of specification, design, and code

generation. There exists a particular team of testers for testing the systems. It is recommended

that testing should begin in requirements phase of SDLC. It plays important role for the quality

project. The types of testing are:-

Unit Testing: Unit testing is a done with the components individually having no

interdependency. It basically focuses verification effort on the smallest unit of software

design and on the internal processing logic & data structures within the boundaries of a

component.

Integration Testing: In Integration testing the system has combined individual

components and tested them as a group. It is followed after Unit Testing. The main use of

Integration testing is to verify the functionality, the performance and the reliability. There

are different approaches for Integration testing i.e. Top Down Approach and Bottom

Up Approach.

Test case name Date of Student Registration

Test case ID TbDOR_01

Purpose of test To take the input only in the form of dd-mm-yyyy.

Testing object Unit

Test Attribute Date of Registration(textbox)

Test focus Validation

Test type Unit

Test process Initial StateDate of Registration textbox isrequired to be filled.

Output expected

Accept only current date andin proper date format.

Test results Accept date in proper format and didnt accept past date.

Action No Action Required, working properly and take right input.


64/67



Test case name Date of Examination

Test case ID TbDOE_02

Purpose of test To take the input only in the form of dd-mm-yyyy.

Testing object Unit

Test Attribute Date of Examination(textbox)

Test focus Validation

Test type Unit

Test process Initial State

Date of Examination

textbox is required to be

fill.

Output expected

Accept only current date and in

proper date format.

Test results Accept date in proper format and didnt accept past date.

Action No Action Required, working properly and take right input.

Field Name Table Name Expected Input ExpectedOutput

Net Result

Student

Stud_Id Student Character Error FailNumber No Error Pass

PunctuationMarks

Error Fail

Blank Error Fail

Stud_name/Stud_fname

Character No Error Pass

Number Error Fail

PunctuationMarks

Error Fail

Stud_dob Blank Error Fail

Date No error PassCharacter Error Fail

Number Error Fail

PunctuationMarks

Error Fail

Blank Error Fail

Stud_address Character No Error Pass

Number No Error Pass

PunctuationMarks

No Error Pass


65/67




Net Result

Instructor

Inst_Id Instructor Character Error Fail


PunctuationMarks

Error Fail

Blank Error Fail

Inst_name/Inst_fname


Number Error Fail

PunctuationMarks

Error Fail

Inst_dob Blank Error Fail

Date No error Pass

Character Error Fail

Number Error FailPunctuationMarks

Error Fail

Blank Error Fail

Inst_address Character No Error Pass


PunctuationMarks

No Error Pass


Net Result

Manager

Man_Id Manager Character Error Fail


PunctuationMarks

Error Fail

Blank Error Fail

Man_name/Man_fname


Number Error Fail

Punctuation

Marks

Error Fail

Man_dob Blank Error Fail

Date No error Pass

Character Error Fail

Number Error Fail

PunctuationMarks

Error Fail

Blank Error Fail

Man_address Character No Error Pass


PunctuationMarks

No Error Pass


66/67


67/67

Documents

Ppsp Group 5