Popular Pitfalls in Software Management Strategies

A IT industry Practitioner’s Perspective

R.RamkumarD.Ae.Tech., B.Com, HSM, PGDBA, CSQA, CISA,

PMP

Agenda

My Introduction Objective Software Engineering Evolution Where industry lacks? SDLC Phase-wise challenges How do we address them? Q & A session

My Introduction Name: R. Ramkumar ‘Ram’ Education:

Aeronautical Engineer Commerce Graduate, PG Honors qualification in IT and PG Diploma in Business Administration

Experience: 15+ years in Information Technology Worked in premier IT organizations like HCL, Polaris, TVS Worked in KPMG as ISO / ISMS Auditor First ISMS Auditor in India to represent KPMG Done around 500 audits in India, US, UK, China, Singapore etc.

Other qualifications: Certified Software Quality Analyst Certified Information Security Auditor Project Management Professional ISO 9001:2000 Lead Auditor ISO/IEC 27001:2005 Lead Auditor

Objective

Learn where industry stumbles, predominantly

Stress on management perspective and touch upon technical perspective

Patterns of failure listed Pitfalls ‘Potential’ risks Intent to increase awareness

Software Engineering Evolution Software Engineering at very nascent level Rules for developing software evolving Popular ones: -

CMMI ISO 90003:2004 Agile

Software Services / Product – different rules The time to reckon has come

Need of the hour

Decreasing margin, dollar value

Increasing overheads

Software Performance Predictability

Where Software Industry Lacks?

Where Software Industry Lacks?

Success in one project is not ‘generally’ replicatable in another project

Arriving at average ‘Productivity’ figures are misleading

Effort estimates are not common between two teams for similar activity

Metrics is a major grey area Eg. NCSLOC Interoperability of team members with

steep learning curve

SDLC Phase-wise challenges

Phases in SDLC

Requirements Design Construction Testing Delivery Maintenance

Requirements Phase

Requirements Phase Objectives

To understand ‘what’ the client wants To understand the domain intricacies To decide the best suited technology

Pitfalls Team does not contain Business Analyst Team provides less time for Requirements

phase User feels “All told” Team feel “All understood” Technology is based on Team’s “comfort

factor” Testing team not involved at this phase

Requirements Phase

Major Contributor

Design Phase Objectives

To decide on “how to” deliver the solution To decide the “Application Framework” To analyze the impact on various other

interfaces Pitfalls

Weak design Does not withstand user load, data load Not flexible to change Interface in-compatibility

Design Phase (contd.) Pitfalls

Least time spent on designing Design with low knowledge on

requirements Vetting of design not effectively done

Internal reviews of design very weak Client concurrence on design very rare

Scalability not addressed Environments the application should work not

properly addressed Low appreciation to product design Design document rarely updated

Design Phase (contd.)

“ We Try to solve the problem by rushing through the design process so that enough time will be left at the end of the project to uncover errors that were made because we rushed through the design process ……….”

-Glenford MyersThe moral : Do not rush through Design

Construction Phase Objective

To implement the design To create maintainable source code

Pitfalls Developers modify the design Source code is not ‘clean’

Non-compliance to coding standards Junk code accumulation No source code Headers / Active Comments

Construction Phase Pitfalls

Construction on non-baselined requirements

Bad tinkering of generated source code Near nil peer reviews of source code Bad naming conventions, decreasing

traceability Memory leaks, Security Threats and

other performance issues rampant

Testing Phase Objectives

To validate whether application addresses all User Requirements

To validate technical performance To validate all possible conditions are

addressed Pitfalls

Tester enters late in the project cycle Test environment does not fully simulate end

user environment Test cases are not comprehensive Testing is seen as a ‘not-so-great’ job

Testing Phase Pitfalls

Root causes of defects not identified Root cause could be:-

Bad requirements gathering Inconsistent design

Fixing of defects leading to more defects Taking defects reporting very personally

(!) Instability of testing team

Delivery Phase Objectives

To delivery the committed application with committed functionalities

To make defect free and on time delivery To have minimum issues during acceptance

testing Pitfalls

Manpower ramp up while delivery date nears

‘Good-news-only Syndrome’ for the customer

Panic grips the entire Project Team

Delivery Phase Pitfalls

If there is a flare-up in the delivery Project goes in full throttle Revenue leakages happen in various channel

Client visits Video / Tele Conferences Long hours of working Early pickup and Late vehicle drops to team

members Further additional strengthening of the team

No proper accounting for many of the above referred revenue leakages

Delivery Phase

Delivery Phase – My Study

0

1

2

3

4

5

Big Medium Small

IT Organizations reaction to customer flare-ups

Personal meeting

Extra effort without billing

Tele / Video conferencing

More interim deliveries

Increase headcount

Prime Contributor

Maintenance Phase Objectives

To change the application without impairing existing functionalities

To add new functionalities to the existing application

To fix any historical defects of the application Pitfalls

Developers do not like this ‘tinkering’ job Impact on the rest of the application is not

known The source repository of the current source is

ambiguous viz. on-site and off-site team

Maintenance Phase Pitfalls

Regression testing is missed out Existing source not understandable,

leading to huge re-work Any deficient design is carried forward

for want of huge extra effort to do permanent fix

Solution – That Matters

There should be SYSTEM in place A mechanism to know compliance to

this SYSTEM should be established EFFECTIVENESS of this SYSTEM

should be measured ACTION to be taken where the

SYSTEM lacks in providing RESULTS

Solution – The PDCA Approach

Establish Establish ProcessProcess

Monitor & Monitor & Review Review processprocess

Implement & Implement & operate the operate the

processprocess

Maintain & Maintain & improve the improve the

processprocessActAct DoDo

PlanPlan

CheckCheck

Solution – That Matters Tighter integration between the plan

and check In practice improved co-ordination

between QA and QC teams Key formula “Processes that deliver” Never encourage system violation, even

if gives instantaneous gratification Ensure that “All are same before the

law” to ensure compliance to system

Solution – The Approach Take good practices from Standard

Software Engineering Literature Adopt guidelines of ISO 90003:2004 Practice the process Enhance with CMMI Level 2/3 practices Practice the processes again and

mature Enhance with CMMI Level 4/5 practices

Summary Indian IT industry is still evolving its

system There are many potential landmines

that we could place our foot upon It’s only “Effective System” that will

help in bring in sanity “Effective System” has to evolve by

monitoring results Consistent Quality Delivery is the key to

long term success

Case Studies

Two interesting cases

A Troubled ProjectSoftware Project “Antigua” was done for radar imaging software.

John & Bill who were veteran Technical Leads were sent by ForeStone Software for study

The first requirements study was completed with 30% less effort than planned

When John & Bill presented the requirements to the customers, customers were thrilled. “You got it right” exclaimed the IT director of “Antigua”

When the design was completed and construction was over for the first three modules, an interim release was made.

The CEO of ForeStone software was able to hear bomb explosion in his email. The first delivery has really “Bombed” at client’s place. The same IT Director was screaming “This is not what you committed”

What went wrong? How to solve this?

The SureFire CustomerCustomer representative David sent yet another mail telling “This is not what I meant when we wanted an easy interface…”JohnAshton Software CEO Ronnie was reading it red faced. Project is already consumed 70% of the effort and client is yet to freeze the requirements. An earned value analysis told that there would be not less than 180% effort over runProduct team has already started developing some of the modules by now. This thought made Ronnie sweat further.Money paid by the client was a paltry 25% of the total value. Meanwhile Legal came up about clauses on penalty for any overshooting of schedule.What went wrong? What is the solution?

Q & A

The floor is yours…!