Professional Documents
Culture Documents
The problem that could cause some loss or threaten the success of the
project, but which has not happened yet. The potential problems might have an adverse
impact on cost, schedule, or technical success of the project, the quality of our software
products, or project morale. Risk management is the process of identifying addressing
and eliminating these problems before they can damage the project.
S/W maintenance is the very broad activity that includes error corrections,
enhancements of capabilities, deletion of obsolete capabilities, and optimization. Change
is inevitable, mechanisms must be developed for evaluating, controlling and making
modifications. So any work done to change the software after it is in operation is
considered to be maintenance. The purpose is to preserve the value of the s/w overtime.
The value can be enhanced by expanding the customer base, meeting additional
requirements, becoming easier to use, more efficient and employing newer technology.
Maintenance may span for 50 years, whereas development may be 1-2 years.
It is now-a-days suggested that more time and resources should be invested in the
development-specification & design of more maintainable systems rather than allocating
resources to develop unmentionable or difficult to maintain systems
5. Software Reengineering
System Existing
Specificatio Software
n System
New
System Reengineer
ed System
The costs of re-engineering depend on the extent of the work that is carried out.
Other factors affecting costs are the quality of the software. The following suggestions
may be useful for the modification of the legacy code:
6. Define Modularity
Modularity is the single attribute from the outside than from the inside be
intellectually manageable. It enhances the design clarity , which in turn eases
implementations, debugging, documenting and maintenance of the s/w product.
Abstraction is the intellectual tool that allows us to deal with concepts apart from
particular instances of those concepts. During requirements definition an design,
abstraction permits separation of the conceptual aspects of a system from the
implementation details. We can specify the FIFO property of a queue or the LIFO
property of a stack without concern for the representation scheme to be used in
implementing the stack or queue.
Three widely used abstraction mechanism in s/w design are
functional abstraction
data abstraction
control abstraction.
Functional Abstraction
Data Abstraction
Control Abstraction
Cohesion is the measure of the degree to which the elements of a module are
functionally related. A strongly cohesive module implements functionality that is related
to one feature of the solution and requires little interaction with other modules. The
internal cohesion of a module is measured in terms of the strength of binding of elements
within the module. Cohesion of elements occurs on the scale of weakest to strongest as
follows:
1. Coincidental cohesion
2. Logical Cohesion
3. Temporal cohesion
4. Communication cohesion
5. sequential cohesion
6. Functional Cohesion
7. Informational cohesion
It is important to quantify the level of uncertainty and the degree of loss associated
with the each risk. Different categories of risks are considered. Different categories
of risks are considered.
Project risk : If project risk become real, it is likely that the project schedule will slip
and that cost will increase.
Technical risks: It threaten the quality and timeliness of the s/w to be produced. If a
technical risk becomes a reality, implementation may become difficult or impossible.
Business risks: It threatens the viability of the s/w to be built.
Known risks: The risks are uncovered after careful evaluation of the project plan, the
business and technical environment in which the project is being developed.
Project Metrics
Size oriented metrics
S/W metrics are derived by normalizing quality and/or productivity
measures by considering the “size “ of the s/w that has been produced . If a s/w
organization maintains simple records, a table of size-oriented measures.
Function oriented metrics
The following SCIs become the target for configuration management techniques
and form a set of baselines.
1. System specification
2. Software project plan
3. Software Requirements Specification
(a) Graphical analysis models
(b) Process specifications
(c) Prototype
(d) Mathematical specification
4. Preliminary User Manual
5. Design specification
a) Data Design Description
b) Architectural design specification
c) Module design description
d) Interface design descriptions
e) Object descriptions
6. Source code listing
7. Test spcification
a) Test plan and procedures
b) Test cases and recorded results
8. Operation and Installation Manuals
9. Executed Program
a) Module executable code
b) Linked Modules
10. Database Descriptions
a) Schema file structure
b) Initial content
11. As-built User manual
12. Maintenance Documents
a) Software problem reports
b) Maintenance requests
c) Engineering change orders
13. Standards and procedures for s/w engineering
Over the past two decades a number of s/w configuration management standards
have been proposed. Many early SCM standards, such as MIL-STD-483, DOS-STD-
480A, and MIL-STD-1521A, focused on s/w developed for militry applications. More
recent ANSI / IEEE standards such as ANSI / IEEE Std. No. 1042-1987, and Std.No.
1028-1988, are applicable for commercial software and recommended for both large and
small software engineeringorganizations.
21. What is the role of SQA
The people responsible for the s/w projects are the only ones who can be
responsible for quality. The role of SQA is to monitor the way these groups perform
their responsibilities.
Testing
The process of executing a program with the intention of finding errors
Verification
An attempt to find erros by executing program in a test or simulated environment
Validation
An attempt to find erros by executing a program in a real environment
Debugging
Diagnosing the precise nature of a known error and then correcting it.
2. Integration tests
It verifies the interfaces between system parts (modules, components, and
subsystems)
3. External function tests
It verifies the external system functions, as stated in the external
specifications
4. Regression tests
It runs a subset of previously executed integration and function tests to
ensure that program
5. System tests
It verifies and/or validate the system to its initial objectives
6. Acceptance tests
It validates the system or program to the user’s requirements
7. Installation test
It validate the installability and operability of the user’s system
1. Goals and objectives: It describes what is to be done, for whom, and by when, as
well as the criteria for determining project success
2. Work Breakdown structure(WBS) The WBS subdivides the project into tasks that
are each defined, estimated and tracked.
3. Product size estimates: These are quantitative assessments fo the code required
for each product element. Contingencies are applied to yield reasonable estimates
of the resources required fro each WBS element.
4. Project Shedule: Based on the available project staffing and resource estimates, a
schedule for the key tasks and deliverable items is produced.