Questionnaire: Access your SCM Process in Project

TABLE OF CONTENTS

1…… General Assessment Questions. 2

1.1     Questions to analyze the development process description.. 2

1.2     Questions to characterize the project application.. 2

1.3     Questions to identify the supporting tools. 2

2…… Assessment on Configuration and Change Management   2

2.1     Project/Development Managers. 2

2.2     Developers. 3

2.3     Testers. 3

2.4     Configuration Manager. 3

3…… Assessment on Build and Release Management.. 3

3.1     Build Engineer. 3

3.2     Release Engineer. 4

 

1           General Assessment Questions

1.1      Questions to analyze the development process description

 

Which of the following do you get from your existing process?

·         Examples

·         Guidelines

·         Artifact templates

·         Activity descriptions

·         Artifact descriptions

 

1.2      Questions to characterize the project application

 

  • What is the size of each project (duration, persons, person years,  LOC)

·         What type (maintenance / enhancement / new development / prototype /

§  feasibility)

  • What type of development model is being used?
  • Are we using any process models like UCM, RUP or any other?
  • Any industry/domain specific standards (like CMMI, ITIL etc.) to be followed?

 

1.3      Questions to identify the supporting tools

 

·         What are the tools that you currently use in your work?

·         How is the integration among the above tools?

·         Are we using the tool features the way they are designed or intended?

 

2           Assessment on Configuration and Change Management

2.1         Project/Development Managers

 

·         How do you maintain all the artifacts together and version them?

·         Where are the people working on the project located?

·         What’s the difference between Developer CM and Release CM?

·         How do you assess, and track the impact of a proposed change?

·         How do you manage system integration of modules developed by individual developers?

·         How many product versions are you supporting at this moment?

·         Who is the designated Configuration Manager?

 

 

2.2         Developers

 

·         How do you baseline project artifacts?

·         Can you build your system reliably and repeatedly?

·         Explain your labeling scheme?

·         Can you show me what versions went into a certain release?

·         What does the version tree for this file look like?

·         How many product versions are you supporting at the moment?

·         What is the version control tool being used? Is it user friendly?

·         What is the bug tracking/change management tool being used? Is it user friendly?

 

2.3         Testers

·         Do you know what files/documents should be delivered?

·         How do you assess, and track the impact of a proposed change?

·         Can you show me what artifact versions went into a certain release?

·         How comfortable are you working with Bug/Change management tool?

 

2.4         Configuration Manager

·         Do you know what files/documents should be delivered?

·         How do you track who changed what, when, where, and why?

·         How long does a build or release take?

·         Is there a Configuration Management Plan document?

·         Is there a tight integration between Version control tool and Bug/Change tracking tool?

·         How the parallel (if any) development is enabled? Any limitations with the current branching strategy?

·         Is this project development spanned across multiple sites? If so, what is your multi-site strategy?

 

3          Assessment on Build and Release Management

3.1         Build Engineer

 

  • What is the build process adopted (automated/manual)?
  • Are there nightly builds?
  • Is there continuous integration?
  • Are there smoke and sanity tests at the end of the build?
  • What is the build acceptance criterion (BAT)?
  • What is the build duration? Is it optimal?
  • How are pre-conditions to the build verified?
  • Are there any build environment integrated automated unit test-cases?
  • Is there any enforcement tool on coding standards?
  • Is there any code coverage tool being used?
  • Are the post build activities automated?
  • Any additional practices (like checksum generation, signing the build artifacts) in place as part of the build?
  • Are there any scripting technologies used in automating build process?
  • Is Labeling strategy well-defined?
  • If any third party tool is being used for packaging, is that package creation process automated?

 

3.2         Release Engineer

 

  • How many major, minor releases a year per project?
  • How many customers per release per project?
  • How do you deliver the releases to the customers? – Is it physical media distribution or Push/Pull mechanism from web or any other process?
  • Is the distribution CD/DVD creation process automated?
  • What is the size of the release deliverable?
  • What are the contents of a release?
  • How is the release bundle tested?
  • How many platforms are certified? How different are the release packages?
  • Is there any release check-list for cross-check?
  • Is any part of the release process automated?
  • Is there a need for i18n? If yes, is the i18n release handled separately?
  • In case of installers, is there installer testing? Is it automated?
  • Is the release schedule well-planned?
  • Are you delivering patches in well constructed and cost effective way?
  • Is there any release audit process in place?
  • How are you tracking your releases?
  • Is there any legal compliance in place while shipping the release to the customers?
Tagged : / / / /

SCM Process and smartBuild Overview, What is SCM Process and smartBuild?

scm-process-and-smartbuild

SCM Process and smartBuild

Tagged : / / / / / / / / / / / / / / / /

What Is Software Configuration Management, its importance & how to implement it?

software-configuration-management

Software engineers usually find coding to be the most satisfying aspect of their job. This is easy to understand because programming is a challenging, creative activity requiring extensive technical skills. It can mean getting to “play” with state-of-the-art tools, and it provides almost instant gratification in the form of immediate feedback. Programming is the development task that most readily comes to mind when the profession of software engineering is mentioned.
That said, seasoned engineers and project managers realize that programmers are part of a larger team. All of the integral tasks, such as quality assurance and verification and validation, are behind-the-scenes activities necessary to turn standalone software into a useful and usable commodity. Software configuration management (SCM) falls into this category—it can’t achieve star status, like the latest “killer app,” but it is essential to project success. The smart software project manager highly values the individuals and tools that provide this service.
This chapter will answer the following questions about software configuration management.

What Is Software Configuration Management?
Software configuration management (SCM) is the organization of the components of a software system so that they fit together in a working order, never out of synch with each other. Those who have studied the best way to manage the configuration of software parts have more elegant responses.
Roger Pressman says that SCM is a “set of activities designed to control change by identifying the work products that are likely to change, establishing relationships among them, defining mechanisms for managing different versions of these work products, controlling the changes imposed, and auditing and reporting on the changes made.”>
We think that Pressman’s description is a better description because we often view SCM as meaning software change management.
Wayne Babich describes SCM as “the art of identifying, organizing, and controlling modifications to the software being built by a programming team. It maximizes productivity by minimizing mistakes.”>
The Software Engineering Institute says that it is necessary to establish and maintain the integrity of the products of the software project throughout the software life cycle. Activities necessary to accomplish this include identifying configuration items/units, systematically controlling changes, and maintaining the integrity and the traceability of the configuration throughout the software life cycle.
Military standards view configuration as the functional and/or physical characteristics of hardware/software as set forth in technical documentation and archives in a product. In identifying the items that need to be configured, we must remember that all project artifacts are candidates—documents, graphical models, prototypes, code, and any internal or external deliverable that can undergo change. In SW PM terminology, a configuration item might be a proposal/estimate or bid, project plan, risk management plan, quality assurance plan, CM plan itself, test plan, system requirements specification, system design document, review metric, code, test result, tool (editors, compilers, CASE), and so on. There are basic objects and aggregate objects to be configured. The number of relationships among them reflects the complexity of the configuration task.

Why Is SCM Important?
Software project managers pay attention to the planning and execution of configuration management, an integral task, because it facilitates the ability to communicate status of documents and code as well as changes that have been made to them. High-quality released software has been tested and used, making it a reusable asset and saving development costs. Reused components aren’t free, though—they require integration into new products, a difficult task without knowing exactly what they are and where they are.
CM enhances the ability to provide maintenance support necessary once the software is deployed. If software didn’t change, maintenance wouldn’t exist. Of course, changes do occur. The National Institute of Standards and Technology (NIST) says that software will be changed to adapt, perfect, or correct it. Pressman points out that new business, new customer needs, reorganizations, and budgetary or scheduling constraints may lead to software revision.
CM works for the project and the organization in other ways as well. It helps to eliminate confusion, chaos, double maintenance, the shared data problem, and the simultaneous update problem, to name but a few issues to be discussed in this chapter.

Who Is Involved in SCM?
Virtually everyone on a software project is affected by SCM. From the framers of the project plan to the final tester, we rely on it to tell us how to find the object with the latest changes. During development, when iterations are informal and frequent, little needs to be known about a change except what it is, who did it, and where it is. In deployment and baselining, changes must be prioritized, and the impact of a change upon all customers must be considered. A change control board (CCB) is the governing body for modifications after implementation.

How Can Software Configuration Be Implemented in Your Organization?
We used to say, “Make a plan and stick with it—never waffle,” and “Requirements must be frozen—how else will we know what to code?” Now, we say, “Plans are living documents—they will be in a continual state of change as project knowledge increases.” We now know that requirements are never frozen—they merge, morph, and evolve and become expanded, enhanced, and extended. As long as artifacts of software development can undergo change, we will need some method of managing the change.
Because SCM is such a key tool in improving the quality of delivered products, understanding it and how to implement it in your organization and on your projects is a critical success factor. This chapter will review SCM plan templates and provide you with a composite SCM plan template for use in any of your projects. We will cover the issues and basics for a sound software project CM system, including these:

  • SCM principles
  • The four basic requirements for an SCM system
  • Planning and organizing for SCM
  • SCM tools
  • Benefits of SCM
  • Path to SCM implementation

 

Tagged : / / / / / / / / / / / / / / / / / /

The Four Basic Requirements for SCM Process – SCM Guide

scm-basic-requirements

Identification, control, audit, and status accounting are the four basic requirements for a software configuration management system. These requirements must be satisfied regardless of the amount of automation within the SCM process. All four may be satisfied by an SCM tool, a tool set, or a combination of automated and manual procedures.

  1. Identification—Each software part is labeled so that it can be identified. Furthermore, there will be different versions of the software parts as they evolve over time, so a version or revision number will be associated with the part. The key is to be able to identify any and all artifacts that compose a released configuration item. Think of this as a bill of materials for all the components in your automobile. When the manufacturer realizes that there has been a problem with parking brakes purchased from a subcontractor, it needs to know all the automobile models using that version of the parking brake. It is the same with software. If we are building a multimedia system that has audio MPEG3 drivers for Windows 98, Windows 2000, Windows CE, Linux, and FreeBSD operating systems, how do we find out which releases are impacted when we find an error in the Linux product? You must go back to your SCM system to identify all the common components in all operating system releases that are impacted.
  2. Control—In the context of configuration management, “control” means that proposed changes to a CI are reviewed and, if approved, incorporated into the software configuration. The goal is to make informed decisions and to acknowledge the repercussions associated with a change to the system. These changes may impact budgets, schedules, and associated changes to other components. If a problem is reported in a released product, software engineers must act quickly to evaluate repercussions—a “fix” for one client’s version of the product may be dangerous to another. The control inherent in an SCM system shows each version in which the flawed component appears.
  3. Auditing—Auditing an SCM system means that approved requested changes have indeed been implemented. The audits allow managers to determine whether software evolution is proceeding both logically and in conformance with requirements for the software. The SCM system should document changes, versions, and release information for all components of each configuration item. When such documentation is in place, auditing becomes a straightforward analysis task.
  4. Status accounting—Reports and documentation produced by the status accounting function are the auditable entries. All approved parts of a software configuration must be accounted for, and the software parts list must reflect the transition from part CIn to CIn+1. This accounting provides the historic information to determine both what happened and when on the software project. Status accounting enables the auditing requirement of the SCM. As a project manager, the status accounting holds a wealth of information on the amount of effort required throughout the life cycle of the product in its development and maintenance. This is critical to the software project manager in making estimates for new systems based on historic information. The SCM can be used as one of the key components of the project managers’ metrics system.
Tagged : / / / / / / / / / / / / / / /

The symptoms of our software development malaise

software-development-malaise

Software development has traditionally suffered from producing end products with a definite lack of inherent quality. The symptoms of this quality lack are listed here:

  • Software development projects are often delivered late and over budget.
  • Often the delivered product does not meet customer requirements and is never used.
  • Software products simply do not work right.

As we look into the symptoms of our software development malaise, five principal issues related to software development arise.

Lack of Visibility
Software is conceptual in nature. Unlike a bridge, a building, or another physical structure, it is not easy to look at software and assess how close it is to completion. Without strong project management, “software is 90% complete 90% of the time.” Through the adoption of SCM policy and the definition of the configuration management model of the software under development, all CIs, components, and subcomponents are immediately visible for versions, releases, and product families.


Lack of Control
Because software is inherently intangible, it is also more difficult to control. Without an accurate assessment of progress, schedules slip and budgets are overrun. It is hard to assess what has been accomplished and what remains to be done. SCM provides the mechanism for controlling the project through measuring the amount of effort compared to the project management plan and estimating the future effort based on past work.

Lack of Traceability
A lack of linkage between project events contributes to project failures. The main benefit of SCM is providing the traceability among versions, releases, and product families. The value of this traceability is enormous when a problem arises in one release or product family that impacts other client releases and products. Making one change and promoting that through the entire product software base is an incredible cost savings in time, money, and client good will. A lack of linkage between project events contributes to project failures where solving one problem either exacerbates a problem in another area or fails to fix the same problem elsewhere. A traceability thread allows management to examine the chain of events that caused a project to encounter difficulty as an integral process within the auditing capability of SCM. A project becomes a year late one day at a time unless the effort reported on the schedule maps to the actual work being done and traced within the software configuration management system.

Lack of Monitoring
Without traceability and visibility, monitoring of software development projects becomes extremely difficult. Management cannot make informed decisions, and thus schedules slip further and costs continue to exceed budget.
There is no way to monitor a project when the project manager has no tools to look into the actual product development within the project. SCM provides the tools that open up the process to external monitoring. With SCM in place and a policy of traceability and visibility accepted, monitoring of software development projects becomes a simple part of the overall project management task. Management makes informed decisions avoiding schedule slips and budget excesses through the monitoring available with SCM tools and the integral workings of the CCB.

Uncontrolled Change
Software is very malleable; it is idea-stuff, and customers constantly have new ideas for it. People would rarely ask a bridge constructor to make the kinds of changes midproject that software customers tend to request. The impact of such changes can be just as great. All SCM tools, along with the CCB, support a mechanism for appropriate change control.

SCM Interacts with Verification and Validation
SCM is most important, and most often neglected, during V&V activities, which include software testing. It is employed in tracking which module versions are included in a particular system build, as well as which tests have been run. The results of the tests are tied directly to the modules or subcomponents being tested. Many times there are “action items” resulting from the tests. SCM tracks the action item status, so overall system status can be assessed well before final builds and releases are done.
Verification and validation testing are supported through the four basic SCM processes: identification, control, auditing, and status accounting. Let’s look at examples of V&V testing in the context of each of these components.

SCM Identification Benefits to V&V

  • Automatic preparation of release notes
  • List of changed software modules
  • Definition of development baseline
  • Generation of incident reports
  • Definition of operational baseline
  • Control of the configuration item identification
  • Management of CCB meetings
  • Prioritization of test and incident issues
  • Establishment of turnover dates
  • Approval of audit and test reports
  • Approval of incident report resolutions

SCM Auditing Benefits to V&V

  • Comparison of new baseline to previous baseline
  • Assurance that standards have been met
  • Audit trail of the testing process (verification, validation, and acceptance) of the software system
  • Documentation of experience with technical aspects of system engineering or software engineering

SCM Status Accounting Benefits to V&V

  • Logging and tracking of incident reports
  • Publication of CCB minutes

With all of these potential benefits of SCM, project managers must address real-world considerations. Management commitment is the real key to implementing SCM on a specific project in a given organization. By treating the implementation of SCM as a project, the project plan must start at the top to secure commitment to checks and balances. Now is the time to bring out the organization’s list of project disasters to draw on management experience with their previous software project difficulties. If there are no historic disasters in the organization, or if it is inappropriate to discuss them, refer to literature articles that provide accounts of project disasters (refer to the Web resources at the end of this chapter). Finally, after putting a notional return-on-investment financial argument in place, explain the intangible benefits of SCM.
One of the major sources intangible benefits is auditing. Auditing can be a heavy consumer of configuration management resources, and management may question the benefit of this kind of expenditure. Auditing pays for itself through the avoidance of larger, unnecessary expenses. Savings of 100:1 (large projects) or 4–6:1 (small projects) are obtained by finding and fixing problems early in the life cycle. The auditing process in SCM uncovers the areas where a little more effort or control will result in higher-quality software products and lower overall project costs.
There can be audit compromises to reduce costs. As a project manager, plan audits based on both the phases of the life cycle and the frequency of builds, versions, releases, and product families. Auditing each baseline in a project while reducing the depth of each audit maintains some traceability with loss of visibility.
Eliminating one or more audits (installation baseline, for example) maintains visibility but slightly impacts traceability.

Tagged : / / / / / / / / / / / / / / / /