meetings

Herb Krasner started his presentation by discussing how SASPIN focuses on topics related to software process improvement experiences and practical ideas in order to promote: the advancement of software quality, software productivity improvement, and software process maturity.

Process maturity, for example, occurs at all organizational levels including that of the individual programmer. The CMM, with its focus on project/organizational behavior, presumes that good SWE exists but cannot trump bad project, process and organizational management. The CMM KPA of Software Product Engineering is about consistently performing a well-defined engineering process that integrates all software engineering tasks to produce correct, consistent software products effectively and efficiently. These tasks usually involve a lifecycle of analyzing the system requirements allocated to software, defining the software requirements, developing the software architecture, designing the software, implementing the software in code, integrating software components, testing the software to verify that it satisfies the specified requirements, delivering quality software products, and evolving that software over time to meet changing needs. But how can we fully achieve this without disciplined, professional software engineers? In fact, the whole CMM approach falls flat on its face without them.

In spite of the millions of software professionals worldwide and the ubiquitous presence of software in our society, software engineering has not yet reached the status of a legitimate engineering discipline and a recognized profession.

There are numerous efforts underway to foster the evolution of software engineering as a professional discipline. This talk will discuss the elements of SWE professionalism, and the recent development of a code of ethics.

Specifically, the approved SWE code of ethics (Version 5.2) both summarizes aspirations at a high level of abstraction; and includes clauses that give examples and details of how these aspirations change the way SWEs should act as professionals. In short the code of ethics states that software engineers shall commit themselves to making the analysis, specification, design, development, testing and maintenance of software a beneficial and respected profession. In accordance with their commitment to the health, safety and welfare of the public, software engineers shall adhere to the following eight principles:

1. PUBLIC - Software engineers shall act consistently with the public interest.

2. CLIENT AND EMPLOYER - Software engineers shall act in a manner that is in the best interests of their client and employer.

3. PRODUCT - Software engineers shall ensure that their products and related modifications meet the highest professional standards possible.

4. JUDGMENT - Software engineers shall maintain integrity and independence in their professional judgment.

5. MANAGEMENT - Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance.

6. PROFESSION - Software engineers shall advance the integrity and reputation of the profession.

7. COLLEAGUES - Software engineers shall be fair to and supportive of their colleagues.

8. SELF - Software engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession.

This code of ethics, which is being taught to graduating college seniors, is expected to positively change the behavior of practicing SWEs in industry. This code, and the emerging SWE BOK are key milestones that are crucial for the evolution of software engineering toward a professional status.

If you are using Microsoft Internet Explorer 4 or later you must use Adobe Acrobat 3.01 or later to view and print the slides and if you wish to save the file you must have Internet Explorer 5 or later.

With Netscape 3 or later you may view, save or print the slides with Adobe Acrobat 3 or later.

If you don’t already have the Acrobat Reader click on the image to the left to download the latest version free.

Jorge Boria presentation was easy to follow and understand because the presentation is based on an actual company he worked with as a senior management consultant. Testing being easier to sell than QA in low maturity organizations, Jorge Boria presented how a leader in the EFT market, which has a strong testing group under the same manager as QA has been, splits the quality improvement tasks into suggestion (QA) and enforcement (testing). Testing activities were moved forward in the life cycle to enforce peer reviews (although initially they are just walkthroughs, more formal reviews will follow) and provide all phases with test cases, as much as possible. This shortened the time to develop them and significantly shortens the number of iterations for system testing. Now phases have acceptance criteria linked to QC, and if they are not met, QC returns the work product to the development team.

Eventually, QA rescues the team by (a) helping them produce a review in short notice, or (b) showing them ways to obtain a waiver. In either case, QA is seen as help, while QC are the enforcers. This changes the dynamics of SPI, giving QA more room for proposing process improvements and more opportunity to review their proposals with project teams.

Our presenter has graciously granted us permission to place a copy of his slides on our web site. The slides are in Adobe Acrobat format and are available by clicking the file name Saspin_May2001_Boria.pdf .

With Netscape 3 or later you may view, save or print the slides with Adobe Acrobat 3 or later.

If you don’t already have the Acrobat Reader click on the image to the left to download the latest version free.

Vic Helbling presented an overview on COCOMO 1987 methodology and David Srulowitz presented an overview of COCOMO II -- a variation reputably useful for WEB applications. Both our efforts are mentored by Barry W. Boehm at USC and his merry band of PHD co-authors.

The essential algorithms of the constructive cost model (COCOMO) was developed by Dr. Barry Boehm and published in his Software Engineering Economics book in 1981. Today COCOMO remains the only software-estimating model whose algorithms are not treated as trade secrets. Vic will explain what COCOMO was and how it was used (1987).

Dave discussed COCOMO II, an objective cost and schedule model for planning and executing software projects. It is an important ingredient for managing software projects and provides a framework for communicating business decisions among project stakeholders. It is a substantial update to COCOMO (about 30%), the authors' 1981 effort that has worked well for mainframe-based waterfall methodology projects, to provide lessons learned over the past 20 years and address the next generation of process, methods, and tool improvements in the software industry. Dave also provided an overview of the changes from COCOMO to COCOMO II.

The third section of the presentation was demo of Cost Xpert, a software estimation tool (utilitizing COCOMO II) created by Marotz, Inc. This section was presented by Mike Bandor.

The presenters have graciously granted us permission to place a copy of their slides on our web site. The slides are in Adobe Acrobat format and are available by clicking the file name SASPIN_Apr2001_COCOMO.pdf .

With Netscape 3 or later you may view, save or print the slides with Adobe Acrobat 3 or later.

If you don’t already have the Acrobat Reader click on the image to the left to download the latest version free.

The application of Object Oriented Analysis and Design using the Unified Modeling Language (UML) is rapidly growing in the software industry. However, too many software developers (analysts, designers, programmers, testers, architects, et al…) still don’t utilize their Use Cases to drive their design and let the software development process help them discover their solution. Typically, they go straight to class design. Software developers may build Use Cases, but usually build a detailed class diagram as the next step with little or no basis for evolving to that level of design. Developing software is a process of discovery. Use Case realization is the process of discovering all the design elements that will lead to a quality, robust, component based solution that can be easily maintained and reused. In this presentation Bill discussed concepts and techniques necessary to effectively use system requirements captured using use cases to drive the development of a robust design model. He covered the Fundamental object-oriented analysis and design concepts in the context of an iterative, use case-driven, architecture-centric process.

You can contact Bill Cottrell at the Rational Software Corporation, at (512) 608-6817, or bcottrell@rational.com .

Bill has graciously granted us permission to place a copy of his slides on our web site. The slides are in Adobe Acrobat format and can be viewed by clicking the file Saspin_Mar2001_Cottrell.pdf .

With Netscape 3 or later you may view, save or print the slides with Adobe Acrobat 3 or later.

If you don’t already have the Acrobat Reader click on the image to the left to download the latest version free.

Effective requirements management and traceability from requirements to the rest of a software development effort have long been one of the greatest challenges of software development. Studies which address the successes and failures of software projects find that requirements management, including elicitation, analysis and the ability to respond to changing requirements, is a substantial influence in a project's success. The Use Case approach to requirements management is an effective technique for capturing the user's perspective on the system. This approach ties easily into the other critical aspects of the development - project management, design, testing, and documentation.

In this presentation Cindy clearly addressed the basics of the Use Case approach and how it can be used within the context of requirements activities to help ensure the success of a software development project. The presentation also described some specific success stories using this approach.

You can contact Cindy Van Epps at the Rational Software Corporation, cvanepps@rational.com .

Cindy has graciously granted us permission to place a copy of her slides on our web site. The slides are in Adobe Acrobat format and can be viewed by clicking the file SASPIN_feb2001_Van_Epps.pdf . The project estimating excel spreadsheet that Cindy mentioned can be downloaded by clicking the file ProjectEstimateMethod.xls .

With Netscape 3 or later you may view, save or print the slides with Adobe Acrobat 3 or later.

If you don’t already have the Acrobat Reader click on the image to the left to download the latest version free.

When we think about judging the effectiveness of a SPI program, we often think of financial justification – that is, the classic Return on Investment (ROI). But is that return the limit to effectiveness of improvement? As the SASPIN recognizes in its theme for the year, there’s a need for a balanced look at People, Process, and Technology when looking at the value of process improvement programs. So, too, our effectiveness measures should have a balanced look.

During the last several years, the Practical Software and Systems Measurement program has been collecting best practices for measuring various aspects of process improvement. One of those is the common issue area of Project Justification, considerations used before and after the fact of running a process improvement project. In this presentation, Dr. Statz examined the kinds of questions and concerns addressed by this common issue area and what measures have been found that address those questions and concerns.

Dr. Statz has graciously granted us permission to place a copy of her slides and two attachments on our web site. The slides are in Adobe Acrobat format and can be viewed by clicking the file Saspin_Jan2001_Statz.pdf (99 KB). The Attachments are in Microsoft Word format and can be viewed by clicking Saspin_Jan2001_statz_attachment_1.doc for attachment 1 and Saspin_Jan2001_statz_attachment_2.doc for attachment 2. Attachment 1 is the Project Justification Category/Questions/Measures Table and Attachment 2 is the Issue Areas - Categories - Measures Mapping Table.

With Netscape 3 or later you may view, save or print the slides with Adobe Acrobat 3 or later.

If you don’t already have the Acrobat Reader click on the image to the left to download the latest version free.

Today there is need in virtually every industry for bigger, more complex systems to support our undying thirst for automated products and services in our every day life (e.g. cellular based integrated financial services); just to keep in touch with everything going on in the world. These, and other problems in software development, spurred the development of the Unified Software Development Process (USDP), by "The Big Three." It is a use-case driven, architecture-centric, iterative and incremental process used to develop component-based solutions using the Unified Modeling Language (UML) during an Iterative Development Life Cycle.

Captain Noe gave an excellent overview of the USDP, which is widely used around the world, both as a software development process and a generic process framework that can be specialized to meet the needs of different organizations, systems, and solutions. It has also been integrated with a commercial software tool, allowing ease of use and enforcement of rules. The basics of the USDP were presented, as well as a very brief overview of UML.

Captain Noe has graciously granted us permission to place a copy of her slides on our web site. The slides are in Adobe Acrobat format and can be viewed by clicking the file Saspin_Nov2000_Noe.pdf (99 KB). .

With Netscape 3 or later you may view, save or print the slides with Adobe Acrobat 3 or later.

If you don’t already have the Acrobat Reader click on the image to the left to download the latest version free.

The PSP was developed by Watts Humphrey at the Software Engineering Institute (SEI). Watts sought to show that large system principles could be used effectively by small software development teams and individuals. He designed the PSP to apply the principles of the Capability Maturity Model to individual software work.

Mr. Terrel explained how the Personal Software Process (PSP) is a structured set of forms, standards, and procedures designed to help you do better work. The PSP teaches the principles of process definition and measurement and shows you how to tailor a PSP process to best fit your unique needs and preferences.

From historical data collected, Mr. Terrel explained how experienced software engineers typically inject 100 or more defects per KLOC. Data on the PSP's use show that engineers achieve average reductions of 75% in numbers of injected defects, make more accurate plans, and have higher productivity.

Mr. Terrel discussed the key elements of the PSP, analytical results from the use of PSP and the challenges of applying the PSP in the real world.

Hiring and retaining software people is no longer a standard staff function in most organizations. It is war. Dr. Curtis recent research results on which factors are most critical in hiring and retaining software folks, and how they can be addressed with short term actions by managers. He described methods for improving recruiting success. He also discussed the single most important factor for determining whether someone will leave and what can be done about it. He presented a staged model to improve team-building success and some radically new ideas about how to create integrated product development teams that solve some of the biggest problems that cause them to fail. He showed how these advances are being incorporated into version 2 of the People CMM. He presented some results and lessons learned in trying to improve the management of software professionals in organizations like Boeing, Ericsson, Novo Nordisk, Tata Consultancy Services, and others. The bottom line is that organizations that take workforce management and development seriously can cut their turnover rates in half within one or two years. The reduced cost of replacing people more than pays for the improvement program.

Dr. Curtis has graciously granted us permission to place a copy of his slides on our web site. The slides are in Adobe Acrobat format and can be viewed by clicking the file Saspin_Sep2000_Curtis.pdf (1307 KB). .

With Netscape 3 or later you may view, save or print the slides with Adobe Acrobat 3 or later.

If you don’t already have the Acrobat Reader click on the image to the left to download the latest version free.

Last revised: October 16, 2002