UNIT I

1. Software Engineering (14 Marks)

Introduction:

Software Engineering is the systematic, disciplined, and quantifiable approach to the development,
operation, and maintenance of software. It applies engineering principles to software to ensure it is
reliable and works efficiently on real machines.

Main Body:

Definition and Purpose:

• Software Engineering focuses on creating software that is correct, reliable, maintainable, and
within budget.

• It addresses the challenges of software complexity, user requirements, deadlines, and cost
constraints.

Goals:

• High-quality software

• Cost-effectiveness

• Timely delivery

• Maintainability and scalability

Key Phases of Software Development Life Cycle (SDLC):

1. Requirement Analysis – Understand what the software must do.

2. System Design – Decide how the software will achieve its tasks.

3. Implementation – Write the actual code.

4. Testing – Identify and fix errors.

5. Deployment – Install the system for use.

6. Maintenance – Fix bugs, add features after deployment.

Characteristics of Good Software:

• Functionality

• Usability

• Efficiency

• Maintainability

• Portability

• Reliability
Types of Software:

• System Software: OS, Compilers

• Application Software: Word processors, Games

• Embedded Software: Firmware in devices

Conclusion:

Software engineering is essential for building large, reliable, and efficient systems. It helps minimize
cost, risk, and complexity while delivering value to users.

2. Time Management (14 Marks)

Introduction:

Time management in software engineering refers to the process of planning and exercising control
over the time spent on specific tasks, especially in projects that have deadlines and multiple
stakeholders.

Main Body:

Importance of Time Management:

• Ensures timely delivery

• Improves productivity

• Reduces stress and burnout

• Facilitates better planning and coordination

Key Principles:

• Set SMART Goals: Specific, Measurable, Achievable, Relevant, Time-bound

• Prioritization: Use tools like Eisenhower Matrix or MoSCoW method

• Time Estimation: Break down tasks, use historical data for predictions

Techniques for Time Management:

• Pomodoro Technique: 25 minutes focused work, 5 minutes break

• Time Blocking: Pre-allocating hours for specific tasks

• Task Lists and To-Dos: Use software like Trello, Todoist

• Avoiding Multitasking: Focused work improves efficiency

Common Challenges:

• Scope creep
 • Procrastination

• Poor estimation

• Interruptions

Conclusion:

Effective time management helps engineers meet deadlines, maintain work-life balance, and
consistently deliver high-quality software.

3. Tracking Time (14 Marks)

Introduction:

Time tracking is the process of monitoring how time is spent on activities. It provides visibility into
task durations, helping individuals and teams make informed decisions.

Main Body:

Purpose of Time Tracking:

• Understand effort distribution

• Improve estimates and planning

• Measure productivity and performance

• Provide accountability

Methods of Time Tracking:

1. Manual Logs: Written records or spreadsheets

2. Automated Tools: Toggl, Clockify, RescueTime

3. In-Built Tools in IDEs: Time monitoring plugins

4. Jira or Trello Logging: Agile tools with time-tracking features

Metrics to Track:

• Development time

• Review and testing time

• Rework time

• Interruptions and delays

Best Practices:

• Track in real time, not retrospectively

• Review weekly summaries

 • Use categories and tags for activities

Conclusion:

Tracking time leads to greater transparency and control in software projects. It enhances
accountability and helps with future planning and decision-making.

4. Period and Product Planning (14 Marks)

Introduction:

Planning is essential for structuring work and managing uncertainty. Period planning deals with
short-term tasks, while product planning focuses on overall product development lifecycle.

Main Body:

Period Planning:

• Focuses on week-to-week or sprint-based goals

• Helps identify blockers early

• Tools: Gantt charts, Kanban boards, burn-down charts

Product Planning:

• Involves long-term strategy and deliverables

• Includes roadmap creation, feature planning, and risk management

• Helps in aligning team goals with client expectations

Activities Involved:

• Requirement gathering

• Milestone setting

• Task allocation

• Time estimation

• Risk assessment and mitigation

Planning Techniques:

• Agile sprints for period planning

• Product backlog grooming for long-term planning

• PERT, CPM, and Gantt charts for scheduling

Conclusion:
Effective planning, both short-term and long-term, is key to handling software complexity and
delivering successful projects.

5. Product Size Estimation (14 Marks)

Introduction:

Estimating product size helps in forecasting effort, cost, and time. Size estimation allows teams to
make data-driven planning decisions.

Main Body:

Importance:

• Critical for budgeting

• Basis for effort and time estimation

• Affects staffing and resource planning

Methods of Estimation:

1. Lines of Code (LOC):

o Easy to calculate but varies by language and programmer

2. Function Points (FP):

o Counts inputs, outputs, files, interfaces, and inquiries

o Independent of language

3. Use Case Points (UCP):

o Based on system actors and use case complexity

o Common in modern systems

Example:

If a system has 30 FP and industry average is 10 hours/FP, then effort = 300 person-hours.

Challenges:

• Vague requirements

• Changing scope

• Developer productivity differences

Conclusion:

Estimating product size accurately is fundamental for successful software engineering projects. It
enables precise resource allocation and risk minimization.
 6. Managing Commitments (14 Marks)

Introduction:

Managing commitments involves ensuring that team members deliver tasks they agreed to do within
the specified timeline and quality expectations.

Main Body:

Why It Matters:

• Builds trust within the team and with stakeholders

• Keeps projects on schedule

• Helps in workload balancing

Commitment Management Practices:

• Clear Communication: Document everything agreed

• Task Clarity: Ensure everyone knows what is expected

• Buffer Planning: Allow time for unexpected delays

• Tracking Tools: Use Trello, Jira to visualize commitment status

Failure Handling:

• Encourage early reporting of delays

• Renegotiate scope or timeline

• Avoid blame culture—focus on solutions

Conclusion:

Managing commitments creates a culture of accountability. It improves team cohesion and project
reliability.

7. Managing Schedules (14 Marks)

Introduction:

Scheduling is the process of creating a timeline for the development process, ensuring tasks are done
in the right order and on time.

Main Body:

Purpose:
 • Avoids resource conflicts

• Prevents deadline slippage

• Aligns team efforts

Key Concepts:

• Milestones: Major checkpoints

• Dependencies: Task relationships

• Critical Path Method (CPM): Longest path through the project

• Slack Time: Time that a task can be delayed without affecting overall schedule

Scheduling Techniques:

• Gantt Charts: Visual task scheduling

• PERT Charts: Estimate task duration and sequence

• Agile Boards: Sprint-based planning

Best Practices:

• Include buffer time

• Monitor schedule regularly

• Use project management software

Conclusion:

Proper scheduling ensures that projects progress smoothly. It enhances predictability and reduces
last-minute pressure.

UNIT II

1. The Project Plan (14 Marks)

Introduction:

A project plan is a formal document that defines how a project is to be executed, monitored, and
controlled. It serves as a roadmap for project execution, aligning resources, timelines, and objectives.

Main Body:

Key Components of a Project Plan:

1. Project Scope – Defines boundaries and deliverables.

2. Objectives – Clearly stated outcomes.

3. Schedule – Timeline with milestones.

 4. Resources – Human, financial, and technical assets.

5. Risk Management Plan – Identifies risks and mitigation strategies.

6. Quality Management Plan – Sets quality standards.

7. Communication Plan – Describes how information is shared.

Importance of a Project Plan:

• Clarifies goals and direction.

• Minimizes risks and resource wastage.

• Helps track progress and manage change.

Tools for Project Planning:

• Gantt Charts

• Work Breakdown Structures (WBS)

• PERT and CPM diagrams

Conclusion:

A well-crafted project plan ensures structured execution, improves team coordination, and increases
the probability of project success.

2. The Software Development Process (14 Marks)

Introduction:

The software development process is a structured sequence of stages in software engineering to

develop the intended software product. It ensures systematic development.

Main Body:

Common Software Development Models:

1. Waterfall Model – Linear, sequential phases.

2. Agile Model – Iterative and incremental.

3. Spiral Model – Combines iterative development with risk analysis.

4. V-Model – Extension of waterfall with a testing focus.

5. RAD Model – Rapid development through prototyping.

Typical Phases:

1. Requirement Analysis

2. Design
 3. Coding

4. Testing

5. Deployment

6. Maintenance

Selection Criteria:

• Project size and complexity

• Client requirements

• Risk level and flexibility needed

Conclusion:

Choosing the right development process is key to successful delivery. It defines how tasks are
structured, assigned, and executed.

3. Defects (14 Marks)

Introduction:

A defect in software is an imperfection that causes a deviation from the expected behavior. It can
arise in any stage of development.

Main Body:

Types of Defects:

1. Syntax Defects – Language rules violated.

2. Logic Defects – Incorrect logic or algorithms.

3. Design Defects – Architectural flaws.

4. Interface Defects – Mismatches between modules.

5. Performance Defects – Efficiency issues.

Sources of Defects:

• Misunderstood requirements

• Design errors

• Coding mistakes

• Inadequate testing

Impact of Defects:

• Rework cost
 • Project delay

• Poor user satisfaction

• Reputation loss

Conclusion:

Understanding defects is vital to quality assurance. Early detection and prevention save time and
cost.

4. Finding Defects (14 Marks)

Introduction:

Defect detection is essential to ensure the quality and reliability of the software. Various techniques
are used across development stages to identify errors early.

Main Body:

Defect Detection Methods:

1. Static Techniques:

o Code Reviews

o Walkthroughs

o Inspections

2. Dynamic Techniques:

o Unit Testing

o Integration Testing

o System Testing

Automated Tools:

• SonarQube

• Selenium

• JUnit/TestNG

Best Practices:

• Conduct reviews regularly

• Use version control and CI/CD pipelines

• Maintain detailed test cases

Conclusion:

Finding defects early reduces costs and improves software quality. Both manual and automated
techniques play a role.

5. The Code Review Checklist (14 Marks)

Introduction:

A code review checklist is a structured list used during peer reviews to evaluate source code for
quality and correctness.

Main Body:

Checklist Categories:

1. Functionality:

o Does the code meet requirements?

2. Readability:

o Is the code clean, well-indented, and documented?

3. Maintainability:

o Is it modular and reusable?

4. Security:

o Are there vulnerabilities?

5. Error Handling:

o Are exceptions properly handled?

Benefits:

• Reduces defects

• Ensures adherence to standards

• Encourages knowledge sharing

Sample Checklist Items:

• Are variable names meaningful?

• Are loops and conditions optimal?

• Are functions small and single-purpose?

Conclusion:
A code review checklist ensures consistency and quality across a codebase, reducing bugs and
increasing maintainability.

6. Design Defects (14 Marks)

Introduction:

Design defects are issues in the software’s architecture or structure that cause performance
degradation, functionality issues, or maintenance challenges.

Main Body:

Types of Design Defects:

1. Poor Modularity: Tight coupling between modules

2. Low Cohesion: Unrelated responsibilities in a module

3. Violation of Design Principles: Like SRP, OCP in OOP

4. Improper Abstraction: Overuse or underuse of abstraction

Causes:

• Lack of experience

• Inadequate requirement analysis

• Rushed deadlines

Impacts:

• Difficult maintenance

• Increased bugs

• Scalability issues

Conclusion:

Identifying and resolving design defects early helps in building flexible and robust systems that can
evolve with changing needs.

7. Product Quality vs. Process Quality (14 Marks)

Introduction:

Product quality refers to the attributes of the software itself, while process quality relates to how the
software was built. Both are crucial for overall software excellence.
Main Body:

Product Quality Attributes:

• Functionality

• Reliability

• Efficiency

• Usability

• Maintainability

Process Quality Attributes:

• Adherence to standards

• Process maturity (e.g., CMMI)

• Consistency

• Repeatability

Relationship Between the Two:

• A good process usually leads to a good product.

• A flawed process may occasionally yield a good product but is not sustainable.

Tools and Standards:

• ISO 9001 (Quality management)

• Six Sigma (Process improvement)

• Capability Maturity Model Integration (CMMI)

Conclusion:

High product quality is achievable through robust process quality. Emphasizing both ensures
sustainable success in software engineering.

UNIT III

1. Team Software Process (TSP) Overview (14 Marks)

Introduction:

The Team Software Process (TSP) is a framework developed by the Software Engineering Institute
(SEI) to help software engineering teams improve their performance. TSP guides teams in producing
high-quality software on schedule and within budget.

Main Body:
Objectives of TSP:

• Enhance team performance.

• Improve product quality.

• Promote personal responsibility.

• Manage time and resources efficiently.

Principles of TSP:

1. Planning by Engineers: Engineers plan their work.

2. Data-driven Management: Progress tracked using actual data.

3. Team Self-Management: Teams take ownership.

4. Quality Focus: Early detection and prevention of defects.

TSP Lifecycle:

1. Launch – Team forms and plans are created.

2. Execution – Work is performed as per the plan.

3. Monitoring – Progress and quality are continuously tracked.

4. Postmortem – Performance is evaluated and lessons are learned.

Benefits of TSP:

• Reduces defects by up to 90%.

• Improves project tracking and visibility.

• Encourages team collaboration and morale.

Conclusion:

TSP is an effective approach to disciplined software development. It emphasizes team ownership,

planning, and quality, ensuring reliable software delivery.

2. Logic of the Team Software Process (14 Marks)

Introduction:

The logic of TSP is grounded in the idea that disciplined teams, when given responsibility and the
right tools, can produce superior software. It provides structure, accountability, and process control.

Main Body:

Core Logic Principles:

1. Goal Setting: Teams define measurable goals.

 2. Defined Roles: Each team member takes specific roles (e.g., team leader, quality manager).

3. Detailed Planning: Plans are created collaboratively with clear task distribution.

4. Metrics Usage: Data is collected continuously to guide decisions.

5. Incremental Improvement: Teams learn from data and improve practices.

Human-centric Logic:

• Empowers developers.

• Fosters motivation through ownership.

• Encourages honest reporting and tracking.

Logical Flow of TSP:

1. Form team and assign roles

2. Set team goals

3. Build personal and team plans

4. Track progress using data

5. Analyze and adjust plans

6. Conduct postmortems for continuous learning

Conclusion:

The logic of TSP revolves around self-managed teams, data-driven decisions, and consistent
feedback, making it highly effective in real-world software development scenarios.

3. Launching a Team Project (14 Marks)

Introduction:

Launching a team project in TSP is the initial and critical phase where the foundation for successful
execution is laid. It sets the tone, structure, and direction for the entire project lifecycle.

Main Body:

Steps to Launch a TSP Project:

1. Forming the Team:

o Assign specific roles: team leader, planning manager, etc.

o Establish communication and collaboration protocols.

2. Project Planning:

o Define goals (quality, schedule, cost).

 o Create personal and team plans.

o Use estimation techniques (PROBE, size-based estimation).

3. Goal Alignment:

o Ensure team and individual goals are in sync with project objectives.

o Create shared vision and commitment.

4. Training:

o Educate the team on TSP principles and tools.

5. Launch Meeting:

o A formal session led by a coach to kick-start the project.

o Activities include plan reviews, role explanations, and scheduling.

Conclusion:

Launching a TSP project ensures that the team starts with clarity, direction, and motivation. It builds
a strong foundation for success through preparation and mutual understanding.

4. The Development Strategy (14 Marks)

Introduction:

The development strategy in TSP defines how the software will be designed, developed, tested, and
delivered. It aligns the team’s work with the project’s technical and business goals.

Main Body:

Key Elements of Development Strategy:

1. Defining Product Scope:

o Understanding features, modules, and customer needs.

2. Selecting the Development Model:

o Waterfall, Agile, or Hybrid depending on project needs.

3. Setting Milestones:

o Breaking down work into iterations or phases.

4. Resource Allocation:

o Assigning work based on expertise and availability.

5. Quality Assurance Plan:

o Defect prevention, code reviews, and testing strategies.

 6. Risk Management:

o Identifying risks and preparing mitigation plans.

Integration with TSP:

• Every strategic decision is data-informed.

• Plans are reviewed and revised based on metrics.

Conclusion:

A solid development strategy aligns technical decisions with organizational goals, minimizes risks,
and ensures efficient use of time and resources.

5. The Development Plan (14 Marks)

Introduction:

The development plan in TSP is a detailed guide that outlines the tasks, timelines, resources, and
processes required to achieve the project’s objectives. It is both a planning and execution tool.

Main Body:

Components of a Development Plan:

1. Work Breakdown Structure (WBS):

o Breaks the project into manageable tasks.

2. Task Estimation:

o Uses historical data and PROBE methods to predict effort.

3. Scheduling:

o Timelines for each task and milestone.

4. Resource Management:

o Assignment of team members and hardware/software needs.

5. Quality Assurance:

o Review checkpoints and defect tracking.

6. Risk Management Plan:

o Identification and handling of potential risks.

Use in TSP:

• Individual and team plans are merged.

• Continuously updated based on actual performance data.

 • Facilitates accountability and transparency.

Conclusion:

A well-prepared development plan guides the team in managing complexity and delivering software
that meets time, cost, and quality expectations.

6. Defining the Requirements (14 Marks)

Introduction:

Requirement definition is the process of documenting what the software system must do. In TSP, it’s
a collaborative activity that ensures clarity and shared understanding among stakeholders.

Main Body:

Types of Requirements:

1. Functional Requirements:

o Describe system behaviors, features, and actions.

2. Non-functional Requirements:

o Define system quality attributes like performance, scalability, and security.

Steps in Defining Requirements:

1. Stakeholder Interviews

2. Use Case Development

3. Prototyping

4. Requirement Workshops

5. Documentation and Validation

Tools Used:

• Requirement management tools (e.g., JIRA, IBM DOORS)

• Flowcharts and UML diagrams

TSP Emphasis:

• Requirements are baselined before development starts.

• Every change is documented, assessed, and communicated.

• Frequent customer feedback loops to reduce misunderstanding.

Conclusion:
Clearly defined and well-managed requirements reduce rework and confusion. In TSP, this step lays
the groundwork for a successful, goal-oriented development effort.

UNIT IV

1. Designing with Teams (14 Marks)

Introduction:

Designing with teams is a collaborative process in software engineering where team members work
together to define the architecture and structure of a software product. In the context of TSP, it
emphasizes collective decision-making and shared ownership of the system’s design.

Main Body:

Objectives of Team-Based Design:

• Achieve a well-thought-out, scalable architecture.

• Leverage diverse skills and expertise.

• Encourage mutual understanding and consistency.

Key Activities:

1. Requirement Review:

o Ensures that the entire team understands what needs to be built.

2. Design Planning:

o Teams divide the system into subsystems and assign design tasks.

3. Team Brainstorming Sessions:

o Encourage innovation and identify design alternatives.

4. Architecture Definition:

o Establish the overall system structure (client-server, layered, etc.).

5. Interface Design:

o Define how components/modules communicate.

6. Design Reviews and Walkthroughs:

o Peer feedback and validation against requirements.

Benefits in TSP:

• Shared understanding leads to fewer defects.

• Improves maintainability and adaptability.

• Reduces development risks through early error detection.

Conclusion:

Designing with teams fosters collaboration, innovation, and alignment, ultimately leading to better
quality and higher productivity in software development.

2. Product Implementation (14 Marks)

Introduction:

Product implementation is the phase where design is converted into actual working code. In TSP, this
is done in a disciplined manner with a strong focus on individual accountability, peer reviews, and
quality metrics.

Main Body:

Steps in Product Implementation:

1. Code Development:

o Writing clean, modular, and reusable code based on the design.

2. Code Reviews:

o Conducted using checklists to detect defects early.

3. Unit Testing:

o Developers write and run tests for their own code to verify functionality.

4. Defect Logging and Analysis:

o All defects are recorded and categorized for future improvement.

Key Practices in TSP Implementation:

• Developers plan their own tasks and schedules.

• Daily logs are maintained for tracking time and defects.

• Implementation is tracked against the baseline plan.

Tools Involved:

• Version Control Systems (Git)

• IDEs with debugging tools

• Testing frameworks (JUnit, PyTest)

Conclusion:
Product implementation in TSP is not just about coding; it’s about disciplined engineering. It
combines planning, review, and quality tracking to ensure reliable and efficient software
development.

3. Integration & System Testing (14 Marks)

Introduction:

Integration and system testing are critical stages in software development that ensure individual
components work together as a whole and that the software system meets all specified
requirements.

Main Body:

Integration Testing:

• Combines modules and tests their interaction.

• Types: Top-down, bottom-up, sandwich, and big bang integration.

System Testing:

• Verifies the complete system functionality in an environment that simulates production.

Activities in TSP:

1. Test Planning:

o Team defines testing strategies and prepares test cases.

2. Test Execution:

o Integration issues, data flow, and end-to-end processes are tested.

3. Bug Tracking:

o Issues found during testing are logged, analyzed, and resolved.

4. Regression Testing:

o Ensures that new code doesn’t break existing functionality.

Tools Used:

• Selenium, JUnit, TestNG, Postman, JIRA

Importance in TSP:

• Early detection of integration bugs.

• Increases system reliability and user confidence.

• Provides closure before release.

Conclusion:

Systematic integration and system testing confirm that software functions correctly as a unified
product. TSP encourages rigorous testing to deliver high-quality outcomes.

4. The Postmortem (14 Marks)

Introduction:

The postmortem phase in TSP is a reflective activity conducted after project completion. It helps
teams understand what worked well, what didn’t, and how they can improve in future projects.

Main Body:

Purpose of Postmortem:

• Evaluate project performance.

• Learn from mistakes.

• Identify process improvement opportunities.

Steps Involved:

1. Data Collection:

o Gather time logs, defect logs, quality metrics, schedule adherence, etc.

2. Analysis:

o Compare planned vs. actual performance.

o Use Pareto charts and trend analysis.

3. Root Cause Identification:

o Understand why deviations occurred.

4. Team Discussion:

o Reflect on individual and team performance in a safe and open environment.

5. Actionable Recommendations:

o Document lessons learned and propose improvements.

Benefits:

• Prevents recurrence of issues.

• Reinforces good practices.

• Enhances team communication and morale.

Conclusion:
Postmortem is essential for continuous improvement. It allows teams to evolve by reflecting on their
practices and outcomes, making TSP a powerful learning and development model.

UNIT V

1. The Team Leader Role (14 Marks)

Introduction:

The Team Leader is a key figure in the software project who is responsible for facilitating
collaboration, ensuring alignment with goals, and maintaining motivation. In TSP (Team Software
Process), the team leader acts more as a coach and coordinator than a commander.

Main Body:

Responsibilities:

1. Goal Setting and Planning:

o Helps the team define goals and develop a plan to achieve them.

2. Communication:

o Serves as the communication bridge between team members and stakeholders.

3. Conflict Resolution:

o Resolves interpersonal or technical disputes that may hinder progress.

4. Facilitation:

o Ensures effective meetings, reviews, and planning sessions.

5. Progress Monitoring:

o Tracks team progress using metrics and ensures tasks are on schedule.

6. Motivation and Morale:

o Keeps the team motivated and engaged throughout the development process.

Key Traits:

• Leadership by example

• Active listening

• Emotional intelligence

• Decision-making ability

In TSP Context:

• The team selects its own leader.

• The leader supports and coordinates but does not dictate.

Conclusion:

The team leader plays a critical role in aligning team efforts, solving problems, and promoting a
healthy working environment. Their role is pivotal to the success of the team-based software
development approach in TSP.

2. Development Manager Role (14 Marks)

Introduction:

The Development Manager is responsible for overseeing the technical execution of the software
project. This role ensures that the development activities align with the project’s requirements and
deadlines.

Main Body:

Responsibilities:

1. Technical Task Allocation:

o Assigns technical tasks to team members based on expertise.

2. Tracking Progress:

o Monitors the completion of development milestones and ensures quality.

3. Managing Dependencies:

o Identifies and resolves technical interdependencies and bottlenecks.

4. Code and Integration Oversight:

o Ensures consistency in coding standards and oversees system integration.

5. Support for Developers:

o Helps solve technical issues and provides guidance where needed.

Key Contributions:

• Ensures technical quality

• Reduces risk by identifying issues early

• Helps in accurate time and size estimation of tasks

In TSP:

• Supports disciplined engineering and enforces review practices.

• Monitors defect rates and rework trends.

Conclusion:

The Development Manager ensures technical integrity and quality across all development tasks. In
TSP, this role enhances the team’s ability to deliver a reliable and maintainable product.

3. The Planning Manager Role (14 Marks)

Introduction:

The Planning Manager is responsible for scheduling, resource planning, and risk management in a
software development project. They maintain the master plan and help guide the team toward
timely project completion.

Main Body:

Responsibilities:

1. Creating the Project Plan:

o Collaborates with the team to develop a detailed schedule and task breakdown.

2. Time and Resource Allocation:

o Assigns time and resources based on workload and priorities.

3. Risk Identification and Mitigation:

o Identifies potential risks and formulates contingency plans.

4. Progress Tracking:

o Uses earned value metrics to track if the team is ahead or behind schedule.

5. Coordination:

o Coordinates planning sessions and updates the plan as needed.

Importance in TSP:

• Helps avoid delays and overrun costs.

• Uses historical data from previous projects for better planning.

• Improves predictability and control of the software process.

Conclusion:

The Planning Manager ensures that software development proceeds as per plan. They anticipate
problems and guide the team with effective scheduling and risk management, a crucial role in any
TSP-driven team.

4. The Quality/Process Manager Role (14 Marks)

Introduction:

The Quality and Process Manager (QPM) ensures that the software meets predefined quality
standards and that the development process adheres to best practices and guidelines. This role is
essential for producing defect-free software.

Main Body:

Responsibilities:

1. Process Enforcement:

o Ensures the team follows the defined software development process.

2. Quality Metrics Tracking:

o Monitors defect rates, yield, productivity, and rework.

3. Conducting Reviews:

o Ensures code and document reviews are held and properly documented.

4. Defect Analysis:

o Analyzes root causes of defects and implements preventive actions.

5. Process Improvement:

o Suggests improvements to reduce defects and enhance efficiency.

Role in TSP:

• Uses checklists and statistical quality control.

• Collects and reports data for continuous improvement.

• Maintains the quality plan and reviews adherence.

Key Outcomes:

• Early defect detection

• Higher product reliability

• Reduced rework and cost

Conclusion:

The QPM is central to ensuring product and process quality. In TSP, this role empowers teams to
produce high-quality software through continuous monitoring and proactive improvement.

5. The Support Manager Role (14 Marks)

Introduction:
The Support Manager is responsible for all logistical, administrative, and tool-based aspects of
software development. They ensure that the team has everything it needs to work efficiently.

Main Body:

Responsibilities:

1. Tool Support:

o Sets up and maintains software tools (IDEs, version control, testing tools).

2. Environment Setup:

o Prepares the development and testing environments.

3. Document Management:

o Organizes and maintains team documentation and logs.

4. Training and Onboarding:

o Assists new members in understanding tools and processes.

5. Coordination with External Support:

o Acts as a liaison with IT, HR, or external vendors.

In TSP:

• Tracks tool usage effectiveness.

• Helps maintain the team’s time-tracking and defect-logging systems.

• Supports smooth day-to-day operations.

Value Addition:

• Reduces non-technical delays.

• Ensures operational continuity.

• Allows technical roles to focus on their core tasks.

Conclusion:

The Support Manager plays a behind-the-scenes but essential role in software development. By
handling tools and environment logistics, they free up developers to focus on coding and design,
making them vital to TSP success.