SOFTWARE ENGINEERING PRACTICES[1][1]

Initiative Practices Software Engineering Management Practices This work focuses on the ability of organizations to predict and control quality, schedule, cost, cycle time, and productiv

SOFTWARE ENGINEERING PRACTICES

NITHILA GOVINDARAJU

Abstract:

The core purpose of this paper is to help others make measured improvements in their software engineering capabilities This paper introduces some of the effective software engineering practices It can be management practices or technical practices, which helps

in the overall improvement in the performance of the organization

Introduction:

“It is often literally impossible or commercially unreasonable to guarantee that software

of any complexity contains no errors that might cause unexpected behavior or intermittent malfunctions so called ‘bugs’ The presence of such minor errors is fully within common expectations.”

The above statement is a legal expression which signifies the widespread acceptance of low quality software The core of the problem can best be summed up as the “software gap”, the gab between ambitions and achievements in software engineering The techniques presented here helps in overcoming these difficulties

Initiative Practices

Software Engineering Management Practices

This work focuses on the ability of organizations to predict and control quality, schedule, cost, cycle time, and productivity when acquiring, building, or enhancing software systems

• Capability Maturity Model

The models provide a structured and integrated collection of best practices (capability maturity models) that are used by organizations to improve their technical and management performance in disciplines that affect software The CMM can be used to rate maturity profile for an organization (on a five-point scale with five being the best) and for process improvement From 1987-1991, the initial years of reporting (130 organizations) showed that 80% of organizations were CMM-1 while only 0.8% (apparently only one organization) were CMM-5, the highest rating The latest study in August 2000 (with 1269

organizations) indicated that 45.9% were CMM-1 while 2.2% (about 28 organizations) were CMM-5

Software Engineering Technical Practices

This work focuses on the ability of software engineers to analyze, predict, and control selected properties of software systems Work in this area involves the key choices and tradeoffs that must be made when acquiring, building, or enhancing software systems

MANAGEMENT PRACTICES

 Higher quality and productivity, faster delivery, lower costs, and better morale

 Predictable schedule, cost, and quality from your software developers

 Effective software acquisition practices and visibility into the software contracts

Building High Performance Teams Using Team Software Process (TSP) and

Personal Software Process (PSP)

High Performance Teams

While the Capability Maturity Model (CMM) focuses on what organizations should do, it does not specify how to reach those goals The PSP provides specific guidance on how individual engineers can continually improve their performance The TSP provides specific guidance about how PSP-trained engineers can work as effective team members

on a high-performance team All of these technologies can work together to allow organizations to produce quality software on schedule

The Team Software Process (TSP)

The Software Engineering Institute has developed the Team Software Process (TSP) to help integrated engineering teams more effectively develop software-intensive products This process method addresses many of the current problems of developing software-intensive products and shows teams and their management explicitly how to address them For example, hardware-software projects in even very experienced groups generally have cost, schedule, and quality problems Testing is generally expensive and time consuming, and often followed by many months of user trials before the products are fully usable

Team Software Process has four principal phases:

1 Requirements

2 Design

3 Implementation

4 Test

 Each phase starts with a launch or re-launch

 TSP projects can start or end on any phase

 The TSP phases can and should overlap

 TSP permits whatever process structure makes the most business and technical sense

The TSP shows engineering groups how to apply integrated team concepts to the development of software-intensive systems It walks teams and their management through

a launch process that establishes goals, defines team roles, assesses risks, and produces a comprehensive team plan

Following the launch, the TSP provides a defined and measured process framework for managing, tracking, and reporting on the team's work

The TSP has been used with pure software teams and with mixed teams of hardware, software, systems, and test professionals and it has been shown to sharply reduce the total cost of development and acquisition TSP has been used for both new development and enhancement and with both commercial and embedded real-time systems Team size ranges from 3 up to 12 to 15 professionals for simple teams Larger multi-teams can range up to several dozen professionals Additional process extensions are required for larger teams

The TSP has five objectives:

1 To build self-directed teams that plan and track their work, establish goals, and own their processes and plans These can be pure software teams or integrated product teams of three to 20 engineers

2 To show managers how to coach and motivate their teams and how to help them sustain peak performance

3 To accelerate software process improvement by making CMM level 5-type behavior normal and expected

4 To provide improvement guidance to high-maturity organizations

5 To facilitate university teaching of industrial-grade team skills

The principal benefit of the TSP is that it shows teams of engineers how to produce quality products for planned costs and on aggressive schedules It does this by showing teams how to manage their work and by making them owners of their plans and processes

The TSP was developed to help software engineering teams build quality products within cost and schedule constraints and to accelerate software process improvement A typical software engineering team spends a great deal of time and creative energy struggling with questions like:

• What are our goals?

• What are the team roles and who will fill them?

• What are the responsibilities of these roles?

• How will the team make decisions and settle issues?

• What standards and procedures does the team need and how do we establish them?

• What are our quality objectives?

• How will we track quality performance and what should we do if it falls short?

• What processes should we use to develop the project?

• What should be our development strategy?

• How should we produce the design?

• How should we integrate and test the product?

• How do we produce our development plan?

• How can we minimize the development schedule?

• How can we determine project status?

• How do we assess, track, and manage project risks?

• What do we do if our plan does not meet management's objectives?

• How do we report status to management and the customer?

The Personal Software Process (PSP)

The Personal Software Process helps individual engineers to improve their

performance by bringing discipline to the way they develop software Based on the practices found in the Capability Maturity Model (CMM), the PSP can be used by engineers as a guide to a disciplined and structured approach to

developing software

Because 70 percent of the cost of developing software is attributable to personnel costs, the skills, experience, and work habits of engineers largely determine the results of the software development process This relationship of the engineer to the results of the development process is the premise on which PSP is based Because software engineers are generally not taught planning, tracking or quality measurement, they usually don't track their work, and software quality is rarely measured

The PSP shows engineers how to manage the quality of their products and how to make commitments they can meet It also provides them with the data to justify their plans The PSP can be applied to many parts of the software development process, including small-program development, requirement definition, document writing, systems tests, and maintenance and enhancement of large software systems

The PSP has been shown to substantially improve the estimating and planning ability of engineers while significantly reducing the defects in their products

Personal Software Process

ENGINEERING PRACTICES

Software Architecture and Architecture Tradeoff Analysis

Software architecture forms the backbone for building successful software-intensive systems A system's quality attributes are largely permitted or precluded by its architecture Architecture represents a capitalized investment, an abstract reusable model that can

be transferred from one system to the next Architecture represents a common vehicle for communication among a system's stakeholders, and

is the arena in which conflicting goals and requirements are mediated

Architecture Tradeoff Analysis

 Background

 Goals

 Benefits

Background

Quality attributes of a large software system reside principally in the system's software architecture In large systems, the achievement of qualities such as performance, availability, survivability, and modifiability depends more on the overall software architecture than on code-level practices such as language choice, detailed design, algorithms, data structures, and testing It is cost effective to try to determine, before a system is built, whether it will satisfy its desired qualities

Although methods for analyzing architectures with respect to quality attributes exist, these analyses have typically been performed on specific qualities in isolation However, the attributes (and hence their analyses) interact Performance affects modifiability Availability affects safety Security affects performance Everything affects cost While experienced designers know that these tradeoffs exist, there is no codified method for characterizing them and, in particular, for characterizing their interactions More importantly, these tradeoffs present the areas of highest risk in architecture

Goals

• Establish and transition validated techniques for analyzing the effect of software architectural decisions on selected product quality attributes

• Establish and transition validated techniques for reconstructing the architecture of legacy systems and for determining the conformance of as-built systems to defined architectures

• Diagramming architectures

• Promote understanding of software architecture and architecture analysis

Benefits

A growing number of organizations are recognizing the importance of software

architecture and are making architecture evaluations part of their corporate practice

PRODUCT LINE PRACTICES

The Product Line Practice (PLP) Initiative is designed to guide organizations away from traditional one-at-a-time system development and towards the systematic large-scale reuse paradigm epitomized by product lines The vision of the Product Line Practice (PLP) is that:

• Product line development is a low risk/high return proposition

• Techniques for finding and exploiting system commonalities and for controlling variability are standard software engineering practice in DoD, government, and industry

We recognize that each organization is different, and the path taken to sound product line practice will vary depending on these differences For example, organizations differ by the kind of systems they build, e.g., how large they are, whether or not they are real-time,

or whether or not they are distributed They differ by the kind of market they address, e.g., how large the customer base is or the expected lifetime of a system They differ by the assets they have in hand, e.g., how much software has already been developed that can be reused, how much domain knowledge is available, the talent and expertise of their personnel or the structure of their enterprise

What is a Software Product Line?

A software product line is a set of software-intensive systems that share a common,

managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way

Benefits and Costs of a Product Line

Software product line approaches accrue benefits at multiple levels This section lists the benefits (and some of the costs) from the perspective of the organization as a whole, individuals within the organization, and the core assets involved in software product line production

Organizational Benefits

The organizations that we have studied have achieved remarkable benefits that are aligned with commonly held business goals Some of these include:

• large-scale productivity gains

• decreased time-to-market

• increased product quality

• increased customer satisfaction

• more efficient use of human resources

• ability to effect mass customization

Product Line Essential Activities

At its essence, fielding of a product line involves core asset development and product

development using the core assets, both under the aegis of technical and organizational

management Core assetdevelopment and product development from the core assets can occur in either order: new products are built from core assets, or core assets are extracted from existing products Often, products and core assets are built in concert with each other Core asset development has also been called domain engineering Product development from core assets is often called application engineering The following

Essential Product Line Activities

Each rotating circle represents one of the essential activities All three are linked together and in perpetual motion, showing that all three are essential, are inextricably linked, can occur in any order, and are highly iterative The rotating arrows indicate not only that core assets are used to develop products, but also that revisions of existing core assets or even new core assets might, and most often do, evolve out of product development The diagram in the above figure is neutral in regard to which part of the effort is launched first In some contexts, already existing products are mined for generic assets—perhaps a requirements specification, an architecture, or software components—which are then migrated into the product line's asset base In other cases, the core assets may be developed or procured for later use in the production of products

There is a strong feedback loop between the core assets and the products Core assets are refreshed as new products are developed Use of assets is tracked, and the results are fed back to the asset development activity In addition, the value of the core assets is realized