The goals or Purposesof SCM are generally:
·Configuration Identification- What code are we working with?
·Configuration Control- Controlling the release of a product and its changes.
·Status Accounting- Recording and reporting the status of components.
·Review- Ensuring completeness and consistency among components.
·Build Management- Managing the process and tools used for builds.
·Process Management- Ensuring adherence to the organization's development process.
·Environment Management- Managing the software and hardware that host our system.
·Teamwork- Facilitate team interactions related to the process.
·Defect Tracking- making sure every defect has traceability back to the source
Showing posts with label Test Management Design Development. Show all posts
Showing posts with label Test Management Design Development. Show all posts
Tuesday, January 20, 2009
Software Configuration Management (SCM)
Software Configuration Management (SCM) is part of configuration management (CM). Roger Pressman, in his book Software Engineering: A Practitioner's Approach, says that software configuration management (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." In other words, "SCM is a methodology to control and manage a software development project."
SCM concerns itself with answering the question: somebody did something, how can one reproduce it? Often the problem involves not reproducing "it" identically, but with controlled, incremental changes. Answering the question will thus become a matter of comparing different results and of analysing their differences. Traditional CM typically focused on controlled creation of relatively simple products. Nowadays, implementers of SCM face the challenge of dealing with relatively minor increments under their own control, in the context of the complex system being developed.
The specific terminology of SCM,
·Source configuration management (Often used to indicate that a variety of artifacts may be managed and versioned, including software code, documents, design models, and even the directory structure itself.)
·Revision control (also known as version control or source control)
.See also List of revision control software.
·Source code
·Change management
·Configuration item
·software configuration
·Change set
·Baseline (configuration management)
In particular, the former vendor, Atria (later Rational Software, now a part of IBM), used "SCM" to stand for "Software Configuration Management".
Analyst firm, Gartner Inc., uses the term Software Change and Configuration Management or (SCCM).
SCM concerns itself with answering the question: somebody did something, how can one reproduce it? Often the problem involves not reproducing "it" identically, but with controlled, incremental changes. Answering the question will thus become a matter of comparing different results and of analysing their differences. Traditional CM typically focused on controlled creation of relatively simple products. Nowadays, implementers of SCM face the challenge of dealing with relatively minor increments under their own control, in the context of the complex system being developed.
The specific terminology of SCM,
·Source configuration management (Often used to indicate that a variety of artifacts may be managed and versioned, including software code, documents, design models, and even the directory structure itself.)
·Revision control (also known as version control or source control)
.See also List of revision control software.
·Source code
·Change management
·Configuration item
·software configuration
·Change set
·Baseline (configuration management)
In particular, the former vendor, Atria (later Rational Software, now a part of IBM), used "SCM" to stand for "Software Configuration Management".
Analyst firm, Gartner Inc., uses the term Software Change and Configuration Management or (SCCM).
Software deployment Theory
Software deployment is all of the activities that make a software system available for use.
The general deployment process consists of several interrelated activities with possible transitions between them. These activities can occur at the producer site or at the consumer site or both. Because every software system is unique, the precise processes or procedures within each activity can hardly be defined. Therefore, "deployment" should be interpreted as a general process that has to be customized according to specific requirements or characteristics.
Deployment activities
Release
The release activity follows from the completed development process. It includes all the operations to prepare a system for assembly and transfer to the customer site. Therefore, it must determine the resources required to operate at the customer site and collect information for carrying out subsequent activities of deployment process.
Install
The Install is the initial insertion of software into a customer site. Currently, this activity is best supported by specialized tools. The two sub-activities are transfer and configure. The former is to move the product from the producer site to the customer site, while the latter one refers to all the configuration operations that make the system ready for customer users.
Activate
Activation is the activity of starting up the executable component of software. For simple system, it involves establishing some form of command for execution. For complex systems, it should make all the supporting systems ready to use.
In larger software deployments, the working copy of the software might be installed on a production server in a production environment. Other versions of the deployed software may be installed in a test environment, development environment and disaster recovery environment.
Deactivate
Deactivation is the inverse of activation, and refers to shutting down any executing components of a system. Deactivation is often required to perform other deployment activities, e.g., a software system may need to be deactivated before an update can be performed.
Adapt
The adaptation activity is also a process to modify a software system that has been previously installed. It differs from updating in that adaptations are initiated by local events such as changing the environment of customer site, while updating is mostly started from remote software producer.
Uninstall
Uninstallation is the inverse of installation. It is a remove of a system that is no longer required. It also involves some reconfiguration of other software systems in order to remove the uninstalled system’s files and dependencies. This is not to be confused with the term "deinstall" which is not actually a word.
Retire
Ultimately, a software system is marked as obsolete and support by the producers is withdrawn. It is the end of the life cycle of a software product.
The general deployment process consists of several interrelated activities with possible transitions between them. These activities can occur at the producer site or at the consumer site or both. Because every software system is unique, the precise processes or procedures within each activity can hardly be defined. Therefore, "deployment" should be interpreted as a general process that has to be customized according to specific requirements or characteristics.
Deployment activities
Release
The release activity follows from the completed development process. It includes all the operations to prepare a system for assembly and transfer to the customer site. Therefore, it must determine the resources required to operate at the customer site and collect information for carrying out subsequent activities of deployment process.
Install
The Install is the initial insertion of software into a customer site. Currently, this activity is best supported by specialized tools. The two sub-activities are transfer and configure. The former is to move the product from the producer site to the customer site, while the latter one refers to all the configuration operations that make the system ready for customer users.
Activate
Activation is the activity of starting up the executable component of software. For simple system, it involves establishing some form of command for execution. For complex systems, it should make all the supporting systems ready to use.
In larger software deployments, the working copy of the software might be installed on a production server in a production environment. Other versions of the deployed software may be installed in a test environment, development environment and disaster recovery environment.
Deactivate
Deactivation is the inverse of activation, and refers to shutting down any executing components of a system. Deactivation is often required to perform other deployment activities, e.g., a software system may need to be deactivated before an update can be performed.
Adapt
The adaptation activity is also a process to modify a software system that has been previously installed. It differs from updating in that adaptations are initiated by local events such as changing the environment of customer site, while updating is mostly started from remote software producer.
Uninstall
Uninstallation is the inverse of installation. It is a remove of a system that is no longer required. It also involves some reconfiguration of other software systems in order to remove the uninstalled system’s files and dependencies. This is not to be confused with the term "deinstall" which is not actually a word.
Retire
Ultimately, a software system is marked as obsolete and support by the producers is withdrawn. It is the end of the life cycle of a software product.
Types of Testing Documentation
Types of Documentation
Documentation is an important part of software engineering. Types of documentation include:
·Architecture/Design - Overview of software. Includes relations to an environment and construction principles to be used in design of software components.
·Technical - Documentation of code, algorithms, interfaces, and APIs.
·End User - Manuals for the end-user, system administrators and support staff.
·Marketing - Product briefs and promotional collateral.
Architecture/Design Documentation
Architecture documentation is a special breed of design documents. In a way, architecture documents are third derivative from the code (design documents being second derivative, and code documents being first). Very little in the architecture documents is specific to the code itself. These documents do not describe how to program a particular routine, or even why that particular routine exists in the form that it does, but instead merely lays out the general requirements that would motivate the existence of such a routine. A good architecture document is short on details but thick on explanation. It may suggest approaches for lower level design,
but leave the actual exploration trade studies to other documents.
Technical Documentation
This is what most programmers mean when using the term software documentation. When creating software, code alone is insufficient. There must be some text along with it to describe various aspects of its intended operation. It is important for the code documents to be thorough, but not so verbose that it becomes difficult to maintain them.
Often, tools such as Doxygen, javadoc, ROBODoc, POD or TwinText can be used to auto-generate the code documents—that is, they extract the comments from the source code and create reference manuals in such forms as text or HTML files. Code documents are often organized into a reference guide style, allowing a programmer to quickly look up an arbitrary function or class
User Documentation
Unlike code documents, user documents are usually far divorced from the source code of the program, and instead simply describe how it is used.
In the case of a software library, the code documents and user documents could be effectively equivalent and are worth conjoining, but for a general application this is not often true. On the other hand, the Lisp machine grew out of a tradition in which every piece of code had an attached documentation string. In combination with
strong search capabilities (based on a Unix-like apropos command), and online sources, Lispm users could look up documentation and paste the associated function directly into their own code. This level of ease of use is unheard of in putatively more modern systems.
Typically, the user documentation describes each feature of the program, and assists the user in realising these features. A good user document can also go so far as to provide thorough troubleshooting assistance. It is very important for user documents to not be confusing, and for them to be up to date. User documents need not be organized in any particular way, but it is very important for them to have a thorough index. Consistency and simplicity are also very valuable. User documentation is considered to constitute a contract specifying what the software will do
Marketing Documentation
For many applications it is necessary to have some promotional materials to encourage casual observers to spend more time learning about the product. This form of documentation has
three purposes:-
1. To excite the potential user about the product and instill in them a desire for becoming more involved with it.
2. To inform them about what exactly the product does, so that their expectations are in line with what they will be receiving.
3. To explain the position of this product with respect to other alternatives.
One good marketing technique is to provide clear and memorable catch phrases that exemplify the point we wish to convey, and also emphasize the interoperability
of the program with anything else provided by the manufacturer
Documentation is an important part of software engineering. Types of documentation include:
·Architecture/Design - Overview of software. Includes relations to an environment and construction principles to be used in design of software components.
·Technical - Documentation of code, algorithms, interfaces, and APIs.
·End User - Manuals for the end-user, system administrators and support staff.
·Marketing - Product briefs and promotional collateral.
Architecture/Design Documentation
Architecture documentation is a special breed of design documents. In a way, architecture documents are third derivative from the code (design documents being second derivative, and code documents being first). Very little in the architecture documents is specific to the code itself. These documents do not describe how to program a particular routine, or even why that particular routine exists in the form that it does, but instead merely lays out the general requirements that would motivate the existence of such a routine. A good architecture document is short on details but thick on explanation. It may suggest approaches for lower level design,
but leave the actual exploration trade studies to other documents.
Technical Documentation
This is what most programmers mean when using the term software documentation. When creating software, code alone is insufficient. There must be some text along with it to describe various aspects of its intended operation. It is important for the code documents to be thorough, but not so verbose that it becomes difficult to maintain them.
Often, tools such as Doxygen, javadoc, ROBODoc, POD or TwinText can be used to auto-generate the code documents—that is, they extract the comments from the source code and create reference manuals in such forms as text or HTML files. Code documents are often organized into a reference guide style, allowing a programmer to quickly look up an arbitrary function or class
User Documentation
Unlike code documents, user documents are usually far divorced from the source code of the program, and instead simply describe how it is used.
In the case of a software library, the code documents and user documents could be effectively equivalent and are worth conjoining, but for a general application this is not often true. On the other hand, the Lisp machine grew out of a tradition in which every piece of code had an attached documentation string. In combination with
strong search capabilities (based on a Unix-like apropos command), and online sources, Lispm users could look up documentation and paste the associated function directly into their own code. This level of ease of use is unheard of in putatively more modern systems.
Typically, the user documentation describes each feature of the program, and assists the user in realising these features. A good user document can also go so far as to provide thorough troubleshooting assistance. It is very important for user documents to not be confusing, and for them to be up to date. User documents need not be organized in any particular way, but it is very important for them to have a thorough index. Consistency and simplicity are also very valuable. User documentation is considered to constitute a contract specifying what the software will do
Marketing Documentation
For many applications it is necessary to have some promotional materials to encourage casual observers to spend more time learning about the product. This form of documentation has
three purposes:-
1. To excite the potential user about the product and instill in them a desire for becoming more involved with it.
2. To inform them about what exactly the product does, so that their expectations are in line with what they will be receiving.
3. To explain the position of this product with respect to other alternatives.
One good marketing technique is to provide clear and memorable catch phrases that exemplify the point we wish to convey, and also emphasize the interoperability
of the program with anything else provided by the manufacturer
A sample testing cycle
Testing Cycle With Simple explanation
Although testing varies between organizations, there is a cycle to testing:
1.Requirements Analysis: Testing should begin in the requirements phase of the software development life cycle. During the design phase, testers work with developers in determining what aspects of a design are testable and under what parameter those tests work.
2.Test Planning: Test Strategy, Test Plan(s), Test Bed creation. A lot of activities will be carried out during testing, so that a plan is needed.
3.Test Development: Test Procedures, Test Scenarios, Test Cases, Test Scripts to use in testing software.
4.Test Execution: Testers execute the software based on the plans and tests and report any errors found to the development team.
5.Test Reporting: Once testing is completed, testers generate metrics and make final reports on their test effort and whether or not the software tested is ready for release.
6.Retesting the Defects
Although testing varies between organizations, there is a cycle to testing:
1.Requirements Analysis: Testing should begin in the requirements phase of the software development life cycle. During the design phase, testers work with developers in determining what aspects of a design are testable and under what parameter those tests work.
2.Test Planning: Test Strategy, Test Plan(s), Test Bed creation. A lot of activities will be carried out during testing, so that a plan is needed.
3.Test Development: Test Procedures, Test Scenarios, Test Cases, Test Scripts to use in testing software.
4.Test Execution: Testers execute the software based on the plans and tests and report any errors found to the development team.
5.Test Reporting: Once testing is completed, testers generate metrics and make final reports on their test effort and whether or not the software tested is ready for release.
6.Retesting the Defects
TEST DEVELOPMENT
SOFTWARE TESTING LIFE CYCLE
It contains 6 phases.
1. TEST PLANNING.
2. TEST DEVELOPMENT.
3. TEST EXECUTION.
4. RESULT ANALYSIS.
5. BUG TRACKING.
6. REPORTING.
It contains 6 phases.
1. TEST PLANNING.
2. TEST DEVELOPMENT.
3. TEST EXECUTION.
4. RESULT ANALYSIS.
5. BUG TRACKING.
6. REPORTING.
Subscribe to:
Posts (Atom)
RSS Feed (xml)
