1. SOFTWARE PROCESS
• Process is the heart of the software engineering.
•According to webster , the process means “a particular method of doing
something ,generally involving a number of a steps or operations.
•In software engineering, software process refers to the methods of developing
software.
•A software process is a series of steps inveloving activities,constraints and
recourses that produce intended output.
.
SOFTWARE PROCESS :
•In this many of do not concern software engineering through they depend on
software development. These are called as non-software engineering process.
Ex : Business Process , Social Process and Training Process.
•The process that deals with the technical and management issues of software
development is called a software process.
2. PROCESS AND PROCESS MODELS:
•The successful a project one that satisfies the expectation on all 3 goals of cost,
schedule and quality.
•The actual process exists when the project is actually executed.
•The process specification is distinct from the actual process.
•A process model specifies a general process, as a set of stages in which a project
should be divided , executed etc.
•The basic premise behind a process model is that in the situation for which the
model is applicable
•Using process model as the projects process will lead to low cost , high quality or
reduced cycle time and provides the suitable guidelines for developing a suitable
process for a project.
.
3. COMPONENT SOFTWARE PROCESS:
There are two major components
a) Development Process.
b) Project Management ProcesS
a)Development Process:
It specifies the development and quality assurance activities that
need to be performed.
b) Project Management Process:
It specifies how to plan and control these activities so that
cost schedule,quality and other objectives are met.
Software configuration control process :
It focuses evaluation and changes.It primarily
deals with managing change .
Process Management process : The main objective of the process
is to improve the software process.
The whole process of understanding the current process,analyzing
itsproperties,determining how to improve and
then affecting the improvement.
5. • Development activities are performed by programmers,designers testers etc.
• Project management process activities performed by project management.
• Configuration management process performed by configuration controller
.
• Process management process activities performed by
the software engineering process group(SEPG)
6. •In a typical project ,development activities are performed by programmers,
designers , tester etc.
•The project management process activities are performed by the project
management
•configuration control process activities are performed by a group generally called
as configuration controller and process management , process activities are
performed by the software engineer process group(SEPG).
ETVX APPROACH FOR PROCESS SPECIFICATION:
•A process has a set of phase(or step), each phase performing a well-defined task which
leads a project towards satisfaction of its goal.
•As a process typically contains a sequence of steps, the next issue to address is when
a phase should be initiated and terminated.
•This is frequently done by specifying the entry and exit criteria for a phase.
•The entry criteria of a phase specifies the conditions that the input to the phase should
satisfy to initiate the activities of that phase.
•The exit phase specifies the conditions that the work product of this phase should
satisfy constraints of when to start and stop an activity.
•It should be clear that the entry criteria of a phase should be consistent with the exit
criteria of the previous phase.
•As errors can be introduced in every stage, a stage should end with some verification of
its activities, and these should also be clearly stated.
•ETVX (Entry Criteria , Task , Verification and Exit Criteria).
7. Figure : A step in a development process.
DESIRED CHARACTERISTICS OF SOFTWARE PROCESS :
PREDICTABILITY:
•Predictability of a process determines how accurately the process in a project
can be predicted before the project is completed.
•Predictability is a fundamental property of any process.
•The fundamental basis for quality prediction is that quality of the product is
determined by the process used to develop it.
•Management of quality control depends on the predictability of the process.
PROCESS STEP V AND V
CONTROL INFORMATION OF MANAGEMENT
PROCESS
INPUT
OUTPUT
ENTRY CRITERIA EXIT CRITERIA
8. •Using this basic , quality of the product of a project can be estimated or predicted.
•If we want to use the past experience to control costs and ensure quality , we must
use a process that is predictable.
•Predictable process is also said to be under statistical control.
PROPERTY OF
INTEREST
PROJECTS
Y
X
FIGURE : PROCESS STATISTICAL CONTROL
9. •The Y-axis represents some property of interest (quality, productivity etc) and X-
axis represents the project.
•The dark straight line is the expected value of the property for this process.
•To develop a software of high quality at low cost it is necessary to have a process
that is under statistical control.
•A predictable process forms the backbone of the software engineering methods.
SUPPORTS TESTABILITY AND MANAGEMENT :
•In software maintenance costs generally exceed the development costs.
•If we want to reduce the overall cost of software the goal of development should
be to reduce the maintenance efforts.
•In development ,coding is frequently given a great importance.
•We know that process consists of phases and a process generally includes
requirement , design , coding and testing process.
•For example ; Distribution of effort with the different phases.
* Requirements 10%
* Design 10%
* Coding 30%
* Testing 50%
Above all are Organization and Nature of Process.
10. •The effort spent in programming i.e. how programmer spend their time in a
software organization. A study conducted in Bell Laboratory to determine how
programmers spend their time.
Writing Programs 13%
Reading Programs and Manual 16%
Job Communication 32%
Other(Including Personal) 39%
•Programmer spend less than 25% for writing programs. By Boehm's it was found
that programmers spend less than 20%.
•The goal of the process should not be to reduce the effort of design and coding
but to reduce the cost of testing and maintenance.
SUPPORT CHANGE :
•Software changes because of many different reasons.
•Here changes are occurred due to requirement changes.
•As an organization and business change the software supporting the business has
to change.
EARLY DEFECT REMOVAL:
•Programming is a central activity during software development. Programming is
sometimes called as “art” .
•Error can occur at any stage during development.
11. A distribution of error occurrences by phase is
Requirements 20%
Design 30%
Coding 50%
Where ;
1 -1000 , 2-100 , 3-50 , 4-10 , 5-5 , 6-2
a- Requirements , b- Design Code c- Development Test
d- Acceptance Test e- Operation
e
d
c
b
a
1
2
3
4
5
6
Relative cost to fix error
Phase in which error was detected
12. •When error is detected , the more expensive it is to correct it.
•As the figure shows an errors that occurs during acceptance testing , can cost up
to 100 times more than correcting the error during the requirements then design
and the code will be affected.
•Correcting the error after coding is require both design and code to be changed
by increasing a cost of correction
•We should detect errors that occurs in phase during that phase itself and should
be continuous process that is done throughout the software development.
•Hence , we should try to verify the output of each phase before starting with the
next.
•A process should have a quality control.
•A quality control(Q & C) activity is one whose main purpose is to identify and
remove defects.
13. PROCESS IMPROVEMENT AND FEEDBACK:
•A process is not a static entity.
•Improving the quality and reducing the cost of products are basic goals of
any engineer discipline.
•Process improvement as a fundamental objective requires that the
software process be a closed loop process. That is process must be
improved based on previous experiences.
•Activity of analyzing and improving the process is largely done in the
process management component of the software process.
•Feedback from previous parts of the project can be used to improve the
execution of the remaining projects.
•This type of feedback is suited for iterative development process model.
•Here feedback of 1 iteration is used to improve the execution of next
iteration.
14. SOFTWARE DEVELOPMENT PROCESS MODEL:
In the software development process , the activities
directly related to production of software .
Ex : Design , Coding and Testing.
WATERFALL MODEL :
•The simplest process model is the waterfall model. Which states that the
phases are organized in a linear order.
•The model was originally proposed by Royce in 1970 ‘s
•The below figure shows the Waterfall Model.
16. The sequential phases in Waterfall model are:
•Requirement Gathering and analysis: All possible requirements of the system to
be developed are captured in this phase and documented in a requirement
specification doc.
•System Design: The requirement specifications from first phase are studied in this
phase and system design is prepared. System Design helps in specifying hardware
and system requirements and also helps in defining overall system architecture.
•Implementation: With input from system design, the system is first developed in
small programs called units, which are integrated in the next phase. Each unit is
developed and tested for its functionality which is referred to as Unit Testing.
•Integration and Testing: All the units developed in the implementation phase are
integrated into a system after testing of each unit. Post integration the entire
system is tested for any faults and failures.
17. •Deployment of system: Once the functional and non functional testing is done,
the product is deployed in the customer environment or released into the market.
•Maintenance: There are some issues which come up in the client environment. To
fix those issues patches are released. Also to enhance the product some better
versions are released. Maintenance is done to deliver these changes in the
customer environment.
All these phases are cascaded to each other in which
progress is seen as flowing steadily downwards (like a waterfall) through the
phases. The next phase is started only after the defined set of goals are achieved
for previous phase and it is signed off, so the name "Waterfall Model". In this
model phases do not overlap.
18. •In this model , a project begins with feasibility analysis , which feasibility of a
project is successfully demonstrated the requirement analysis and project planning
begins.
•The design start after the requirements analysis is complete and coding begins
after the design is completed.
•When testing is successfully completed the system is installed. After this,
operation and maintenance takes place.
•The requirement analysis phase is mentioned as “analysis and planning”.
•Linear ordering of activities has some important consequeness.
* Identify the end of a phase and the beginning of next with some
certification mechanism after each phase.
•The following documents generally form a reasonable set that should be
produced in each projects.
* Requirement Documents
* Project Plan.
* Test Plan and Test Report.
* Final Code.
* Software Manuals (Ex : user , installation ,etc).
19. WATERFALL MODEL ADVANTAGES AND DISADVANTAGES:
ADVANTAGE
•It is used for smaller duration projects.
•It is a simple process (its simplicity)
•The advantage of waterfall development is that it allows for departmentalization and
control.
•A schedule can be set with deadlines for each stage of development and a product
can proceed through the development process model phases one by one.
•Development moves from concept, through design, implementation, testing,
installation, troubleshooting, and ends up at operation and maintenance.
•Each phase of development proceeds in strict order.
DISADVANTAGE
•It cannot be evolutionary.
•It is not a repetitive process.
•High cost if any requirement is missed.
•The disadvantage of waterfall development is that it does not allow for much
reflection or revision.
• Once an application is in the testing stage, it is very difficult to go back and change
something that was not well-documented or thought upon in the concept stage.
20. LIMITATIONS :
•It assume that the requirements of a system can be frozen (base line)
before the design begins.
•This is possible for existing system. But for new systems , determining the
requirements is difficult as the user does not know the requirements.
•Freezing the requirements usually requires choosing the hardware.
•It follows the “Big Bang” approach the entire software is delivered in one
shot at the end.
•It is a document driven proceed that requires formal documents at the
end of each phase.
21. PROTOTYPING MODEL :
•The basic idea here is that instead of freezing (not changing) the
requirements before any design or coding can proceed, a throw-away
prototype is built to understand requirements.
•Prototype is developed based on the current know requirements.
•Development of prototype obviously undergoes design , coding and
testing.
•By using prototype the client can actually come to know , how the project
is going to develop.
•Because the interactions with the prototype can enable the client to better
understand the requirements of the desired system.
•Prototyping is an attractive model for complicated and large system for
which there is no existing system.
•The risk with projects are reduced through the use of prototyping.
23. PROTOTYPE MODEL :
•The development of prototype starts when the requirement specification
document has been developed.
•After the prototype has been developed the end user and clients are given
an opportunity to use the prototype. Based on their experience , they
provide feedback to the developers.
•Such as , what is correct ,what needs to be modified , what is missing ,
what is not needed etc.
•Based on the feedback again the prototype is modified and then given to
users and the clients
• REQUIREMENT
ANALYSIS
* DESIGN
* CODE
* TEST
DESIGN CODE
TEST
24. Advantages :
•Users are actively involved in the development.
•Since in this methodology a working model of the system is provided, the
user get a better understanding of the system begin developed.
•Errors can be detected much earlier.
•Quicker user feedback is available leading to better solution.
•Missing functionality can be identified easily.
•Confusing or difficult functions can be identified requirement validation,
quick implementation of functional application.
Disadvantages:
•Leads to implementing and then repairing way of building systems.
•Practically this methodology may increase the complexity of the system as
scope of the system may expand beyond original plans.
•Incomplete application may cause application not to be used as the full
system was designed
•Incomplete or inadequate problem analysis.
25. ITERATIVE DEVELOPMENT :
This process model tries to combine the both prototyping and the waterfall model.
1.The basic idea is software should be developed in increments, each increment adding some functional
capability to the system until the full system is implemented.
2.Each step consists of removing next task from the list , designing the implementation for the selected
task , coding and testing the implementation ,performance an analysis of the partial system obtained after
this step.
3. And updating the list as result of the analysis. These 3 phase are called as design phase , implementation
phase and analysis phase.
26. •This cycle repeat until we get final requirements specification.
•Exception handling , recovery are not included in prototypes.
•The cost of software development without prototyping may be more than with
prototyping .
There are two majors reasons.
* Experience of developing the prototype might reduce the cost of the
later process.
* In many projects the requirements are constantly changing , when
development takes a long time.
•Changes in requirements at a last stage of development it leads to increase the
cost.
•It is an excellent technique for reading some types of risks associated with a
project.
27. ADVANTAGES :
•It can result in better testing because testing each increment is likely to be easier
than testing the entire system as in the waterfall model.
DESIGN
IMPLEMENTS
ANALYSIS
DESIGN
IMPLEMENTS
ANALYSIS
DESIGN
IMPLEMENTS
ANALYSIS
29. •This was originally proposed by Boehm in the year 1988
•Each cycle in a spiral begins with the identification of objectives for cycle , the
different alternatives that are possible for achieving the objectives and the
constraints that exist.
•The next step in cycle is to evaluate different alternatives based on the objectives
and constraints.
•The focus of evaluation in this step is based on the risk perception for the project.
•The next step is to develop strategies that resolve the uncertainties and risk . This
step may involves activities such as bench marking , simulation(action) and
prototyping.
•Finally the next stage is planned.
•The software process represent as a sequence of activities with some backtracking
from one activity to another , the process is represented as a spiral.
•Each loop in the spiral represents a phase of the software process.
•The inner most loop might be concerned with system feasibility , the next loop
with system requirements definition the next loop with system design and so on.
•Each loop in spiral is spilt into four sectors.
30. a) OBJECTIVE SETTING :
•Specifies objectives for that phase of the project are defined.
•Constraints on the process and the product are identified and a detailed
management plan is drawn up.
•Project risk are identified , alternative strategies , depending on these risk may be
planned.
b) RISK ASSESSMENT AND REDUCTION:
•For each of the identified project risk, a detailed analysis is carried out , step are
taken to reduce the risk .
•For example , if there is a risk that the requirements are inappropriate , a
prototype system may be developed.
31. c) DEVELOPMENT AND VALIDATION:
•After risk evaluation , a development model for the system is then chosen.
•For example , if user interface risk are dominant , an appropriate development
model might be evolutionary prototyping.
•If safety risk are the main consideration , development based on formal
transformations may be the most appropriate and so on.
d) PLANNING :
•The project is reviewed and a decision mod whether to continue with a
further loop of the spiral.
•If it is decided to continue plans are drawn up for the next phase of the
project.
ADVANTAGES :
•Involves identification and reserving the risk.
DISADVANTAGES :
•Limitation of number of iteration.
32. When we use the spiral model:
•When the project is large.
•When release are required to be frequent.
•When risk & cost evaluation is important.
•When requirements are unclear & complex.
•When changes may require at any time.
•For medium to high risk project.
ADVANTAGES :
•Additional functionality or changes can be done at later stage.
•Cost estimation become easy.
•Development is fast & features are added in a systematic way.
•These is always space for customer feedback.
DISADVANTAGES :
•Risk is not meeting the schedule or budget.
•Documentation is more as it has intermediate phases.
•It is not advisable for smaller projects, it might cost them a lot
.
33. TIME BOXING:
In the time boxing model , the basic unit of development is a time box , which is of
fixed duration.
•Here functionality selected and then the time to deliver is determined.
•Each time box is divided into a sequence of stages like waterfall model.
•The model also requires that the duration of each stage i.e. the time it takes to
complete the task of that stage is approximately the same.
•Having time boxed iteration with stages of equal duration and having dedicated
teams renders itself to pipelining of different iterations.
•Pipelining is the concept of hardware in which different instructions are executed
in parallel.
•With the execution of new instructions starting once the first stage of the previous
instruction is finished.
•Consider a time box with duration T and consisting of n stages s1,s2,s3,…..sn ,
each stage is being executed by a dedicated team.
•The team of each stage has T/n time available to finish their task for a time box i.e.
the duration of each stage is T/n.
34. •For example , consider a time box consisting of three stages.
a) Requirement Specification
b) Build
c) Deployment.
A)REQUIREMENT SPECIFICATION:
•The requirement stage is executed by its team of analysts and ends with a
prioritized list of requirements to be built in this iteration along with a high level
design.
B) BUILD:
•The build team develops the code for implementing the requirements and
performs the testing. The tested code is than handled over to the deployment
team.
C) DEPLOYMENT :
•The deployment team , which performs pre-deployment tests and then installs the
system for production use.
36. •When the requirement team (RT) has finished requirements for time box -1 , the
requirements are given to the build team for building the software .
•The requirement team then goes on and start preparing the requirements form time
box -2 .
•When the build for the time box-1 is completed , the coded is handled over to the
deployment team and build team moves on to build code for requirements for time box-
2.
•And the requirements team moves on to the doing requirements for team box -3.
Requirement Team : RT Deployment : D
Build Team : BT Requirement Analysis : RA
Development Team : DT
Figure : Tasks of different teams.
RT RA FOR –TB1 RA-TB2 RA-TB3 TB4 TB5
BT BT-TB1 TB2 TB3 TB4 TB5
DT DT-TB1 TB2 TB3 TB4 TB5
37. •There are 3 teams working on the project the requirements team , the build team and
the deployment team.
•Time boxing is well suited for projects that require a large number of features to be
developed in a short time around a stable architecture using stable technologies.
•It is also not suitable for projects where different iterations may require different
stages.
COMPARISION OF MODELS :
WATER FALL MODEL:
STRENGTH : Simple , easy to execute , initiative and logical
WEAKNESS : All or nothing approach requirements frozen early , disallows changes ,
cycle time too long , may choose outdated hardware technology , user feedback not
allowed , encourages requirements bloating(increase).
TYPES OF PROJECTS : For well understood problem short duration project ,
automation of existing manual system.
38. PROTOTYPING MODEL :
STRENGTHS : Helps in requirement elicitation , reduces risk ,leads to a better
system.
WEAKNESS : Front heavy process , possibly higher cost , disallows later changes.
TYPES : System with novice(inexperienced) users , when uncertainties in
requirements when UI very important.
ITERATIVE MODEL :
STRENGTHS : Regular/quick deliveries , reduce risk , accommodates changes ,
allows user feedback , allows reasonable exit points , avoid requirements bloating
priorities requirements.
WEAKNESS : Each iteration can have planning overhead , cost many increases as
work done in the one iteration may have to be undone later , system architecture and
structure may suffer as frequent changes are made.
TYPES : For business where time is of essence where risk of a long project cannot be
taken , where requirements are not known and will be known only with time.
39. TIME BOXING :
STRENGTH : All strength of iterative , planning and negotiations somewhat easier
very short delivery cycle.
WEAKNESS : Project management is complex , possibly increased cost , large team
size.
TYPE : Where very short delivery times needed , flexibility in grouping features exist.
OTHER SOFTWARE PROCESS :
PROJECT MANAGEMENT PROCESS :
•Project management is an part of software development.
•A large software development project involves many people working for a long period
of time.
•The cost , quality and schedule objectives resources have to be allocated to each
activity for the project.
•All these activities are part of the project management process.
40. •The activities in the management process for a project can be grouped into 3 phases.
a) Planning
b) Monitoring and Controlling.
c) Termination Analysis.
a) PLANNING :
•The goal of this phase is to develop a plan for software development .
•A software plan is usually produced before the development begins and is updated as
development proceeds and data about progress of the project becomes available.
•During planning the magic activities are cost estimation , schedule and milestone
determination , project staffing , quality control plans and controlling and monitoring
plans.
b) PROJECT MONITORING AND CONTROL PHASE :
It is the longest in terms of duration. It includes all activities the project
management has to perform and development proceeds according to the developed
plan.
c) TERMINATION ANALYSIS :
•This phase is performed when development process is over. The basic reason for
performing termination analysis is to provide information about the development
process.
•This phase also called as “postmortem analysis” .In iterative development this
analysis can be done after each iteration to provide feedback to improve the execution
of next iterations.
41. Figure : Development and Management Relation.
•This is an idealized relationship showing that planning is done before development
begins and termination analysis is done after development is over.
•As the figure during development process quantitative information flows to the
monitoring and control phase of the management process ,.
•Which uses the information to exist control on the development.
PLANNING TERMINATION ANALYSIS
METRIC VALUES
MANAGEMENT
PROCESS
DEVELOPEMNT
PROCESS
MANAGEMENT
CONTROLL
TIME
Monitoring & control
42. THE INSPECTION PROCESS :
•The main goal of the inspection process is to detect defects in work products.
•Software inspection were first proposed by Fagan.
•In earlier days were focused on code that but over the years its use has spread to other
work products too.
•Software inspection help in improving quality and also improve productivity.
•The basic goal of inspections is to improve the quality of the work product by finding
defects.
CHARACTERISTICS OF INSPECTIONS :
1)An inspection is conducted by technical people.
2)It is structured process with defined roles for the participants.
3)The focus is on identifying problems , not resolving them.
4)The review data is recorded and used for monitoring the effectiveness of the
inspection process.
•Inspection are performed by group of a people , they can be applied to any work
product that cannot be done with testing .
•Inspections are performed by a team of reviewers (or inspectors) including the author
with one of them being the moderator.
43. •The different stages in this process are planning , preparations, and overview , group
review meeting and rework and also follow-up .
•These stages are generally executed in linear order.
PLANNING :
1)The objective of the planning phase is to prepare for inspection and work product is
ready for inspection.
2)The moderator checks the entry criteria are satisfied by the work product.
3)The package that needs to be distributed to the reviews team is prepared.
4)For example , when a high level design has to be reviewed then the package must
include the requirement specification also without checking the correctness of design.
OVERVIEW AND PREPARATION :
5)The package of review is given to the reviewers.
6)The main task in this phase is for each reviewer to do a self review of the work
product.
7)Relevant checklist , guidelines and standards may be used while reviewing.
44. Example :
Project Name and ID :
Work Product Name and ID :
Reviewer Name :
Efforts Spent for Preparation (Hrs) :
Defeat List :
Figure : Self Review Log.
Sl Location DESCRIPTION CRITICALITY SERIOUSNESS
45. GROUP REVIEW MEETING:
1)The basic purpose of group review meeting is to come up with the final defect list.
2)The main outputs of this phase are the defect log and the defect summary report.
3)The meeting is conducted as follows:
* A team member (called the reader) goes over the work product line by line
and paraphrases each line to the team.
*Sometimes no paraphrasing is done and the team just goes over the work
product line by line.
* After meeting are one member of review team (called the scribe) records the
identified defects in the defect log.
*At the end of meeting the scribe reads out the defects recorded in the defect
log.
46. Project xxxxxx
Work Product Type ProjectPlan , V 1.0
Size of |Product 14 Pages
Review Team P! , P2 , P3 , P4
Efforts :
Preparation Total 10 Person Hours
Group Review Meeting 10 Person Hours
Total Efforts 20 Person Hours
Deffects :
Number of Critical Defects 0
Number of Major Defects 3
Number of Minor Defects 16
Total Number of Defects 19
Review Status Accepted
Recommendation for Next Phase Comments The plan has been well
documented and presented
Figure : Summary Report of an Inspection:
47. •The summary reports is itself explanatory .Total number of minor defects found was
16 and the total number of major defects found was 3 i.e. the defect density found is
16/14 = 1.2
•3/14 =0.2 Major defects per page.
•The review team had 4 members and each had spent 2.5 hours in individual review
and the review meeting lasted 2.5 hours.
REWORK AND FOLLOWUP:
•In this phase the author corrects all the defects raised during the inspection.
•The author may redo the work product , if that is ,what the moderator recommended.
•The scribe ensure that the group review report and minutes of the meeting are
communicated to the group review team.
ROLE AND RESPONSIBILITY :
•The key in a group review are moderator , reader (team member) , scribe (review
team) author and reviewer.
•The author cannot be the moderator or the reader and the moderator cannot be reader.
•Group review team is three the author , the moderator and the reader.
48. RESPONSIBILITIES OF MODERATOR INCLUDE:
•Schedule the group review meeting.
•At the opening of group review meeting ensure that all participants are prepared and
have submitted self preparation log or reschedule the group review.
•Conduct the group review in an orderly and efficient manner.
•Ensure that the meeting stays focused on the main task of defect identification.
•Track each problem to resolution or ensure that ,it is tracked by someone else.
•Ensure that group review reports are completed.
THE MAIN ISSUES FOR A REVIEWERS :
•Be prepared group view
•Be objective focus on issues and not on people
•Concentrate on problems
•If something is not clear do not hesitate to stop progress until it is understood.
49. GUIDELINES FOR WORK PRODUCTS:
Guidelines for inspection of work products
WORK PRODUCT FOCUS OF INSPECTION PARTICIPANTS
Requirement
Specification
Requirement Customer need
Requirement are implementable , omission ,
inconsistencies and ambiguity in the requirement
Customer
Designer
Tester
Developer
High Level
Design
High level design implement the requirement
The design is implementable
Requirements , omission and other defects in the
design
Requirements
Detailed Designer
Author
Developer
Code Code implements the design code is complete
and correct defects in code
Designer
Tester
Developer
System Test
Cases
The set of test cases check all condition in the
requirement test cases are executable
Requirements author
Tester Project leader
Project
Management
Plan
Plan is complete project management plan is
implementable , omission and ambiguities
Project Leader
SEPG member another
Project leader
50. SOFTWARE CONFIGURATION MANAGEMENT PROCESS :
•Changes continuously take place in a software, project changes due to the evolution of
work products as the project process changes due to defects being found and changes
due to requirement changes.
•Configuration management (CM) or software configuration management (SCM) is the
discipline for systematically controlling changes that take place during development.
•The IEEE defines SCM as the process of identifying and defining the items in the
system controlling the change of these items throughout their life cycle , recording and
reporting the status of items and change request and verifying the completeness and
correctness of items.
•SCM directly controls only the products of a process and only indirectly influence the
activities producing the product.
Figure : Configuration Management and Development Process.
WORKING UNDER REVIEW UNDER SCM
REJECT
DEVELOPER SATISFIED APPROVED
51. CM FUNCTIONALITY :
•Give latest version of a program.
•Undo a change or revert back to a specified version.
•Prevent unauthorized changes or deletions.
•Gather all sources , documents , and other information for the current system.
CM MECHANISM :
The mechanism commonly used to provide the necessary
functionality include the following:
* Configuration , identification and base lining.
* Version control or version management.
* Access control.
•A base line , once established capture a logical state of the system and form the base of
change. A base line also form reference point in the development of a system.
•Base line is an arrangement of a set of SCI(software configuration item).
•It should be noted that the SCI being managed by SCM are not independent of one
another and there are dependencies between various SCI’s.
•An SCI x is said to depend on another SCI y ,if a change to y might require a change
to be made to x for x to remain correct or for the base line to remain consistent.
52. Figure : SCM Life Cycle of an Item.
CM PROCESS:
•The process defines the set of activities that need to be performed to control change.
•The first stage in CM process is planning.
•Planning for configuration management involves identifying the configuration items.
•Typical example of configuration items include requirement specification , design
documents , source code , test plan , test script, test procedures , test data , standards
used in the project (such as coding , design standards ) , the acceptance plan ,
documents such as the CM plan and the project plan , user documentation such as the
user manual , documents compiler , quality records ( review , test records ) and CM
readers (release records , status tracking records).
WORKING UNDER REVIEW UNDER SCM
REJECT
DEVELOPER SATISFIED APPROVED
53. •The configuration controller (CC) is responsible for the implementation of an CM
plan.
•Configuration Control Board(CCB) . This board includes representatives from each of
the teams.
REQUIREMENT CHANGE MANAGEMENT PROCESS :
•Changes in requirements can come at any time during the life of a project.
•Uncontrolled changes to requirement can have a adverse effect on the cost , schedule
and equality of the projects.
•The change management process defines the set of activities that are performed , when
there are some new requirements or change to existing requirement.
•The change management process has following step :
* Log the change.
* Perform impact analysis on the work products.
* Estimate the impact on effort and schedule.
* Review impact with concerned stakeholders.
* Rework work products.
54. •A change is initiated by a change request.
•Change request log is maintained to keep track of the change request.
•The log contains a change request number a brief description of the change , the effect
of the change , the status of the change request and key dates.
•The effect of a change request is accessed by performing impact analysis .
•Impact analysis includes identifying work products and configuration items and
evaluating the change to each reassessing the projects risk and schedule estimates.
PROCESS MANAGEMENT PROCESS :
•A software process is not a static entity it has to change to improve higher quality and
are less costly.
•Improving the Q&P of the process is the main objectives of the process management
process.
•The process management and project management are quit different.
•In process management it focus on improving the Q&P but in project management it
focus is an executing the current project.
•Concept of introducing changes of small increment based on the current state of the
process has been captured in the capability maturity model (CMM) framework .
•The CMM framework provides a general road map for process management.
55. Figure : Capability Maturity Model:
OPTIMIZING(5)
MANAGED(4)
DEFINED(3)
REPEATABLE(2)
INITIAL(1)
CONTINUOUSLY
IMPROVING PROCESS
PREDICTABLE PROCESS
STANDARD CONSISTENT
PROCESS
DISCIPLANED
PROCESS
56. THE INITIAL PROCESS (LEVEL-1):
Basic projects controls for ensuring that activities are being done
properly. The process capability is unpredictable as the process constantly changes.
REPEATABLE PROCESS (LEVEL-2):
Project management is well developed in a process at this level .
Some of the characteristics of a process at this level are: project commitments are
realistic(practical) and based on post experience with similar projects , cost and
schedule are tracked, problems resolved when they arise, formal configuration control
mechanism are in place, and software project standards are defined and followed.
DEFINED LEVEL (LEVEL-3):
The organization has standardized a software process , which is
properly documented . A software process group exists in the organization that owns
and manages the process . In the process each step is carefully defined with entry and
exit criteria.
MANAGED LEVEL (LEVEL-4)
Quantitative goals exist for process and products . Data is collected
from software process , which is used to build models to characterized the process.
OPTIMIZING LEVEL (LEVEL-5)
The focus of the organization is on continuous process improvement .
Data is collected and analyzed to improve quality or productivity.
57. Figure : Key Process Areas:
LEVEL-5 OPTIMIZING
* PROCESS CHANGE MANAGEMENT
* TECHNOLOGY CHANGE MANAGEMENT
* DEFECT PREVENTION
LEVEL-3 DEFIEND
• ORGANIZATION PROCESS DEFINITION
• TRAINING PROGRAM
• PEER REVIEWS
* INTEGRATED SOFTWARE MANAGEMENT
LEVEL-2 REPEATABLE
• SOFTWARE REQUIREMENT MANAGEMENT
• SOFTWARE CONFIGURATION MANAGEMENT
• PROJECT PLANNING
* PROJECT MONITORING AND CONTROL
LEVEL-4 MANAGED
• SOFTWARE QUALITY MANAGEMENT
* QUANTITATIVE PROCESS MANAGEMENT
