NASA Langley Research Center Software Process Improvement Initiative

NASA Langley Research Center Software Process Improvement Initiative (SPII) Findings Presentation October 27, 1997

NASA Langley Research Center Corner. Stone Findings Presentation q Corner. Stone Overview q Findings q Next Steps

NASA Langley Research Center Corner. Stone Overview

NASA Langley Research Center Corner. Stone Goals q The Corner. Stone Phase is the foundation of La. RC’s overall Software Process Improvement Initiative q The goals of the Corner. Stone Phase are: Ø Develop a plan to improve La. RC’s software development practices n Identify current state of software development at La. RC n Identify current best practices used in software development at La. RC n Develop a High Performance Model for La. RC’s software development activities (incorporates the appropriate elements of the Capability Maturity Model, ISO 9000 -3, Strategic and Quality Framework, and Baldrige Award Criteria) Ø Obtain management’s support, complete with resources, to implement La. RC’s Software Process Improvement Plan

NASA Langley Research Center Software Process Improvement Initiative (SPII) Goals Ø Improve the work environment for La. RC’s software community, leading to higher morale and increased productivity Ø Develop sustainable mechanisms for continuous improvement in the productivity and quality of software developed across La. RC Ø Increase customer satisfaction with La. RC software products

NASA Langley Research Center Corner. Stone Activities q Lay the Foundation Ø Establish Infrastructure n Plan for the Assessment n Corner. Stone Planning and Validation Ø Baseline n Workshop Training n Customer Workshops n Supplier Workshops n Follow-Up Interviews (as needed) n Best Practices Documentation n Analyze Workshop Results n Prepare and Present Findings Ø Plan n Define La. RC SEPG n Develop SPI Plan n Review SPI Plan with Sponsors n Present SPI Plan q Implement Improvements …

NASA Langley Research Center Corner. Stone Team Members Norma Campbell, RTG/FDCD Victoria Chung, IOG/ISSD Michael Holloway, RTG/FETD Chuck Niles, IOG/FSED Pam Rinsland, IOG/AESD Pat Schuler, IOG/ISSD Jim Townsend, RTG/FMAD Jim Watson, OSEMA/OMA Sue Voigt, SASPG/SSCD Consultant: Cindy Torpey, Change. Bridge Inc.

NASA Langley Research Center Corner. Stone Scope q Centerwide involvement q Organizations involved in software management, development, and maintenance q Customers of software projects q 101 civil servants and contractors interviewed

NASA Langley Research Center Corner. Stone Principles q Start with a process framework q Baseline current state (not audit) Ø Conduct interviews and discussions Ø Observe strict confidentiality q Involve senior management q Work as a Centerwide team q Focus on La. RC needs

NASA Langley Research Center Capability Maturity Model Product and process are quantitatively controlled Target N-2 Time/$/. . . Target N-y Managed Process improvement is institutionalised Predicted Performance Probability Optimising Process Characteristics Probability Level Process is informal and unpredictable Target N-x Target N-1 -a Time/$/. . . Target N Initial Probability Repeatable Project management system in place; performance is repeatable Time/$/. . . Probability Defined Software engineering and management processes defined and integrated Probability Time/$/. . .

NASA Langley Research Center Capability Maturity Model q Repeatable / Level 2 (All Key Process Areas covered in interviews ) Ø Ø Ø Requirements Management Software Project Planning Software Project Tracking & Oversight Software Quality Assurance Software Subcontractor Management Software Configuration Management q Defined Level (Selected Key Process covered in interviews) Ø Training Program Ø Software Product Engineering Ø Intergroup Coordination Ø Peer Reviews

NASA Langley Research Center Corner. Stone Approach…. q Baseline current state (snapshot in time) Ø …some improvements are already initiated q Baseline included all areas which impact the software development group Ø … some are under our control, others will require a coordinated effort q Not all points are at the same detail Ø …some are very specific, other are more general q Processes were assessed, not specific groups Ø …especially when we discuss SQA and Training Program q Identify areas for improvement Ø …not specify how to

NASA Langley Research Center Corner. Stone Findings q Key Process Area Ø Purpose and Description Ø Best Practices Ø Improvement Opportunities

NASA Langley Research Center Requirements Management q Purpose Ø Establish a common understanding of the customer’s requirements that will be addressed by the software project q Description Ø Establish and maintain an agreement with the customer on the requirements for the software project Ø The "customer" is a system engineering group, TAG, a project office, another internal organization, or an external customer Ø Agreement covers both the technical and nontechnical (e. g. , delivery dates) requirements Ø Agreement forms the basis for estimating, planning, performing, and tracking the software project's activities throughout the software life cycle

NASA Langley Research Center Requirements Management q Best Practices Ø Requirements are prioritized and managed according to priority Ø Developer works with customer to interactively draw out requirements Ø Operational Concepts Documents help in understanding the requirements (some projects put on the web for increased visibility) Ø Test cases traceable back to requirements Ø Explicit contractor task to capture and manage requirements Ø Rapid prototyping to validate requirements with customer

NASA Langley Research Center Requirements Management q Improvement Opportunities Ø Ø Ø Importance of requirements is not realized Requirements are neither defined early enough, nor refined far enough Inadequate resources dedicated to requirements management Software requirements do not track to system requirements Don’t know how to adequate document requirements Customers are not trained in requirements generation Changes in requirements handled by overtime masks over-commitment Requirements creep is not managed nor controlled (cost is not understood) No established policy to guide projects in requirements management Role and responsibility of systems analysis is not clearly understood Requirements are not consistently documented and reviewed with the customers Segmentation of responsibilities between researchers and software developers leads to uncertainty in product functionality

NASA Langley Research Center Requirements Management q Consequences Ø Project schedule and cost are significantly increased when requirements are inadequately defined and documented Ø Rework is common due to changing requirements Ø Customer satisfaction is decreased when their requirements are not met

NASA Langley Research Center Software Project Planning q Purpose Ø Establish reasonable plans for performing software engineering and managing the software project q Description Ø Develop estimates for the work to be performed, establish the necessary commitments, and define the plan to perform the work

NASA Langley Research Center Software Project Planning q Best Practices Ø Project cost, effort and duration estimates are developed and tracked Ø Software Work Breakdown Structure is generated at the same level as hardware WBS Ø Scheduling tools (MS Project, REVIC) are used Ø Statements of Work specifies creation of project plans Ø Software staged release at planned milestones Ø Software manager designated to oversee a software development project Ø Software personnel participate in project plans Ø SQA involved in project planning

NASA Langley Research Center Software Project Planning q Improvement Opportunities Ø Schedules are driven by externally set milestones, instead of actual work required Ø Software Management Plans are not consistently documented, if at all Ø No planning metrics are captured across the organization on which to base realistic future estimates Ø Commitments are not honestly negotiated Ø Inadequate project planning is compensated for by overtime Ø Over-commitment Ø No La. RC project policy for managing software projects - the approach to software project management is project dependent Ø The value of software project plans is not fully understood by developers, managers, or researchers Ø Personnel are not aware of available procedures and guidelines for software estimating Ø No guidelines are available for document software development plans

NASA Langley Research Center Software Project Planning q Consequences Ø Software projects do not meet schedules or budgets (could face cancelation) Ø Burn out civil servants and contractors

NASA Langley Research Center Software Project Tracking and Oversight q Purpose Ø Provide adequate visibility into actual progress so that management can take effective actions when the software project's performance deviates significantly from the software plans q Description Ø Track and review the software accomplishments and results against documented estimates, commitments, and plans Ø Adjust plans based on the actual accomplishments and results

NASA Langley Research Center Software Project Tracking and Oversight q Best Practices Ø Informal interchange meetings are held frequently for tracking Ø Automated tools (MS Project, PC Artemis) are used to track project progress Ø Milestones used as checklist Ø Formal reviews held at selected milestones Ø Dedicated business manager to track software project status

NASA Langley Research Center Software Project Tracking and Oversight q Improvement Opportunities Ø Corrective actions are not taken in a timely manner Ø Software costs are not accurately reflected in project charge structures Ø No measurements or lessons learned are captured and used for future projects Ø Software size is not estimated or tracked Ø Managers are not trained in software project management and tracking Ø Technical issues are not managed and communicated Ø Software Development Plans are not used to manage the project Ø Software project reviews are ad hoc and ineffective; results are not elevated to management (guidelines needed)

NASA Langley Research Center Software Project Tracking and Oversight q Consequences Ø Products not completed on expected dates Ø The real software project status is not known until it is too late to do anything about it

NASA Langley Research Center Software Subcontractor Management q Purpose Ø Select qualified software subcontractors and manage them effectively q Description Ø Select a software subcontractor Ø Establish commitments with the subcontractor Ø Track and review the subcontractor's performance and results

NASA Langley Research Center Software Subcontractor Management q Best Practices Ø Periodic reviews are conducted with contractors to review progress and communicate status Ø COTRs and Technical Monitors are designated to establish and manage the software contract Ø Source Evaluation Boards select contractors based on their ability to perform the work Ø Success has been demonstrated using Performance Based Contracting Ø Formal quarterly evaluations are required Ø Software services are acquired using standard NASA contracting regulations

NASA Langley Research Center Software Subcontractor Management q Improvement Opportunities Ø No accountability for poor contractor performance Ø COTRs and Technical Monitors are not trained in software engineering or managing software development efforts Ø Performance Based Contracting is misunderstood, and due to poor training it is ineffectively applied Ø Source Evaluation Board frequently recommends lowest bidder rather than best qualified Ø Required reviews are not consistently conducted Ø Contractor turnover is high and requires frequent reorientation resulting in increased costs Ø No written La. RC policy or guidelines for managing software contracts Ø Contractors over-commit and rely on “free” overtime Ø Skill level and training on the contract does not match what is required

NASA Langley Research Center Software Subcontractor Management q Consequences Ø Frequent dissatisfaction with contractor’s products Ø PBC task generation is more time-consuming

NASA Langley Research Center Software Quality Assurance q Purpose Ø Provide management with appropriate visibility into the process being used by the software project and of the products being built q Description Ø Review and audit the software products and activities to verify that they comply with the applicable procedures and standards Ø Provide the software project and other appropriate managers with the results of these reviews and audits

NASA Langley Research Center Software Quality Assurance q Best Practices Ø SQA contractors advise and give consultation to projects on software engineering when requested (on configuration management and software management plan) Ø Infractions are reported to participating project teams

NASA Langley Research Center Software Quality Assurance q Improvement Opportunities Ø Need sufficient staff for uniform coverage of SQA on Langley software projects Ø Increase awareness of added value of SQA practices Ø Appropriate guidelines for SQA activities (current LHB not widely accepted) Ø Review SQA activities on a regular basis Ø Track cost and associated return on investments on SQA tasks

NASA Langley Research Center Software Configuration Management q Purpose Ø Establish and maintain the integrity of the products of the software project throughout the project's software life cycle q Description Ø Identify the configuration of the software (i. e. , selected software work products and their descriptions) at given points in time Ø Systematically control changes to the configuration Ø Maintaining the integrity and traceability of the configuration throughout the software life cycle Ø Placed under software configuration management both the software products delivered to the customer (e. g. , the software requirements document and the code) and the items identified with or required to create these software products (e. g. , the compiler)

NASA Langley Research Center Software Configuration Management q Best Practices Ø Configuration Control Boards are established and used to control changes, assess impacts and communicate status Ø Automated tools (Clear. Case, PVCS, RCS, Lib. Link, CVS, Lab. View) are used to control software work products (requirements, change rationale, code and supporting documentation) Ø Intent of SCM can be met without the use of automated tools for projects Ø Web-based change request system established (Clear. DDTS) Ø SCM process documented and followed on some projects

NASA Langley Research Center Software Configuration Management q Improvement Opportunities Ø Rigor of formal SCM is not always appropriate for project’s size, phase and purpose Ø Change request status is not adequately communicated across all project personnel Ø Lack of awareness of existing guidelines and templates results in significant duplication of effort Ø Insufficient funding for SCM staff, tools and training Ø SCM typically applied too late in project phase Ø SCM plans are not documented and/or followed and changes are not controlled Ø Lack of understanding of the benefits of SCM Ø Contracts do not always require the appropriate level of SCM and there is inadequate CM on deliverables

NASA Langley Research Center Software Configuration Management q Consequences Ø Lack of SCM results in compromised mission certainty and validity of data and products

NASA Langley Research Center Training Program q Purpose Ø Develop the skills and knowledge of individuals so they can perform their roles effectively and efficiently q Description Ø Identify the training needed by the organization, projects, and individuals Ø Develop or procure training to address the identified needs Ø Evaluate current and future skill needs and determines how these skills will be obtained Ø Use informal vehicles when appropriate (e. g. , on-thejob training and informal mentoring)

NASA Langley Research Center Training Program q Best Practices Ø Training Office exists to meet the needs of the La. RC including the software development community Ø Some projects and organizations successfully leverage the capabilities of the Training Office to meet their needs Ø Training Office annually surveys La. RC to establish training needs

NASA Langley Research Center Training Program q Improvement Opportunities Ø Increase is needed in training budget due to cross training and retraining of La. RC personnel Ø Inconsistent management support for training Ø Insufficient time is allocated for attending training Ø Training is not considered a priority Ø Need full implementation of Individual Development Plan (IDP) which ties to the SQF and the agency strategic plan Ø No effective mechanism for consistently training contractors and civil servants working on the same project Ø No project training plan Ø Travel funds shortage limits training opportunities and technical exchange

NASA Langley Research Center Software Product Engineering q Purpose Ø Consistently perform a well-defined engineering process that integrates all the software engineering activities to produce correct, consistent software products effectively and efficiently q Description Ø Perform the engineering tasks to build and maintain the software using the project's defined software process and appropriate methods and tools

NASA Langley Research Center Software Product Engineering q Best Practices Ø Operational Concept, Users Manual and Test Plans/Cases developed prior to code Ø Apply techniques such as Object Oriented Design (OOD), reverse engineering, structured programming, and modularity to reduce code complexity, increase reusability and improve maintainability Ø Automated software development tools (Purify, Quantify, Pure. Coverage, Rational Rose, Clear. Case, Clear. DDTS, Object Manual, Lab. View GUI) are used to design, test, CM, and document software Ø Provide realistic operational testing scenario for software Ø Office automation tools used in innovative ways for software development, testing and documentation (databases, spreadsheets)

NASA Langley Research Center Software Product Engineering q Best Practices (cont. ) Ø A project has demonstrated La. RC’s ability to meet FAA standards for airworthy flight software Ø On line Web sites exist that describe software engineering guidebooks, formal methods and metrics collection database Ø Third party tests against requirements agreed to by users Ø Continuous rapid prototyping used to demonstrate feasibility and early progress Ø Requirements gathering techniques resulted in improved software product Ø Centralized facility provides access, guidance and expertise for domain-specific tools

NASA Langley Research Center Software Product Engineering q Improvement Opportunities Ø Insufficient time allocated for software engineering tasks (requirements definition, design, testing, integration, configuration management, and documentation) Ø Software engineering activities often hidden because their value is not recognized, perceived as overhead by projects, and researchers/projects do not want to pay for reuse (no corporate view for long-term investment) Ø No rewards for good software engineering Ø Single point failures on many projects created by one person and insufficient documentation Ø Testing address physics only, not software quality Ø No La. RC dissemination guidelines for software exist

NASA Langley Research Center Software Product Engineering q Improvement Opportunities (cont. ) Ø Lack of in-house software product engineering expertise Ø Need point of contact where software engineering expertise and guidance can be obtained Ø Ineffective tool utilization due to poor communication and awareness Ø Web sites not advertised Ø Software engineering techniques not appropriately tailored for small projects Ø No incentive to take research code to production quality or make it reusable by other projects Ø Lack of expertise in project planning and scheduling leads to insufficient time for fundamental software engineering tasks

NASA Langley Research Center Software Product Maintenance q Best Practices Ø Use portable computer to set up, perform experimental test, and analyze results q Improvement Opportunities Ø Insufficient funding for sustaining and maintenance of software Ø Ineffective implementation of CM prohibits quick minor changes to software for experimental use Ø Insufficient verification of software prior to delivery leads to high maintenance cost Ø Due to insufficient manpower and maintenance procedures, staff is not adequately notified on software changes Ø Constant changes in COTS upgrade decrease productivity due to perpetual learning curve

NASA Langley Research Center Intergroup Coordination q Purpose Ø Establish means for the software engineering group to participate actively with the other engineering groups so the project is better able to satisfy the customer's needs q Description Ø Software engineering group participates with other project engineering groups to address system-level requirements, objectives, and issues Ø Representatives of the project's engineering groups participate in establishing the system-level requirements, objectives, and plans by working with the customer and end users, as appropriate Ø Requirements, objectives, and plans become the basis for all engineering activities

NASA Langley Research Center Intergroup Coordination q Best Practices Ø Workshops and shared facilities bring different groups together for improved information exchange Ø Interface Control Documents, frequent meetings and timely meeting notes ensure effective exchange of information Ø Web-based information and email exchange facilitates technical coordination Ø Physical co-location of discipline specialists promotes intergroup coordination during a project Ø Teamwork training is available Ø Communication between software programs used by different groups achieved by in-house developed interfaces (scripts, GUIs, wrappers, standard features, filters)

NASA Langley Research Center Intergroup Coordination q Improvement Opportunities Ø Need to have representatives of all technical disciplines (including software) involved from the start of a project (requirements, cost estimates, operational concepts, requirements allocation) Ø Due to the lack of systems engineering performed at La. RC, software and hardware staff are forced to fill that role in an ad-hoc manner Ø Poor communication among groups doing similar work within La. RC results in duplication of work Ø No effective mechanism to ensure all disciplines are represented on project teams Ø Software specialists not aware of overall project concept Ø Perception that software can fix anything, including poor hardware selection, leads wasted funds and staff hours Ø Lack of documented commitments between engineering groups Ø Changes are not effectively communicated across the engineering groups Ø Contractors resist communication due to proprietary fear

NASA Langley Research Center Peer Reviews q Purpose Ø Remove defects from software products early in the development process where it is more cost effective to remove them Ø Develop better understanding of software products and defects that might be prevented q Description Ø Peers methodically examine software work products to identify defects and areas where changes are needed Ø Identify and schedule specific products that will undergo peer review as part of the defined software process

NASA Langley Research Center Peer Reviews q Best Practices Ø Peer reviews identify problems early in the lifecycle resulting in saved time and decreased costs Ø Post-mortem review is effective mechanism to capture lessons learned Ø Informal review by an in-group peer works well on small projects Ø Peer reviews captures problems not otherwise identified Ø Completion of peer reviews is a phase exit requirement and indicates readiness to proceed Ø Peer reviews are effective mechanism to train staff and indoctrinate new hires Ø Peer review process is documented (NASA Formal Inspection Handbook, project documentation) Ø User requirements are basis for code reviews Ø Email and Key Activities are used to document peer review results

NASA Langley Research Center Peer Reviews q Improvement Opportunities Ø Peer reviews are not commonly used (even unknown by some projects) in spite of positive return on investment experienced at La. RC Ø Current review process frequently omits software issues Ø Current formal design review system (PDR, CDR) often misses large problems Ø Post-mortem reviews hardly ever held Ø Limited time, training, and staff are provided for performing peer reviews Ø No data collected on peer review results and lessons learned (dormant data base)

NASA Langley Research Center Non-CMM Related Concerns q Improper ISO 9000 implementation could impose restrictive procedures on research and significantly impact resources to perform future research q Numerous management issues were identified such as: · · · The lack of management awareness of the pervasiveness and magnitude of work required to develop software at La. RC Need investment, encouragement, and reward system for improvements, best practices, positive technical transfer Lack of adequate resources for performing software development q There is a lack of a central pool of software developers to service La. RC q Relation of La. RC’s Strategic Quality Framework to real work is poorly defined

NASA Langley Research Center Next Steps

NASA Langley Research Center Critical Point in La. RC’s SPI Program q Corner. Stone phase is a critical milestone in the software process improvement program q Corner. Stone phase baselines our current state and develops a plan for future process improvement q Proactive management is required to go forward with successful implementation of the Improvement Plan

NASA Langley Research Center Upcoming Activities q Receive feedback on Findings Briefing q Develop draft Software Process Improvement Plan q Review SPI Plan with sponsors q Establish Senior Management Steering Group (SMSG) q Establish Software Engineering Process Group (SEPG) q Finalize SPI Plan q Conduct SPI Plan Briefing q Implement Improvement Plan

NASA Langley Research Center Management Steering Group Description q Comprised of the La. RC CIO, ISO Project Manager, and Division Chiefs who have a stake in the successful achievement of the Software Process Improvement (SPI) goals q Monitors and evaluates SPI efforts from the perspective of the total organization to ensure that the overall improvement efforts are in concert with La. RC’s mission and goals q Meets regularly with the Software Engineering Process Group (SEPG) to discuss the progress of the SPI program, problems, issues and concerns q Works together with the SEPG to identify and provide the long-term commitments and resources required to coordinate the development and maintenance of software engineering processes for use by current and future software projects

NASA Langley Research Center Suggested Management Steering Group Membership Ø Ø Ø Doug Arbuckle/Associate Director, La. RC Fay Collier/ISO 9000 Project Manager, La. RC Pat Dunnington/CIO, La. RC Luat Nguyen/FDCD Bill Wessel/OSEMA Carl Gray/FSED Milt Holt/FETD Rob Kudlinski/ISSD Lenny Mc. Master/AESD Bill Smith/SSCD David Stephens/FMAD

NASA Langley Research Center Responsibilities of the Management Steering Group (MSG) · · · · · Ensure alignment of Software Process Improvement (SPI) initiatives with La. RC mission and goals Approve strategic plan for SPI Provide sponsorship, pro-active commitment, and visible management support Allocate resources Monitor the progress of the SPI initiative Provide guidance and direction to the Software Engineering Process Group (SEPG) Conduct regular meetings with the SPI Group Promote cooperation and cross-functional communications Cultivate an enabling environment for continuous process improvement Obtain and sustain the support for the SPI initiative

NASA Langley Research Center Software Engineering Process Group (SEPG) Description q Chartered by the MSG, as the focal point for software process improvement q Coordinate and plan the SPI program activities in concert with the guidance and direction of the MSG q Report the progress of SPI related activities to the MSG q Provide technical support and consultation q Staffed by experienced software development practitioners who facilitate the definition, maintenance, and improvement of the software engineering processes used within the organization q Work collaboratively with the projects to resolve process related problems and assist in the development, training and implementation of processes and procedures

NASA Langley Research Center Suggested Software Engineering Process Group (SEPG) Membership q Members of the Corner. Stone team q Volunteers from interview workshops q Appointees from participating divisions

NASA Langley Research Center Responsibilities of the Software Engineering Process Group (SEPG) q Define and manage the plan for development and implementation of software process improvements across the La. RC q Provide a pool of software engineering expertise and corporate knowledge (Formal part of La. RC organization with assigned resources and management commitment) q Provide consultation and guidance on appropriate level of software engineering implementation and future directions q Provide and facilitate education on software engineering to management and staff via workshops, seminars, symposiums, and setting up news/user groups and maintain web sight q Provide a repository for reuse code, documents, tool knowledge, procedures, processes, La. RC best practices, templates, lessons learned, metrics, and examples q Facilitate sharing of tools and maintenance of COTS across projects q Build and reinforce sponsorship for the SPI program management support at all levels

NASA Langley Research Center Next Steps q Establish membership of MSG & SEPG (by Nov. 12) q Post Best Practices on Web q Prioritize Improvement Opportunities q Develop SPI Project Plan q Review and Obtain Approval of Plan (by Dec. 19) q Complete Final Report q Implement Improvement Plan

NASA Langley Research Center Closing Thought “Creative thinking may simply be the realization that there is no particular value in doing things the way we’ve always done them. ” - R. Flesch, Educator

NASA Langley Research Center Odd and ends follow: q Global Improvement Opportunities Ø Ø Ø Seminars (maybe during lunch) on SW topics of interest Establish Web site to capture and publicize best practices Establish basic training in software engineering Short-course training on widely-used COTS. Need to provide guidelines and expertise for appropriate level of software engineeringprocedures based on project size, application and criticality.

NASA Langley Research Center Odds and ends cont. : q Some analysis was started on the Closing Q 1 data that is captured below(not to be used in findings briefing): Global Improvement Opportunities >Provide education on requirement gathering and documentation >Do pilot/demonstration projects on selected software engineering activities >Conduct lesson learned review on project complete and post results on the web Management Related Improvement Opportunities >Need to overcome resistance to positive change >Segmentation of responsibilities across organizations has led to lack of single point of accountability for technical issues >Improve management awareness of the pervasiveness? ? importance and magnitude of work required to develop software Global Concerns >Improper ISO 9000 implementation could impose restrictive procedures on research and significantly impact resources to perform future research >Civil servants should be made technically knowledgeable in software >Sponsor research in appropriate software engineering practices for the research environment NASA software put in commercial system with no profit to NASA (companies make profits on NASA software)

NASA Langley Research Center Responsibilities of the Software Engineering Process Group (SEPG) · · · · Establish a repository for SPI products (best practices, code, and lessons learned) Establish appropriate organizational metrics and mechanisms for the collection of metrics Provide desk-side mentoring to project teams Track, monitor and report the status of SPI initiatives to the MSG Promote technical awareness and coordinate training for software engineering with the La. RC training office Provide consultation and CMM expertise to the MSG and the technical working groups which implement improvements Compare current practices against the goals and key practices of the CMM Keep La. RC apprised of SPI activities and progress

NASA Langley Research Center Sponsors q Kristin Hessenius/Associate Director, La. RC q Fay Collier/ISO 9000 Project Manager, La. RC q Pat Dunnington/CIO, La. RC q Rob Kudlinski/ISSD