Abstract— Quality is a big concern and is becoming a
challenge for the software organizations. About 60% of the projects are stalled for not fulfilling the quality norms. Customers or end users have some different expectation with them based on their perceptions and requirement and the product development is done with different perception. Hence this is building a gap between the end product and the end user. The reason for the failure is very simple. The key objective of this paper is to mainly focus on bridging the gap between the customer and end user needs to the final product. This can be achieved by concentrating on the requirements phase. And including the quality by testing the requirements are properly documented and are updated. A project manager is to mainly concentrate on bringing quality aspects right from the Requirement collection. A project manager is always the one who is aligned with all the phases of the software development life cycle. The methodology used is adapting agile type methodologies to check whether testing the requirements all the time thru the product design and development achieve the possible outcome like a quality product. A sample questionnaire is circulated to the software engineers, managers and a sample population and came to know that the procedure which we are adopting lead to deliver a successful quality product.
Index Terms— Project manager, Requirement traceability, Software development life cycle, Quality management
I.INTRODUCTION
What Project Manager need to concentrate on Quality?
A project manager needs to ensure that the project is satisfying the needs for which it was undertaken. With this re defined statement and terms a project manager has to get clearly stated requirements.
Requirements define Project Scope. This describes what’s required to achieve the quality. And also indicates how a quality can be measured. Most of the project managers are not concentrating on these quality terms.
In general, the tendency on thinking about quality, 1. The best equipment
2. Absolute perfection means Zero defects. This ends up in an impression of redefining the scope considering these are additional items and can be accepted by the customer. This of course can be called as Gold plating. As per PMBOK, this is not recommended. This gold plating might lead to a failure approach with the customer, this result in over schedule and increasing cost and delay in project executions. And the ultimate is Project failure. A Project Manager has to understand the Customer and his requirements through his voice. This can help in getting the information of the unstated needs of the customer. A Project manager at the initial phases of the project/product must know the importance of the customer voice. And then this should lead to the definition of the quality by analyzing what is critical and to adhere the respective changes in service or the process. This is more critical to quality and is perceived mostly to be important for any customer. Hence this adds more value to what the project/product being delivered to the customer. Why Quality is essential always and how project a manager can fulfill the role of Quality manager? Most of the software organizations are looking for the problem solvers instead the managers. And the future of the project managers is also the same. Inside the work place and are encouraging in building a separate team for maintaining quality and making the quality managers are using their brains to solve the problems permanently. Now a day’s quality management is the key functional area and
A study on how a project manager can deliver a
quality product with reference to the
requirements
organizations are linking that to the strategic plan. Quality management helps in putting huge premium on innovations and improving the existing products or services and the processes [1]. Hence a Project manager must concentrate on quality management as well consequently keep up with the changes happening rapidly or constantly and able to adjust the processes to ensure the top quality standards. These are to be maintained.
Quality is handled as an afterthought in most of the software organizations. Such organizations follow a process of doing quality checking or verification once the coding is completed. And the respective testers and the Quality manager are on the fire of certifying the product with a given squeezed schedule. And hence it’s a night mare for the organization to certify the product having many issues which are identified at the time Quality analysis or so. It’s very tough to find what’s going wrong and cannot find any hope after doing back tracking or analysis. This eats the time of resources and also company’s time and cost. A project manager has to ensure that all the requirements are correctly recorded and properly planned for the quality phase and the coverage is good.
II. BIG CHALLENGE
As per Standish reports it’s understood that quality management and Quality phase is most important in the software development life cycle. The failure percentage from the past survey’s starting right from 1995, 2004, 2006, and 2009 is 31%, 15%, 19%, 24% respectively. And the success rate is 34%, 35% and 32% for the respective years 2004, 2006 and 2009. Refer to the following table for success and failure rates of the projects with the increasing importance given to quality phase in the software development life cycle. The Source is chaos report 2010/2012 [6].
Table – 1, Projects success results
With this increasingly organizations are focusing more on the challenges which are around the projects stopped for delivery. Ultimately this is endeavoring to reduce cost and risk. And at the same time this is helping in increasing the quality. Without proper quality planning the project success is very rare which is resulting in 45% of average cost overrun and the additional time taken is 63% and functionality delivered on an average is 67%. Source Standish group.
Adaption of agile process is not that pace in all the organizations. This always encourages in reviewing the business requirements at the initial phases of software development life cycle. These defined reviews can help in getting the changes to be considered and incorporated at the design and development phases. This results in gaining confidence from stake holders which leads in meeting the needs of the organization. Agile process also concentrates on non-functional testing like performance and Stress testing scenarios. This is like the system should respond in certain amount time and what the behavior of system is if it’s overloaded for more time and the system is stable all the time [3]. These are the things which are always linked to the requirements. Of course all the time customers are concentrating on these factors. For example, a customer planning to purchase a Television he checks for how much time it takes to respond if I switch channels and how stable it can be if I am watching it continuously for about a day or so. And also about the radiations and effects to the eye are to be minimal if continuously watching.
These are some of the factors to be taken at the requirement phase. If the quality team is involved in this stage all the things can be planned prior to the coding and can ensure the project success with the defined quality. Traditional approaches always plan the performance testing in the later part of the life cycle resulting critical issues at the end of life cycle. With this the cost and impact can be huge. These result to be a challenged project which sometimes results in delaying the delivery or a failure project. Hence the project manager has to take utmost care at the requirements phase to consider the quality aspects. All the time 50% of the bugs/defects are
Year Success Partial
success
Failure
1994 20 49 31
2000 26 50 24
2004 34 51 15
2006 35 46 19
resulted with the improper requirements. And the remaining can be attributed to the requirements that are omitted.
Always 40% of the projects are costing for reworks. This is because of the defects introduced by the requirements. A survey states that 56% of defects were observed in the requirements and 27% in design, 7% in code, and other 10% [6].
Figure – 1, Defect analysis
And the cost of defect correction increases based on the phases of the Software development life cycle, in which the defect is found. The defects which are observed when the product is ready to deliver to customer it ends up in chaos and rework. Else if it’s taken care at the time requirements phase of the SDLC the cost incurring and rework are ignored. This ensures to improve build quality at the early stages when the project is in requirement phase. If the defects are addressed early enough in the design and development cycle, the costs can be catastrophic and can be
1. Brand damage 2. Revenue loss
3. Increase of support cost 4. Liability costs.
Requirements are to be authored properly and it might be a daunting task and covering all the business, functional, technical requirements is a large effort. The process and procedures need to be
completed and consistent and helpful for further escalations.
All the changes need to be intelligently addressed by connecting all the dots. A project manager has to quickly assess the impact and communicate the changes to the right people involved
Adopting Agile in the organization is encouraging the culture that is nimble. This makes the team to respond quickly and effectively for the requirements change. The traditional approach is like documenting the changes and circulating across all the departments. And the new proposed approach is Cooperative approach. This provides in maintaining the requirements and best practices borrowed from traditional methods like traceability, change management and impact analysis. Here the mostly followed traditional water fall model doesn’t benefit and the challenge is adopting the Agile which can connect all the teams and information on change can be easily propagated.
Figure – 2, Project Manager Role in new model
A. Defining the Requirements
In general, Requirements are documented in paragraphs and results in difficult to understand them. The requirements would be multiple in a paragraph. This makes the ambiguity and results in 56%
27% 7% 10%
Defects found across
different SDLC phases
Requirements Design Code others
Stake Holders Business
Analyst
Development Team
QA Project
rework and requires more clarification. Hence they are to be properly documented giving the numbers for each requirement. The requirements are not to be clubbed and have to be written in a row wise with bulleted numbers. This ensures of having track of all the requirements and easy to understand.
B. Requirements review
Review of requirements is important and always to be done prior to the design phase. The review process can involve peer review, stake holder review and project manager review.
C. Principle behind review
A review is type of static testing. Reviews frequently have as a major objective the detection of defects. Reviews find defects by directly examining documents.
All types of Reviews are best executed as soon as the relevant source documents (documents which describe the Project Requirements) and standards (to which the project must adhere) are available. If one of the documents or standards is missing, then faults and inconsistencies across all documentation cannot be discovered, only those within once document can be discovered. Reviewers must be provided with the documents to be reviewed in adequate time to allow them to become familiar with the contents of the document.
A Review can lead to three possible results:
The document can be used unchanged or with the minor changes.
The document must be changed but a further review is not necessary.
The document must be extensively changed and a further Review is required.
Reviewer Roles:
Manager
Moderator or Leader,
Author,
Reviewers and Scribe
Others (Who may be involved in reviews include decision makers or stakeholders, and customer or User Representatives).
Reader (Optional Role: Who is intended to paraphrase section of the work product in the meeting).
D. Requirements Vs Test Coverage
By the increase in adoption of agile methods, resulting increase in collaboration between teams like development and test. This is breaking the old methods of silo’ed activities and helps in increasing the visibility of test activities bringing quality into Development phase at the early stages of Software development life cycle. This is also leading to reuse and sharing of assets.
Quality is not working sitting with the test team, it’s increasingly and equally responsible for both the test and development teams. The reason is development team has to consolidate the test assets and provide the open visibility as to the quality of builds. By doing so, quality activities are becoming part of integration approach of testing and resulting in identifying the issues in the early stages of software development life cycle by reducing defect resolution costs.
E. Undisciplined changes
Scope change is one of the uncontrollable and is impacting the development, quality and resulting in rework. Here the requirements are changed without any plan and authorization and forwarded to the testing team. A project manager has to control the undisciplined approach of changing the scope and requirements without proper authorization. This results in adding more confusion. Project manager has to quickly react and understand the impact to the testing and timeline and scope.
F. Including testing in the early stages
approach to development. This helps in finding defects at the early stage and reduces the cost of defects. This approach encourages organizations to incorporate test earlier in the development life cycle instead at the end is enabling quick resolution of defects and increasing the quality of the product.
Defects observed at the end of Development life cycle
III. SUGGESTEDAPPROACH
Most of the industry reports confirm that resolving the defects at the end of the cycle are 100% costlier than they are identified prior to the Development or requirements phase. Below is the defect cost relation rate and it says like requirements phase 1% effect and Design and development phases can go with 5-6% and the testing phase its 51% and the deployment or final stages costs 100%..
Figure – 3, Comparison of different approaches Suggested Approach is having three major methods to its approach. They are
Requirement Induction.
Requirement traceability
Test coverage.
Identifying the business risk and need to prioritize the requirements and testing is the basing task here for a project manager. This enables focus for the critical thinks and business risks.
A project manager has to think that its impossible to perform 100% testing. Hence project manager need to prioritize.
A. Requirement Induction
Project manager has to follow a pictorial approach, instead going to thru the old traditional paragraph approach. This encourages in facilitating clear requirements and interactive environment for the Business Analyst, stake holders, Developers and QA team.
Requirements gathering is not the same job and the business user cannot give the good requirements and cannot sure that the business user and customer provide all the requirements [2]. A project manager has to visualize the requirements. This helps the business user to see their requirements in all the dimensions instead in a paragraph. This visualization ensures the developers, testers and Business analysts to get involved in the earlier phases of Software development life cycle.
Figure – 4, Quality induction at requirements phase Requirements visualization is essential especially for the projects that contain the presentation layers. Now a day’s most of the companies are investing energy in identifying the Quality management and spending on it to achieve the success with all the projects. And if we compare with the Standish reports a slash in failure projects can be observed.
0 20 40 60 80 100 120
Traditional approach
Suggested approach
Requirements
Analysis
Design & Coding
Acceptance
Development
B. Requirement Traceability.
Without traceability products can drift away from what the user requires. Quality is conformance to requirements.
As soon as the requirements are defined in a Requirement document the traceability matrix is also need to be built. Use cases, code artifacts and test cases are also planned at this phase. By this testing becomes a parallel activity to the development. This is an approach that spans all the stake holders aware of the quality objectives. As a result, testing cannot be a bottleneck for a product which is performed under pressure at the end of the software development life cycle. Most of the defects can be identified at these stages and can be easily estimated and planned for fixing them. This can ease the developers and testers who significantly see the surprises after code is delivered.
C. Test coverage.
Test coverage always followed by the traceability matrix. Once the requirements are constructed all the teams are to be involved by Project manager and check for the test coverage is as per expected. This is an ice breaker of traditional approach of throwing the build to the QA and expecting the certification. The benefits of requirement traceability and test coverage are self evident. This ensures systematic design of test cases and plan to the predictable test coverage. This approach also helps in facilitating the test plan design which is not relying on the skilled or experienced testers. This injects repeatability and improves testing process to make predictable test coverage. Also this approach results in making the test cycle rapid and manageable. The requirements are quality assured and the test plan is having good coverage. These requirements based matrix is to be used across all the phases of the software development life cycle.
Capturing the intent of users as part of business in very difficult and it’s not easy to communicate their business needs to the development teams. In fact the
root cause for the 70% of defects is poor definition of requirements. The simple reason is
Requirements are defined in a complex manner.
They are more and come from different stake holders.
Users are unable to anticipate what they need until they actually see.
Traditional approaches leave us with a little margin for error, which makes a project manager difficult to fulfill the business needs, delivering quality product by eliminating waste.
Now a day’s due to globalization the team are spread across the globe and sometimes the work is outsourced. There may be mix and match of usage of tools and also sometimes the teams uses open source tools. This increases complexity and its very tough for a project manager to manage a change. With this milestones are missed and product might fail. With the tight deadlines Quality team cannot concentrate half of the development time to eliminate the waste. Developers are delivering code which doesn’t exactly match to the business needs and rework is a constant approach and is today’s reality.
More than 40% of the developer’s time is spent on rework [6].
Software organizations are unable to address this challenge and are habituated to go in a traditional approach of doing software testing at the end of the cycle. Quality team is not included at the time of requirements definition and test plan creation and development is completed. Thus Quality of the product is very bad and it’s failing and unable to meet the business requirements.
How a project manager can address these challenges and deliver a product the business needs?
1. Requirements 2. Change 3. Quality
Figure – 5, Proposed Key areas of Project manager
Risk of poor business outcomes can be slashed with the clear cut idea on defining the requirements and visualization of them. This also frees from the ambiguity for the direction.
A project manager has to gain control in the constantly shifting world. Project manager has to prioritize the tasks, defects, requirements, test plan, test scripts. A project manager has to be the point of contact and need to have a dashboard on all the tasks which were being handled by the global teams and continuously monitor the tasks to provide a quality output. [4]
And the possible outcome is quality how it is? [5] From initial phase to product delivery, the entire process is to be scheduled properly by the project manager. This helps in tracking and analyzing the quality at each phase. And all the test plans are to be planned early and should be in sync with the business goals and doesn’t get affected even the requirements are changed. This would help a software project management by shifting focus from re moving defects to preventing defects. And also gives a predictable and managed path by removing rework and controlling additional costs.
This also leads to focus on new developments and innovations which might help in achieving to deliver successfully the required product for what business needs.
Hence as mentioned above the Project manager need to concentrate on the following three areas.
1. Always get aligned with business needs to deliver a quality software.
2. Proper verification and validation to deliver quality software.
3. Have a visibility and control to deliver quality software.
IV.FINDINGS
The proposed technique like checking the quality of requirements has been identified as the best approach by many of them, who are selected for the analysis. A detailed questionnaire is presented to a sample population selected across different software firms. And the selected members are software engineers, leads, managers and senior management members. Received mixed responses and most of them are aligning to the proposed solution.
The responses are like
Projecting clean and clear requirements to both customer/end user and internal team members bridges the gap between the business needs and the development including the testing.
TheobjectiveofcalculatingQIistoachievecustomersatis factionandalsoresultinimprovedproductivity,reducede rrors,reducedtrainingandimprovedacceptance. As mentioned above 63% of projects don’t succeed as per chaos manifesto 2010. Of course this shows improvement for which 68% failures reported in 2009. This means that quality in delivering software projects is slowly increasing. And the software organizations are also moving from the traditional approach of waterfall to the agile process irrespective scrum or iterative. The industry reports say that
Quality
approximately 40% of projects are now adopting agile process [6].
V.CONCLUSION
A project manager needs to concentrate more on checking for the quality from the requirements phase. This helps project manager to bridge the gap between the user needs to the quality product. Always project manager need to document the requirements in a clear and understandable format. In traditional approach the project manager and team including customer cannot visualize about the quality of the product. If the proposed method is adopted or followed project manager can easily gain the confidence of stake holders as well the customer in delivering a quality product.
The proposed solution might require further study to improvising it.
Quality is not working sitting with the test team, it’s increasingly and equally responsible for both the test and development teams [6].
VI.REFERENCES
[1] Don’t Be Confused by Quality Written by Patti Gilchrist – project times [www.project times.com]
[2] www.borland.com
[3] http://www.cse.dcu.ie/essiscope/
[4] Software QA and Testing Resource Center: http://www.softwareqatest.com/
[5] www.SearchSoftwareQuality.com
[6] www.Standish group.com
[7] Project Management Institute. Project management-a proven process for success.
URL: http://www.pmi.org/projectmanagement/success.htm
[8] http://pmtips.net/project-control/
G.V.Bhanu Sai Prasad is a Manager working in a software
organization. He is having 16+ years of experience in software projects, project management and practice. He is holding Masters Degree in Computer science and Business management. He is a research scholar from a reputed university. His main research area is Software engineering. Under this area he is doing research for Software Project management and is particularly interested in picking the different project management techniques which lead to deliver a successful product. He had submitted papers to international journals on different software project management techniques and they talk about maturity management required for software organizations - CMMI, different components or techniques of software project management, challenges of a quality manager and controlling the scope creep
Kranthi Kumar Reddi is a Senior Software Engineer working in a software organization. He is having 6 years of experience in software projects, Testing Services and practice. He is holding Masters Degree in Computer science. He is a research scholar from a reputed university. His main research area is Software engineering. Under this area he is doing research for Software Project management and is particularly interested in picking the different project management techniques and Quality Management which lead to deliver a successful product. He had submitted papers onAffect of Quality Management in finding test escapes by improving process at different levels in SDLC, Do Quality Management skills are advantageous for a Software Quality Analyst?, Poor Software Quality Causes – How to overcome?
.
P.B.V. Prasad is a Sr.Manager in GAIL (INDIA) LTD., having 25 years of experience in Industrial Automation, Application programming and Software Development. He is holding Masters Degree in Computer science and Business management. He is a research scholar from a reputed university. His main research area is Software engineering. Under this area he is doing research for Software Project management and is particularly interested in picking the different project management techniques which lead to deliver a successful product. He had submitted papers to international journals under project management like, Critical Success Factors that are essential for Project Management, A study on risk management, and about the leadership qualities of the project manager.
