2.4 What are Key Methods for SPI?


2.4 What are Key Methods for SPI?

Key methods consist of general-purpose process improvement cycles and general-purpose process improvement criteria. Methods include software process modeling notations, software engineering standards, and software engineering life cycles. Software engineering methodologies, software engineering notations, and software engineering processes are key methods. Software engineering tools, software engineering measurement, and computer programming languages are also key SPI methods.

General-Purpose Process Improvement Cycles

General-purpose process improvement cycles are used in conjunction with general-purpose process improvement criteria. These are very popular and are the preferred methods for many. Software engineering methodologies tend to integrate many of the SPI methods into a single unified approach.

General-purpose process improvement cycles are designed to be the basic frameworks necessary to begin the process of SPI. However, these frameworks tend to be diluted and ineffective at best, with little overall direction for improving software processes. These methods are not recommended for novices who need specific help to identify high-impact and high-ROI SPI methods. Examples include Six Sigma, statistical process control, plan-do-check-act, and initiating-diagnosing-establishing-acting-learning. Total quality management, total productivity management, and total cost management are also popular examples. Total resource management, total technology management, and total business management are part of this family of methods.

General-Purpose Process Improvement Criteria

General-purpose process improvement criteria are used in conjunction with general purpose process improvement cycles. General-purpose process improvement cycles tend to have an appraisal stage. This stage is used to leverage the specific requirements of general-purpose process improvement criteria. These criteria have built-in mechanisms to help organizations identify high-leverage areas for improvement. They also have mechanisms to prioritize process improvements and steward resources toward high-priority areas.

They tend to be more specific than general-purpose process improvement cycles and minimize some confusion for the novice. However, they tend to have so many criteria as to confuse and dilute the overall effectiveness of using them. Examples of general-purpose process improvement criteria include ISO 9001, TL 9000, BOOTSTRAP, and TRILLIUM. The Malcolm Baldrige National Quality Award and Software Process Improvement and Capability Determination are popular examples.

And who can forget the host of capability maturity models? There are the Software Capability Maturity Model and Capability Maturity Model Integration . There are the Systems Engineering Capability Maturity Model and Integrated Product Team Capability Maturity Model. There are the Systems Security Engineering Capability Maturity Model and System Acquisition Capability Maturity Model. The Trusted Capability Maturity Model, People Capability Maturity Model, and Integrated Capability Maturity Model are unique models. The Network Engineering Capability Maturity Model and Testing Capability Maturity Model are good examples. And don't forget the E-Commerce Capability Maturity Model.

Software Process Modeling Notations

Software process modeling notations are textual or visual aids designed to define and document software processes. These notations are also used to communicate, facilitate, and even use a new and improved software process. Software process modeling notations can be confusing for a variety of reasons. First, many are inadequate for expressing the depth of detail necessary to describe software processes. This can hinder the use, exploitation, and consistency of software processes. Second, choice of which notation to use can lead to debilitating politics. This results in little progress toward the creation and use of a new and improved software process. Third, only one or two of these notations are effective. Few are recommended for defining new and improved software processes. These methods provide little direction for novices on what software processes to define and at what depth to define them. They also lack guidance on how to define software processes to achieve peak operating efficiency. In many cases, definition of software processes is a task for highly trained experts, not arbitrary novices.

Examples of software process modeling notations include short checklists, textual descriptions, flowcharts, and ETVX diagrams. IDEF0 diagrams, information mapping, input/output charts , and professional policy and procedure formats are good examples. Proprietary notations built into workflow automation tools are also prime examples of software process modeling notations.

Software Engineering Standards

Software engineering standards are basic but well-rounded minimum requirements for designing new software processes. They, too, have their strengths and weaknesses. Software engineering standards have greater breadth than general-purpose process improvement criteria. Therefore, they tend to offer better priorities for SPI. However, software engineering standards have much less depth than general-purpose process improvement criteria. Without depth, their guidance can be ineffective to achieve their purpose. An ideal approach may be to blend general-purpose process improvement criteria and software engineering standards. This would seem to achieve a balance of both breadth and depth. But this too is futile, quite confusing, and amounts to attempting to save the Titanic with Scotch tape and bailing wire. Examples of software engineering standards include MIL-STD-1521B, MIL-STD-973, MIL-HDBK-61, and MIL-STD-2549. MIL-HDBK-881, DO-178B, DOD-STD-2167A, MIL-STD-498, J-STD-016, ISO 12207, and ISO 15288 are good examples.

Software Engineering Life Cycles

Software engineering life cycles add integration, workflow, and tactical execution to software engineering processes. Tactical execution is intended to help organizations manage the design and development of software products and services. They sometimes have activities for software quality and reliability. Unfortunately, software engineering life cycles lack the breadth of software engineering standards. They also lack the depth of general-purpose process improvement criteria. With a few rare exceptions, they lack critical activities for successfully performing software project and quality management. Software engineering life cycles tend to offer much tactical guidance for novices. Once again, however, they do not provide enough guidance in software project and quality management. Without these skills, novices simply cannot succeed. Examples include waterfall, Spiral, evolutionary, prototyping, incremental, concurrent, concurrent incremental, and V model.

Software Engineering Methodologies

Software engineering methodologies are designed to string or thread multiple software engineering notations together. This is done to achieve the goal of specifying, designing, and implementing software-based systems. They tend to be based on graphical or mathematical notations. These notations are used for capturing software requirements, software designs, and constructs for software implementation. Software engineering methodologies suffer from a dual personality. They focus only upon technical engineering activities. However, they fail to include fundamentally necessary principles in software project and quality management. The creators of software engineering methodologies do not value the activities of software project and quality management. Instead, they focus on software visualization. It would be better if they combined project and quality management with visualization. However, not all software engineering methodologies are bad. One or two have a unique blend of all key methods for SPI. Examples include structured analysis, structured design, information engineering, and object oriented analysis. Object-oriented design, Clean Room, and Rational Unified Process are popular examples. Extreme Programming, Agile Methods, Personal Software Processs SM , and Team Software Process SM are even better examples.

Software Engineering Notations

Software engineering notations are the building blocks of software engineering methodologies. They are early attempts at formalizing methods for SPI. They are used to create visual representations of software constructs. This is done to facilitate rational and logical software development. Software engineering notations are meant to visually capture requirements and designs. They are designed to influence software engineers to do more than just computer programming. Individual software engineering notations are some of the earliest forms of in-depth software engineering guidance. Many software engineering notations have been haphazardly strung together to form software engineering methodologies. Similarly, software engineering notations offer no guidance for software project and quality management. These are the tenets of SPI, and software engineering for that matter. Examples include data flow diagrams, state transition diagrams, and entity relationship diagrams. Control specifications, structure charts, and program design languages are older examples. The Object Modeling Technique, Unified Modeling Language, and formal methods are newer examples.

Software Engineering Processes

Software engineering processes are designed to represent coarse-grained logical groupings of major software engineering activities. They tend to be some of the earliest forms of software engineering formalisms. Some software engineering processes formed the basis for entire software engineering standards. Software engineering standards are merely collections of software engineering activities. In any case, software engineering processes are thought of as major subactivities or subelements within the software life cycle. They are also considered subelements of a software project and software development process. Many at one time may have embodied the entire discipline of software engineering. Configuration management is an example of a process that once embodied the entire discipline of software engineering. While some software engineering processes add negligible value, others offer an overwhelming amount of benefits. These benefits often pay for the cost of all other software engineering processes combined. The Software Inspection Process is a good example of this. Use of one or two software engineering processes has led a few organizations to the peak of world-class operating performance. A few late 20th century software engineering methodologies have eclipsed the value of performing individual software processes. Software engineering processes are both a blessing and a curse.

Some software engineering processes are basically innocuous . However, they are so immensely popular as to cause some to ignore substantially important software engineering processes. Examples include software configuration management, software testing, and independent verification and validation. The Software Inspection Process, software defect classification, and software project management are very good examples. Popular examples also include software configuration management, software defect prevention, and software reuse. Commercial off-the-shelf integration, software architecture, and product line management are some of the latest examples.

Software Engineering Tools

Software engineering tools are designed to define and formalize software engineering processes. They are designed to automate tedious tasks that cannot be consistently performed by humans . At the same time, they add great value, increase software productivity, and increase work product output. More importantly, they perform many built-in verification and validation tasks . Large-scale investment in software engineering tools dates back to the 1970s. Key SPI methods that added the greatest value were not even present in public consciousness. Software engineering tools in the 1970s were extremely primitive and added only marginal value. They were often hosted on primitive but expensive computer systems. These computer systems were oftentimes counterproductive to use.

Software engineering tools, fueled by SPI methods and computer systems, will answer many SPI challenges in the 21st century. Examples include computer-aided software engineering tools, software project management tools, and software estimation tools. Code generation tools, graphical user interface management systems, and automated static analysis tools are good examples. Model checkers, automated software testing tools, and workflow automation tools are even better examples. Don't forget popular tools such as software process definition tools and software configuration management tools. Requirements management tools, office automation tools, Web-enabled tools, and operating systems are also good examples.

Software Engineering Measurement

Software engineering measurement is designed to institute quantitative analysis in the field of software engineering. Most other methods tend to have a qualitative element. Software engineering measurement is meant to elevate the field of computer programming to a true engineering discipline. This is accomplished by quantifying the essential properties of software. It is meant to be similar to what physics does for the classical engineering disciplines of mechanical and electrical engineering. Software engineering measurement is the shield of world-class software organizations. It is also the shield of organizations that have achieved peak operating efficiency. Yet, most organizations do not perform any software engineering measurement at all. One or two of the best software engineering methodologies have a blend of good software activities and software measurement. It is best to look at software measurement as an integrated discipline rather than a stand-alone process. Examples include software productivity metrics, software structure or design metrics, and software cost models. Software quality models, software reliability models, and customer satisfaction measurement are classical examples. Earned value management, the Taguchi method, House of Cards, and Quality Function Deployment are measurement examples.

Computer Programming Languages

Computer programming languages are natural language dialects, instructions, and commands which are used to control computers. People use computer programming languages to operate computers, task them to perform activities, and build applications. They are used to build operating systems, office automation suites, graphical processing tools, and useful productivity tools. Computer programming languages are the building blocks of software, applications, computers, and even the field of SPI. Many people believe that selection, use, and mastery of computer programming languages are the only significant SPI method. They embodied the fields of computer science and software engineering following the birth of the electronic computer. The first advances in computer science came with the invention of high-level, English-like computer programming languages. They were designed to consummate the marriage between humans and machines. A few popular examples of computer science breakthroughs are attributed to computer programming languages. These include the invention of COBOL for business applications, FORTRAN for math applications, and Ada for military use. Higher level, easier-to-understand, and English-like computer programming languages significantly improve productivity. The more computers can do, the easier it is to program, and the higher quality the code will be. Eventually, millions of armchair computer programmers created Web sites overnight using World Wide Web technologies. No SPI method has ever had the impact that Web-enabled technologies and related computer programming languages have. Examples include machine language, assembly, COBOL, FORTRAN, Algol, PL/1, Jovial, LISP, Ada, SQL, and BASIC. LOGOS, Pascal, C, C++, Ada95, Visual Basic, HTML, Java, Perl, and C# are some of the latest examples.




ROI of Software Process Improvement. Metrics for Project Managers and Software Engineers
ROI of Software Process Improvement: Metrics for Project Managers and Software Engineers
ISBN: 193215924X
EAN: 2147483647
Year: 2004
Pages: 145

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net