Software Engineering — Detailed Answers (Bold
Questions + Diagrams)
Q1 a) What is project scheduling? Explain in brief about the basic principles guiding the
s/w project scheduling.
Answer: Project scheduling is the activity of planning when each task in a software project will be performed, by
whom, and for how long. A schedule converts estimates into a time-phased plan that coordinates people, tasks
and milestones to meet delivery commitments. It balances dependencies, resource availability, and risk to
produce a realistic timeline. Schedules are living documents that should be updated as progress and risks
emerge.
Key principles guiding software project scheduling: • Decompose work into manageable tasks (work packages)
that can be estimated and monitored. • Identify dependencies and sequence tasks logically (finish-to-start,
start-to-start, etc.). • Use historical data and expert judgement for realistic time estimates; include contingency. •
Assign clear ownership and expected deliverables for each task. • Define milestones for progress checkpoints and
decision gates. • Balance workload to avoid resource bottlenecks and burnout. • Continuously monitor and revise
schedule to reflect actual progress and new risks.
GANTT (conceptual) Time -> | Week1 | Week2 | Week3 | Week4 | Week5 | Task A | ====== |
Task B | ======== | Task C | ======== | (= work duration)
Q1 b) What is the need of project Estimation? What are the steps while estimation of
software?
Answer: Why estimation is needed: Estimation provides a forecast of effort, duration, cost and resource needs. It
forms the basis for budgeting, staffing, contract terms, and milestone commitments. Without reasonable estimates
projects face unrealistic deadlines, under-resourcing, and scope creep.
Steps in estimation (detailed): 1) Requirements clarification: Confirm scope, constraints and acceptance criteria.
2) Select method: Expert judgment, analogy, parametric models (COCOMO), Function Points, Use Case Points,
Story Points, etc. 3) Decompose: Break system into modules/features for granular estimates. 4) Size
measurement: Use LOC, FP, UCP or story points to quantify size. 5) Effort conversion: Apply productivity rates
(e.g., person-hours per FP) and factor in team speed. 6) Schedule modeling: Determine elapsed time considering
resource calendar and dependencies. 7) Risk buffer: Add contingency for identified risks and uncertainty. 8)
Review and validation: Peer review and compare with historical project data; adjust accordingly. 9) Re-baseline:
Re-estimate as requirements change or new information becomes available.
Q1 c) How are LOC and FP used during Project Estimation? Explain any one with
suitable example.
Answer: LOC (Lines of Code) and FP (Function Points) are size metrics. LOC counts code lines and is easy to
measure post-development but language-dependent and poor at early estimates. Function Points measure
functionality from a user's perspective, enabling early estimation independent of language.
Detailed example — Function Point method: 1) Identify counts: External Inputs (EI), External Outputs (EO),
External Inquiries (EQ), Internal Logical Files (ILF), External Interface Files (EIF). 2) Classify complexity and apply
standard weights (example weights: EI 3/4/6, EO 4/5/7, etc.). 3) Sum to obtain Unadjusted Function Points (UFP).
4) Rate 14 General System Characteristics (GSC) to compute Value Adjustment Factor (VAF). 5) Adjusted FP =
UFP × VAF. Use historical productivity (hours/FP) to get effort. Mini example calculation: UFP=58, SumGSC=30
→ VAF=0.95 → Adjusted FP=55.1. At 10 hours/FP → ~551 person-hours.
Q2 a) What is the difference between COCOMO and COCOMO II Model?
Answer: COCOMO (1981) is a classic parametric model that estimates effort primarily from LOC and categorizes
projects by mode (organic, semidetached, embedded). It provides Basic, Intermediate and Detailed variants with
cost drivers and scale factors. COCOMO II extends and modernizes COCOMO for component-based,
object-oriented and iterative development. It includes multiple models (Application Composition, Early Design,
Post-Architecture), revised cost drivers, support for reuse and modern productivity factors. COCOMO II is more
adaptable to contemporary practices.
Q2 b) What is the necessity of Estimation? How estimation with Use-cases is
performed?
Answer: Necessity: Estimation is essential for decision-making, financing, staffing, and controlling project scope. It
supports risk management and stakeholder alignment. Use-case estimation process (detailed): • Identify all
use-cases and actors and document typical flows and transaction counts. • Classify each use-case as simple,
average, or complex (based on transaction count, screens, logic). • Assign weights to complexity classes and
compute Unadjusted Use Case Points (UUCP). • Identify technical and environmental factors (e.g., performance
requirements, team experience) and compute adjustment factors. • Apply adjustments to obtain Use Case Points
(UCP) and convert to effort using productivity (person-hours per UCP). This creates an early, requirement-level
estimate tied directly to functionality requested by stakeholders.
Q2 c) What is the need for defining a software scope? What are the categories of
software engineering resources (Project Resources)?
Answer: Defining scope prevents ambiguity about what is included in delivery, provides a baseline for change
control, and enables realistic estimates and schedules. Scope definition identifies features, constraints, exclusions
and acceptance criteria. Project resources categories (expanded): • Human: Developers, QA, UX, PM, architects,
support staff. • Software: Frameworks, libraries, third-party services, licensed tools. • Hardware: Servers, test
devices, developer machines and networking. • Infrastructure: CI/CD, monitoring, databases, cloud services. •
Documentation and knowledge: Requirement specs, design docs, training. • Financial: Budget, contingency,
procurement capacity.
Q3 a) Explain the following design concepts: i) Abstraction ii) Patterns iii) Modularity
Answer: Abstraction: Abstraction separates the 'what' from the 'how'. It lets designers express concepts
(interfaces, services) while hiding implementation. Abstraction reduces complexity, enables multiple
implementations and improves maintainability. Patterns: Design patterns capture proven solutions. They help
teams communicate designs succinctly and avoid common pitfalls. Patterns also guide structure (e.g., MVC for UI
separation) and interaction (e.g., Observer for event distributions). Modularity: Dividing a system into modules
reduces complexity, enables parallel work, and increases testability. Each module should have a single
responsibility and well-defined interfaces to other modules.
Q3 b) What is meant by coupling and cohesion. Explain these terms in relation with
good software design.
Answer: Cohesion describes the degree to which elements inside a module belong together. High cohesion
means focused responsibilities and easier maintenance. Coupling describes the degree of interdependence
between modules. Low coupling means fewer side effects when changing a module. Good design aims for high
cohesion and low coupling to maximize adaptability and minimize ripple effects of change.
Q3 c) What is the importance of software design? What are types of design classes?
Answer: Importance: Design translates requirements into a realizable architecture and components. It determines
non-functional qualities such as performance, security and modifiability. Good design improves delivery speed
over the lifetime of the product and reduces defect rates. Types of design classes: • Entity classes – domain data
and business objects. • Boundary classes – interface adapters (UI, APIs). • Control classes – orchestrate
use-cases and application flow. • Helper/utility classes – cross-cutting utilities. • Data access classes –
encapsulate persistence mechanisms.
Architectural Context (conceptual) [User] --> | System Boundary | --> [Third-Party API]
- User: interacts via UI/API - System Boundary: core services, data store - Third-Party
API: external integration
Q4 a) Explain in detail the Architectural design and Component level design elements.
Answer: Architectural design is concerned with the whole-system organization and key decisions that affect quality
attributes. It includes component identification, allocation of responsibilities, selection of architectural styles
(layered, microservices, event-driven), communication patterns, and mapping components to deployment nodes.
Important outputs are architecture views, deployment diagrams, and technology stack choices. Component-level
design delves into class and module internals: method algorithms, data structures, interface signatures, error
handling, and performance considerations. It ensures each component meets its responsibilities while honoring
system-wide constraints.
Q4 b) What is software Architecture? What is architectural context diagram?
Answer: Software architecture is the blueprint of the system describing elements, relationships and guiding
principles required to meet stakeholders' concerns. An architectural context diagram shows how the system fits
into its environment by displaying external actors, external systems and primary interfaces—helpful for clarifying
integration responsibilities and boundary conditions.
Q4 c) Write short note on ‘Interface analysis and design models’.
Answer: Interface analysis catalogs every touchpoint (UI screens, APIs, message formats, file exchanges) and
specifies protocols, data schemas, error handling and performance constraints. Design models to capture
interfaces include wireframes and flow diagrams for UI, API contracts (OpenAPI), sequence diagrams for
interactions, and message schema definitions for event-driven systems. Proper interface modeling reduces
integration errors and speeds development.
Q5 a) Briefly explain the steps involved in risk planning in project development.
Answer: Risk planning steps: 1) Identify risks using checklists, lessons learned and stakeholder input. 2) Analyze
risks qualitatively (likelihood and impact) and quantitatively (expected monetary value, schedule variance). 3)
Prioritize risks by exposure and criticality. 4) Plan responses: mitigate, transfer, accept, or avoid. 5) Assign owners
and triggers to take action. 6) Track risks and update plans as project evolves.
Q5 b) Describe with an example how the effect of risk on project schedule is evaluated
using PERT.
Answer: PERT technique uses optimistic (O), most likely (M) and pessimistic (P) estimates: TE = (O + 4M + P) / 6
Variance = ((P - O)/6)^2 To evaluate a risk, increase the pessimistic estimate or decrease the likelihood of the
optimistic estimate for affected tasks, then recalculate TE and recompute the critical path. This quantifies schedule
impact and helps decide contingency allocation. Example: Task has O=2d, M=4d, P=8d → TE=(2+16+8)/6=4.33d.
If a risk worsens P to 12d, TE becomes 5d, increasing overall project duration if that task lies on the critical path.
Q5 c) Explain Version Control and Change Control Layer in Software Configuration
Management in detail.
Answer: Version Control (VC): VC systems (e.g., Git) record the evolution of files and enable branching, merging,
tagging, and rollbacks. Key practices: commit frequently with meaningful messages, use branches for
features/fixes, perform code reviews and CI on merges, and tag releases for traceability. Change Control Layer:
This governance layer ensures that any change to baselined artifacts follows a controlled process: raise change
request, perform impact analysis, get approvals (CCB), schedule and implement changes under VC, and update
documentation. It prevents ad-hoc modifications that could destabilize releases and ensures auditability.
Q6 a) Discuss Software Configuration Management in detail.
Answer: Software Configuration Management (SCM) coordinates artifacts and processes to maintain integrity
across versions and environments. SCM components include configuration identification (what items are
controlled), version control (how changes are recorded), change control (how changes are authorized), build and
release management (how artifacts are assembled and delivered), configuration audit (ensuring conformance),
and status accounting (reports and baselines). Effective SCM reduces integration defects and supports
reproducible builds and deployments.
Q6 b) Define Software Risk in detail. What are different types of Software Risk?
Answer: Software risk is any uncertain event that could negatively affect project objectives. Risks have probability
and impact; both should be explicitly estimated. Types: • Technical: unproven tech, interfaces, performance. •
Requirements: volatile, ambiguous or missing requirements. • Schedule/Cost: unrealistic estimates, vendor
delays. • Organizational: resource turnover, shifting priorities. • External: legal/regulatory changes, third-party
failures. • Operational: deployment, maintenance and support risks. Each risk requires a tailored mitigation and
monitoring approach.
Q6 c) Discuss the RMMM plan in detail.
Answer: RMMM (Risk Mitigation, Monitoring and Management) is a proactive approach composed of: • Mitigation:
actions to reduce probability or impact (prototyping, architecture spikes, extra testing). • Contingency: fallback
plans and reserved time/budget if mitigation fails. • Monitoring: regular review of risk indicators and thresholds. •
Management: assign owners, triggers, and ensure responses are executed when needed. The RMMM should be
part of project artifacts and updated across the lifecycle.
RMMM Flow: [Identify] --> [Analyze/Prioritize] --> [Mitigate] --> [Monitor] -->
[Execute Contingency if triggered]
Q7 a) What are the guidelines those lead to a successful software testing strategy?
Answer: Effective testing strategy guidelines: - Start early and integrate testing into development (shift-left). -
Focus on high-risk and high-value features first. - Automate regression, smoke and CI tests. - Use both functional
(black-box) and structural (white-box) techniques. - Maintain test data, environments and test Harness. - Track
metrics and continuously improve the test process. - Ensure traceability between requirements and test cases.
Q7 b) What is meant by integration testing? Explain top down and bottom up integration
testing.
Answer: Integration testing validates interactions between modules. Top-down integration begins with top-level
modules and stubs simulate lower-level modules; it verifies control flow and architectural decisions early.
Bottom-up integration starts with low-level modules and uses drivers to simulate higher-level modules; it validates
utilities and services early. Hybrid approaches (sandwich/incremental) combine both to speed integration.
Q7 c) What is the difference between verification and validation?
Answer: Verification: ensures the product is built according to design/specifications (reviews, static analysis, unit
tests). Validation: ensures the final product satisfies user needs and intended use (system testing, UAT).
Verification is correctness to spec; validation is suitability for purpose.
Q8 a) Differentiate between black box testing and white box testing.
Answer: Black-box testing tests the functional behavior from the user's perspective without looking at internals;
test cases derive from requirements. White-box testing requires knowledge of the internal code structure and tests
paths, conditions and data flows to achieve coverage goals.
Q8 b) Explain how Object oriented software testing is different from conventional
software testing.
Answer: OO testing emphasizes class behavior, object state and interactions. It must handle inheritance,
polymorphism and dynamic dispatch; therefore test strategies include class-level unit tests, state transition tests,
and testing polymorphic behavior across subclass hierarchies. Conventional (procedural) testing focuses more on
function inputs/outputs and control flow.
Q8 c) Explain Unit Testing and Integration Testing with respect to the Object Oriented
Context.
Answer: Unit testing (OO): target individual classes and methods, using mocks or fakes for collaborator objects,
verifying state changes and method contracts. Integration testing (OO): test collaborations, message interactions,
sequence flows and combined behavior across objects, including inheritance and polymorphism scenarios.