software project manager 4
wilden
software_manger_project_plan_key_assignment.docx
SWE440-1402A-01
Software Project Management
Project Plan
|
Content |
Page |
|
1)Project Description and Methodology
|
3-6 |
|
2)Project Plan Outline
|
7-8 |
|
3)ISO & IEEE Standard
|
9-11 |
|
4)Configuration Management
|
12-16 |
|
5)Defect Tracking
|
17 |
|
6)Risk Management
|
19-22 |
|
7) Final Project Report
|
23 |
|
8)References |
24 |
|
|
|
Project Description and Methodology
The IT ecosystem of financial services institutions faces many challenges in aligning business needs with IT solutions which generally span technology (delivery channels), regulatory compliance laws(Banking Laws BASEL III) and management. Because of large amount of regulation within the industry, banks and other institutions have continued to use the tried and tested approach of Waterfall model because of its perception of being predictable. But even waterfall model has its own cons. Customer satisfaction with the final applications may be lower even if the application has all the features. The customer even has be very patient while waiting for 2-3 years to see a finished product.
Financial institutions can address issues such as quality, time and cost by following agile methodology. Agile development is a way of succeeding by way communication, redundant deliveries of small working software modules, small phases of process, involving users opinions throughout the whole development SLDC of the project leading to the creation of a more innovative and valuable information system which is closely aligned to what customer needs.
We see that in this there is continuous review of what work has been done and continuous modification depending on the feedback of the client/user. So even if there is a change in requirement or change in any functionality, it can be modified effectively. It also improves the testing process as we first test small modules that we make and then by means of integration we move on to larger ones. This is the basis of agile model and this is what we are going to follow here.
Despite its advantage of working closely with the client and delivering satisfactory projects it faces a lot of challenge especially within large firms, which coordinate development between segregated team that work individually on one component such as design, analysis, development or testing. Shown below are challenges and stake holders in Agile Methodology.
Challenges in Agile Methodology
Agile Methodology Stakeholders
2. Project Plan Outline
Project planning comes under project management which also involves, monitoring and control of the people, process that occur in the process of evolution of software from a concept to a product. This generally focuses on the 4Ps: People, product to be developed, process to be followed and Project.
Project planning involves estimation of effort, cost, resource, project duration, preparing project schedule and staffing, preparing risk management plan, project tracking plans and other plans such as quality assurance and configuration management plan. All these are done in order to ensure that we
1. Complete project within the deadline.
2. Complete project within the budget specified.
3. Provide all deliverables that is needed.
4. Fulfill all stated requirements as mentioned in SRS.
Agile Project plan includes:
1) Gathering of requirements from the client
2) Performing analysis and design of the required functionality
3) Developing Code
4) Testing the developed code for errors and bugs
5) Deployment
6) Customer Feedback and continuous Review.
We have also captured the set of tasks in Microsoft project manager that would be carried out once the project has been approved and given a green signal to carry forward. It only includes phases of developing code, testing the individual model and the integrated module, demo deployment, waiting for client feedback and if required rework.
1. ISO and IEEE Standards
ISO 9001 Standard
“This is a standard developed by International Organization for Standardization, that define, establish such standards so that we maintain a quality for manufacturing and services industries.”
The requirements of ISO 9001 are as follows:
1. The business will have a proper total quality department to process and ensure the deliverable conforms to the defined standard.
2. Every business will have their management have several resources available that will be necessary for a better work and training if personal
3. The company shall have a reports from analysis for quality control such that reports produced can be reviewed for acceptance.
4. All reports of errors or issues, both for the product developed and the process followed, should be reported and analysed.
ISO9001 considers the document review process as its main verification and control mechanism.
IEEE Standard
IEEE standard for Information Technology-Software Lifecycle Process addresses issues relating to software life cycle right from the start of acquiring and supplying, through the process, to maintain operations and logistics. It provides a better outlook upon which an organization should make a better business for software lifecycle in order to meet all project specific requirements.
As we are using agile methodology for developing the project assigned to us, we observe that there is a strict conformance between agile methodology and ISO and IEEE standards.
As for any kind of development, agile methodology begins by defining resources of the methodology will be tasked and placed in project. The process starts off by identifying the characteristics of the project. These may include the team size, organizations policy and project criticality. Next, the process requires that all the affected stakeholders of the project to be consulted. The planning of an Agile methodology design or project can easily be recorded in a form identifying the length document or record.
In between process and analysis reports, the conformity is evaluated by the clients and documents for the same of the results are kept as evidence of conformity. Here both the software product and related knowledge about it grows. Code reviews are done in order to find bugs early in the stage and eliminate them as soon as possible. Such reviews produce brings out the flaws which demands quick action, as a mean to a positive. To improve the development process for later development projects. Reports are based on input from technician’s and users feedback. Output from such retrospective are in the components of ISO 9001 be used as input to departmental analysis.
The main difference between the stndards of ISO 9001and the IEEE standards. For the agile methods is that ISO 9001 and IEEE insists on records for reviews and to act on the process conformity. Agile methods try to avoid writing or recording any records that does not contribute to the finished system. On the other hand if the customer requires a certain document, the use of agile methods are no hindrance for developing them.
One broad approach for ensuring that an agile development team conforms to the standard is to assign the task of providing that assurance to one or more individuals. This person or the group enables the team to produce the necessary product in the manner required of the standard without failure.
Configuration Management
HUMAN RESOURCE PLAN
Human resource planning means deciding the number of human resources required for a job, organization in order to carry out its day to day activities.
The purpose of doing this is to recruit and retain human resources of quality, to meet the needs of organizations expansion and diversification, to improve the skill knowledge and standard of the existing resources.
All this is done by analysing corporate strategies towards growth and forecasting the requirement of human resources on the events that may occur. This is done so that a quality program and service is delivered to the client, thus strengthening its potential and increasing competitiveness in the market.
A flowchart for HR Planning Process
STUDY BUSINESS GOAL
SCAN YOUR WORKING ENVIRONMENT
GAP ANALYSIS
HUMAN RESOURCES/
TALENT POOL
IMPLEMENT SOLUTION TO ADDRESS THE GAP
MONITOR AND REPORT THE PROGRESS
Here a gap analysis as shown below as an example:
|
Business |
HR Requirement |
Gap Exists |
Outcome of not addressing the issue |
Solution to address the gap |
|
Financial Software application development |
Engineers with specialized training and knowledge. |
Yes |
Plan may not be implemented.
Negative impact on reputation of the organization. |
Recruit engineers from college or other companies.
Open internships to bring in new talent pool to work in the industry.
Reorganize the organizational structure |
After we are done with this we implement the solution where before bringing in human resource we identify competencies requires, assesses candidates potential, make provisions for proper training to make one equipped with all knowledge that may be required for the project.
WORK BREAKDOWN STRUCTURE
A work down structure basically gives the structure of the project. It decomposes a small project into smaller ones and depending on this estimation and scheduling of the project is done. In short it provides a way to manage and organize work.
WORK BREAKDOWN SCHEDULE
TESTING
INSTALLATION
DEVELOPMENT
DESIGN
MANAGEMENT
NTEGRATE AND COMPLETE SOFTWARE
PREPARE
PRELIMINARY DESIGN
TEST PLAN
PLAN PROJECT
DEVELOP INSTALLATION PLAN
DEVELOP SOFTWARE MODULES
PROCURE SOFTWARE DESIGN
PROCURE SOFTWARE PACKAGE
DEVELOP REPORT
CLIENT FEEDBACK
ACCEPTANCETESTING
INTEGRATION TESTING
MODULE TESTING
REVIEW DESIGN
DOCUMENT DESIGN
PERFORM CM
TRACK PROJECT
INSTALL AT LOCATION
SITE PREPARATION
PREPARE DETAILED DESIGN
PERFORM QUALITY
Defect Tracking and Reporting
Risk Management
RISK ASSESSMENT AND MITIGATION
Software development is a highly unpredictable and complex process associated with high risk and this is where risk assessment is necessary as it gives the managers to plan for the potential risks that can arise during the development process.
Risk assessment is done as given below:
1. Identification of potential risk that can arise.
2. Deciding what may be affected, if the risk materialise.
3. Evaluate the risk and decide on precautions that can be taken.
4. Record the findings and implement them.
5. Review the assessment done and update to make sure risks are mitigated.
6. Monitor the plans made and continue with risk identification.
We can again divide a risk into 3 levels of severity or the way they would impact the project:
1. Low: Very unlikely to occur during the project lifecycle
2. Medium: 50-50 chance of it to occur.
3. High: Very likely to occur.
The risks in the lifecycle of a project can be due to the new technologies, software system requirements and architecture, organization and non-functional area.
Listed are some of the risks that can occur during the lifecycle of the project:
1. Acquisition of resources (Software/Hardware) can be delayed.
2. Project schedule can exceed the estimated time.
3. Project Team members may not be in place as and when required.
4. Risk to project caused by inadequate requirement gathering.
5. Client side support staff may not be present to discuss issues.
6. Elements of the project can be handled by remote groups on which the manager doesn’t have a direct control basically found in onsite-offsite model.
7. Human resource issues.
8. Availability of funds.
As we have listed some of the risks that can materialise during the project lifecycle. We also list down few methods that can be followed to avoid the risk or mitigate it.
1. When working in big teams which involves coordination and combining of products from different groups of people, it is necessary that the design document prepared in the initial phase is carefully reviewed and there should be proper plans for proper communication between the interacting groups so that project can be delivered on time.
2. A good Work Break down schedule can be an effective tool in determining the right mix of skills required for project and their staffing. All the human resources and skilled should be planned and brought in the project.
3. Buffer human resource should be present in case of any leaves of a team member or to cope up with any unanticipated issues that may crop up in between.
4. All the support activities required for the project should be mentioned in the project plan so
as to work accordingly without any discrepancy.
We can also make this risk assessment a bit easier by making a risk assessment matrix for the above problem in the format as shown below:
|
RISK FACTOR
|
SEVERITY OF RISK IMPACT
|
||
|
|
LOW |
MEDIUM |
HIGH |
|
|
|
|
|
Final Project Report
1) Scheduling & Tracking Progress
2) Dependencies between tasks
3) Gantt charts with WBS and Milestones
4) Program Evaluation Review Technique (PERT)
5) Critical Path Method (CPM)
6) Configuration management
7) Risk management
References Board, I. S. (n.d.). IEEE Standard for Developing Software Life Cycle Processes. ISO 9000-Quality Management. (n.d.). Retrieved from ISO: http://www.iso.org/iso/home/standards/management-standards/iso_9000.htm Tor Stålhane, G. K. (n.d.). The application of ISO 9001 to agile software development. W.H. MORKEL THEUNISSEN, D. G. (n.d.). Standards and Agile Software Development. hr planning. (n.d.). Retrieved from hrcouncil.ca: http://hrcouncil.ca/hr-toolkit/planning-strategic.cfm Risk Mitigation Planning, Implementation, and Progress Monitoring. (n.d.). Retrieved from http://www.mitre.org/publications/systems-engineering-guide/acquisition-systems-engineering/risk-management/risk-mitigation-planning-implementation-and-progress-monitoring Software development Risk assessment. (n.d.). work breakdown structure. (n.d.). Retrieved from SearchSoftware Quality: http://searchsoftwarequality.techtarget.com/definition/work-breakdown-structure
Challenges Faced in Agile Methodology
Lack of Team Cohesion, Communication and Knowledge Sharing
Sub Optimal Governance
Sub Optimal support from organization and business users
Sub Optimal Team and Task Division
Agile Methodology Stakeholders
Business Analyst
Clients
Project Managers
Development Team and IT Operations
Project Management Office
Software Project Management Page 1
