 |
Many organizations greatly underestimate the cost of their approach
to the software process.
In part this is due to a common failure to recognize the following
characteristics of software construction.
| The Problem |
|
- Volatility
-
Modern software methods and modern computer environments have greatly
increased the frequency and speed of changes to software products.
Keeping a software product up-to-date and maintaining control
has been made significantly more difficult.
- Volume
-
Modern software projects are produced from thousands of source files
and large volumes of third party products rendering the management
of their production difficult and complicated.
- Urgency
-
The increased competition in the software market and the emergence
of the internet as a marketing, sales, and distribution mechanism
has substantially increased the need for quick response to the
changing market place.
- Complexity
-
Server/Client systems and internet solutions are just examples of
modern systems that involve the integration of large numbers of
programs and datafiles.
Products consisting of thousands of files are not uncommon.
Managing such products and ensuring their consistency has become
exceedingly complicated without a comprehensive approach.
- Inadequate Tools
-
Most organizations are using tools that were initially developed
25 years ago and were not designed to deal with the large scale
software systems of today.
Measures to compensate for the inadequacy of the tools lead to inefficient,
complicated, poorly understood, and poorly controlled home grown
solutions that do not scale well and are inconsistency applied.
- Poor Training
-
As most organizations must be aware, it is difficult to find good
programmers and unfortunately the training they have received does
not prepare them well for the realities of real software production.
- Poor Standards
-
Few useful standards exist that can be applied to improve the
software process.
- Lack of Concern
-
Quality assurance and configuration management are often considered
low status positions and hence usually not staffed by senior or
experienced staff.
Many organizations do not dedicate sufficient resources to QA and CM
as other aspects of the projects have first call and get the
lion's share of the resources.
- Regulatory Requirements
-
Clients and regulatory agencies are demanding that software suppliers
improve their process to ensure reproducibility and confidence in
the reliability of their process.
Given the above problems, these demands are difficult to achieve.
| The Symptoms |
|
The above problems inevitably lead to the following problems:
- Complicated Build Procedures
- process to build products requires
magic knowledge and too many manual procedures
- Inefficient Builds
- the process often involves far more processing
than is required due to poor build architecture.
Developers often have to build far more than should be necessary
to test their changes.
- Incomplete Builds
- complicated process often leads to missed
phases and processes
- Inability to Rebuild Reliably
-
poor build tools make it difficult to guarantee that shipped product
can be reconstructed as it was when shipped.
- Difficulty Porting
-
the build process is often difficult to adapt to new platforms
- Version Skews
-
the build process does not guarantee that version inconsistencies
cannot arise
- Build Gurus
-
complicated build processes often lead to a dependence on a few
individuals who have the necessary knowledge
- Non-transferable Staff
-
inconsistent build processes across projects prevent or complicate
the transfer of staff from one project to another
- Lost Opportunity Costs
-
inefficient complicated builds lead to missed opportunities
| So How's QEF Going to Help? |
|
Based on a survey of QEF users, an organization can expect to realize
a 10-15% productivity improvement from their software development
group.
Some users have claimed improvements by as much as 50%.
If an organization has 100 developers, usually costed at $100,000 per
year each, even a 10% improvement would be a savings of $1M per year.
Also, the lack of consistent, comprehensive processes leads to lower
quality products, wasted time and effort, and lost opportunities.
| Who uses QEF |
|
Anyone who wants to be able to manage their software process
reliably, completely and correctly can use QEF to achieve that goal.
The QEF Software Process Automation System is useful
in projects as small as a few files and as large as many thousands of files.
With its sophisticated auditing and logging it particularly appeals to
industries that have strong regulatory requirements or need to meet standards
like ISO 9000.
Yet QEF's efficient facilities for organizing and controlling
software construction makes it popular in even single developer
operations.
| | | | |
