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

                                                 

Types of Testing

Unit testing – Unit testing focuses on the smallest unit of software design i.e. the software component or module. Using the component-level design description as a guide, important control paths are tested to uncover errors within the boundary of the module. The unit test is white box oriented. Selective testing of execution paths is an essential task during the unit test. Boundary testing is the last and one of the most important tasks of the unit.

Advantages of Unit testing:

(1) Can be applied directly to object code and does not require processing source code. 
(2) Performance profilers commonly implement this measure.

Disadvantages of Unit testing:

(1) In sensitive to some control structure (numbers of iteration).

(2) Does not report whether loops reach their termination condition.

(3) Statement coverage is completely insensitive to the logical operators (// and &&).

Integration Testing – Integration testing is a systematic technique for constructing the program structure while at the same time conducting tests to uncover errors associated with interfacing. The objective is to take unit tested components and build a program structure strictly as per design. The program is constructed and tested in small increments, where errors are easier to isolate and correct.

System testing – System testing is actually a series of different tests whose primary purpose is to fully exercise the computer-based system. All the tests are done to verify that system elements have been properly integrated and perform allocated functions. Recovery testing is a system test that forces the software to fail in a variety of ways and verifies that recovery is properly performed. Security testing attempts to verify that protection mechanisms built into a system will, in fact protect it, from improper penetration. Stress testing executes a system in a manner that demands resources in abnormal quantity, frequency, or volume and observes how much stress the system can handle. Performance testing is designed to test the run-time performance of software in which both the software and hardware get tested for performance.

Regression testing – Each time a new module is added as part of integration process the software changes. These changes may cause problem with functions that previously worked flawlessly. Regression testing is the re-execution of some subset of tests that have already been conducted to ensure that changes have not propagated un-intended side effects. Regression testing may be conducted manually by re-executing a subset of all test cases to ensure that the new integration is flawless. Following are the basic levels of tests performed during regression testing:-

(1) Tests that will exercise all software functions.

(2) Tests that focus on software function that are likely to be affected by the change.

(3) Test that focus on the software components that have been changed.

Acceptance testing – Acceptance testing involves Planning & Execution of various types of tests in order to demonstrate that the implemented software system satisfies the requirement stated in the requirements document.

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

                                                                                                                 

Test metrics

 Various Test metrics commonly used in software projects are:

(A) The Defects per project phase metric, provides a general comparison of defects found in each project phase. This metric is usually shown as appear graph with the project phase on the X-axis, the number of defects on the Y-axis.

(B) The mean Defect discovery rate metric, weighs the number of defects found on a day-by-day basis over the course of the project. This is a standard and useful tool to determine whether a specific project is going, according to a projected defect discovery rate (based on previous projects and industry averages).

(C) The Defect resolution rate, tracks the time taken to resolve defects from the time that they are identified. This can be used to predict release dates by calculating the amount of time required to solve the remaining problems presently in the project.

(D) Defect age, is used to measure how effective the review and inspection process. A defect that was introduced in the scope or requirements phase but not discovered until testing is far more costly to fix than, if it would have been caught in early process. So the mean defect age should be as low as possible.

(E) The percentage of engineering effort metric, compares how software effort (in man hours) and actual calendar time break down into project phases. These two measurements will be useful in determining where additional training, staff, or process improvement is needed. This metric measures the average number of man-hours spent in each project phase. A project manager can use this measurement to gauge whether the effort is being used efficiently over the course of the project schedule.                                                         

(F) Defect density, measures the number of defects per KLOC (thousand lines of code). It is often used to determine whether the software is ready for release. A test plan may have a maximum defect density listed in the acceptance criteria. Which requires that the software should not contain any critical or high priority defects & contain less than a specific number of low priority defects per KLOC . 


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

                                                                                                       

Software Quality Assurance (SQA)

Quality: It’s a measurable quantity which can be compared with known standards for any product or process. It specifies the degree to which a product or process maintains the known standards. Quality can be classified in two groups: - (A) Quality of design & (B) Quality of conformance. 

(A) Quality of design – It refers to the standards maintained during design processes which include the grade of material, tolerances and performance specifications.

(B) Quality of conformance – It refers to the degree to which the design specifications are followed during manufacturing.

Quality control: It’s a series of inspections, reviews and tests used throughout the development cycle to ensure that each work product meets the requirement placed up on it. It includes a feedback loop to the process that created the work product. The feedback loop helps tune up the process during the creation of the product. It should be a part of the manufacturing process.

Quality Assurance (QA) – It’s the auditing and reporting functions of the management. If the data provided through quality assurance identify problems then the management’s responsibility to solve the problems and apply the necessary resources to resolve the quality issues. The goal of quality assurance is to provide management to provide information and data related to product quality so that they can evaluate whether or not the manufacturing process is maintaining the product quality.

Software Quality Assurance (SQA) Activities – The activities performed in software quality assurance involves two groups:

(1) The software engineers doing the technical work: - Their works includes:

  Applying technical methods and measures for ensuring high quality . 

 Conducting formal reviews and

 Performing well planned software testing

(2) The SQA group:- That has the responsibility for:

Quality assurance planning

Oversight

To assist the software engineering team in achieving high standards of production.

Record keeping

Analysis and

Reporting

The SQA activities performed by both SQA groups and software engineering group are governed by an SQA plan for the project.


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