User:Rumjhum00/sandbox

Title: Develop a Software Project Management Plan for Automated Ticket Issuing System for BRTC (Bangladesh Road Transport Corporation)

Introduction:

Bangladesh Road Transport Corporation (BRTC) is the state-owned transport corporation of Bangladesh. It was established under the Government Ordinance No.7 of 1961 dated 4 February 1961. Following the independence of Bangladesh in 1971, it assumed its current name. BRTC is a semi-autonomous corporation under the Ministry of Communication. The governing body includes the Communication Minister, the Communication Secretary, the Director of the corporation, and other officials our software firm “AIUB IT Solutions Inc.” has been awarded a contract to develop software for automatic bus-ticket vending machine for Bangladesh Road Transport Corporation (BRTC). An automated ticket issuing system sells bus tickets. Users can select their destinations, and insert a credit card and a personal identification number (PIN). The bus ticket is issued and their credit card account is charged with its cost. When the user presses the start button, a menu display of potential destinations is activated along with a message to the user to select a destination. Once a destination has been selected, users are requested to insert their credit card. Its validity is checked and the user is then requested to enter a personal identifier number. When the credit transaction has been validated, the ticket is issued.

Process Model : Process model or software development life cycle (SDLC), is a structure imposed on the development of a software product. Similar terms include software life cycle and software process. It is often considered a subset of systems development life cycle. There are several models for such processes, each describing approaches to a variety of tasks or activities that take place during the process. Some people consider a lifecycle model a more general term and a software development process a more specific term. For example, there are many specific software development processes that 'fit' the spiral lifecycle model. ISO 12207 is an ISO standard for software lifecycle processes. It aims to be the standard that defines all the tasks required for developing and maintaining software. For our software development project plan we use waterfall model.In some development projects, the complete set of requirements can be accurately identified in advance. This allows the development team to predict, to large extents, the nature of flow of the project and thus, structure the entire development process into phases, with clear deliverables at the end of each phase. This methodology is the sole purpose of the widely known Waterfall Model. When approaching the most basic of projects, OffshoreDotNetDevelopment understands the importance of segregation of modules to allow smoother delivery. The significance of this task becomes even more evident in the case of large and stable projects. The Waterfall Development approach is primarily beneficial in projects that consist of pre-optimized, working processes that need to be automated. The simple structure of the Waterfall model ensures that there is limited cross-team communication during the development process as all tasks are well defined. The entire project is broken down into extremely structured phases and each phase is directly dependent on the successful completion of the previous stage. The single team involvement at each phase makes the project easier to manage. This feature is particularly supportive when determining estimates for the project and its phases. The project's life-cycle begins with the, all-important, "Requirement Analysis" phase. This involves a comprehensive requirement gathering stage wherein each and every minute detail is accounted for. The second phase is the "Design" phase where, based on the requirements, the entire structure and path to be followed, is designed; this is followed by "Development" where the actual coding takes place; "Testing" becomes the next step before "Implementation" of the finished product. The Waterfall Model has numerous benefits such as the easy analysis of potential changes, precise dollar budget creation and easy coordination of large project teams, even over wide geographical regions.

Quality phase of SW development each model gate for waterfall:

A Quality Gate is a special milestone in a software project. Quality Gates are located before a phases in which breaches in disciplines must be overcome. Such a breach typically occurs, for example, when embedded software must be transferred to a hardware chip. Quality Gates are more general than Milestones; Quality Gates can be defined for each phase that is strongly dependent on the outcome of a previous phase. They are be used in larger set of more or less similar projects, whereas milestones must especially useful between project from scratch. Each Quality Gate includes a check of documents relevant to the previous phase. Unlike a software review, this check is only formal; no deep check on the contents of applicable documents is conducted in a Quality Gate. A Quality Gate demands a set of documents and includes special requirements on these documents, both of which are detailed in a checklist. The check itself is performed in a session with decision makers and domain experts. Depending on their decision, the project can be canceled, put on hold, or approved to proceeded normally.The waterfall model strengthen the completion of each phase before continue to the next phase. This will simplify the management to the software and will reduce the costly iterations among phases. In each phrase, this model will provide quality gates. The quality gate is a checkpoint to determine the quality of each phase. The next phase will not proceed unless quality of each phase is achieved. By doing this, the finished product will have a better quality.

List of task: 	Orient new Team Members 	Review Project Materials 	Kick Off Project Execution 	Manage Project Scope 	Manage Project Schedule 	Manage Project Budget 	Monitor Risks 	Control Risks 	Monitor Impact on Triple Constraints 	Manage Change Control 	Manage Deliverable Acceptance 	Manage Issues 	Execute Communication Plan 	Manage Organizational Change 	Manage Project Team 	Manage Project Transition 	Conduct Final Status Meeting 	Gain Acceptance Signatures Estimation for each work:

Name of the task	       Time to performing task	          Hour for a week Orient new Team Members                  4days	                    6hr Manage Project Scope	                 3month	            6hr Manage Project Schedule	                 2month	            6hr Manage Project Budget	                 4week	                    6hr Monitor Risks	                         4week	                    6hr Control Risks	                         4week	                    6hr Monitor Impact on Triple Constraints	 1week	                    4.5hr Manage Change Control	                 1.5week	            4.5hr Manage Deliverable Acceptance	         1year	                    4.5hr Manage Issues	                         5week	                    2hr Execute Communication Plan	         2week	                    2hr Manage Organizational Change	         2week	                    2hr Manage Project Team	                 1year	                    5hr Conduct Final Status Meeting	         3days	                    5hr

Schedule the task:

Schedule Tracking techniques used by Project Managers:

•	Conducting periodic project status meeting in which each team member reports progress & problems •	Evaluating the results of all reviews •	Compare actual start-date with scheduled start-date

Task name	          working hour	         Per week	Start time	Finished time	Leasure time	other works team member select	    3hr 	          2week	          1st week	 2nd week	  none	          none Engineer working	    6.5hr	          1week	            1st day	   365day	   2hr	           2hr comunication	            4hr	          3week	            1st week	    3rd week	   none	           none Planing	                    4hr	           3week	     1st week	    3rd week	    none	   none design	                    5hr	           4week	    1st week	     4th week	    none	   none coding	                   7.5hr	           96days	     1day	      96day	    1hr	           none testing	                    3hr 	           1week	    1st day	      7th day	    30mins	    none monitoring	            4hr	           1week	     1st day	      7th day	    30mins	   30mins risk analysis	           3.5hr	           3week	     1st day	      21th day	     1.5hr	    none team management	            8hr	           1year	     1st day	      365th day	      2hr	     2hr

Prepare a list of milestone:

Task name	     Duration	Start	Finish	27-Apr	4-May	4-May M/T/W/T/F/S/S	s	M/T/W/T/F/S/S Requirement phase     40 days	Mon 27.04.11	Fri 19.06.11 Requirement detail	25 days	Mon 27.04.11	Fri 29.05.11 Interactive requirements	25 days	Mon 27.04.11	Fri 29.05.11 retail requirements	25 days	Mon 27.04.11	Fri 29.05.11 Bussiness system requirements	35 days	Mon 04.05.11	Fri 19.06.11 Design phase	35 days	Mon 04.05.11	Fri 19.06.11 Design delivered	35 days	Mon 04.05.11	Fri 19.06.11 Software development phase	50days 	Wed 13.05.11	tue 21.07.11 Development	50 days	Wed 13.05.11	tue 21.07.11 System testing phase	61 days	tue 07.07.11	Tue 29.09.11 Testing	61 days	tue 07.07.11	Tue 29.09.11 Code	1day	Wed 30.09.11	Wed 30.09.11 Launch	1day	fri 06.10.11	fri 06.10.11

Staffing Plan:

In our project first we assign task of requirement analysis and project planning to one of our software engineer.In this first stage we fixed a meeting with the customer, to understand the requirements. The first stage, this is the most crucial stage, as any miscommunication and misinterpretation at this stage may give rise to the software, that is being developed. When the requirements have been noted, it is important to make sure the requirements are detailed and accurate and there is no place for any ambiguity. Understanding the requirements and expectations of the customer properly will ensure, that the end product meets the specification.Then we assign task for system design. The requirements, that are gathered in the previous phase are broken down into logical units, so that the software process becomes easy for implementation. This is the stage, when the software requirements along with the hardware requirements for every unit are identified. Then the designs are made accordinglyNext we assign task for system implementation. In this phase the actual development of the software takes place. This phase is also known as coding and verification phase. Based on the algorithms written in the previous phase, software program is written. For every module software code is written and check if tested, to the correct output is received.Then the assigning task is system intregation and testing. Now all the modules are integrated, after which the software is tested for correct output. All the bugs, that are made, due to integration are removed. Then software testing is carried out again. They are normally a series of tests, which are run to check the performance of the software, and also to find if any new bugs were introduced into the system.Next we assign task of system deployment and maintenance. This task is assign for the final phase of the system. where the software is deployed at the clients side, after it has undergone thorough testing. After the deployment of the software, routine maintenance work is carried out. Once the software has been deployed, in case the customer asks for any changes or enhancements, then the entire process is restarted.

Monitoring and Controlling Mechanism:

keep The purpose of project monitoring and control is to keep the team and management up to date on the project's progress. If the project deviates from the plan, then the project manager can take action to correct the problem. Project monitoring and control involves status meetings to gather status from the team. When changes need to be made, change control is used to the products up to date.

Risk management: •	It is very important to gather all possible requirements during the first phase of requirements collection and analysis. If not all requirements are obtained at once the subsequent phases will suffer from it. Reality is cruel. Usually only a part of the requirements is known at the beginning and a good deal will be gathered during the complete development time. •	Iterations are only meant to happen within the same phase or at best from the start of the subsequent phase back to the previous phase. If the process is kept according to the school book this tends to shift the solution of problems into later phases which eventually results in a bad system design. Instead of solving the root causes the tendency is to patch problems with inadequate measures. •	There may be a very big "Maintenance" phase at the end. The process only allows for a single run through the waterfall. Eventually this could be only a first sample phase which means that the further development is squeezed into the last never ending maintenance phase and virtually run without a proper process.

List of deliverables: 	Team Members Prepared to Work 	Project Planning Outputs reviewed 	Kick-off Meeting Agenda 	Kick-off Meeting Notes 	Scope under control 	Updated Project Schedule 	Updated Budget 	Risk Management Worksheet 	Project Status Report 	Triple Constraints Managed 	Updated Triple Constraints 	Project Deliverables Approved 	Issues Log and Project Status Report 	Project Status Report and other Communication Tools 	Organizational Change Processes Executed 	High Performing Team 	Product of the Project 	Final Project Status Report Schedule tracking process: 	Update and analyze the Project Schedule as needed 	Conduct peer review of deliverables, if appropriate Defect tracking process: 	Management shortcomings. 	The requirements are not clear, or they are constantly changing. 	stop the requirements dithering 	expand the Project Budget to accommodate the process (warning: you will still need option 1 eventually!) 	cancel the project now (with small overruns) or later (with major overruns). 	The project environment is not what you expected. Metrix: 	Analytical measurement 	Spending total time of the project 	Total numbers of lines of code per week 	Defects of lines of code per week 	Each of time which spending in the phases 	Unit testing time 	System testing time 	Help to the future project 	Help long term process improvement Postmortem: 	Status meeting between the customer and the developer. 	Change the requirement as the customers needed.