Software Project Management
Q1. (a) What are the characteristics of a good software?
Ans. A software refers to instructions which when executed provide desired function and
performance and data structures that enable the programs to adequately manipulate
information, and documents describing the operation and the use of the software. It
refers to set of instructions also known as program.
Characteristics of a good software :
a)
b)
c)
d)
e)
f)
Focuses on user’s actual needs.
Does not expose its implementation
Makes error hard.
Uses graphical control property
Handles error carefully
Gives plenty of feedback.
The three characteristics of good application software are :1) Operational Characteristics
) Correctness: The software which we are making should meet all the specifications stated by
the customer.
b) Usability/Learnability: The amount of efforts or time required to learn how to use the
software should be less. This makes the software user-friendly even for IT-illiterate people.
c) Integrity : Just like medicines have side-effects, in the same way a software may have a sideeffect i.e. it may affect the working of another application. But a quality software should not
have side effects.
d) Reliability : The software product should not have any defects. Not only this, it shouldn't fail
while execution.
e) Efficiency : This characteristic relates to the way software uses the available resources. The
software should make effective use of the storage space and execute command as per desired
timing requirements.
f) Security : With the increase in security threats nowadays, this factor is gaining importance.
The software shouldn't have ill effects on data / hardware. Proper measures should be taken to
keep data secure from external threats.
g) Safety : The software should not be hazardous to the environment/life.
2) Transition Characteristics
) Interoperability : Interoperability is the ability of software to exchange information with other
applications and make use of information transparently.
b) Reusability : If we are able to use the software code with some modifications for different purpose
then we call software to be reusable.
c)Portability : The ability of software to perform same functions across all environments and platforms,
demonstrate its portability.
3) Revision Characteristics
a) Maintainability : Maintenance of the software should be easy for any kind of user.
b) Flexibility : Changes in the software should be easy to make.
c) Extensibility : It should be easy to increase the functions performed by it.
d) Scalability : It should be very easy to upgrade it for more work(or for more number of users).
e) Testability : Testing the software should be easy.
f) Modularity : Any software is said to made of units and modules which are independent of
each other. These modules are then integrated to make the final software. If the software is
divided into separate independent parts that can be modified, tested separately, it has high
modularity.
Q1. (b) Explain the linear sequential and RAD models of software process. State the advantages and
limitations of each model.
Ans . Linear Sequential Model:
The simplest process model is the water fall model which states that the force is organized
in a linear order. So it is also known as the linear sequential model or classic life style
model. The linear sequential model is oldest and the most widely used paradigm for software
engineering. Linear sequential model suggests a systematic, sequential approach to software
development that begins at the system level and progresses through analysis, design, coding,
testing and maintenance.
Modeled after the conventional engineering cycle, the linear sequential model encompasses the
following activities.
-
System / Information engineering and modeling
-
Software requirement analysis
-
Design
-
Code generation
-
Testing
-
Maintenance
1.
System / Information Engineering
Because software is always part of a larger system (or business), work begins by establishing
requirements for all system elements and then allocating some subset of these requirements to
software.
This view is essential when software must interface with other elements such as hardware,
people, and databases. This provides Top-Level design and analysis.
2.
Software requirements analysis
The requirements gathering process is intensified and focused specifically on software.
Analysis is important for software engineer to understand the information domain for the
software, required functions, behavior, performance, and interfacing.
Requirements for both the system and the software are documented and reviewed with the
customer.
3.
Design
Software design is actually a multi-step process that focuses on data structure, software
architecture, procedural detail and interface characterization.
The design process translates requirements into a representation of the software that can be
assessed for quality before code generation begins.
The design documents must e prepared and stored as a part of software configuration.
4.
Code generation
The code generation step translates the design into a machine readable form. If design is
performed in a detailed manner, code generation can be accomplished mechanistically.
5.
Testing
Once code has been generated, program testing begins. The testing process focuses on the logical
internals of the software, assuring that all statements have been tested, and on the functional
externals – that is, conducting test to uncover errors and ensure that defined input will produce
actual results that agree with required results.
6.
Maintenance
Software will undergo change after it is delivered to the customer. Change will occur because,
errors have been encountered or to accommodate changes in its external environment (e.g.
change in device) or customer requires functional or peripheral enhancement.
Advantages:



Simple and systematic.
Linear ordering clearly marks the end of the one phase and starting of another phase
The output of particular phase will be input put for next phase there for this output are normally
referred as intermediate product or based line
Limitations:
1) Real projects rarely follow the sequential flow that the model proposes. Changes can cause
confusion as the project team proceeds.
2) It is difficult for the customer to state all requirements explicitly at the beginning of the
projects.
3) The water fall model assumes that the requirement should be completely specified before the
rest of the development can proceed. In some situation it might be required that first developed a
part of the system completely and then later enhance a system where the client face an important
role in requirement specification.
4) The customer must have patience. A working version of program(s) will not be available
until late in the project time span.
5) Development is often delayed unnecessarily. The linear nature of the classic life cycle leads
to “Blocking state” in which some project team members must wait for other members of the
team to complete dependent tasks.
6) The time spent waiting can exceed the time spent on productive work
RAPID APPLICATION DEVELOPMENT (RAD) :
RAD model is Rapid Application Development model. It is a type of incremental model. In RAD
model the components or functions are developed in parallel as if they were mini projects. The
developments are time boxed, delivered and then assembled into a working prototype. This can
quickly give the customer something to see and use and to provide feedback regarding the
delivery and their requirements.
The phases in the rapid application development (RAD) model are:
Business modeling: The information flow is identified between various business functions.
Data modeling: Information gathered from business modeling is used to define data objects that
are
needed
for
the
business.
Process modeling: Data objects defined in data modeling are converted to achieve the business
information flow to achieve some specific business objective. Description are identified and
created
for
CRUD
of
data
objects.
Application generation: Automated tools are used to convert process models into code and the
actual
system.
Testing and turnover: Test new components and all the interfaces.
Advantages of the RAD model:





Reduced development time.
Increases reusability of components
Quick initial reviews occur
Encourages customer feedback
Integration from very beginning solves a lot of integration issues.
Disadvantages of RAD model:





Depends on strong team and individual performances for identifying business requirements.
Only system that can be modularized can be built using RAD
Requires highly skilled developers/designers.
High dependency on modeling skills
Inapplicable to cheaper projects as cost of modeling and automated code generation is very
high.
When to use RAD model:



RAD should be used when there is a need to create a system that can be modularized in 2-3
months of time.
It should be used if there’s high availability of designers for modeling and the budget is high
enough to afford their cost along with the cost of automated code generating tools.
RAD SDLC model should be chosen only if resources with high business knowledge are available
and there is a need to produce the system in a short span of time (2-3 months).
Q2. (a) Describe a structure of a SRS document with a suitable example.
SRS is a specification for a particular software product, program or set of programs that performs certain
functions in a specific environment. It serves a number of purposes depending on who is writing it. First,
the SRS could be written by the customer of a system. Second, the SRS could be written by the
developer of the system. The scenarios create entirely different purposes for the document. First case,
SRS is used to define the needs and expectations of the users. The second case, SRS is written for
different purposes and serve as a contract document between the customer and developer.
Structure of SRS:
1 Introduction
1.1 Purpose
Comment: Purpose of the document and not the purpose of the software.
Example: This document provides all of the requirements for the yyy. Parts 1 and 2 are intended
primarily for customers of the application, but will also be of interest to software engineers
building or maintaining the software. Part 3 is intended primarily for software engineers, but will
also be of interest to customers.
1.2 Scope
Comment: What aspects of the application this document tends to cover?
Example: This document covers the requirements for release xxx of yyy. Mention will be made
throughout this document of selected probable features of future releases. The purpose of this is
to guide developers in selecting a design that will be able to accommodate the full-scale
application.
1.3 Definitions, Acronyms, and Abbreviations
Comment: Glossary of that will be used throughout the documents, as well as in other documents
based on this one. Usually in the form of table.
1.4 References
Comment: References to all documents that are connected to this one.
Example: Software Project management Plan for yyy, version xxx (xxx is the vesrion of the
document and not the version of the software). Software Design Description for yyy, version
xxx.
1.5 Overview
Comment: Overview of the software. Its main goals, tasks and users.
2 Overall Description
Comment: Overall description of software - more detailed than in 1.5. This should be general
enough so that it is unlikely to change much in future versions. Avoid statements that are
repeated in later sections.
2.1 Product perspective
Comment: In this section software should be compared with other related or competing
products, which is a good way to provide perspective of our product.
2.1.1 System interfaces
Comment: List all special interfaces to operating system.
2.1.2 User interfaces
Comment: Preliminary sketches and/or principles of key user interfaces only, used to provide
perspective on the product. All user interfaces are described in detail in section 3.
2.1.3 Hardware interfaces
Comment: List all special hardware needed for software operation.
Example: Joystick will be used as an input device for some functions of the software (enlisted
later).
2.1.4 Software interfaces
Comment: Interfaces with other software products.
2.1.5 Communication interfaces
Comment: List all communication interfaces.
Example: Modem will provide access to Internet when necessary.
2.1.6 Memory constraints
Comment: memory that is expected to be used by the software (external and internal).
Example: yyy is expected to use no more than 16 MB of Ram and 20 MB of external storage.
2.1.7 Operations
Comment: List all normal and special operations required by the user.
Example: It must be possible to save and retirev the current state of the software.
2.1.8 Site adaptation requirements
Comment: Requirements for execution on a particular installation
Example: User interface must exist in three different languages: Hungarian, Serbian, and Slovak.
2.2 Product functions
Comment: Summary of the major functions of the application. More detailed than section 1.5 but
less detailed than section 3.
Example: Use case can be used to describe the main functions. If done so, then here all use cases
can be briefly described (and displayed).
2.3 User characteristics
Comment: Indicate what kind of people the typical user are likely to be. For example: novice,
software professional, accountant with 5 years of computer usage, etc.
2.4 Constraints
Comment: All conditions that may limit developer's options. These can originate from many
sources.
Example: yyy shall operate on PCs running Windows 95 or later at a minimum speed of 100
MHZ. Java shall be the implementation language.
2.5 Assumptions and dependencies
Comment: Any assumptions being made.
Example: Future versions of yyy shall operate on PCs running Linux.
2.6 Apportioning of requirements
Comment: Order in which requirements are to be implemented.
Example: The requirements described in sections 1 and 2 of this document are referred to as
preliminary specifications; those in section 3 are referred to as requirements (or functional)
specifications. The two levels of requirements are intended to be consistent. Inconsistencies are
to be logged as defects. In the event that a requirement is stated within both preliminary and
functional specifications, the application will be built from functional specification since it is
more detailed.
'Essential requirements' (referred to in section 3) are to be implemented for this version of yyy.
'Desirable requirements' are to be implemented in this release if possible, but are not committed
to by the developers. It is anticipated that they will be part of future release. 'Optional
requirements' will be implemented at the discretion of developers.
3 Specific requirements
3.1 External interface requirements
3.1.1 User interfaces
Comment: Description of user interface in section 2.1.2 showed only sketches of user interfaces
in order to provide product perspective. It lacks details and should not be regarded as the last
word. If user interfaces are not completely specified later in this document, then all details
should be given in this section.
3.1.2 Hardware interfaces
Comment: Hardware that the software product deals with.
3.1.3 Software interfaces
Comment: Other software with which software product must interface.
3.1.4 Communication interfaces
Comment: Communication interfaces (Internet, modem, ...).
3.2 Classes/Objects
Comment: This style of SRS expects that detailed requirements are classified by classes. This
section should list classes pertaining to the domain of the application and are adequate for
organizing all of the requirements. These classes are not all of the classes that will be used by
the application. Every function/class should be marked as 'essential', 'desirable', or 'optional'.
3.3 Performance requirements
Comment: Performance requirements include required speeds and/or time to complete. Unless
documented in a different section of the SRS, they may also include memory usage (RAM and/or
disk) noted either statically or dynamically (i.e., memory required at runtime).
3.4 Design constraints
Comment: Restrictions on design. If there is no material in this section, designers are free to
create any (good) design that satisfies the requirements.
3.5 Software system attributes
3.5.1 Reliability
Example: yyy shall fail not more than once in a week. Reference to test documentation goes also
here.
3.5.2 Availability
3.5.3 Security
Example: yyy shall ask for user-name and password at the beginning. Passwords will be
encrypted before saving.
3.5.4 Maintainability
Comment: Lists of all functions/classes that are expected to change soon or to change frequently.
3.6 Other requirements
4 Supporting information
4.1 Table of Contents and Index
4.2 Appendices
Q2.(b) What is data flow diagram? Why is it used?
Ans. A data-flow diagram (DFD) is a graphical representation of the "flow" of data through
an information system. DFDs can also be used for the visualization of data processing
(structured design).
On a DFD, data items flow from an external data source or an internal data store to an internal
data store or an external data sink, via an internal process.
A DFD provides no information about the timing or ordering of processes, or about whether
processes will operate in sequence or in parallel. It is therefore quite different from a flowchart,
which shows the flow of control through an algorithm, allowing a reader to determine what
operations will be performed, in what order, and under what circumstances, but not what kinds of
data will be input to and output from the system, nor where the data will come from and go to,
nor where the data will be stored (all of which are shown on a DFD). Data flow diagrams can be
used in both Analysis and Design phase of the SDLC.
When it comes to conveying how information data flows through systems (and how that data is
transformed in the process), data flow diagrams (DFDs) are the method of choice over technical
descriptions for three principal reasons.
(1) DFDs are easier to understand by technical and nontechnical audiences.
(2) DFDs can provide a high level system overview, complete with boundaries and connections
to other systems.
(3) DFDs can provide a detailed representation of system components.
Example:
Q3. How projects are estimated using SLOC, FP and COCOMO techniques?
Source lines of code (SLOC or LOC) is a software metric used to measure the size of a software
program by counting the number of lines in the text of the program's source code. SLOC is
typically used to predict the amount of effort that will be required to develop a program, as well
as to estimate programming productivity or effort once the software is produced.
Measurement methods
There are two major types of SLOC measures: physical SLOC (LOC) and logical SLOC
(LLOC). Specific definitions of these two measures vary, but the most common definition of
physical SLOC is a count of lines in the text of the program's source code including comment
lines. Blank lines are also included unless the lines of code in a section consists of more than
25% blank lines. In this case blank lines in excess of 25% are not counted toward lines of code.
Logical LOC attempts to measure the number of "statements", but their specific definitions are
tied to specific computer languages (one simple logical LOC measure for C-like programming
languages is the number of statement-terminating semicolons). It is much easier to create tools
that measure physical SLOC, and physical SLOC definitions are easier to explain. However,
physical SLOC measures are sensitive to logically irrelevant formatting and style conventions,
while logical LOC is less sensitive to formatting and style conventions. Unfortunately, SLOC
measures are often stated without giving their definition, and logical LOC can often be
significantly different from physical SLOC.
Consider this snippet of C code as an example of the ambiguity encountered when determining
SLOC:
for (i = 0; i < 100; i += 1) printf("hello"); /* How many lines of code is
this? */
In this example we have:



1 Physical Lines of Code (LOC)
2 Logical Line of Code (LLOC) (for statement and printf statement)
1 comment line
Depending on the programmer and/or coding standards, the above "line of code" could be written
on many separate lines:
for (i = 0; i < 100; i += 1)
{
printf("hello");
} /* Now how many lines of code is this? */
In this example we have:



4 Physical Lines of Code (LOC): is placing braces work to be estimated?
2 Logical Line of Code (LLOC): what about all the work writing non-statement lines?
1 comment line: tools must account for all code and comments regardless of comment
placement.
Even the "logical" and "physical" SLOC values can have a large number of varying definitions.
Robert E. Park (while at the Software Engineering Institute) et al. developed a framework for
defining SLOC values, to enable people to carefully explain and define the SLOC measure used
in a project. For example, most software systems reuse code, and determining which (if any)
reused code to include is important when reporting a measure.
FUNCTION POINTS:
Function point measures functionality from the users point of view, that is, on the basis of what the
user requests and receives in return from the system. The principle of functional point analysis iis that a
system is decomposed into functional units.





Inputs – information entering the system
Outputs – information leaving the system
Enquiries – requests for instant access to information
Internal Logical Files – Information held within the system
External Interface files – Information held by other systems that is used by the system being
analyzed
Measurement Method:
Now to calculate the function points we need to follow the following steps:
1. Measure the application boundary
a. The application boundary defines what is external to the application.
b. It is dependent on the users external business view of the application and not on
the technical and/or implementation consideration
2. Identify the data functionalities (ILF and EIF)
a. User identifiable group of data; logically related and maintained with in the
boundary of the application through one or more elementary process is know as
ILF.
b. User identifiable group of data, logically related, referenced by the application
but maintained with in the boundary of different application is known as EIF.
c. Few other terminologies of RET and DET are to be understood here as well to
determine the function points.
d. A RET (record element type) is a user recognizable subgroup of data elements
with as ILF or EIF
e. A DET (data element type) is a unique user recognizable, non-repeated field
either maintained in an ILF or retrieved from an ILF or ELF.
3. Identify the transaction functionalities (EI, EO, EQ)
a. All the tree Transactional functionalities are "elementary processes"
b. An Elementary Process is the smallest unit of activity that is meaningful to the
user(s).
c. The elementary process must be self-contained and leave the business of the
application in a consistent state.
d. An EI (External Input) is an elementary process of the application which
processes data that enters from outside the boundary of the application.
Maintains one or more ILF.
e. An EO (External Output) is an elementary process that generates data that exits
the boundary of the application (i.e. presents information to the user) through
processing logic, retrieval of data through ILF or EIF. The processing logic
contains mathematical calculations, derived data etc.
f. An EQ (External Query) is an elementary process that results in retrieval of data
that is sent outside the application boundary (i.e. present information to the
user) through retrieval of data from ILF or EIF. The processing logic should not
contain any mathematical formula, derived data etc.
4. Using the above data we can calculate the UFP (Unadjusted Function Points)
a. After all the basic data & transactional functionalities of the system have been
defined we can use the following set of tables below to calculate the total UFP.
b. Now for each type of Functionality determine the UFP's based on the below table.
c. For EI's, EO's & EQ's determine the FTR's and DET's and based on that
determine the Complexity and hence the Number of UFP's it contributes. We
have to calculate this for all the EI's, EO's & EQ's.
External Inputs (EI)
File Type Referenced
(FTR)
Less than 2
2
Greater than 2
">Data Elements (DET)
1-4
5-15
Low (3)
Low (3)
Average (4)
Low (3)
Average (4)
High (6)
Greater than
15
Average (4)
High (6)
High (6)
External Outputs (EO)
">File Type Referenced
(FTR)
Less than 2
2 or 3
Greater than 3
">Data Elements (DET)
1-5
6-19
Low (4)
Low (4)
High (7)
Low (4)
Average (5)
High (7)
Greater than
19
Average (5)
High (7)
High (7)
External Inquiry (EQ)
">File Type Referenced
(FTR)
">Data Elements (DET)
Less than 2
2 or 3
Greater than 3
1-5
6-19
Low (3)
Low (3)
Average (4)
Low (3)
Average (4)
High (6)
Greater than
19
Average (4)
High (6)
High (6)
d. For ILF's & EIF's determine the RET's and DET's and based on that determine
the Complexity and hence the Number of UFP's it contributes. We have to
calculate this for all the ILF's & EIF's.
Internal Logical File (ILF)
">Record Element Types
(RET)
">Data Elements (DET)
1-19
Low (7)
Low (7)
1 RET
2 to 5 RET
6 or more RET
Average
(10)
20-50
Low (7)
Average
(10)
High (15)
51 or More
Average (10)
High (15)
High (15)
External Interface File (EIF)
">Record Element Types
(RET)
1 RET
2 to 5 RET
6 or more RET
">Data Elements (DET)
1-19
Low (5)
Low (5)
Average (7)
20-50
Low (5)
Average (7)
High (10)
51 or More
Average (7)
High (10)
High (10)
e. Once we have the score of all the Functionalities we can get the UFP as
UFP = Sum of all the Complexities of all the EI's, EO's EQ's, ILF's and EIF's
5. Further the calculation of VAF (Value added Factor) which is based on the TDI (Total
Degree of Influence of the 14 General system characteristics)
a. TDI = Sum of (DI of 14 General System Characteristics) where DI stands for
Degree of Influence.
b. These 14 GSC are
1. Data Communication
2. Distributed Data Processing
3. Performance
4. Heavily Used Configuration
5. Transaction Role
6. Online Data Entry
7. End-User Efficiency
8. Online Update
9. Complex Processing
10. Reusability
11. Installation Ease
12. Operational Ease
13. Multiple Sites
14. Facilitate Change
c. These GSC are on a scale of 0-5
6. Once the TDI is determined we can put it in the formula below to get the VAF.
VAF = 0.65 + (0.01 * TDI)
7. Finally the Adjusted Function Points or Function Points are
FP = UFP * VAF
8. Now these FP's can be used to determine the Size of the Software, also can be used to
quote the price of the software, get the time and effort required to complete the software.
9. Effort in Person Month = FP divided by no. of FP's per month (Using your
organizations or industry benchmark)
10. Schedule in Months = 3.0 * person-month^1/3
COCOMO Model:
COCOMO is a hierarchy of software cost estimation models, which include basic, intermediate
and detailed sub models.
Basic : It aims at estimating in a quick and rough fashion, most of the small to medium sized
software products. Three modes of software development are considered in this model: organic,
semi – detached and embedded.
In the organic mode, a small team of experienced developers develop s software in a very
familiar environment. The size of the software development in this mode ranges from small( a
few KLOC) to medium ( a few tens of KLOC), while in other two modes the size ranges from
small to very large( a few hundreds of KLOC)
In the embedded mode of software development, the project has tight constraints which
might be related to the target processor and its interface with the associated hardware. The
problem to be solved is unique and so it is often hard to find experienced persons as the same
does not usually exist.
The semi – detached mode is an intermediate between the organic mode and embedded
mode.
The Basic COCOMO equations take the form:
E = ab KLOC bb
D = cb E db
where E is the effort applied in person-months, D is the development time in
chronological months and KLOC is the estimated number of delivered lines of code for
the project (express in thousands). The coefficients ab and cb and the exponents bb and db
are given in Table 1.
Basic COCOMO Model
Software Project
ab
bb
cb
db
organic
2.4
1.05
2.5
0.38
Semi-detached
3.0
1.12
2.5
0.35
embedded
3.6
1.20
2.5
0.32
The basic model is extended to consider a set of "cost driver attributes" that can be
grouped into four major categories:
1. Product attributes
a. required software reliability
b. size of application data base
c. complexity of the product
2. Hardware attributes
a. run-time performance constraints
b. memory constraints
c. volatility of the virtual machine environment
d. required turnaround time
3. Personnel attributes
a. analyst capability
b. software engineer capability
c.applications experience
d. virtual machine experience
e. programming language experience
4. Project attributes
a. use of software tools
b. application of software engineering methods
c. required development schedule
Each of the 15 attributes is rated on a 6 point scale that ranges from "very low" to "extra
high" (in importance or value). Based on the rating, an effort multiplier is determined
from tables published by Boehm , and the product of all effort multipliers results is an
effort adjustment factor (EAF). Typical values for EAF range from 0.9 to 1.4.
The intermediate COCOMO model takes the form:
E = ai KLOC bi x EAF
where E is the effort applied in person-months and KLOC is the estimated number of
delivered lines of code for the project. The coefficient ai and the exponent bi are given in
Table 2.
INTERMEDIATE COCOMO MODEL
Software project
ai
bi
organic
3.2
1.05
Semi-detached
3.0
1.12
embedded
2.8
1.20
COCOMO represents a comprehensive empirical model for software estimation.
Q4. (a) What are the reasons of delay of a software project? How can these delays be prevented?
Ans. The following are few of the reasons of delays of a software project:
1. Expansion of functionality
The expansion of functionality is a phenomenon in which new functionalities continue to
be conceived and requested as the project proceeds. The software can never be completed
in this way.
2. Gold plating
Gold plating is a phenomenon in which programmers and designers try to make many
details of the software or design too elaborate. Much time is spent improving details,
even though the improvements were not requested by the customer or client. The details
often add little to the desired result.
3. Neglecting quality control
Time pressure can sometimes cause programmers or project teams to be tempted to skip
testing. This frequently causes more delays than it prevents. The time that elapses before
an error is discovered in the software is associated with an exponential increase in the
time that is needed to repair it.
4. Overly optimistic schedules
Overly optimistic schedules place considerable pressure on the project team. The team
will initially attempt to reach the (unrealistic) deadlines. These attempts lead to sloppy
work and more errors, which cause further delays.
In this regard, be particularly wary of schedules that are imposed from above. The
desire to complete a project (more) quickly sometimes arises for primarily strategic
reasons; if it is not feasible, however, it should not be attempted. The project will not
proceed more quickly and the product will ultimately suffer.
5. Working on too many projects at the same time
Dividing work across many different projects (or other tasks) causes waiting times that
lead to many delays in projects.
6. Poor design
The absence (or poor realisation) of designs leads to delays, as it requires many revisions
at later stages.
7. The 'one-solution-fits-all' syndrome
Using the right software for a project is important. Some software platforms are more
suited to particular applications than others are. Thinking that the use of particular
software will greatly improve productivity, however, is also a trap.
8. Research-oriented projects
Projects in which software must be made and research must be conducted are difficult to
manage. Research is accompanied by high levels of uncertainty. When or if progress will
be achieved in research is unclear. When software development is dependent upon the
results of research, the former frequently comes to a standstill.
9. Mediocre personnel
Insufficiently qualified personnel can cause project delays. Technically substantive
knowledge of the subject of the project plays a role, as do knowledge and skills in
working together to play the game of the project.
10. Customers fail to fulfil agreements
Customers are not always aware that they are expected to make a considerable
contribution to the realisation of a project. When customers do not react in a timely
manner to areas in which they must be involved, projects can come to a standstill. Worse
yet, the team may proceed further without consulting the customer, which can lead to
later conflicts.
11. Tension between customers and developers
The tension that can arise between customers and developers (e.g. because the project is
not proceeding quickly enough) can cause additional delays, as it disturbs the necessary
base of trust and the working atmosphere.
How to avoid Delays:
People participate in various projects, including projects at work, school and home. These
projects often take weeks, months or years to complete, depending upon schedules, materials,
costs and complications. People involved in the projects have to save or raise money,
coordinate workers and purchase supplies while working on the project. Finding ways to
stick to schedules, coordinate activities and deal with unexpected problems helps to ensure
you don't have delays that cause your project to be a failure.
1. Project Planning and Implementation
o
Come up with a method for completing your plan that is feasible given your
timeframe, workforce, resources and funding. Have clear goals for the project so
you know what you wish to accomplish with the project. Your project plan should
outline the different phases of the project and the timeframe for completing each
segment. Brainstorm with group members when developing a project plan. Think
about the needs and wishes of the people, organization or groups for which you
are completing the project, if you are not the recipient of the final product,
according to Project Smart.
When working on the project, stick to the original plan as much as possible, and
be prepared to alter your plan as unexpected problems arise. Organize workers in
such a way that you can maximize how much work gets completed at a given time
and make sure that others are staying on task. Appoint people as supervisors or
group leaders to coordinate activities, deal with issues with workers and
troubleshoot when complications come up, if you are unable to take on the role of
project supervisor or are dealing with a large group of people. Regularly
communicate with other group members using telephone calls, emails, text
messages and other forms of communication, so that each phase of a project goes
off smoothly.
2. Schedule
o
Develop a master schedule that outlines how long you expect to take to finish the
project. Account for the time it will take to raise or save money, work on each
phase of the project, and purchase and move materials when you develop a
schedule. Also consider time periods when you won't be able to work on the
project. Use paper or computer documents, such as a Word or Excel document, to
keep track of work that you have accomplished and need to do. Also, use
documents to keep track of everyone's schedule. Be prepared to revise your
master and weekly schedules due to unexpected events, including those in
people's lives. When you get off your schedule, work harder and for longer hours
to make up for time lost and prevent extended delays.
3. Costs
o
Plan for project costs from the start of the project, taking worker and material
costs into account. Do research on what materials and services cost to develop a
basic estimate of project costs. Find out what different materials and services you
will need for the project by talking to experts or others who have worked on
similar projects to come up with an estimate. When you start to spend money on
the project, keep track of your costs to ensure that you have enough money to
complete the project. Find ways to get additional funding through bank loans,
investors or personal funds ahead of time if your project has unexpected costs.
Purchase good materials, but do not choose luxury items if you don't have the
funding.
Complications
o
Be prepared for or anticipate possible complications ahead of time, if possible.
Include potential solutions in your initial or revised plan for problems that could
arise during the implementation phase. Talk to people who have done similar
projects to avoid making the same mistakes, or prepare an emergency plan for
potential complications. When you have problems within your project, come up
with and implement solutions in a timely manner so you don't experience time
delays. Consult different resources, including experts, to find out how to deal with
the problem in the most efficient manner.
Q5. A) How is Gantt chart used in software project management?
Gantt chart:
A Gantt chart, commonly used in project management, is one of the most popular and useful
ways of showing activities (tasks or events) displayed against time. On the left of the chart is a
list of the activities and along the top is a suitable time scale. Each activity is represented by a
bar; the position and length of the bar reflects the start date, duration and end date of the activity.
This allows you to see at a glance:





What the various activities are
When each activity begins and ends
How long each activity is scheduled to last
Where activities overlap with other activities, and by how much
The start and end date of the whole project
To summarize, a Gantt chart shows you what has to be done (the activities) and when (the
schedule).
A simple Gantt chart
b) What is Rayleigh curve?
Ans. The Norden /Rayleigh equation, represents manpower, measured in persons per unit time as a
function of time. It is usually expressed in person-year/year (PY/YR). The Rayleigh curve is modeled
by the differential equation:
Q6.a) What are the various types of testing strategy?
Ans. Software testing must be planned carefully to avoid wasting development time and
resources. Testing begins “in the small” and progresses “to the large”. Initially individual
components are tested and debugged. After the individual components have been
tested and added to the system, integration testing takes place. Once the full software
product is completed, system testing is performed. The Test Specification document
should be reviewed like all other software engineering work products.
Strategic Approach to Software Testing






Many software errors are eliminated before testing begins by conducting effective
technical reviews
Testing begins at the component level and works outward toward the integration of
the entire computer-based system.
Different testing techniques are appropriate at different points in time.
The developer of the software conducts testing and may be assisted by independent
test groups for large projects.
Testing and debugging are different activities.
Debugging must be accommodated in any testing strategy.
Verification and Validation



Make a distinction between verification (are we building the product right?) and
validation (are we building the right product?)
Software testing is only one element of Software Quality Assurance (SQA)
Quality must be built in to the development process, you can’t use testing to add
quality after the fact
Organizing for Software Testing



The role of the Independent Test Group (ITG) is to remove the conflict of interest
inherent when the builder is testing his or her own product.
Misconceptions regarding the use of independent testing teams
o The developer should do no testing at all
o Software is tossed “over the wall” to people to test it mercilessly
o Testers are not involved with the project until it is time for it to be tested
The developer and ITGC must work together throughout the software project to
ensure that thorough tests will be conducted
Software Testing Strategy




Unit Testing – makes heavy use of testing techniques that exercise specific control
paths to detect errors in each software component individually
Integration Testing – focuses on issues associated with verification and program
construction as components begin interacting with one another
Validation Testing – provides assurance that the software validation criteria
(established during requirements analysis) meets all functional, behavioral, and
performance requirements
System Testing – verifies that all system elements mesh properly and that overall
system function and performance has been achieved
Strategic Testing Issues








Specify product requirements in a quantifiable manner before testing starts.
Specify testing objectives explicitly.
Identify categories of users for the software and develop a profile for each.
Develop a test plan that emphasizes rapid cycle testing.
Build robust software that is designed to test itself.
Use effective formal reviews as a filter prior to testing.
Conduct formal technical reviews to assess the test strategy and test cases.
Develop a continuous improvement approach for the testing process.
Unit Testing






Module interfaces are tested for proper information flow.
Local data are examined to ensure that integrity is maintained.
Boundary conditions are tested.
Basis (independent) path are tested.
All error handling paths should be tested.
Drivers and/or stubs need to be developed to test incomplete software.
Integration Testing



Sandwich testing uses top-down tests for upper levels of program structure coupled
with bottom-up tests for subordinate levels
Testers should strive to indentify critical modules having the following requirements
Overall plan for integration of software and the specific tests are documented in a
test specification
Integration Testing Strategies

Top-down integration testing
1. Main control module used as a test driver and stubs are substitutes for
components directly subordinate to it.
2. Subordinate stubs are replaced one at a time with real components (following the
depth-first or breadth-first approach).
3. Tests are conducted as each component is integrated.
4. On completion of each set of tests and other stub is replaced with a real
component.
5. Regression testing may be used to ensure that new errors not introduced.

Bottom-up integration testing
1. Low level components are combined into clusters that perform a specific
software function.
2. A driver (control program) is written to coordinate test case input and output.
3. The cluster is tested.
4. Drivers are removed and clusters are combined moving upward in the program
structure.

Regression testing – used to check for defects propagated to other modules by
changes made to existing program
1. Representative sample of existing test cases is used to exercise all software
functions.
2. Additional test cases focusing software functions likely to be affected by the
change.
3. Tests cases that focus on the changed software components.

Smoke testing
1. Software components already translated into code are integrated into a build.
2. A series of tests designed to expose errors that will keep the build from
performing its functions are created.
3. The build is integrated with the other builds and the entire product is smoke
tested daily (either top-down or bottom integration may be used).
General Software Test Criteria

Interface integrity – internal and external module interfaces are tested as each
module or cluster is added to the software



Functional validity – test to uncover functional defects in the software
Information content – test for errors in local or global data structures
Performance – verify specified performance bounds are tested
Object-Oriented Test Strategies



Unit Testing – components being tested are classes not modules
Integration Testing – as classes are integrated into the architecture regression tests
are run to uncover communication and collaboration errors between objects
Systems Testing – the system as a whole is tested to uncover requirement errors
Object-Oriented Unit Testing




smallest testable unit is the encapsulated class or object
similar to system testing of conventional software
do not test operations in isolation from one another
driven by class operations and state behavior, not algorithmic detail and data flow
across module interface
Object-Oriented Integration Testing






focuses on groups of classes that collaborate or communicate in some manner
integration of operations one at a time into classes is often meaningless
thread-based testing – testing all classes required to respond to one system input
or event
use-based testing – begins by testing independent classes (classes that use very
few server classes) first and the dependent classes that make use of them
cluster testing – groups of collaborating classes are tested for interaction errors
regression testing is important as each thread, cluster, or subsystem is added to the
system
WebApp Testing Strategies
1.
2.
3.
4.
WebApp content model is reviewed to uncover errors.
Interface model is reviewed to ensure all use-cases are accommodated.
Design model for WebApp is reviewed to uncover navigation errors.
User interface is tested to uncover presentation errors and/or navigation mechanics
problems.
5. Selected functional components are unit tested.
6. Navigation throughout the architecture is tested.
7. WebApp is implemented in a variety of different environmental configurations and
the compatibility of WebApp with each is assessed.
8. Security tests are conducted.
9. Performance tests are conducted.
10. WebApp is tested by a controlled and monitored group of end-users (looking for
content errors, navigation errors, usability concerns, compatibility issues, reliability,
and performance).
Validation Testing



Focuses on visible user actions and user recognizable outputs from the system
Validation tests are based on the use-case scenarios, the behavior model, and the
event flow diagram created in the analysis model
o Must ensure that each function or performance characteristic conforms to its
specification.
o Deviations (deficiencies) must be negotiated with the customer to establish a
means for resolving the errors.
Configuration review or audit is used to ensure that all elements of the software
configuration have been properly developed, cataloged, and documented to allow its
support during its maintenance phase.
Acceptance Testing



Making sure the software works correctly for intended user in his or her normal work
environment.
Alpha test – version of the complete software is tested by customer under the
supervision of the developer at the developer’s site
Beta test – version of the complete software is tested by customer at his or her own
site without the developer being present
System Testing






Series of tests whose purpose is to exercise a computer-based system
The focus of these system tests cases identify interfacing errors
Recovery testing – checks the system’s ability to recover from failures
Security testing – verifies that system protection mechanism prevent improper
penetration or data alteration
Stress testing – program is checked to see how well it deals with abnormal resource
demands (i.e. quantity, frequency, or volume)
Performance testing – designed to test the run-time performance of software,
especially real-time software

Deployment (or configuration) testing – exercises the software in each of the
environment in which it is to operate
Q6. b) How is software quality ensured using SEI-CMM?
Ans.
Q7. What is statistical Quality Assurance(SQA)? Develop your own metrics for
correctness, maintainability, integrity and usability of the software?
Ans. The statistical quality assurance is application of statistical principle and
techniques in all stages of production, design, maintenance and services, directed
toward the economic satisfaction of demand. The statistical quality assurance is a
system of application that embraces all formal quantitative aspect of planning, design,
purchase, production, services, marketing and re-design of product, it helps to find
problems to state them in meaningful terms and to solve them, it provides a plan, a
road-map, that leads to better competitive position. The great advantages of statistical
thinking are that it allows managers to differentiate between common causes and
special causes of trouble .
Q8.(a) How is risk reduction different from risk mitigation?