MANAKULA VINAYAGAR INSTITUTE OF TECHNOLOGY

KALITHEERTHAL KUPPAM, PUDHUCHERY -605 107

DEPARTMENT OF CSE
SOFTWARE ENGINEERING (CS T55)

UNIT –II Software Project Management and Requirements Analysis

2 Marks Questions:

1. What is the main goal of software project management?

The main goal of software project management is to enable a group of developers
to work effectively towards the successful completion of a project.

2. Write the Software Project Management Complexities.

The main factors contributing to the complexity of managing a software project, as
identified by are the following:
Invisibility
Changeability
Complexity:
Uniqueness
Exactness of the solution
Team-oriented and intellect-intensive work

3. What are the Responsibilities of a Software Project Manager?

Project planning: Project planning involves estimating several characteristics of a
project and then planning the project activities based on these estimates made.
Project monitoring and control: The focus of project monitoring and control
activities is to ensure that the software development proceeds as per plan.

4. What are the Skills Necessary for Managing Software Projects?

Three skills that are most critical to successful project management are the
following:
Knowledge of project management techniques.
Decision taking capabilities.
Previous experience in managing similar projects.
5. What are the Planning activities?

Software Engineering 1 MIT/CSE

 Estimation to be calculated
Cost: How much is it going to cost to develop the software product?
Duration: How long is it going to take to develop the product?
Effort: How much effort would be necessary to develop the product?
The effectiveness of all later planning activities such as scheduling and staffing are
dependent on the accuracy with which these three estimations have been made.

6. Define Lines of Code (LOC)

LOC is possibly the simplest among all metrics available to measure project size.
This metric measures the size of a project by counting the number of source
instructions in the developed program while counting the number of source
instructions, comment lines, and header lines are ignored
7. Write the Shortcomings of the LOC metric
LOC is a measure of coding activity alone.
LOC count depends on the choice of specific instructions
LOC measure correlates poorly with the quality and efficiency of the Code
LOC metric penalises use of higher-level programming languages and code reuse
LOC metric measures the lexical complexity of a program and does not address
the more important issues of logical and structural complexities
It is very difficult to accurately estimate LOC of the final program from problem
specification

8. Define Function Point (FP) Metric.

Function Point (FP) Metric overcomes many of the shortcomings of the LOC
metric.
In the function point metric size can easily be computed from the problem
specification itself, whereas in LOC metrics the size can accurately be determined
only after the product has fully been developed.

9. Write the conceptual idea behind the function point metric.

The conceptual idea behind the function point metric is the following.

The size of a software product is directly dependent on the number of different high-
level functions or features it supports.
A software product supporting many features would certainly have large size than the
product with fewer features.
Each function invokes some function for input data and transforms it to output data.

10. What are the steps in Function point (FP) metric computation?

The size of a software product (in units of function points or FPs) is computed using
different characteristics of the product identified in its requirements specification.

Step 1: Compute the unadjusted function point (UFP) using a heuristic expression.

Software Engineering 2 MIT/CSE

Step 2: Refine UFP to reflect the actual complexities of the different parameters used in UFP
computation.
Step 3: Compute FP by further refining UFP to account for the specific characteristics of the
project that can influence the entire development effort.

11. Write the Formula to calculate UFP.

UFP unadjusted function point
UFP = (Number of inputs)*4 + (Number of outputs)*5 + (Number of inquiries)*4 +
(Number of files)*10 + (Number of interfaces)*10

12. What are the different types of Project Estimation Techniques?

Empirical estimation techniques
Heuristic techniques
Analytical estimation techniques
13. What are the two popular Empirical Estimation Techniques?

Expert Judgment
Delphi Cost Estimation
14. Define Expert Judgment.

Expert judgement is a widely used size estimation technique. In this technique, an expert
makes an educated guess about the problem size after analysing the problem thoroughly.
Usually, the expert estimates the cost of the different components (i.e. modules or
subsystems) that would make up the system and then combines the estimates for the
individual modules to arrive at the overall estimate.
15. Define Delphi cost estimation.

Delphi cost estimation technique tries to overcome some of the shortcomings of the
expert judgement approach.
Delphi estimation is carried out by a team comprising a group of experts and a co-
ordinator.
In this approach, the co-ordinator provides each estimator with a copy of the software
requirements specification (SRS) document and a form for recording his cost estimate.
Estimators complete their individual estimates anonymously and submit them to the co-
ordinator.

16. Define COCOMO – COnstructive COst estimation MOdel .

This model was proposed by Boehm, 1981. He postulated that any software development
project can be classified into any one of the following three categories based on the development
complexity, they are
Organic
Semidetached
Embedded
It is not only classified by the characteristic of the product but also by the development
team and development environment.

Software Engineering 3 MIT/CSE

17. Define organic.
It is organic If the project deals with developing a well understood application
program
The size of the development team is reasonably small
The team members are experienced in developing similar types of projects
18. Define semidetached.
It is semidetached if the developing team consists of mixture of experienced and
inexperienced staff
Team member may have limited experience on related systems but may be unfamiliar
with some aspects of the system being developed
19. Define embedded.
It is embedded if the software being developed is strongly coupled to complex
hardware
20. What are the three stages in COCOMO model?
Software cost estimation should be done through three stages:
Basic COCOMO Model
Intermediate COCOMO
Complete COCOMO.
21. Write the formulas for estimating the effort based on the code size.
Estimation of development effort
Organic: effort = 2.4(KLOC) 1.05 PM
Semidetached: effort = 3.0(KLOC)1.12 PM
Embedded: effort= 3.6(KLOC)1.20PM
22. Write the formula for estimating the development time based on the effort.
Estimation of development time
Organic: Tdev= 2.5(Effort)0.38 Months
Semidetached: Tdev=2.5(Effort)0.35 Months
Embedded: Tdev=2.5(Effort)0.32 Months
23. What are the Parameter of Intermediate COCOMO model.
1.product: it considered the complexity of the product, reliability requirements of the
products, etc.,
2.computer: it consider the execution speed, storage space required, etc.,
3.personnel: it consider the experience level of the person, programming capability,
analysis capability, etc.,
4.development environment: it consider the development facilities available to the
developers, sophistication of software development tools used for development(CASE).
24. What are the sub components of MIS ?
The subcomponents of the MIS project are,
Database part
Graphical user interface(GUI) part
Communication part

Software Engineering 4 MIT/CSE

25. What are the three increasingly detailed cost estimation models in COCOMO model 2?
COCOMO 2 model provides three increasingly detailed cost estimation models.these can
be used to estimate project costs at different phases of the software. Project progresses through
these models can be applied at the differen stages. They are,
1.application composition: used to estimate the cost of the prototyping eg: to
resolve user interface issues.
2.early design: this support estimation of cost at the architectural design stage
3.post architecture stage: this provides cost estimation during detailed design
and codeing stage.

26. Write about Norden’s Work.

where, E is the effort required at time t. E is an indication of the number of developers (or the
staffing level) at any particular time during the duration of the project, K is the area under the
curve, and td is the time at which the curve attains its maximum value.
27. Write about Putnam’s Work.

where the different terms are as follows:

• K is the total effort expended (in PM) in the product development and L is the product size in
KLOC.
• t d corresponds to the time of system and integration and testing. Therefore, t d can be
approximately considered as the time required developing the software.
• Ck is the state of technology constant and reflects constraints that impede the progress of the
programmer. Typical values of C k =2 for poor development C k =8 for good software
development environment Ck =11 for an excellent environment

Software Engineering 5 MIT/CSE

28. Write about Jensen’s Model.

where, Cte is the effective technology constant, td is the time to develop the software, and K is
the effort needed to develop the software.

29. Define scheduling.

The scheduling problem, in essence, consists of deciding which tasks would be taken up
when and by whom.

30. Write the tasks which project manager follows to schedule the project activities.
In order to schedule the project activities, a software project manager needs to do the
following:
1. Identify all the major activities that need to be carried out to complete the project.
2. Break down each activity into tasks.
3. Determine the dependency among different tasks.
4. Establish the estimates for the time durations necessary to complete the tasks.
5. Represent the information in the form of an activity network.
6. Determine task starting and ending dates from the information represented in the activity
network.
7. Determine the critical path. A critical path is a chain of tasks that determines the duration of
the project.

31. Define Work Breakdown Structure.

Tasks are the lowest level work activities in a WBS hierarchy. They also form the basic units of
work that are allocated to the developer and scheduled
The decomposition of the activities is carried out until any of the following is satisfied:
A leaf-level subactivity (a task) requires approximately two weeks to develop.
Hidden complexities are exposed, so that the job to be done is understood and can be
assigned as a unit of work to one of the developers.
Opportunities for reuse of existing software components is identified.

32. Define Activity Networks.

Activity on Node (AoN): In this representation, each activity is represented by a rectangular
(some use circular) node and the duration of the activity is shown alongside each task in the
node.
Activity on Edge (AoE): In this representation tasks are associated with the edges. The edges
are also annotated with the task duration. The nodes in the graph represent project milestones.

Software Engineering 6 MIT/CSE

33. Define Critical Path Method (CPM) and Minimum time (MT).
Critical Path Method (CPM)
A critical task is one with a zero slack time. A path from the start node to the finish node
containing only critical tasks is called a critical path.
Minimum time (MT): It is the minimum time required to complete the project. It is computed
by determining the maximum of all paths from start to finish.

34. Define Earliest start (ES) and Latest start time (LST).
Earliest start (ES): It is the time of a task is the maximum of all paths from the start to this task.
The ES for a task is the ES of the previous task plus the duration of the preceding task.
Latest start time (LST): It is the difference between MT and the maximum of all paths from
this task to the finish. The LST can be computed by subtracting the duration of the subsequent
task from the LST of the subsequent task.

35. Define Earliest finish time (EF), Latest finish (LF)and Slack time (ST).
Earliest finish time (EF): The EF for a task is the sum of the earliest start time of the task and
the duration of the task.
Latest finish (LF): LF indicates the latest time by which a task can finish without affecting the
final completion time of the project. A task completing beyond its LF would cause project delay.
LF of a task can be obtained by subtracting maximum of all paths from this task to finish from
MT.
Slack time (ST): The slack time (or float time) is the total time that a task may be delayed
before it will affect the end time of the project. The slack time indicates the ”flexibility” in
starting and completion of tasks. ST for a task is LS-ES and can equivalently be written as LF-
EF.
36. How to compute the ES, EF, LS, LF and ST?
The project parameters for different tasks for the MIS problem can be computed as follows:
1. Compute ES and EF for each task. Use the rule: ES is equal to the largest EF the immediate
predecessors
2. Compute LS and LF for each task. Use the rule: LF is equal to the smallest LS of the
immediate successors
3. Compute ST for each task. Use the rule: ST=LF-EF

37. What are the cases in PERT Charts?

Optimistic (O): The best possible case task completion time.

Most likely estimate (M): Most likely task completion time.
Worst case (W): The worst possible case task completion time.

38. Define Gantt chart.

A Gantt chart is a special type of bar chart where each bar represents an activity. The bars are
drawn along a time line. The length of each bar is proportional to the duration of time planned
for the corresponding activity.

Software Engineering 7 MIT/CSE

39. Define Functional format and Project format.

Functional format
In the functional format, the development staff are divided based on the specific functional group
to which they belong to.
Project format
set of developers is assigned to every project at the start of the project, and remain with the
project till the completion of the project.

40. Functional versus project formats.

The main advantages of a functional organisation are:
• Ease of staffing
• Production of good quality documents
• Job specialisation
• Efficient handling of the problems associated with manpower turnover

41. Define Matrix format.

A matrix organisation is intended to provide the advantages of both functional and project
structures. In a matrix organisation, the pool of functional specialists are assigned to different
projects as needed. Thus, the deployment of the different functional specialists in different
projects can be represented in a matrix

Software Engineering 8 MIT/CSE

42. Define Chief programmer team.
In this team organisation, a senior engineer provides the technical leadership and is
designated the chief programmer. The chief programmer partitions the task into many smaller
tasks and assigns them to the team members. He alsoverifies and integrates the products
developed by different team members.

43. Define Democratic team.

The democratic team structure, as the name implies, does not enforce any formal team
hierarchyTypically, a manager provides theadministrative leadership. At different timesdifferent
members of the group provide technical leadership.

44. Define Mixed control team organization.

The mixed control team organisation, as the name implies, draws upon the ideas from both the
democratic organisation and the chief-programmer organisation.

45. Define Staffing.

Software project managers usually take the responsibility of choosing their team.
Therefore, they need to identify good software developers for the success of the project. A
common misconception held by managers as evidenced in their staffing, planning and scheduling
practices, is the assumption that one software engineer is as productive as another.

Software Engineering 9 MIT/CSE

46. Who is a good software engineer?
Exposure to systematic techniques, i.e. familiarity with software engineering principles.
Good technical knowledge of the project areas (Domain knowledge)
Good programming abilities.
Good communication skills. These skills comprise of oral, written, and interpersonal
skills.
High motivation.
Sound knowledge of fundamentals of computer science
Intelligence.
Ability to work in a team.
Discipline, etc.
47. Define risk and types of Risk Management
A risk is any anticipated unfavourable event or circumstance that can occur while a project is
underway.
Risk Identification
 Project risks:
 Technical risks:
 Business risks:
Risk Assessment
Risk Mitigation
 Avoid the risk
 Transfer the risk
 Risk reduction

48. Define Risk Assessment.

The objective of risk assessment is to rank the risks in terms of their damage causing potential.
For risk assessment, first each risk should be rated in two ways:
The likelihood of a risk becoming real (r).
The consequence of the problems associated with that risk (s).

49. Define Risk Mitigation.

After all the identified risks of a project have been assessed, plans are made to contain the most
damaging and the most likely risks first. Different types of risks require different containment
procedures.
 Avoid the risk
 Transfer the risk
 Risk reduction

Software Engineering 10 MIT/CSE

50. What are the ways to gather requirements?
Requirements gathering is also popularly known as requirements elicitation.
 Studying existing documentation:
 Interview:
 Task analysis
 Scenario analysis
 Form analysis
 Requirements Analysis
51. What are the three main types of problems in the requirements?
During requirements analysis, the analyst needs to identify and resolve three main types of
problems in the requirements:
• Anomaly
• Inconsistency
• Incompleteness

52. Define Anomaly.

It is an anomaly is an ambiguity in a requirement. When a requirement is anomalous,
several interpretations of that requirement are possible. Any anomaly in any of the requirements
can lead to the development of an incorrect system, since an anomalous requirement can be
interpreted in the several ways during development.

53. Define Inconsistency.

Two requirements are said to be inconsistent, if one of the requirements contradicts the
other.

54. Define Incompleteness.

An incomplete set of requirements is one in which some requirements have been
overlooked. The lack of these features would be felt by the customer much later, possibly while
using the software. Often, incompleteness is caused by the inability of the customer to visualize
the system that is to be developed and to anticipate all the features that would be required. An
experienced analyst can detect most of these missing features and suggest them to the customer
for his consideration and approval for incorporation in the requirements.
55. Define Software Requirements Specification (SRS).
After the analyst has gathered all the required information regarding the software to be
developed, and has removed all incompleteness, inconsistencies, and anomalies from the
specification, he starts to systematically organise the requirements in the form of an SRS
document. The SRS document usually contains all the user requirements in a structured though
an informal form.
56. Write the Users of SRS Document.
Users, customers, and marketing personnel:
Software developers
Test engineers:
User documentation writers:
Project managers
Maintenance engineers

Software Engineering 11 MIT/CSE

57. Why Spend Time and Resource to Develop an SRS Document?
Forms an agreement between the customers and the developers:
Reduces future reworks:
Provides a basis for estimating costs and schedules:
Provides a baseline for validation and verification
Facilitates future extensions:
58. Write the Characteristics of a Good SRS Document.
Concise
Implementation-independent
Traceable
Modifiable
Identification of response to undesired events
Verifiable
59. Write the Attributes of Bad SRS Documents.
Over-specification
Forward references
Wishful thinking
Noise

60. What are the Important Categories of Customer Requirements?

An SRS document should clearly document the following aspects of software:

• Functional requirements
• Non-functional requirements
Design and implementation constraints
External interfaces required
Other non-functional requirements
Goals of implementation.
61. Define Functional requirements.
The functional requirements capture the functionalities required by the users from the
system.
It is useful to consider a software as offering a set of functions {fi} to the user.
These functions can be considered similar to a mathematical function f : I → O, meaning
that a function transforms an element (ii) in the input domain (I) to a value (oi) in the
output (O).
62. Define Non-functional requirements.
The non-functional requirements are non-negotiable obligations that must be supported
by the software.
The non-functional requirements capture those requirements of the customer that cannot
be expressed as functions (i.e., accepting input data and producing output data).
Non-functional requirements usually address aspects concerning external interfaces, user
interfaces, maintainability, portability, usability, maximum number of concurrent users, timing,
and throughput (transactions per second, etc.).

Software Engineering 12 MIT/CSE

63. Define Traceability.
Traceability means that it would be possible to identify (trace) the specific design component
which implements a given requirement, the code part that corresponds to a given design
component, and test cases that test a given requirement. Traceability analysis is an important
concept and is frequently used during software development
64. What are the Techniques for Representing Complex Logic?
There are two main techniques available to analyze and represent complex processing logic—
decision trees and decision tables.
 Decision tree
 Decision table

65. Define Decision tree.

A decision tree gives a graphic view of the processing logic involved in decision making
and the corresponding actions taken.
Decision tables specify which variables are to be tested, and based on this what actions
are to be taken depending upon the outcome of the decision making logic, and the order
in which decision making is performed.
The edges of a decision tree represent conditions and the leaf nodes represent the actions
to be performed depending on the outcome of testing the conditions.

66. Define Decision table.

A decision table shows the decision making logic and the corresponding actions taken in
a tabular or a matrix form.
The upper rows of the table specify the variables or conditions to be evaluated and the
lower rows specify the actions to be taken when an evaluation test is satisfied.
A column in the table is called a rule. A rule implies that if a certain condition
combination is true, then the corresponding action is executed.
The decision table for the

67. Decision table versus decision tree

Decision table decision tree

decision table causes the analyst to look at Decision trees are easier to read and
every possible combination of conditions understand when the number of conditions are
which he might otherwise omit. small.

decision tables can only represent a Single the decision trees, the order of decision making
decision to select the appropriate action for is abstracted out in decision tables. A situation
execution. where decision tree is more useful is when
multilevel decision making is required
When very large number of decisions is Decision trees become very complex to
involved, the decision table representation may understand when the number of conditions and
be preferred. actions increase. It may even be to draw the
tree on a single page.

Software Engineering 13 MIT/CSE

68. What is a Formal Technique?
A formal technique is a mathematical method to specify a hardware and/or software system,
verify whether a specification is realisable, verify that an implementation satisfies its
specification, prove properties of a system without necessarily running the system, etc. The
mathematical basis of a formal method is provided by its specification language.
69. Define Syntactic domains.
The syntactic domain of a formal specification language consists of an alphabet of symbols
and a set of formation rules to construct wellformed formulas from the alphabet. The well-
formed formulas are used to specify a system.
70. Define Semantic domains.
Formal techniques can have considerably different semantic domains. Abstract data type
specification languages are used to specify algebras, theories, and programs. Programming
languages are used to specify functions from input to output values. Concurrent and distributed
system specification languages are used to specify state sequences, event sequences, state-
transition sequences, synchronisation trees, partial orders, state machines, etc.
71. Define Satisfaction relation.
It is important to determine whether an element of the semantic domain satisfies the
specifications. This satisfaction is determined by using a homomorphism known as semantic
abstraction function.

72. Define Operational Semantics

The operational semantics of a formal method is the way computations are represented.
There are different types of operational semantics
 Linear semantics:
 Branching semantics:
 Maximally parallel semantics:
 Partial order semantics:
73. What are the Merits and limitations of formal methods?
 Formal specifications encourage rigour.
 Formal methods usually have a well-founded mathematical basis.
 Formal methods have well defined semantics
 Mathematical basis
74. How to develop an axiomatic specifications?
The following are the sequence of steps that can be followed to systematically develop the
axiomatic specifications of a function:
 Establish the range of input values over which the function should behave correctly.
Establish the constraints on the input parameters as a predicate.
 Specify a predicate defining the condition which must hold on the output of the function
if it behaved properly.
 Establish the changes made to the function’s input parameters after execution of the
function. Pure mathematical functions do not change their input and therefore this type
assertion is not necessary for pure functions.
 Combine all of the above into pre- and post-conditions of the function.

Software Engineering 14 MIT/CSE

75. What are the sections in An algebraic specification?
An algebraic specification is usually presented in four sections.
Types section:
Exception section:
Syntax section:
Equations section:
76. What are the operators in An algebraic specification?
 Basic construction operators
 Extra construction operators
 Basic inspection operators
 Extra inspection operators
77. Properties of algebraic specifications
 Completeness
 Finite termination property
 Unique termination property
78. Define Auxiliary Functions.
Sometimes while specifying a system, one needs to introduce extra functions not part of the
system to define the meaning of some interface procedures. These are called auxiliary functions
79. Define Software Configuration Management.
The configuration of the software is the state of all project deliverables at any point of time;
and software configuration management deals with effectively tracking and controlling the
configuration of a software during its life cycle.
80. What are the Necessity of Software Configuration Management?
 Problems associated with concurrent access
 Providing a stable development environment
 System accounting and maintaining status information
 Handling variants
81. What are the Configuration Management Activities?
Configuration identification
Configuration control

Software Engineering 15 MIT/CSE