Chapter 2: PROJECT MANAGEMENT
2.1 PROJECT PLANNING
Project Planning includes project plan activities and project development approach followed during the making of project. It also entails the details of different milestones achieved and roles and responsibilities assigned to us.
2.1.1 Project Development Approach and Justification
The Requirements provided by the users are converted into Users Requirement Specification as described above. The URS documents are then revised, validated, authorized and approved by the users. The development commences after the approval phase i.e. after the signing off of the URS documents. Thus, the URS is concerned to be the most important document from user and developer prospective. The Developer will try to adhere to the requirements specified in the URS documents in order to develop the required application. We have used Waterfall model as a development model.
Fig. 2.1 Waterfall Model
The Waterfall Model
As the process model for our project we use Waterfall model .The definition of business requirements, design, build and test are undertaken in a linear fashion. Provided the desired project outcomes can be clearly defined from the outset, this approach is swift and effective. Difficulties arise when unforeseen risks are encountered in later stages, requiring an unwinding of the process and the generation of significant project rework.
The waterfall model is well understood and time tested but generally considered to be less useful than it once was due to the increasing complexity of systems. It “works well for automating the tasks of clerks and accountants, less well for knowledge works such as experts trying to solve problems” (Information Center Quarterly article, Larry Runge). Another problem is that in the waterfall model users only input is in specifying requirements and that all requirements must be specified at one points before production begins. However, requirements typically change through the process and require more feedback.
We use waterfall model because:
It is easy for managers to understand, plan by and to test progress against as it has very clear sequential milestones
It encourages good design practices such as early clarification of system goals, which in turn save time and money (the earlier a bug is caught, the less harm it can cause)
Due to lots of up front design planning, should the project be stopped and taken up at a later date, or should project members change, implementation can continue far easier than with more agile development models where there is considerably less design documentation.
It is compatible with a wide range of design strategies
In sense of 10% customization in this model, users may change requirements often, at stages beyond the requirements stage.
In sense of testing, constant verification of each stage is required to ensure that the next phase can start on a correct base Technology may change during development.
2.1.2 Project Plan
The key to a successful project is in the planning. Creating a project plan is the first thing you should do when undertaking any kind of project.
Often project planning is ignored in favour of getting on with the work. However, many people fail to realize the value of a project plan in saving time, money and many problems.
Areas, which would be considered during the planning and analysis, would be:
Ensure that the information flow is process driven.
Reduce the manual efforts to the maximum extent for all activities.
Ensure validation at each and every level.
Act as an effective tool in decision support.
Provide user friendly system.
Fig. 2.2 Project Planning and Management Approach
2.1.3 Milestones And Deliverables
Milestones
A milestone is an end-point of the software process activity.
At each milestone there should be formal output that can be represented to the management. The weekly report is submitted to our project Guide, which include day to day work report.
Milestone report not be large document, they are the short report of achievements in software project activity.
Milestone represents the end of the distinct, logical state in the project.
Deliverable
Deliverable is a project report that is delivered the administrator of our project.
Deliverables are delivered to the administrators of our organization at the end of the some major project phase such as specification, design, etc.
Deliverables are usually milestones.
Milestones may be internal project results that are used by project manager to check process but which are not delivered to the administrator.
Table 2.1 Milestones and Deliverables
PHASE DELIVERABLES PURPOSE
System Requirement and Analysis • Requirement Gathering and analysis.
• Fields and information required for the forms It gives exact understanding of the user’s requirements.
System Design • E-R Diagram
• Database Design
• Class diagram
• Sequence Diagram
• Use Case Diagram
• Form layouts It gives the logical structure that describes the system.
Implementation and Testing The output obtained for the required functionality after implementing and doing various types of testing It gives the required module
2.1.4 Roles and Responsibilities
Table 2.2 Roles and Responsibilities
Role Responsibility Team/Member
Project Manager Defining scope Mr. Kakadiya Nikunj
Mr. Thummar Chirag
Providing required resources
Project planning, tracking and monitoring.
Analysis and Effort Estimation.
Coordination between project teams.
Team Members Designing & Documentation Mr. Kakadiya Nikunj
Mr. Thummar Chirag
Execution project as per defined schedule.
Reporting to PM
Testing & QA/QC
2.1.5 Group Dependencies
One of our team members will report the progress of work in their respective modules to the Project Leader on a weekly basis. The Project Leaders will in turn submit weekly status reports to the concerned Project Managers.
The Project Manager will monitor the progress of the activities against the plan and prepare a consolidated Monthly Report to Project Manager (PM) of CLIENT. This report will cover the project status and deviations against plan.
2.2 PROJECT SCHEDULING
Project scheduling is a process of assigning the time to different phases of the project.
Table 2.3 Project Scheduling
Phases Time Period No. of Days
Study Of Component
(Net Advantage Tool) 8th January 11 - 21th February 11 19
Understand Existing System 16th January 11 -15th February 11 23
System Design 13th February 11 – 21thebruary 11 7
Form & Database Design 22d February 11 – 4th March 11 11
Implementation (Coding) 3th March 11 - 18th April 11 45
Integration & Testing 3th March 11 - 25th April 11 52
Documentation 15th April 11 – 28th April 11 8
2.3 RISK MANAGEMENT
RISK analysis and managements are a series of steps that help a software team to understand and manage uncertainty. A risk is a potential problem- it might happen, it might not .But, regardless of the outcomes, and it’s really good idea to identify it, assess its probability of occurrence, estimate its impact, and establish a contingency plan should the problem occurs.
2.3.1 Risk Identification
Recognizing what can go wrong is the first step, called risk identification. Each risk is analyzed to determine the likelihood that will occur and the damage that it will do if it does occur.
Risk identification is a systematic attempt to specify threats to the project plan. There are two types of risks: generic risks and product –specific risk. Generic risk is the risk associated with the potential threat to every project. Product specific risk is the risk associated with the clear understanding of the technology, the people and environment that is specific to the project at hand.
Technical Risk
The main Technical Risk is that we have used .Net which is new Technology. The technology is new so no one has experience working with this technology works on Windows XP, Windows 2000 & Windows Vista.
Risk Identification is a systematic attempt to specify threats to the project plan. There are two types of risks are there: Generic and Product Specific.
One method for identifying risks is to create a risk item checklist. The checklist can be used for identification and focused on some subset of known and predictable risks in the following generic subcategories:
• Product Size
• Risks associated with the overall size of software to built or modified.
• Business Impact
• Risks associated with constraints imposed by management or the marketplace.
Customer Characteristics
Risk associated with the sophistication of the customer and the developer’s ability to communicate with the customers in the timely manner.
Process Definition
Risks associated with the degree to which the software process has been defined and is followed by the development organization.
Table 2.4 Risk Planning
Risk Strategy
Organizational financial
Problems Prepare a briefing document for senior management showing how the project is making a very important contribution to the goals of the business
Requirement problems Alert customer of potential difficulties and the possibility of delays, investigate buying-in components.
Staff illness Reorganize team so that there is more overlap of work and people therefore understand each other’s jobs.
Defective components Replace potentially defective components with bought-in components of known reliability.
Requirement changes Derive traceability information to assess requirements change impact, maximize information hiding in the design.
Database performance Investigate the possibility of buying a higher-performance database.
Underestimated and development time Investigate buying-in components, investigate the use of the program generator.
Risk Monitoring
Risk Monitoring involves regularly assessing each of the identified risks to decide whether or not that risk is becoming more or less probable and whether the effects of the risk have changed. Figure gives some examples of factors that may be helpful in assessing these types of risks.
Table 2.5 Risk Monitoring
Risk type Potential indicators
Technology Late delivery of hardware or support software, many reported technology problems.
People Poor staff morale, poor relationships amongst team members, job availability.
Organizational Organizational gossip, lack of action by senior management.
Tools Reluctance by team members to use tools, complaints about CASE tools, demands for higher-powered workstations.
Requirements Many requirements change requests, customer complaints.
Estimation Failure to meet agreed schedule, failure to clear reported defects.
2.3.2 Risk Analysis
Risk always involves two characteristic uncertainty and loss.
Uncertainty: It is the risk that may or may not happen; there are no 100% probable risks.
Loss: If the risk becomes a reality, unwanted consequences or losses will occur.
2.3.3 Risk Planning
Our Company has given training to the employees for the C# with Asp.Net language and also had some seminars. We also have some books of .Net and internet connection connected all the time incase employees wants to search on internet.
The GUI generated in the project is very user-friendly and so not only a developer but normal user can also use it. Developer can also use their own designing feature with the existing application.
User has a wide range of facility to modify its GUI according to his requirements by just changing the entries in the database table. So the risk related to the customer is reduced to negligible.
2.4 ESTIMATION
Estimation is the process of evaluating the time assigned to different areas of the project and finding out the effort and cost required for that particular phase.
2.4.1 Effort Estimation
Table 2.6 Estimation
Factors Marking
Analysis 40%
Design 20%
Construction (Coding & testing) 30%
Deployment 10%
2.4.2 Cost Analysis
Consultancy Cost: This cost is based on the staffing of the project and its location.
Hardware Cost: This cost is based on the cost incurred on the hardware utilized per person month like computer, tapes etc.
Software Cost: This cost includes the cost incurred on the licensing of tools and software used in the project e.g. Microsoft SQL Server, Microsoft Office etc.
