G-030 Project Management

CHAPTER 02 PROJECT MANAGEMENT

2.1 PROJECT PLANNING

2.2 PROJECT SCHEDULING

2.3 RISK MANAGEMENT

2.4 ESTIMATION

I.T. Department 1
G-030 Project Management

CHAPTER 02 PROJECT MANAGEMENT

2.1 PROJECT PLANNING

Project Plan play a vital part of developing the software. There are many methodologies
which are used by the professional software development companies nowadays. There are
certain advantages and disadvantages associated with each of them. The basic purpose of
these methodologies is to provide smooth software development according to the project
requirements.

Software development methodology is a framework that is used to structure, plan, and

control the process of developing an information system. This kind of development
methodologies are only concerned with the software development process, so it does not
involve any technical aspect of, but only concern with proper planning for the software
development.

Software engineering is the discipline whose aim is:

1. Production of quality software

2. software that is delivered on time
3. cost within the budget
4. satisfies all requirements
2.1.1 Project Development Approach And Justification

To solve actual problems in an industry setting, software engineer or a team of engineers

must incorporate a development strategy that encompasses the process, methods and tools
layers and generic phases. This strategy is often referred to as process model or a software
engineering paradigm or project development approach.

A process model for software engineering is chosen based on the nature of the project and
application, the methods and tools to be used, and the controls and deliverables that are
required. our software is based on Waterfall Model. This software development approach
is as described as below.

Life Cycle Models :

I.T. Department 2
G-030 Project Management

There are various life cycle models to improve the software processes.

1. Waterfall model
2. Prototype model
3. Iterative enhancement model
4. Evolutionary model
5. Spiral model

2.1.2 Project Plan

Waterfall Model :

The waterfall model is one of the most traditional and commonly used software
development methodologies for software development. This life cycle model is often
considered as the classic style of the software development. This model clarifies the
software development process in a linear sequential flow that means that any phase in the
development process begins only if the earlier phase is completed. This development
approach does not define the process to go back to the previous phase to handle changes in
requirements.

Advantages of Waterfall Model:

Waterfall model is very simple and easy to understand and use a method that is why
it is really beneficial for the beginner or novice developer
It is easy to manage, because of the rigidity of the model. Moreover, each phase has
specific deliverables and individual review process
In this model phases are processed and completed are at once in a time thus it saves
a significant amount of time

This model contains 6 phases:

Requirement analysis
The goal of this phase is to understand the exact requirements of the customer and to
document them properly.
System Design
The goal of this phase is to transform the requirement specification into a structure that is
suitable for implementation in some programming language.

I.T. Department 3
G-030 Project Management

Implementation
this phase the design is implemented. Initially small modules are tested in isolation from
rest of the software product.
Testing
In this all the modules are integrated and then tested altogether.
Deployment

The general deployment process consists of several interrelated activities with possible
transitions between them. These activities can occur at the producer side or at the consumer
side or both. Because every software system is unique, the precise processes or procedures
within each activity can hardly be defined.

Maintenance.
Release of software inaugurates the operation and life cycle phase of the operation. The
phases always occur in this order and do not overlap.

I.T. Department 4
G-030 Project Management

Fig 2.1 Waterfall Model

2.1.3 Milestones and Deliverables

Milestones and Deliverables are the part of the project scheduling. In what time your project
is going to be ready, is known by milestones. Milestone is an endpoint of the software
process activity.

Table 2.1 Milestone and Deliverables

Project phase Milestones Deliverables
Draft proposal Draft project proposal
Inception
Proposal submission Project proposal
Admin user interface
Admin user interface layout
layout
Elaboration Presented work in process
Work in process prototype
porotype for supervisor
demo
and sponsor
End of construction literation 1 Basic search function
Construction End of construction literation 2 Advanced search function
End of construction literation 3 Advanced search function
User acceptance test UAT test cases
Transition Final presentation Presentation slides
Final reflection Final reflection report

2.1.4 Roles and Responsibilities:

Research & Document Anvit Patel, Raj Patel

Analysis Anvit Patel

Design Raj Patel

Software Development & Programming Raj Patel, Anvit Patel

I.T. Department 5
G-030 Project Management

Hardware & Software Integration Anvit Patel

Testing Raj Patel

Debugging Anvit Patel

Prototype Construction Raj Patel

2.1.5 Group Dependencies

One assumption about the product is that it will always be used on mobile phones that have
enough performance. if the phone does not have enough hardware resources available for
the application, for example the users might have allocated them with other application,
there may be scenarios where the application does not work as intended or even at all.

Another assumption is that the GPS components in all phones work in the same way. If the
phones have different interfaces to the GPS, application need to be specifically adjusted to
each interface and that would mean the GPS would have different requirements than what
is started in this specification.

2.2 PROJECT SCHEDULING

2.3 RISK MANAGEMENT

Risk management is the process of measuring, or assessing, risk and developing strategies
to manage it. Strategies include transferring the risk to another party avoiding the risk,
reducing the negative effect of the risk, and accepting some or all of the consequences of a
particular risk. Traditional risk management focuses on risks stemming from physical or
legal causes (e.g. natural disaster or fires, accidents, death and lawsuits). Financial risk
management, on the other hand, focuses on risk that can be managed using traded financial
instruments.

In ideal risk management, a prioritization process is followed whereby the risks with lower
probability of occurring are handled first, and risk with lower probability of occurrence and
lower loss are handled later.

Step in the risk management process establishing the context involves:

I.T. Department 6
G-030 Project Management

Planning the remainder of the process.

Mapping out the following: the scope of the exercise, the identity and objectives of
stakeholders and the basis upon which risks will be evaluated.
Defining a framework for the process and an agenda for the Identification.
Developing an analysis of risk involved in the process.

2.3.1 Risk Identification:

After establishing the context, the next step in the process of managing risk is to identify
potential risks. Risks are about events that, when triggered, cause problems. Hence, risk.
identification can start with the source of problems, or with the problem itself

In this project there can be following risks:

The order risk is associated with the software. If in the software the wrong user is authorized
by mistake, then he may do changes that cause the system in dangerous mode. There can
be risk of natural threats.

2.3.2 Risk Analysis:

Once risks have been identified, they must then be assessed as to their potential severity of
loss and to the probability of occurrence. Regardless of the prevention techniques
employed, possible threats that could arise inside and outside the organization need to be
assessed. Regardless of the type of threat, the goals of the business recovery planning are
to ensure the safety of customers, employees and other personal during the following a
disaster.

The relative probability of a disaster occurring should be determined. Here by the first risk
can occur because of the less of communication with all branches of Apollo for requirement
fulfilment. For example, the company may not have interacted with the branch of Apollo
in U.S.A. and that branch needs some additional functionality of the software.

If by mistake any person threat Administrator password, then he can change the data in
software and can leak information. Same thing occurs if the wrong user is authorized. The
software may be in problem by natural threat e.g. internal flooding, External flooding,
internal fire, external fire etc.

I.T. Department 7
G-030 Project Management

2.3.4 Risk Planning:

Once risks have been identified and assessed, all techniques to manage the risk fall into one
or more of these four major categories:

Tolerate (retention)

Treat (mitigation)

Terminate (elimination)

Transfer (buying insure)

Ideal use of these strategies may not be possible. Some of them may involve tread-offs that
are not acceptable to the organization or a person making the risk management decisions.

2.4 ESTIMATION

2.4.1 Effort Estimation

Software development efforts estimation is the process of calculating the most realistic
value of required effort in person-month to develop or maintain the developed software on
the basic of inputs like software requirements, functions points, size, use case point etc.
further, the effort estimates are also used as input to project plan, iteration plan, budgets,
investment analysis, pricing process and binding rounds. Most of the research has focused
on either construction of normal software effort estimation models or consider use case or
function points for the estimation of size or development effort, but does not consider the
SRS of the software for such computation. therefore, there is avital need to find a method
through which the software development effort can be estimated on the basic of
requirement based complexity of the proposed software.

I.T. Department 8