PART B

2. Conducting brainstorming sessions with the project team and arriving at

consensus figures for effort estimates”. Recognize the Statement belongs to
the technique (Answer : Wide band Delphi technique)
Wide Band Delphi technique :
1. Project team meets for several sessions to discuss and refine effort estimates.
2. Team members anonymously provide initial estimates for their assigned tasks.
3. Estimates are discussed and adjusted to remove inconsistencies.
4. A formula combines pessimistic, most likely, and optimistic estimates into a final effort
estimate.

5. Works well for projects with a manageable team size.

6. Most effective when team members have prior experience working together.

4. If you are encounter changes in customer requirements, technical

dependencies, resource constraints, market competition, or regulatory
compliance. What type of risks this scenario belongs to?
Scope Creep :

1. Scope creep is a common and severe risk in software projects.

2. Requirements changes happen even after testing and during implementation.
3. A good change management mechanism is necessary to address scope creep effectively.

Technical Risks :

1. New technology can make your project's chosen tech outdated, rendering the software useless
even before it's finished.
2. If your software relies on specific hardware, that hardware becoming obsolete can make your
software unusable too.
3. To avoid these problems, choose technology carefully - pick languages, hardware, and user
access methods that will likely be around for a while.
4. Also, make sure the vendors you choose will keep supporting the tools you use in the future.

Resource risks :

Losing Team Members: Software professionals are in high demand and can leave projects for better
offers. This can disrupt the project and leave unfinished tasks behind.

Mitigating Strategy 1: Resource Pipeline: Maintain a list of potential replacements to quickly fill
vacancies.
Mitigating Strategy 2: Knowledge Management: Implement a system to capture project knowledge
and completed work so it's not lost if a team member leaves.

Business Risks :
Market Shifts: Changes in competition or market trends can affect the project's value or
purpose. The software may need adjustments to stay relevant.
Regulation Changes: New regulations might force modifications to the software's features
to comply with the law.
Project Impact: Both market shifts and regulation changes can impact the project's viability,
potentially requiring adjustments or even cancellation.

5.If the Project to be completed with one year but it extended to two years.
Illustrate the type of risks suits this scenario.
Schedule Risks :
Deadlines Matter : Businesses lose opportunities if projects are late. Hitting target release
dates is key.
What Causes Delays : Unexpected bugs or unclear requirements can slow things down and
push back deadlines.
Delays Hurt Everyone: If a project runs late, it can hurt both the business and the customer.
Scope creep , Technical risks , Resource Risks same as previous answer.

7. Explain how you will identify the major risks and identify the strategies for
minimizing each of those risks.
Causes of Risks in Software Projects
Quality Constraints: High-quality software is crucial to avoid expensive support costs.
Resource Unavailability: Difficulty finding and retaining skilled software professionals.
Disinterest: Lack of motivation among team members can impact productivity.
Attrition: High demand for software professionals can lead to project team members leaving
for better opportunities.
Scope Creep: Changing or expanding requirements can significantly impact project timelines
and budgets.
Cost Constraints: Unexpected budget limitations can halt project progress.
Bad Negotiation: Poor negotiation skills can hinder efforts to secure additional resources or
budget when needed.
Unrealistic Estimates: Inaccurate project effort estimates can lead to schedule delays or
resource shortages.
Human Error: Mistakes during requirements gathering, design, or development can
introduce defects into the software.
Poor Management: Lack of experience or inadequate leadership skills in a project manager
can negatively impact project outcomes.

Budget Risks :
Budget Tracking & Control: Monitor project expenses to identify and address cost overruns
early.
Budget Reserves: Include buffer funds in the project budget to handle unforeseen cost
increases.
Schedule risks :
Schedule Risks: Unforeseen circumstances like rework or miscommunication can cause
project delays.
Schedule Buffers: Allocate buffer time in the project schedule to accommodate potential
delays.
Resource risks :
Resource Loss: Project delays can occur if team members leave the project mid-way, taking
their knowledge with them.
Mitigation Strategies: Maintain a talent pool for replacements and implement a knowledge
management system to capture project knowledge.
Quality Risks (2 points):
Defects and Errors: Poor design, construction, complexity, or frequent requirement changes
can lead to software defects impacting quality.
Quality Management: Integrating quality checks throughout the development process
(planning, reviews) is crucial for mitigating quality risks.
Technology Risks (2 points):
Technology Obsolescence: Rapidly evolving technologies can make chosen technologies
outdated, rendering the software unusable.
Technology Selection: Careful selection of programming languages, platforms, and tools
with long-term support is essential to minimize technology risks.

9.To track the project execution against the plan”. Which Project Process
explains this statement? (Answer: Project Monitoring)
Project monitoring involves tracking progress against the plan (schedule and budget) at key
points to identify deviations and ensure the project stays on track.
Monitor against project plan :

 Monitoring a project involves comparing its progress against the original plan (schedule
and budget) at key milestones.
 This helps identify any deviations and allows the project manager to take corrective
actions to get the project back on track.
Measure Task Progress and Status Reports :

 Consider Both Planned and Actual Work: Don't rely solely on dates to measure progress.
Track the actual volume of work completed (e.g., code written) compared to the planned
volume to get a more accurate picture.
 Regular Status Reports: Use task progress data to generate status reports. This helps
identify if a team is ahead, behind, or on track for completing a task.
Identify Deviations :

 Regularly compare how far the project has come (schedule and budget) against the
original plan to identify any deviations.
 Don't just focus on whether the project is ahead or behind. Analyze if these deviations
(positive or negative) significantly impact the project timeline or budget.
 Performance indicators :
Performance indicators, like Earned Value Management (EVM), help track project health
in terms of cost, schedule, and quality.
Monitoring a project schedule:

 Project plans provide a high-level overview, while project schedules contain detailed
information like resource allocation and task timelines.
 Project plans are tracked at key milestones, while project schedules are monitored at the
individual task level.
Periodic measurement in project monitoring:
Frequent Tracking: Regularly track and measure progress at the task level to identify issues.
Data for Decisions: Compare actual progress (schedule and cost) to planned figures to
identify deviations. Use this data to make informed decisions and address any problems that
arise.
Earned Value Management (EVM):
Tracks project progress beyond schedule & cost: EVM considers the amount of work
completed (earned value - EV) in addition to time elapsed and actual cost (AC).
Calculates variances to identify performance: EVM uses Schedule Variance (SV = EV - PV)
and Cost Variance (CV = EV - AC) to identify deviations from the planned schedule (PV) and
budget (AC). These variances help project managers understand if the project is
ahead/behind schedule or under/over budget.

13. Explain about Requirement Life – Cycle Management in detail.

Requirements Life-Cycle Management is the first step in developing a software application.
Requirement Development and Management in Waterfall Model
1. The waterfall model is a sequential software development process where phases must
be completed one after another.
2. In real world practice, a review process is often used to check requirements before
moving to the next phase.
3. If there are issues with the requirements during the review, they need to be fixed before
proceeding to the design phase.

Iterative Model
1. Iterative models, unlike waterfall, develop software in small iterations with a subset of
requirements at a time.
2. Scrum uses a backlog to store requirements and pulls them for development during each
sprint (iteration).
3. Agile models handle changes better by incorporating them in future iterations,
minimizing rework.

14. Differentiate Top Down and Bottom up Approach.

Top Down vs. Bottom Up Design Approach

Feature Top Down Approach Bottom Up Approach

Starting Point Overall product structure Individual components

Structure -> Components -> Components -> Middle

Design Sequence
Features Levels -> Top Level

Non-Functional Addressed as
Addressed early in design
Considerations components integrate

- Strong focus on non-functional - Incremental design

Benefits aspects (security, performance, allows for later
usability) adjustments

- Promotes reusable
- Encourages customer
components, increases
buy-in with early demos
maintainability

- Ensures design integrity within - Adaptable to changing

a single framework requirements
 - Potential lack of upfront,
Drawbacks - Risky, entire design upfront
elaborate design

- Requires strong
- Less flexibility for changes
refactoring skills in later
during development
stages

Development Model Agile methodologies,

Waterfall model
Fit iterative development

15. Discuss in detail about Software Design characteristics.

Modularity: Reduces complexity by breaking features into smaller parts.
Simplicity: Easier to understand for developers and maintainers.
Maintainability:

 Well-formed modules with clear documentation.

 Reduces maintenance costs.
Verifiability: Ensures design meets construction needs.
Portability: Allows design reuse for different platforms.
Reliability:

 Complex designs lead to higher defect rates.

 A reliable design is not complex, large, or difficult.
Security: Considers user security needs, especially for internet-facing applications.
Scalability: Allows scaling the software without design changes (or minimal changes).

16. Explain about Coding Methods of Software Construction.

Early Programming Techniques
Limited hardware capacity restricted software size.
Different methods emerged for various software sizes and advancements in computer
science.
Structured Programming

 Arose with the rise of mainframe computers with greater computing power.
 Enabled construction of large programs for commercial and business applications.
 Code stored in procedures/functions for reuse.
 Improved code structure and efficiency.

Object-Oriented Programming (OOP)

 Addresses limitations of structured programming by combining data and structure.

 Models real-world objects with data (properties) and functionality (methods).
 Encapsulation: Hides unnecessary object details for robustness.
 Improved maintainability .
Automatic Code Generation

 Aims to reduce manual coding effort.

 Limited generation capabilities exist in some CASE/modeling tools and ERP platforms.
 Generated code is specific to the platform and environment.
 Some companies are working on more advanced code generation systems.
Software Code Reuse

 Reduces development time and effort by reusing existing code.

 Techniques vary between procedural and object-oriented programming.
 Procedural: Functions and utility libraries for common functionality.
 OOP: Classes reused and extended through inheritance.
 Service-Oriented Architecture (SOA) is another powerful code reuse approach (covered
in Chapter 25).

Test-Driven Development (TDD)

 Emphasizes testing before coding to ensure logic is correct.
 Developers write test cases first and run them for verification.
 Code is written only after successful test runs.
Pair Programming
 Two developers work together on each development task.
 One developer codes while the other guides on requirements.
 Developers take turns coding and coaching, improving understanding and
code quality.

21 . Write short notes on Negotiation Management, Rapport Building

Management, Reporting Management and Bottom Line in Customer
Management.
Negotiation Management

 Negotiate with customer on adjusted timelines or alternative solutions.

 Propose alternative solutions while explaining limitations of original plan.
 Explain technical or budgetary constraints and suggest alternative features.
 Negotiate with customer on feature prioritization.

Importance of Rapport Building

 Customer appreciation for project team's effort.

 Improved communication and information sharing.
 Increased customer satisfaction with project deliverables.
Reporting Management

 Timely project status reports with performance indicators.

 Clear explanations for deviations from the plan.
 Proactive course of action for addressing deviations.
Bottom Line

 Customer prioritizes the project based on its perceived value.

 Changing priorities or cost overruns can lead to project abandonment.
 Project manager's focus should be on customer satisfaction and delivering project value.
22. Differentiate RFP (Request for Proposal) and RFI (Request for
information).

RFP vs. RFI

RFI (Request for

Feature RFP (Request for Proposal)
Information)

Evaluate potential
Purpose Select a supplier for a project
suppliers

Stage Bidding process Pre-RFP stage

Information Supplier details, project details Supplier details, basic

Requested (pricing, schedule, methodology) project information

Level of Detail High (specific to the project) Low (general capabilities)

Use of Compare proposals, select best

Qualify potential suppliers
Responses supplier

Informal information
Formality Formal invitation to bid
gathering
23. Explain in detail about Software Testing Management Tools.

 Test Management:
o Testing will be involved in all stages of product development, from
requirements review to final inspection.
o Test management tools will integrate with review processes for a more
holistic approach.
 Defect Tracking:
o Defect tracking will become part of a larger test management suite,
improving visibility and tracking.
o Defect tracking data will be used to assess the testing team's performance.
 Automation Tools:
o Automation tools will support more environments, recognize new UI
components, and handle various testing types.
o Automation will continue to play a major role, saving time and resources.
 Test Creation Tools:
o Creating effective test cases will likely remain a human-centric task for some
time.
 o Development of "smarter" tools that can mimic human thought processes for
test creation may occur in the long term.
 Test Coverage Tools:
o There will likely remain two main types of test coverage tools - those that
insert code for coverage analysis and those that generate test code
themselves.
o These tools may evolve to provide more comprehensive coverage insights.

26. Examine the Statement “When a test case passes, this means that the
application is working fine and vice versa”. Discuss in detail (Answer: Defect
Tracking pg.311)
Defect Tracking
1. Running tests on a software application can result in pass/fail outcomes.
2. Passed tests indicate the application is functioning correctly, while failed
tests indicate a defect.
3. Identified defects are logged in a defect-tracking tool and assigned to
developers for fixing.
4. Testers then re-run the test case to verify if the fix was successful.
5. If the fix is verified, the defect is closed; otherwise, it's reopened for further
attention.

27 . Examine the Statement “One major area where the project team needs
to do a lot of rework is the requirement change request that the customer
places with the project team”. Discuss in detail (Answer: Customer
Management pg. 284)
Customer Management
1. Software projects require close customer contact due to unclear requirements.
2. Unlike other industries, software specifications are vague and need elaboration.
3. Miscommunication between customer (business) and project team (technology) leads to
misunderstandings.
4. Functional consultants bridge the gap by understanding both business and software.
5. Requirement changes from the customer demand rework in the software design.
6. Unrealistic customer expectations about features and timelines need management.
7. Customer investment requires project justification and successful delivery.
8. Clear communication and effort are crucial for customer satisfaction in software projects.
Negotiation management , rapport building , reporting management , bottom line.

28. Examine the Statement “These standards have been helping software
services and products companies to develop, maintain, and operate software
systems in an economical manner”. (Answer: CMMI Standards pg. 230)
CMMI Standards Summary
1. The Software Engineering Institute (SEI) develops software engineering standards.
2. CMM, PCMM, and SECM are some of their popular standards for developing high-quality
software.
3. These standards were updated or discontinued due to market changes and software
development advancements.
4. Using separate process models for development and maintenance created problems.
5. Maintaining separate models required significant resources and employee change
management.
6. Having two teams for development and maintenance was expensive and inefficient.
7. A single process definition was needed to address these issues.
8. SEI released CMMI (Capability Maturity Model Integration) as a unified process model
for software development, maintenance, and integration.

30. Examine the Statement “ABC Project has time to be rechecked with the
components implemented and executed. Also to be tested with the time
scheduled for each process. (Answer: Test Project Monitoring and control pg.
193)

Test Project Monitoring and Control

Test Case Design
1. Test Case Design Plan: Defines types, quantity, and priority of test cases for
different modules.
2. Test Types: Functionality, performance, usability, compatibility, etc. require
separate test cases. Regression testing is needed for new versions.
Test Case Management
1. Includes managing test case versions, tracking changes, and creating a test
case repository.
2. Automation scripts can be created and managed for test case execution.
Test Bed Preparation
1. Environment Replication: The application under test (AUT) should be
installed on a machine resembling the production environment (hardware,
software configuration).
2. Accessibility and Isolation: The test bed should be centrally accessible
(remote desktop, peer-to-peer) and isolated from unauthorized access or
other testing activities.
3. Test Data Preparation: Test data should mimic real-world user data for
accurate testing.

Test Case Execution

1. Test cases are executed manually or with automation tools.
2. Regression testing often benefits from automation.
3. Pass/Fail outcomes are recorded after each test case execution.
Defect Tracking
1. Crucial activity to ensure defects are logged, fixed, and tracked.
2. Defect count per hour/day is a common performance metric for test teams.
3. Defect tracking application should be centrally accessible and facilitate clear
communication between development and testing teams.

31. Explain in detail about supplier Management.

Supplier Management
Supplier Search: Identify potential service providers based on size, experience, and offered
services.

 Use Requests for Information (RFI) to gather basic details about suppliers.
 Use Requests for Proposal (RFP) to get detailed project proposals from shortlisted
suppliers.
Supplier Qualifications: Evaluate a supplier's qualifications to ensure they can deliver your
project.

 Look for certifications (CMMI, ISO) and industry expertise (Microsoft, etc.).
 Verify employee qualifications (degrees, certifications).
Supplier Experience: Assess a supplier's past experience to gauge their ability to meet your
needs.

 Look for experience in similar projects and industries.

 Consider customer references and conduct site visits if necessary.
Supplier Agreement Management
Agreements with suppliers should be legally binding and address service levels, performance
expectations, and potential revisions.
Short-Term Agreements: Suitable for small, one-time projects where cost is the primary
concern.

 Include clauses for future support from the supplier in case of product issues.
Long-Term Agreements: Used for large, multi-year projects requiring a strong supplier
relationship.

 Include detailed project plans, staffing levels, scope definitions, and legal clauses for
contract breaches.
 Include annual reviews and contract revisions based on changing needs.
 Fixed-cost/fixed-budget contracts are used once project details are finalized.
Supplier Communication Management

 Clear and consistent communication is crucial throughout the project lifecycle.

 The customer must ensure the supplier team understands project requirements.
 The supplier must provide well-documented deliverables for customer
understanding.
 Increased communication is necessary when working with teams from different
cultures.
Offshore Software Outsourcing

 Traditional software development involves highly skilled professionals, making it

expensive to keep them busy after a project.
 Contracting companies emerged to address this by employing software professionals
and assigning them to projects.
 Offshore outsourcing leverages lower-cost countries like India to reduce
development costs and speed up project timelines.

Part C

2.Identify the pros and cons of using pair programming over programmers
working alone. Based on analysis, point out if there are any situations where
the pair programming technique may not be suitable. (Answer: Software
Construction - Pair Programming )

**optional (Certainly, here's a flowchart depicting a typical pair programming session:

The flowchart outlines the following steps:
1. Pairing: Two developers are assigned to work together on a specific task.
2. Roles: One developer takes the role of the driver (who writes the code), while the
other acts as the navigator (who reviews the code and provides guidance).
3. Development Cycle:
o The driver writes code based on the task requirements and discussions with
the navigator.
o The navigator reviews the code, identifies potential issues, and suggests
improvements.
o They discuss the code and agree on the best approach.
4. Switching Roles: Periodically, the developers switch roles. The navigator becomes
the driver, and the driver becomes the navigator. This ensures both developers are
involved in all aspects of the task.
5. Break: If needed, the pair can take breaks to maintain focus and avoid burnout.
6. Completion: Once the task is completed, both developers review the final code and
ensure it meets the requirements.)**Optional

Pros of Pair Programming

 Improved Code Quality: Two developers can identify bugs and suggest
improvements, leading to fewer errors and a more maintainable codebase.
 Enhanced Knowledge Transfer: Senior developers can mentor junior developers,
accelerating learning and improving the team's overall skill level.
 Increased Collaboration and Communication: Working in pairs requires constant
communication and collaboration, fostering a more collaborative development
environment.

Cons of Pair Programming

  Reduced Individual Productivity: Communication and coordination overhead can
reduce individual productivity, and not everyone works well in a collaborative
setting.
 Potential for Domination: If the pairing isn't well-balanced, one developer may
dominate the session, hindering the learning of the less experienced developer.
 Higher Costs: Essentially having two developers work on a single task increases
resource requirements, which can be a cost concern for projects with tight budgets.

Situations Where Pair Programming May Not Be Suitable

 Simple, Repetitive Tasks: Pair programming is overkill for simple, repetitive tasks
that don't require much collaboration or knowledge sharing.
 Introverted Developers: Some developers who prefer independent work may find
pair programming draining or distracting.
 Tight Deadlines: The time spent coordinating and communicating in pair
programming sessions might not be feasible for projects with very tight deadlines.

3.A Software package is to be designed and built to assist in Software cost

estimation. It will input certain parameters and produce initial cost
estimates to be used at bidding time.
i) It has been suggested that a software prototype would be of value in
these circumstances. Explain why this might be.
ii) Discuss how such prototyping could be controlled to ensure that it is
conducted in an orderly and effective way and within a specified time
span. (Answer: Software Effort Cost Estimation – Prototype)

Why Prototype Cost Estimator (i)

1. Validate user needs early: Get feedback before development to ensure the final
software aligns with user workflows and avoids costly rework.
2. Refine cost estimation model: Use the prototype to test your model's accuracy and
efficiency with sample project data, allowing for adjustments before full
development.
3. Uncover development challenges early: Identify potential technical hurdles like data
handling or UI complexities during prototyping, saving time and resources later.
4. Boost communication & buy-in: Showcase the cost estimation software's
capabilities with a working prototype, improving communication and securing buy-in
from stakeholders.
5. Focus on core functionalities: Clearly define the prototype's scope to prioritize
features critical for evaluating the cost estimation model and user interface.

Control Prototype Development (ii)

1. Define scope & time limit: Clearly define the functionalities and development
timeframe to avoid feature creep and maintain focus using techniques like Agile
sprints.
2. User-friendly UI design: Design a clear and intuitive interface for users to easily
interact with the prototype and provide meaningful feedback.
3. Gather feedback & iterate: Plan for iterative development cycles. Gather user
feedback and incorporate suggestions into subsequent iterations for a user-centric
prototype.
4. Document everything: Maintain clear documentation of functionalities, design
decisions, and limitations as a valuable reference point throughout development and
for future enhancements.
5. Focus on efficiency: Build a valuable prototype quickly to make informed decisions
for the final software development.

6.Suppose you are the manager of a software project. Explain why it

would not be proper to calculate the number of developers required for
the project as a simple division of the effort estimate (in person-months)
by the normal distribution estimate (in months). (Answer: Calculate with
an example of Effort Estimation in person-months)
7.Suppose you are the project manager of a large software development
project. List three common types of risks that your project might suffer. Point
out the main steps that you would follow to effectively manage risks in your
project. (Answer: Risk Management – Types of Risks)

Budget Risks :
Budget Tracking & Control: Monitor project expenses to identify and address cost overruns
early.
Budget Reserves: Include buffer funds in the project budget to handle unforeseen cost
increases.
Schedule risks :
Schedule Risks: Unforeseen circumstances like rework or miscommunication can cause
project delays.
Schedule Buffers: Allocate buffer time in the project schedule to accommodate potential
delays.
Resource risks :
Resource Loss: Project delays can occur if team members leave the project mid-way, taking
their knowledge with them.
Mitigation Strategies: Maintain a talent pool for replacements and implement a knowledge
management system to capture project knowledge.
Quality Risks (2 points):
Defects and Errors: Poor design, construction, complexity, or frequent requirement changes
can lead to software defects impacting quality.
Quality Management: Integrating quality checks throughout the development process
(planning, reviews) is crucial for mitigating quality risks.
Technology Risks (2 points):
Technology Obsolescence: Rapidly evolving technologies can make chosen technologies
outdated, rendering the software unusable.
Technology Selection: Careful selection of programming languages, platforms, and tools
with long-term support is essential to minimize technology risks.

8.If you have access to project planning software, investigate the extent to
which it offers support for earned value analysis. If it does not do so directly,
investigate ways in which it would help you to generate a baseline budget
and track the earned value. (Answer: Earned Value Management in Project
Monitoring and Control)
Earned Value Management (EVM)
Difficulty in assessing project progress due to non-linear consumption of budget and time.
Earned Value Management (EVM) is a technique for project performance measurement.
Planned vs. Actual: EVM compares planned values (budget & schedule) with actual
progress.
Earned Value (EV): EV considers both budget spent and work completed on a task.
Performance Indicators: Key metrics include Schedule Variance (SV), Cost Variance (CV), CPI,
and SPI.
Schedule variance (SV) = EV – PV
Cost variance (CV) = EV − AC
Ideal Values: CPI and SPI of 1 indicate project progress aligns with the plan.
Negative Variance: Negative SV or CV indicates project is lagging behind schedule or budget.
Positive Variance: Positive SV or CV suggests progress exceeding the plan (rare).
CPI (Cost Performance Index): Ratio of EV to Actual Cost (AC) - reflects budget efficiency.
CPI = EV/AC
SPI (Schedule Performance Index): Ratio of EV to Planned Value (PV) - reflects adherence to
schedule.
SPI = EV/PV
9.Mention the baseline in the context of software Configuration
Management? How do baselines get updated to form new baselines?
(Answer: Software Configuration Management)
Configuration management is essential in software projects to securely store, track, and
access the various artifacts produced throughout the development lifecycle.
Characteristics of configuration Management :

Each information item can be identified using tags associated with the information item.
Some common tags for item identification include

 Project name
 Year and time stamp
 Document name
 Document number
 Author
 Activity identifier
 Document type
 Version number

Configuration Management Techniques

Following are some techniques and best practices that are extremely useful:
1.Centralized configuration management system
2.Secured access mechanism with role-based access control
3.Continuous integration of software build with smoke test facility
4.Easy branching mechanism to branch out an entire software version
5.Audit facility

11.Discuss the factors to be taken into account while allocating individuals to

tasks. (Answers: Deadline, Budget, Stakeholders, Project members, Demand,
supply and Price. Discuss these topics in detail)

Factors to Consider When Allocating Individuals to Tasks

Deadline:
 Time Constraints: Align individual workload with task deadlines to ensure timely
completion.
 Skillset & Availability: Balance skillset with availability to meet project timelines
effectively.
 Prioritization: Assign tasks that contribute directly to project goals and prioritize
based on deadlines.
Budget:
 Cost-Effectiveness: Consider the individual's cost (e.g., salary) relative to their skillset
and experience for the task.
 Resource Optimization: Balance the project budget with the most cost-effective
allocation of resources.
 Alternative Options: Explore alternative options if budget constraints limit assigning
the ideal individual.
Stakeholders:
 Communication & Expectations: Consider the stakeholder's communication needs
and assign individuals with strong communication skills if necessary.
 Stakeholder Involvement: Account for stakeholder needs and assign individuals who
can effectively manage stakeholder expectations for the task.
 Project Visibility: If stakeholders require high visibility, assign individuals who can
keep them informed on task progress.
Project Members:
 Skillset & Experience: Match the task requirements to the individual's technical skills
and experience for optimal results.
 Team Dynamics: Consider existing team dynamics and how well the individual works
with others involved in the task.
 Development Opportunities: Balance assigning experienced personnel for complex
tasks with providing development opportunities for junior members.
Demand & Supply:
 Workload Management: Avoid overloading individuals with tasks, consider their
current workload and capacity.
 Resource Availability: Account for the individual's current workload and availability
when assigning tasks.
 Team Composition: Consider the overall team composition and skillset distribution
when allocating resources.
Price (cost):
 Cost-Effectiveness: Consider the individual's cost (e.g., hourly rate) relative to their
skillset and experience for the task.
 Resource Optimization: Balance the project budget with the most cost-effective
allocation of resources.
 Alternative Options: Explore alternative options if budget constraints limit assigning
the ideal individual.

12. Draw and Explain a Software Life Cycle Diagram for this scenario
“developing a machine learning model to predict customer churn for a
telecommunications company”
Learning Model to Predict Customer Churn:
1. Planning & Requirements Gathering:
 Business stakeholders define the problem of customer churn and its impact on the
company.
 Data scientists and engineers gather and analyze customer data to identify potential
churn factors.
 Success metrics are defined to measure the effectiveness of the churn prediction
model.
2. Data Acquisition & Preprocessing:
 Relevant customer data is collected from various sources within the
telecommunications company (e.g., call logs, billing records, service usage data).
 Data is cleaned, transformed, and formatted to ensure quality and consistency for
model training.
3. Model Design & Development:
 Data scientists select and develop appropriate machine learning algorithms for churn
prediction. This may involve experimentation with different algorithms to find the
best performing model.
 The model is trained on the prepared historical customer data.
4. Model Testing & Evaluation:
 The trained model is evaluated on a separate hold-out dataset to assess its accuracy
and generalizability in predicting churn.
 Model performance metrics (e.g., precision, recall, F1-score) are measured to
identify areas for improvement.
5. Model Deployment & Monitoring:
  The final machine learning model is deployed into production as a service within the
telecommunications company’s infrastructure.
 The model’s performance is continuously monitored to track its effectiveness over
time and identify potential degradation.
6. Feedback & Maintenance:
 Customer churn predictions are used to develop targeted customer retention
strategies and marketing campaigns.
 Model performance is monitored, and the model may be retrained with new data
periodically to maintain its accuracy and effectiveness.

PART A

5. Define Project Charter.

1. Project charter should set realistic expectations by aligning project goals with
achievable results.
2. It should include project goals, objectives, and major responsibilities.
3. Project charter can be a simple statement outlining the big picture of the effort.
4. It should include the business goals the project is supposed to achieve.

6.State Effort Estimate Techniques.

1. FPA (Function Point Analysis): Estimates effort based on software functionality
(complexity, data access) and team productivity.
2. Wideband Delphi: Uses anonymous expert opinions in multiple rounds to reach a
consensus effort estimate.
3. COCOMO (Constructive Cost Model): A three-tiered algorithmic model for effort
estimation based on project size and complexity.
1. Basic COCOMO: Uses lines of code for early estimates.
2. Intermediate COCOMO: Considers factors like team experience.
3. Detailed COCOMO: Most comprehensive, uses various project attributes and
multiplying factors.
7. Find Effort (in man months) with no. of function points 10, Productivity 50.
Effort (in man months) = No. of Function Points × Productivity

Effort = 10*50
Effort(in man months) = 500

8.Calculate Project Duration, Minimum duration, Optimum Staffing size.(with previous

question data)
Project duration = 2.5 × (effort)^1/3
Minimum duration = 0.75 × (effort)^1/3
Optimum staffing size = (effort)^1/2

9.State COCOMO Model

1. Doesn't rely on historical project data (SPC), uses industry averages instead.
2. Considers various factors impacting effort like project attributes (tools, schedule) and
team skills.

A three-tiered algorithmic model for effort estimation based on project size and
complexity.
1. Basic COCOMO: Uses lines of code for early estimates.
2. Intermediate COCOMO: Considers factors like team experience.
3. Detailed COCOMO: Most comprehensive, uses various project attributes
and multiplying factors.

10.Classify the types of risks.

13. Identify the risk for the scenario: Soft Solution Company working in a project “XYZ”
with 50 members in a project team. After the Completion of the Project, team identified
that the Product may be poor because of bad design.
Quality risk

14. List some of the Characteristics of a good Configuration Management system

15. Calculate Schedule variance(SV) and Cost variance(CV) with Earned value = 50, Planned
value = 20 and Actual cost = 15 (page no.106)

EV = 50
PV = 20
AC = 15
SV = EV-PV = 50-20 = 30
CV = EV-AC = 50-15 = 35

16. . Define Status reports.

Status reports are essentially snapshots of a project's progress at a specific point in time. They
communicate key information to stakeholders about how the project is doing compared to the plan.

17. Outline the Statement “Measuring quality of these work products will provide good insight”.
(page no. 141 - Software Life cycle metrics)
1. We measure both the work products themselves (like SRS document, code) and the
processes used to create them (like design phase).
2. Work product attributes focus on quality aspects like testability, maintainability, and
clarity. Size alone isn't meaningful.
3. Process attributes measure efficiency and productivity of the development team.
4. By measuring both types of attributes, we can compare the project's performance
against benchmarks and standards.

20. Differentiate Top-Down and Bottom-up Approach of Good Software Design.

21. Define Prototypes.

Prototypes are essentially early models of a product or system. They are used to test and refine ideas
before investing significant resources in full development.

25. Define Pair Programming.

26. Differentiate Verification and Validation

Verification vs. Validation

Feature Verification Validation

Are we building the product right Are we building the right

Focus
according to specifications? product for the user's needs?

Tests the actual functionality of

Activity Reviews documents, code, designs
the built product

27. State Defect tracking.

28. List out Software Maintenance types.

 1. Corrective Maintenance: Fixing errors and bugs in the software to ensure it
functions as intended.
2. Adaptive Maintenance: Modifying the software to adapt to changes in the
environment, such as new hardware, operating systems, or regulations.
3. Perfective Maintenance: Enhancing the software's functionality with new features
or improvements based on user feedback or evolving needs.
4. Preventive Maintenance: Proactive maintenance to identify and address potential
issues before they cause problems, improving the software's overall reliability and
maintainability.

29. List out Software Product Release Types.

1. Pre-Alpha: This is an internal version, not shared with external users. It's the
initial, incomplete version used for internal testing by developers to identify
major bugs and ensure core functionalities work.
2. Alpha: An early, unstable version shared within a limited group (often testers
or internal departments) for broader bug identification and initial feedback on
features.
3. Beta: A near-final version shared with a larger audience (potential customers,
public testers) to gather more comprehensive feedback on functionality,
usability, and performance before the final release.
4. Release Candidate (RC): A version very close to the final product, released
to a limited audience for final testing and bug squashing before public release.
5. General Availability (GA): The final, official version of the software product
made available to the general public.

33. Differentiate Long-term and Short-term Agreements.

Long-Term vs. Short-Term Agreements

Feature Long-Term Agreements Short-Term Agreements

Duration Typically 1 year or more (can Typically less than 1 year (can
 be month-to-month or for a
extend to several years)
specific project)

* Stability and predictability in

costs and services * Potentially * Flexibility to adapt to changing
Advantages lower costs due to bulk needs * Faster negotiation and
discounts * Stronger relationship implementation
building with vendor

* Less flexibility to adjust to

* May be more expensive per
changes * Risk of locking into
unit cost * Less time to build a
outdated technology or services
Disadvantages strong relationship with vendor *
* Potential for vendor lock-in
Risk of renegotiation at the end
(difficulty switching to another
of the term
provider)

34. List all benefits of tools.

35. Define Work Break Down Structure.

1. List all tasks: The plan should include all project tasks with start and end dates.
2. Group related tasks: Tasks are grouped by project phase under a "pseudo task"
(phase name). This simplifies the plan and highlights milestones.
3. While listing tasks, it's important to show which tasks depend on others for completion
(critical path).
4. Project management software allows grouping tasks and expanding/collapsing them for
easier navigation of the Work Breakdown Structure (WBS).

36.State Software Configuration Management.

Configuration management is essential in software projects to securely store, track, and
access the various artifacts produced throughout the development lifecycle.
37. List some of the advantages of Software Configuration Management.

 Improved productivity and efficiency

 Reduced risk of errors and defects
 Increased collaboration and communication
 Easier tracking and management of changes
 Improved traceability
40. List some of the advantages of Team Management.
 Increased productivity and performance
 Improved employee satisfaction
 Stronger learning and development
 Reduced staff turnover
 Better decision-making
 Achieved goals