SOFTWARE ENGINEERING PRACTICES[1][1]

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 softwareintensive 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: Requirements Design Implementation 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 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: 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 To show managers how to coach and motivate their teams and how to help them sustain peak performance To accelerate software process improvement by making CMM level 5-type behavior normal and expected To provide improvement guidance to high-maturity organizations 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 we establish them? What are our quality objectives? How will we track quality performance and what should we 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 we produce our development plan? How can we minimize the development schedule? How can we determine project status? How we assess, track, and manage project risks? What we if our plan does not meet management's objectives? How 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 asset development 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 figure illustrates this triad of essential activities 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 through the products that are developed from them As a result, the core assets are made more generic by considering potential new products on the horizon There is a constant need for strong, visionary management to invest resources in the development and to sustain the core assets Management must also precipitate the cultural change to view new products in the context of the available assets Either new products must align with the existing assets, or the assets must be updated to reflect the new products that are being marketed Iteration is inherent in product line activities—that is, in turning out core assets, in turning out products, and in the coordination of the two In the next three sections we examine the three essential activities in greater detail Conclusion: The goal was to put forth effective software engineering practices These practices improve the performance of individual engineers, development team, and the software architecture This in turn improves the performance of the organization, and better quality products can be achieved Hence it can be said that software engineering practices results in better performance and productivity Glossary Acquisition The process of obtaining products and services via contract Acquisition strategy A plan of action for achieving a specific goal or result through contracting for products and services Acquisition plan The artifact that is typically used to document the acquisition strategy Application engineering An engineering process that develops software products from partial solutions or knowledge embodied in software assets Attached process The process associated with a core asset that tells a product builder how to instantiate it or otherwise put it to use in a specific product Business model A framework that relates the different forms of a product line approach to an organization's business context and strategy Commission Contract with another party to build a product or provide a service Concept of operations Document describing an organization's structure, roles and responsibilities, processes, and policies that all detail the way the organization operates Core asset A software artifact that is used in the production of more than one product in a software product line A core asset may be architecture, a software component, a process model, a plan, a document, or any other useful result of building a system Development Generic word used to describe how software comes to be Domain An area of knowledge or activity characterized by a set of concepts and terminology understood by practitioners in that area Domain analysis Process for capturing and representing information about applications in a domain, specifically common characteristics and reasons for variability Domain engineering An engineering process that develops software assets for one or more domains Economies of scale The condition where fewer inputs such as effort and time are needed to produce greater quantities of a single output Economies of scope The condition where fewer inputs such as effort and time are needed to produce a greater variety of outputs Greater business value is achieved by jointly producing different outputs Producing each output independently fails to leverage commonalities that affect costs Economies of scope occur when it is less costly to combine two or more products in one production system than to produce them separately Mining Resurrecting and rehabilitating a piece of an existing software system to serve in a new system for which it was not originally intended Platform Core software asset base that is reused across systems in the product line Practice area A body of work or a collection of activities that an organization must master to successfully carry out the essential work of a software product line Product line A group of products sharing a common, managed set of features that satisfy specific needs of a selected market or mission area Product line approach A system of software production that uses software assets to modify, assemble, instantiate, or generate a line of software products Product line architecture Description of the structural properties for building a group of related systems (i.e., product line), typically the components and their interrelationships The inherent guidelines about the use of components must capture the means for handling required variability among the systems (Sometimes called a reference architecture) Product line scope Description of the products that will constitute the product line Product line system A member of a software product line Production plan The guide to how products in the software product line will be constructed from the product line's core assets Project An undertaking typically requiring concerted effort that is focused on developing or maintaining a specific product or products Typically a project has its own funding, accounting, and delivery schedule Software architecture Structure or structures of the system, which consists of software components, the externally visible properties of those components, and the relationships among them A set of software-intensive systems sharing a common, managed set of Software product features that satisfy the specific needs of a particular market segment line or mission and that are developed from a common set of core assets in a prescribed way Software product A description of an organization's context, the product line problem it line practice is trying to solve, and the set of practice areas to use in concert to solve pattern the problem References Bass, Len; Klein, Mark & Bachmann, Felix Quality Attribute Design Primitives (CMU/SEI-2000-TN-017) Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2000 Bass, Len; Klein, Mark & Moreno, Gabriel Applicability of General Scenarios to the Architecture Tradeoff Analysis MethodSM (CMU/SEI-2001-TR-014) Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2001  ... 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... 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... products Personal Software Process ENGINEERING PRACTICES Software Architecture and Architecture Tradeoff Analysis Software architecture forms the backbone for building successful software- intensive