Software Configuration Management

Software configuration Management (SCM) is an umbrella activity that is applied throughout the software process, because change can occur at any time.

Software Configuration Management (SCM) Process

The Five basic SCM tasks are:                                                             

(1) Identification of Object (2) Version Control (3) Change control (4) Configuration auditing and (5) Reporting

(1) Identification of Object – To control and mange SCIs each of them must be separately named and then organized using object-oriented approach. The SCIs can be classified in to two kinds of objects—(A) Basic objects & (B) Aggregate objects

(A) Basic objects: It is a “unit of text” created by software engineer during analysis, design, coding or testing phases.

(B) Aggregate objects: It’s a collection of basis objects and other aggregate objects.

For example – Design specification is an aggregate object.Each object has a set of unique features for distinct identification. Every object should have :- (a) An unique name (b) A description of the object including its SCI type e.g. Document, program, or data, a project identifier and version information (c) A list resources, which are entities that are processed, provided or required by the project.

(2) Version Control – It combines various tools and procedures to manage and control different versions of SCI objects that are created during the software engineering process.

(3) Change control – Change control includes human procedures and automated tools to control the reasons for change. The following processes take place when a situation of change occurs:

(A) Change Request: A change request is first submitted and then it is evaluated to asses its--- Technical merits, Potential side effects, Subsystem and the cost for implementing the change.

(B) Change Report: After the evaluation is done, a change report is created that is submitted to the change control Authority/Board (CCA/CCB). CCA or CCB is a group who are responsible for evaluating the change report and makes the final decisions on the status and priority of the change. This group generates an Engineering Change Order (ECO) for each approved change.Engineering Change Order (ECO) – It consist of the following:

* The description of the change to be made

* Constraints that has to be taken care of and

* Criteria for review and audit

(C) Check Out & Check In: The object to be changed is “checked out” of the project database, the decided changes are made and appropriate SQA (Software Quality Assurance) activities are performed. The object is then “checked in” the project database and appropriate version control mechanisms are used to create the next version of the software.

(4) Formal technical reviews (FTR) & Configuration auditing – These two activities are required to ensure that the change made to the software is properly implemented.Formal technical review is apart of software Quality Assurance (SQA) procedures. The objectives of FTR are:

* To uncover errors in functions, logic or implementation

* To verify that the software under review should meet its requirement

* To make the project more manageable

* It consists of walkthroughs, inspection and round-robin procedures

Software configuration audit consists of the following auditing procedures:

* To check whether the changes specified in the ECO (Engineering Change Order) has been properly made and to check if any additional modules are added.

* To check whether formal technical reviews are conducted for the assessment of technical correctness.

* To check whether SE standards are properly followed.

* To check whether the change is highlighted in the SCI (Software Configuration Items).

* To check whether all the related SCIs are properly updated.

(5) Configuration Status Reporting (CSR) – It’s an SCM task which summarizes the activities done so far which includes the following:

(a) The report of all the activities done.

(b) The report on the persons involved in the above reported activities.

(c) The report on the time and date when the reported activities were accomplished.

(d) The report on various other factors or objects that will be affected due to the reported activity.


To Download: http://www.megaupload.com/?d=7OBXU6TG

Risk Management

Risk analysis and management are a series of steps that help a software team to understand and manage uncertainty. A risk is a potential---it might happen, it might not. In ideal risk management, a prioritization process is followed whereby the risk with the greatest loss and the greatest probability of occurring are handled first and risks with lower loss and lower probability of occurring are handled in descending order.

Principle of Risk Management

(1) Risk management should create value.

(2) Risk management should be an integrate part of organizational processes.

(3) Risk management should be part of decision making.

(4) Risk management should be systematic and structured.

(5) Risk management should be based on the best available information.

(6) Risk management should be transparent and inclusive.

(7) Risk management should be tailored.

(8) Risk management should be dynamic, iterative and responsive to change.

Risk Management Strategy – There are to types of Risk management strategies:

(a) Reactive risk Strategy: Reactive risk Strategies follows that the risks have to be tackled at the time of their occurrence. No precautions are to be taken as per this strategy. They are meant for risks with relatively smaller impact.

(b) Proactive risk strategy: Proactive risk strategies follows that the risks have to be identified before start of the project. They have to be analyzed by assessing their probability of occurrence, their impact after occurrence and steps to be followed for its precaution. They are meant for risks with relatively higher impact.    

To Download: http://www.megaupload.com/?d=7269JQUB                                                        

Risk Identification

Risk identification is a systematic attempt to specify threats to the project plan (estimates, schedule, resource loading etc).

Methods used for Risk identification under Risk management One method for identifying risks is to create a risk item checklist. The checklist can be used for risk identification and focuses on some subset of known and predictable risks in the following generic categories:

Product Size – Risks associated with the overall size of the software to be built or modified.

Business Impact – Risks associated with constraints imposed by management or the marketplace.

Customer Characteristics – Risks associated with the sophistication of the customer and the developer’s ability to communicate with the customer in a timely manner.

Process Definition – Risks associated with the degree to which the software process has been defined and is followed by the development organization.

Development Environment - Risks associated with the availability and quality of the tools to be used to build the product.

Technology to be built - Risks associated with the complexity of the system to be built and the “newness” of the technology that is packaged by the system.

Staff size and Experience - Risks associated with the overall technical and project experiences of the software engineers who will do the work.


To Download: http://www.megaupload.com/?d=YPSOCIZY

Effort Driven Scheduling

The brief description of Effort Driven Scheduling is shown below:-

(1) Assigning resources to tasks affects the schedule differently, if the tasks are Effort-Driven.

(2) Effort Driven Scheduling means that as we add resources to an effort-driven task, the work is redistributed among all the resources to maintain the same amount of work over all. Likewise if we remove resources from an effort-driven task then the work is redistributed among the remaining resources to maintain the same amount of work over all.

(3) By default tasks have fixed units and are effort-driven. This means that as more resources are assigned to a task there is less work to be done, adding resources reduces duration.

(4) If we have a fixed duration, effort-driven task then by assigning more resources, reduces the overall amount of work to be done and also reduces the overall duration of work.

(5) Effort-Driven scheduling only takes effect when resources are added to or removed from a task.

(6) Effort-Driven calculation rules are not applied when you change work duration and unit.

To Download: http://www.megaupload.com/?d=QQIQ2HCY

Earned Value Analysis (EVA)

The brief description of Earned Value Analysis (EVA) is shown below:-

(1) One approach to measuring progress in a software project is to calculate how much has been accomplished. This called Earned Value Analysis.

(2) It is basically the percentage of the estimated time that has been completed.

(3) This based on estimated effort, it could be based on any quantity that can be estimated and is related to progress.

(4) Basic Measured Used:                                                                    

Budgeted Cost of Work (BCW) – The estimated effort for each work task .

Budgeted Cost of Work Scheduled (BCWS) – The sum of the estimated effort for each work task that was scheduled to be completed by the specified time .

Budget at Completion (BAC) – The total of the BCWS and thus the estimate of the total effort for the project.

Planned Valve (PV) – The percentage of the total estimated effort that is assigned to a particular work task (PV=BCW/BAC).

Budgeted Cost of Work Performed (BCWP) – The sum of the estimated efforts for the work tasks that have been completed by the specified time .

Actual Cost of Work Performed (ACWP) – The sum of the actual efforts for the work tasks that have been completed.

(5) Progress Indicator for EVA:

                  Earned Value (EV) = BCWP/BAC

                 Schedule Performance Index (SPI) = BCWP/BCWS

                Schedule Variance (SV) = BCWP – BCWS

              Cost Performance Index (CPI) = BCWP/ACWP

             Cost Variance (CV) = BCWP – ACWP

To Download: http://www.megaupload.com/?d=SATBBJXL

Capability Maturity Model (CMM)

The brief description of CMM is shown below:-

(1) The CMM for software is a framework that was developed by the software Engineering Institute (SEI) at Carnegie Mellon University by observing the best practices in software and other organizations.

(2) The CMM is one of the most popular frameworks for software process improvement.

(3) One objective of the CMM is to distinguish mature processes from immature ones.

(4) Immature Software Processes imply that projects are executed without many guidelines and the outcome of a project depends largely on the capability of the team and the project leader.

(5) In Mature processes, a project is executed by following defined processes.

(6) Maturity of a process is directly proportional to more predictable results and more controlled projects.

(7) Process Capability is the range of results that can be expected from a project when it is executed using that process.

(8) Process Performance is the actual result achieved in a project which is executed using that process.

(9) To consistently improve process performance on projects, we must enhance the process capability.

(10) CMM has five maturity levels:

Level 1:

  The Initial level

  The project is executed in a manner that the team and project manager find it ok.

Level 2:

 The Repeatable level

 When standard project management practices are employed only for the projects and           not for the organizational structure .

Level 3:

 The Defined level

 Organization wide processes have been defined and are regularly followed.

Level 4:

 The Managed level

 Quantitative understanding of the process capability makes it possible to quantitatively predict and control the process performance on a project.

Level 5:

 The optimizing level

 The process capability is improved in a controlled manner and the improvement is evaluated quantitatively.

(11) Each maturity level (except 1) is characterized by key process areas (KPAS) which specify the areas on which the organization should focus to elevate its processes to achieve that maturity level.

Structure of the SEI CMM: Below figure shows the level of Maturity, indicates the process capability of an organization. This process capability is used as an indicator of an organizations ability to produce expected results.

To Download: http://www.megaupload.com/?d=YK0I04TC

Verification and Validation:

Verification	Validation
(1) Verification is done to ensure that the work product of a given phase of the development cycle fulfill the specifications established during prior phase.	(1) Validation is the process of evaluating software at the end of the software development process to determine compliance with the requirements.
(2) Verification: Are we producing the product right?	(2) Validation: Are we producing the right product?
(3) In verification un-covering of defects will be done in primary ways. Here no code will be executed. Before building actual system this checking will be done. This process will be called Quality Assurance.	(3) Validation concern checking will be done by executing code for errors(defects). This also can be called as Quality control
(4) Verification is nothing but the static testing.	(4) Validation is nothing but the Dynamic testing.
(5) Verification is done before validation.	(5) Validation cannot be done before verification.
(6) Inputs to the verification are check list, issue list, walkthroughs and inspection meetings, reviews and meetings.	(6) Input on the validation on the other hand is the actual testing of an actual product.
(7) Output of the Verification is a nearly a perfect set of documents, plans, specifications and requirements document.	(7) Output of the validation on the other is a nearly perfect actual product.

                                                        

To Download: http://www.megaupload.com/?d=HSEE8AYA