Q1. With a neat diagram explain management control.

 Management involves setting objectives for a system and monitoring its performance.
Local managers collect data, which might include basic details such as "location X has
processed 2000 documents."
 Data processing is required to transform raw data into useful information. This information
could include metrics like "percentage of records processed," "average documents per day
per person," and "estimated completion date."
 Project management examines information such as the "estimated completion date" for
completing data transfer at each branch. They compare actual performance with overall
project objectives.
 Management might find that one or two branches will fail to complete the transfer of details
in time.
 A project plan is dynamic and needs constant adjustment during execution. A good plan
provides a foundation for a successful project, but it requires intelligent execution to be
effective.
Q2. Explain the different phases of project management life cycle.

1. Project Initiation:
 Concept Development: Understand the project's scope, constraints, costs, and
benefits.
 Feasibility Study: Determine if the project is financially and technically feasible.
 Business Case: Develop and get top management's approval.
 Project Charter: Appoint a project manager and form the project team.

W5HH Principle Questions:

 Why is the software being built?
 What will be done?
 When will it be done?
 Who is responsible?
 Where are they located?
 How will it be done technically and managerially?
 How much of each resource is needed?

2. Project Bidding:
 Request for Quotation (RFQ): For known project scope and solutions.
 Request for Proposal (RFP): For understanding alternative solutions.
 Request for Information (RFI): To assess vendor competencies and shortlist
bidders.

3. Project Planning:
 Project Plan: Tasks, schedule, resources, and time frames.
 Resource Plan: Required manpower and equipment.
 Functional Plan: Manpower, equipment, and costs.
 Quality Plan: Quality targets and control plans.
 Risk Plan: Potential risks, prioritization, and mitigation actions.

4. Project Execution:
 Execute tasks as per the project plan.
 Ensure quality through proper processes.
  Complete deliverables and get customer acceptance.

5. Project Closure:
 Release deliverables to the customer.
 Release project resources and complete vendor agreements.
 Conduct a post-implementation review for lessons learned.
Q3. Explain the case study about the responsibilities addressed by Paul Duggan.
Case Study: Paul Duggan's Management Responsibilities.
Paul Duggan is the manager of a software development section. His day involves various
management activities, starting with a meeting at 10:00 am with fellow section heads and his group
manager to discuss staffing requirements for the coming year. Later, at 2:00 pm, Paul meets with
his senior staff to address an important project which gets impacted by a team member's road
accident. Throughout the day, Paul makes critical decisions to ensure the project stays on track.
Management Responsibilities:
1. Planning: Setting objectives and actions.
2. Organizing: Arranging tasks and resources.
3. Staffing: Recruiting and training employees.
4. Directing: Leading and communicating.
5. Controlling: Monitoring performance.
6. Coordinating: Ensuring teamwork.
7. Reporting: Informing stakeholders.
8. Budgeting: Managing financial resources.

Let's analyze Paul's day:

1. Drafting the document ‘bidding’ for staff:
 Planning: Paul is planning the staffing needs for the next year based on the upcoming
work for his section.
2. 10:00 am meeting with fellow section heads and group manager:
 Coordinating: Paul is coordinating with other section heads and the group manager
to ensure that the staffing requirements align with the overall needs of the
organization.
 Reporting: He is discussing and providing information about his staffing plan.
3. 2:00 pm meeting with senior staff about an important project:
  Directing: Paul is leading and discussing how to manage the project, especially in light
of the recent accident.
 Controlling: He is ensuring the project stays on schedule despite the unforeseen
incident.
4. Deciding on transferring another team member:
 Organizing: Paul is organizing his team's workload to keep the important project on
track by reallocating resources.
 Staffing: This also involves staffing decisions, as he needs to bring in a temporary
replacement.
5. Phoning the personnel manager about getting a replacement:
 Staffing: Paul is working on staffing by arranging for a temporary replacement.
6. Phoning the user about the delay in less urgent work:
 Reporting: He is informing the user about the situation and the expected delays.

In summary:
• Planning: Drafting the document ‘bidding’ for staff.
• Coordinating: 10:00 am meeting with section heads and group manager.
• Reporting: 10:00 am meeting and phoning the user about delays.
• Directing: 2:00 pm meeting with senior staff.
• Controlling: 2:00 pm meeting with senior staff.
• Organizing: Deciding on transferring a team member.
• Staffing: Phoning the personnel manager and deciding on a temporary replacement.
Q4. Explain the place of software quality on project planning.
Quality will be of concern at all stages of project planning and execution. But will be of particular
interest at the following points in the step wise framework

1. Identify Project Scope and objective: Some objective could relate to the qualities of the
application to be delivered.
2. Identify project infrastructure: Identify the installation standard and procedures. Some of
these almost certainly be about quality
3. Analyze project characteristics: To identify the other qualities based requirement.
4. Identify the products and activities of the project: It is at this point the entry, exist and
process requirement are identified for each activity
5. Review and publicize Plan: At his stage the overall quality aspects of the project plan are
reviewed
Q5. Product vs Process Quality management.
Product Quality Management
Focus: Evaluating and ensuring the quality of the software product itself.
Key Aspects:
1. Measurement Focus: Metrics for the final product, such as:
 Size (Lines of Code, Function Points)
 Reliability (Defects per LOC)
 Performance (Response Time)
 Usability (User Satisfaction)
2. Evaluation Timing:
 Metrics are measured after the software is developed or at key milestones.
3. Benefits:
 Provides clear benchmarks for success.
 Facilitates comparisons with requirements and standards.
 Identifies improvement areas for future projects.
4. Challenges:
 Predicting final quality from early stages is difficult.
 Metrics may not fully capture the product's complexity.
Process Quality Management
Focus: Assessing and improving the quality of the development processes.
Key Aspects:
1. Measurement Focus: Metrics for development processes, such as:
 Defect detection rates
 Rework effort
 Productivity (e.g., LOC per hour)
 Adherence to standards
2. Evaluation Timing:
 Metrics are monitored continuously throughout the development lifecycle.
3. Benefits:
 Identifies and corrects errors early, reducing rework costs.
 Facilitates continuous improvement of development practices.
  Provides insights into the effectiveness of methodologies.
4. Challenges:
 Requires consistent monitoring and analysis.
 Process improvements may not directly translate into improved product quality without
careful management.

Q6. Cost estimation of cocomo model by boehm.

COCOMO - stands for Constructive Cost Model. It is used to estimate the cost of the project.
Using this model, we can estimate the time (months) & no. of people (members) needed to develop
a project.
According to Boehm, project cost estimation should be done through three stages:
1. Basic COCOMO
2. Intermediate COCOMO
3. Complete COCOMO
1. Basic COCOMO
It predicts the effort & cost of the project. It gives an approximate formula to estimate the cost:
Effort = a1 * (KLOC)^b1 PM (Person Months)
Time = b1 * (effort)^b2 months
2. Intermediate COCOMO
It uses 15 additional predictors (considering the environment) to estimate a more accurate value
of cost.
3. Complete COCOMO:
It is an extensive phase-sensitive model.
It is used to estimate the effort needed to complete every phase:
1. Planning & requirements
2. System design
3. Detailed design
4. Module code & test
5. Integration
Q7. Define testing. Explain V-process model.

Testing in software development is the process of evaluating a software application or system to

ensure that it meets specified requirements and functions correctly. It involves executing the
software to identify defects, verify that it performs as expected, and validate that it fulfills the
user’s needs.
V-Model
The V-Model is a development process that emphasizes matching validation activities with each
development phase. It expands on the traditional waterfall model by adding detailed testing phases.
Development Phases: The left side of the V-Model includes stages like Requirements Analysis,
Design, and Coding.
Testing Phases: The right side of the V-Model mirrors these stages with corresponding testing
activities like Unit Testing, Integration Testing, and System Testing.
Verification vs. Validation
Verification:
Definition: Ensures that each phase of development meets its previous phase's requirements.
When: Performed throughout development.
Example: Checking if design documents align with initial requirements.
Validation:
 Definition: Ensures that the final product meets the overall requirements.
When: Conducted after the product is fully developed.
Example: Testing the final software to ensure it meets customer needs.
Verification checks if each development phase is done correctly.
Validation checks if the final product meets customer requirements.
In the V-Model:
Verification activities are present throughout the development phases (left side of the V).
Validation activities are conducted towards the end (right side of the V), with system testing being
a key example.

Q8. Define Software reliability metrics.

Software reliability metrics are quantitative measures used to assess and predict the reliability of
software systems. These metrics help in understanding how likely a software system is to function
without failure over a specified period under given conditions.
Q9. Explain PSP(Personal software process)
The Personal Software Process (PSP), developed by Watts Humphrey, is a framework for
individual engineers to measure and improve their work. PSP helps in developing personal skills
through estimating, planning, and tracking performance. Here's a simplified overview:
Key Components of PSP
1. Time Management: Developers should track the time spent on tasks using a stopwatch. This
includes time spent on designing, coding, and testing to get an accurate picture of their work.
2. PSP Planning: Developers must plan their projects by estimating the maximum, minimum,
and average Lines of Code (LOC) needed.
Plans are recorded in a project plan summary.

3. Process Tracking:
 Developers plan their activities and make basic plans before starting development.
 During each phase of software development, they record log data using time
measurements.
 Post-implementation, developers compare the log data with the initial plan to improve
future planning and processes.
PSP Maturity Levels
PSP includes four maturity levels, each with specific activities to improve personal processes and
achieve higher levels of efficiency and effectiveness.
By following these steps, developers can continuously improve their personal software process,
leading to better time management and project outcomes.
Q10. What are the general principles behind Fagan method?
 Inspections are carried out on all major deliverables.
 All types of defects are noted.
 Inspection can be carried out by colleagues at all levels except the very top.
 Inspection can be carried using a predefined set of steps.
 Inspection meeting do not last for more than two hours.
 The inspection is led by a moderator who has had specific training in the techniques.
 The participants have define rules.
 Checklist are used to assist the fault-finding process.
 Material is inspected at an optimal rate of about 100 lines an hour.
 Statistics are maintained so that the effectiveness of the inspection process can be
monitored.
Q11. Key process areas of CMMI
Key Process Areas (KPAs)

KPAs are crucial components of the Capability Maturity Model Integration (CMMI). They represent
groups of related activities that help improve an organization's process capabilities. Here's a simplified
explanation:

Definition:

KPAs in CMMI: Each maturity level in CMMI has a set of KPAs. These KPAs are clusters of activities that,
when done together, achieve important goals for process improvement.

Key Features:

1. Gradual Improvement:
 KPAs help organizations improve their processes step-by-step as they move up in maturity levels.

2. Integration Across Domains:

CMMI uses general terms that apply to different fields, unlike specific CMMs that are tailored form
particular disciplines.

Benefits of CMMI:

1. Broad Applicability:

CMMI can be used not just in software development but in various other industries and fields.

2. Consistency and Integration:

It provides a unified framework that reduces redundancy and promotes consistent practices across an
organization.

3. Continuous Improvement:

CMMI encourages ongoing assessment and refinement of processes to achieve higher maturity and
better performance.

Q12. TickIT Standardization responsibilities

TickIT is a quality-management certification program for software development and IT services, aimed at
ensuring compliance with ISO 9001 standards. The responsibilities related to TickIT standardization
include several key areas.

1. First, TickIT is responsible for developing and maintaining standards for software quality and IT
service management based on ISO 9001. This involves establishing guidelines and criteria that
organizations must follow to achieve certification.
2. Second, TickIT manages the certification process to ensure organizations comply with its
requirements. This includes conducting audits and assessments to verify compliance and
awarding certification to those who meet the standards.
 3. Third, TickIT provides training and support for auditors and organizations on its standards and
processes. This includes offering guidance to organizations seeking certification and ensuring
auditors are well-equipped to perform their assessments accurately.
4. Fourth, TickIT is committed to continuous improvement. It regularly updates its standards and
guidelines to reflect best practices and technological advancements, encouraging organizations
to continually enhance their quality management systems.
5. Fifth, TickIT maintains comprehensive documentation of its standards, processes, and
certification criteria. It also reports on the certification statuses and compliance levels of
organizations, ensuring transparency and accountability.
6. Sixth, TickIT engages with stakeholders, including industry experts and regulatory bodies, to
ensure its standards remain relevant and effective. It facilitates communication between certified
organizations and auditors, fostering a collaborative environment.
7. Lastly, TickIT ensures the integrity and consistency of the certification process through rigorous
quality assurance measures. It monitors and addresses any non-compliance issues or deviations
from standards, maintaining high levels of reliability and trust in its certification program.

By fulfilling these responsibilities, TickIT aims to enhance the quality and reliability of software
development and IT services across certified organizations.