ZeePedia buy college essays online


Software Project Management

<<< Previous Software Configuration Management Vs Software Maintenance Next >>>
 
img
Software Project Management (CS615)
LECTURE # 17
2. Software Development Fundamentals
Technical Fundamentals
2.14 Software Configuration management
b. Controlling Versions
Version control combines procedures and tools to manage different versions
of configuration objects that are created during software product development.
To control versions, you can use Version Control Register. In Version Control
Register, you enter the details of components, such as component
identification numbers, their versions, and dates of validity. It is advisable to
release a baseline after a version is released. Baseline is a specification or a
product that is formally reviewed and agreed upon. This serves as the basis for
further development. Baseline can be changed only through formal change
control procedures. A baseline consists of a set of SCIs that are logically
related to each other. Baselines are established when subsequent changes to
the SCIs need to be controlled. Version control is essential so that everybody
uses only the latest version. Any kind of version mismatch might result in
rework.
c. Controlling Changes
Uncontrolled change can lead to chaos. Change control combines human
procedures and automated tools to provide a mechanism for controlling
change. The purpose of change control is to monitor and control changes in
order to baseline SCIs. There are various reasons that trigger changes. A
problem report might call for a change. Similarly, suggestions or ideas from
brainstorming sessions and feedback from clients can result in change.
Modifications or addition to functionality and changes in environment can
also cause changes. The Figure 1 explains the formal change control process
using a flow chart.
112
img
Software Project Management (CS615)
Start
Change request is made
Change request is logged
Change request is evaluated
Outcome is notified
Yes
Is the
Request
Rejected?
No
Is the
Yes
Request
Deferred?
No
Change request is implemented
Stop
Figure 1: Formal Change Control Process
A request for change triggers that change control procedure. Then request is
logged in the change request register. Next, the change request number is
recorded in the change request evaluation plan. The request is evaluated and
analyzed to check if the change is valid. Change request is also evaluated in
113
img
Software Project Management (CS615)
terms of the number of items affected and the effort involved in effecting the
change. Finally, the possible outcome of the change request is communicated.
The request for change is rejected, deferred, or approved. If the request for
change is rejected, the requestor needs to log a fresh request. A deferred
change request is evaluated at a later date while the change request that is
approved is implemented.
There are tools that provide facilities to check in and check out so that the
same version of the object is not updated more than once. The check-in and
checkout facilities provide synchronization control. Synchronization control
helps to ensure that parallel changes performed by two different people do not
overwrite one another.
d. Auditing
Configuration audit is conducted formally by the SQA group in projects
where SCM is a formal activity. The identification, version control, and
change control tasks help the developer maintain order and decorum in an
environment of change. However, the control mechanisms track a change only
until an item is generated. FTRs and software configuration audits (SCA) are
conducted to ensure that change is properly implemented. FTR verifies the
technical correctness of the SCI that is subjected to change. SCA assesses
those characteristics of an SCI that are not considered during FTRs. Audit
verifies whether the changes specified in the request for change are made and
additional modifications, if any, are also noted. Audits ensure that FTRs are
conducted to check for technical correctness. Audits verify that changes made
are highlighted in the SCI. The change date and change author are specified
and the attributes of SCI reflect the change. The SCM procedures for noting,
recording, and reporting change are also followed. Audits also ensure that
related SCIs are updated.
e. Communicating Changes
Another task of SCM is communicating changes. This task ensures
communication between different members in the project. It notes the
activities performed, the time when they are performed, those involved in the
activities, and those affected by the activities. In short, the task is all about
status reporting. In a large project, there is a possibility of miscommunication
among various people involved in the project. This is usually done using
configuration status report shown in Table 11.7. The table contains the name
of the SCI, the latest released version, the date of release, brief description of
changes performed, and associated change request. Further details of the
changes can be obtained from the associated change request. There can be
instances where two developers may be trying to modify the same software
configurable item with different and conflicting intentions. Absence of status
reporting could result in incorrect decisions being taken or important decisions
114
img
Software Project Management (CS615)
not being communicated. At times, those who should be pointing out the
serious side effects caused by a change are not aware of the implementation of
the change. There are also instances of version mismatch when teams are
unaware of the latest version to be followed. To avoid such hazards due to
lack of communication among the project team, changes are communicated
among team members. Therefore, status reporting provides information about
each change to those who need to know. Software configuration management
takes care of changes in a software process. SCM identifies controls, audits,
and reports modifications that occur during software development. SCM helps
maintain the integrity of configurable items produced during software
development.
Software Configuration Management Vs Software Maintenance
SCM is an integral part of SQA. SCM involves assessing the impact of the
changes made during SQA activities and making decisions based on cost and
benefit analysis. SCM can be defined as the art of identifying, organizing, and
controlling changes in a software project with the objective of minimizing
mistakes. SCM is different from software maintenance. Software maintenance is
required after the software is delivered to the client and is put into operation. As
opposed to this, SCM is a set of tracking and controlling activities that begins
when a software project begins and ends only when the software is taken out of
operation.
Baselines vs. Interim Versions
SCM differentiates between baselines and interim versions. A baseline is a tested
and certified version of a system. Baselines can be assigned version numbers such
as 1.0, 2.0, 3.0, and so on. A baseline usually undergoes intensive testing. Interim
versions, on the other hand, have version numbers, such as 1.1 or 1.2. The interim
version is a temporary version. Interim versions have a short life and survive only
during bug fixing, testing, or debugging. However, interim versions also have a
unique version number or name. Baselines are more visible with the marketing
team and the vendors than the interim versions. However, as part of SCM, all
versions of changes are saved, clearly labeled, and archived. Archiving is the
process of maintaining controlled copies of prior versions. Archiving helps in re-
creating earlier versions in the event of data loss or data corruption.
Effective Configuration Control
Effective configuration control requires effective and well-defined organization.
Any configuration control method must be based on the following four concepts:
A clearly defined configuration management authority must be established.
Configuration control standards, procedures and guidelines must be produced and
distributed to the developers.
115
img
Software Project Management (CS615)
Configuration control cannot be effective without the necessary tools and
facilities.
A configuration management plan must be developed at the beginning of the
project.
The configuration management environment consists of the resources necessary
for the implementation of the configuration control plan.
Configuration control tools, including:
Automatic version control and
Change control tools
Monitoring, auditing and registration support utilities
Storage facilities; a safe repository for all approved configuration items,
including:
­ On-site storage for the day to day development process
­ Off-site storage for catastrophe recovery
Guidelines for effective configuration management
The following are some additional guidelines for effective configuration
management. Some of these guidelines are equally applicable to other
management support functions.
·
Configuration management requires authority in order to be effective. This
authority must be clearly delegated by the project manager to the responsible
engineers. Any configuration management plan will become meaningless if
the plan cannot be enforced.
·
Blunt enforcement of any plan policy or standard is best avoided, whenever
possible. One of the qualities of a good manager is the ability to apply policy
with minimal enforcement. Whenever policies and standards are readily
accepted by the developers, they are more willingly followed and there are
fewer rejections of submitted material. This leads to a more efficient
development process.
·
Configuration management should be implemented from the start of a
software project. Many of the formal documents issued during the initial
concept phase are crucial for the requirements and design phases, and must be
placed under configuration control.
·
The early application of configuration management is especially important in
rapid prototyping, spiral models, or other iterative development
methodologies. These development approaches initially produce several
116
img
Software Project Management (CS615)
versions of each product. Many different versions can become an engineering
nightmare without orderly configuration control.
·
Occasionally some software configuration control activities may overlap with
software quality assurance activities. In small projects, these two functions
may be assigned to a single support engineer. Even in large projects, these two
functions are sometimes performed by a single support group.
Misapplication of Guidelines
It should be noted that configuration management can be greatly exaggerated.
The various configuration control activities are not an objective in themselves,
they are a means.
·
A typical example of the misapplication of configuration management (and
misguided quality control), is a requirement to modify reused software to
comply with current standards and procedures.
·
Reused software is software developed previously in another project, and
found suitable to be incorporated into the current project. In such cases it
rarely makes sense to modify a complete and working product in order to
make it comply with administrative standards intended to make it a complete
and working product.
117
Table of Contents:
  1. Introduction & Fundamentals
  2. Goals of Project management
  3. Project Dimensions, Software Development Lifecycle
  4. Cost Management, Project vs. Program Management, Project Success
  5. Project Management’s nine Knowledge Areas
  6. Team leader, Project Organization, Organizational structure
  7. Project Execution Fundamentals Tracking
  8. Organizational Issues and Project Management
  9. Managing Processes: Project Plan, Managing Quality, Project Execution, Project Initiation
  10. Project Execution: Product Implementation, Project Closedown
  11. Problems in Software Projects, Process- related Problems
  12. Product-related Problems, Technology-related problems
  13. Requirements Management, Requirements analysis
  14. Requirements Elicitation for Software
  15. The Software Requirements Specification
  16. Attributes of Software Design, Key Features of Design
  17. Software Configuration Management Vs Software Maintenance
  18. Quality Assurance Management, Quality Factors
  19. Software Quality Assurance Activities
  20. Software Process, PM Process Groups, Links, PM Phase interactions
  21. Initiating Process: Inputs, Outputs, Tools and Techniques
  22. Planning Process Tasks, Executing Process Tasks, Controlling Process Tasks
  23. Project Planning Objectives, Primary Planning Steps
  24. Tools and Techniques for SDP, Outputs from SDP, SDP Execution
  25. PLANNING: Elements of SDP
  26. Life cycle Models: Spiral Model, Statement of Requirement, Data Item Descriptions
  27. Organizational Systems
  28. ORGANIZATIONAL PLANNING, Organizational Management Tools
  29. Estimation - Concepts
  30. Decomposition Techniques, Estimation – Tools
  31. Estimation – Tools
  32. Work Breakdown Structure
  33. WBS- A Mandatory Management Tool
  34. Characteristics of a High-Quality WBS
  35. Work Breakdown Structure (WBS)
  36. WBS- Major Steps, WBS Implementation, high level WBS tasks
  37. Schedule: Scheduling Fundamentals
  38. Scheduling Tools: GANTT CHARTS, PERT, CPM
  39. Risk and Change Management: Risk Management Concepts
  40. Risk & Change Management Concepts
  41. Risk Management Process
  42. Quality Concept, Producing quality software, Quality Control
  43. Managing Tasks in Microsoft Project 2000
  44. Commissioning & Migration