1.

Feasibility Study: A feasibility study evaluates the practicality of a proposed project

or system. It assesses factors like technical feasibility, economic viability, and
operational feasibility to determine if the project is worth pursuing.
2. Sprint: In agile development, a sprint is a time-boxed period (usually 1-4 weeks)
during which a specific set of tasks or user stories are completed by the development
team. Sprints allow for iterative development and frequent feedback.
3. Formal Methods: Formal methods are mathematical techniques used in software
engineering to specify, design, and verify software systems. They involve rigorous
mathematical models and proofs to ensure correctness and reliability.
4. Stakeholders in Software Project Management: Stakeholders in software project
management include individuals or groups (such as customers, users, project
managers, developers, and sponsors) who have a vested interest in the project's
outcome or are affected by its execution.
5. White-Box Testing: White-box testing is a testing technique where the internal
structure, design, and implementation of the software being tested are known to the
tester. It involves testing paths, branches, and conditions within the code to ensure
comprehensive test coverage.
6. Gantt Chart: A Gantt chart is a visual project management tool used to schedule,
coordinate, and track specific tasks in a project over time. It shows tasks as bars along
a timeline, indicating their start and end dates, dependencies, and progress.
7. Technical Risks: Technical risks in software development refer to potential issues or
challenges related to technology, tools, or implementation. An example could be
compatibility issues between different software components or platforms, impacting
system integration.
8. Reengineering: Reengineering (or software reengineering) involves the restructuring
and redevelopment of existing software systems to improve their maintainability,
performance, or other attributes without changing their external behavior.
9. Software Process Improvement (SPI): Software Process Improvement (SPI) refers
to the systematic approach of enhancing software development and maintenance
processes. It aims to improve quality, efficiency, and predictability by adopting best
practices, standards, and methodologies.

10. Classical vs Iterative Waterfall Model:

• Classical Waterfall Model: This model is a sequential approach where development

flows through phases like requirements gathering, design, implementation, testing,
deployment, and maintenance. Each phase begins only after the previous one is
complete and finalized, often represented as a waterfall flowing downwards.

Advantages: Provides a structured approach with clear milestones and deliverables.

It's easy to manage due to its linear nature and emphasizes documentation, making it
suitable for projects with stable and well-understood requirements.

Disadvantages: Limited flexibility for changes once a phase is completed.

Requirements must be well-defined upfront, increasing the risk of late-stage changes
being costly and time-consuming. Customer feedback is typically gathered only after
deployment, which can lead to misunderstandings or dissatisfaction.

• Iterative Waterfall Model: Recognizing the limitations of the classical approach, the
iterative waterfall model introduces feedback loops between phases. After each phase,
 there is a review where stakeholders provide feedback, which may lead to revisiting
previous phases or making adjustments before moving forward.

Advantages: Allows for early feedback and adaptation to changing requirements,

reducing the risk of late-stage changes. It retains the structured approach of the
waterfall model while incorporating iterative elements, making it more adaptable to
evolving project needs.

Disadvantages: Still maintains a sequential nature, requiring disciplined management

of iterative cycles. It may not fully accommodate continuous changes or radical shifts
in project scope, depending on the frequency and extent of feedback loops
implemented.

11. Extreme Programming (XP):

Extreme Programming (XP) is an agile software development methodology known

for its customer-centric approach, rapid iterations, and emphasis on teamwork and
technical excellence.

Key Principles:

o Pair Programming: Two programmers work together at one computer,

continuously reviewing each other's code and improving overall code quality.
It promotes knowledge sharing and reduces defects.
o Continuous Integration: Code changes are integrated frequently (often
daily), ensuring that integration issues are detected early and enabling rapid
feedback on changes.
o Test-Driven Development (TDD): Tests are written before code is
developed, guiding the development process and ensuring that the code meets
requirements. It helps in maintaining and improving code quality.
o Collective Ownership: Any team member can modify any part of the
codebase to improve it. This fosters collaboration, flexibility, and shared
responsibility for the project's success.
o Sustainable Pace: Maintaining a pace that allows for continuous development
without burnout is crucial. XP emphasizes the importance of work-life balance
and sustainable development practices.
12. Roles and Responsibilities of Project Manager:
o Roles: Project managers play a crucial role in planning, organizing, and
managing resources to ensure successful project completion. They are
responsible for setting clear objectives, defining scope, managing budgets and
timelines, and ensuring quality deliverables.
o Responsibilities: Project managers oversee all aspects of a project, from
initiation to closure. They lead teams, allocate resources, monitor progress,
manage risks, and communicate with stakeholders. They are accountable for
delivering projects within constraints while maintaining stakeholder
satisfaction and adherence to organizational standards.
13. Software Project Scheduling Process:
o Define Activities: Break down project deliverables into smaller, manageable
tasks or activities. Each activity should be clearly defined and contribute to
achieving project objectives.
 o Sequence Activities: Determine the order in which activities should be
performed based on dependencies and constraints. Identify critical paths and
milestones that impact project timelines.
o Estimate Resources and Durations: Allocate resources (human, material,
and financial) and estimate the time required for each activity. Consider
factors like skill levels, availability, and potential risks that may impact
resource allocation.
o Develop Schedule: Create a detailed project schedule that includes start and
end dates for each activity, dependencies, critical paths, and key milestones.
The schedule serves as a roadmap for project execution and monitoring.
o Monitor and Control: Continuously track progress against the schedule,
monitor resource utilization, manage changes, and resolve issues promptly.
Adjust the schedule as necessary to ensure project stays on track to achieve its
objectives within defined constraints.
14. Software Reengineering:
o Definition: Software reengineering involves analyzing and modifying an
existing software system to improve its performance, maintainability, or other
attributes without changing its external behavior. It may involve refactoring
code, redesigning architecture, or migrating to a new platform while
preserving or improving functionality.
o Process Model:
▪ Understanding: Conduct a comprehensive analysis of the existing
system to understand its structure, functionality, strengths, weaknesses,
and limitations. Document dependencies, interfaces, and critical
components.
▪ Restructuring: Redesign or refactor the system to improve its
architecture, code quality, or performance. This may involve
modularizing code, optimizing algorithms, or adopting new design
patterns to enhance maintainability and scalability.
▪ Migration: Transition the reengineered system to a new environment,
platform, or technology stack if required. Ensure compatibility, data
migration, and integration with existing systems.
▪ Testing and Validation: Test the reengineered system rigorously to
ensure it meets functional and non-functional requirements. Conduct
integration testing, performance testing, and user acceptance testing to
validate system functionality and performance improvements.
15. CMMI (Capability Maturity Model Integration):
o Continuous vs Staged Representation:
▪ Continuous Model: Focuses on continuous improvement across
process areas without predefined maturity levels. Organizations assess
and improve specific capabilities incrementally to achieve higher
levels of maturity over time. It emphasizes flexibility and adaptability
in process improvement efforts tailored to organizational needs and
goals.
▪ Staged Model: Defines maturity levels (e.g., Initial, Managed,
Defined, Quantitatively Managed, Optimizing) that organizations can
achieve by implementing predefined sets of process areas. Each
maturity level represents increasingly mature and effective software
development and management practices. Organizations progress
through staged levels by systematically addressing and
 institutionalizing specific process areas to enhance overall
organizational capability and performance.

15. Iterative Waterfall Model:

The Iterative Waterfall Model is an enhancement of the traditional Waterfall Model,

addressing its rigid sequential approach and lack of flexibility in accommodating changes
during the software development process. It introduces iterative cycles, allowing for feedback
loops and adjustments at various stages. Here's how it works:

• Phases: Like the Waterfall Model, it consists of sequential phases: Requirements

gathering, Design, Implementation, Testing, Deployment, and Maintenance.
• Iterations: Unlike the traditional Waterfall, after each phase (except Maintenance),
there's an iteration or feedback loop. This means that once a phase completes,
stakeholders review the deliverables, provide feedback, and suggest changes or
enhancements.
• Flexibility: Iterations allow for early detection of issues and requirements changes,
reducing the risk of late-stage rework. It improves responsiveness to customer
feedback and evolving project needs.
• Advantages: Combines the structure of Waterfall with flexibility. Allows for early
feedback, continuous improvement, and better adaptation to changing requirements.
• Disadvantages: Still retains some inherent rigidity and dependency on initial
requirements. Requires disciplined management of iterations to avoid scope creep and
maintain project timelines.

16. Types of Formal Specification Languages:

Formal specification languages are used in software engineering to precisely describe system
requirements, behavior, and designs using mathematical or formal logic constructs. Here are
some types:

• Z Notation: Based on set theory and first-order logic, Z notation is used to specify
and refine software system specifications. It is particularly suited for describing
complex data structures and operations.
• VDM (Vienna Development Method): VDM uses mathematical notations to
describe software systems. It includes two main dialects: VDM-SL (Specification
Language) for functional specifications and VDM++ for object-oriented
specifications.
• B-Method: B-Method uses abstract machines, refinement, and mathematical proofs to
specify and verify software systems. It emphasizes correctness by construction
through systematic refinement.
• Larch: Larch incorporates formal specification techniques with programming
language design. It defines interfaces using specification languages to enhance
software design and verification.
• SPARK: SPARK is a subset of Ada programming language with annotations for
formal verification. It allows for writing formally verifiable software specifications
and guarantees.

17. Techniques of White Box Testing:

White Box Testing (also known as Structural Testing or Clear Box Testing) involves testing
the internal structure, code, and logic of a software application. Several techniques are used:

• Statement Coverage: Ensures that each statement in the code is executed at least
once during testing.
• Branch Coverage: Tests every branch (decision) in the code to ensure all possible
paths are tested.
• Path Coverage: Tests every possible path from start to end within a module to ensure
that all feasible paths are exercised.
• Condition Coverage: Ensures that each Boolean sub-expression in a decision is
evaluated to both true and false during testing.
• Loop Coverage: Ensures that all loops execute at their boundaries, within their
operational bounds, and with maximum iterations.
• Data Flow Coverage: Ensures that all definitions and uses of variables within the
code are exercised during testing.

These techniques aim to achieve thorough test coverage of the code's internal structure,
ensuring its correctness and robustness.

18. Risk Management Process:

Risk management in software projects involves identifying, assessing, prioritizing, and

mitigating risks that could impact project objectives. The process typically includes the
following steps:

• Risk Identification: Identify potential risks that could affect project scope, schedule,
cost, quality, or resources. Use techniques like brainstorming, checklists, and
historical data review.
• Risk Assessment: Assess the likelihood and impact of identified risks. Prioritize risks
based on their severity and potential consequences on project objectives.
• Risk Mitigation Planning: Develop strategies and action plans to mitigate or reduce
identified risks. This may include risk avoidance, risk transfer, risk reduction, or risk
acceptance strategies.
• Risk Monitoring and Control: Continuously monitor identified risks throughout the
project lifecycle. Implement risk responses, track mitigation actions, and reassess
risks as project conditions change.
• Documentation and Communication: Document all identified risks, assessments,
mitigation plans, and decisions. Communicate risks and mitigation strategies to
stakeholders to maintain transparency and alignment.

19. Software Configuration Management (SCM) Process:

Software Configuration Management (SCM) is a set of processes, policies, and tools used to
manage and control changes to software artifacts throughout their lifecycle. Here’s how the
SCM process typically works:

• Identification: Identify and uniquely label each software configuration item (SCI),
including source code, documentation, and configuration files.
• Control: Manage changes to SCIs using version control tools and techniques.
Establish baselines and track changes to ensure consistency and traceability.
 • Status Accounting: Record and report the status and history of SCIs and
configuration baselines throughout the project lifecycle. This includes tracking
changes, versions, and configurations.
• Auditing and Review: Conduct audits and reviews to ensure compliance with SCM
policies, procedures, and standards. Verify adherence to configuration management
plans and identify areas for improvement.
• Build and Release Management: Manage the build process to create software
releases from controlled SCIs. Ensure consistency, reproducibility, and traceability of
software builds.
• Change Management: Implement a formal process for requesting, evaluating,
approving, and implementing changes to SCIs. Ensure that changes are managed and
controlled to minimize disruption and risk.

Effective SCM helps improve software quality, reduce risks associated with changes, and
enhance collaboration among development teams