Software Development Lifecycle, Design, and Testing

Posted on Apr 2, 2025 in Business Administration and Innovation Management

Q1. What is SDLC? Steps and Waterfall Model Limitations

The Software Development Life Cycle (SDLC) is a process used to design, develop, and test high-quality software. It aims to produce software that meets or exceeds customer expectations, within time and cost estimates. The SDLC is a detailed plan describing how to develop, maintain, replace, alter, or enhance specific software. It defines a methodology for improving software quality and the overall development process.

SDLC Stages

1. Planning and Requirement Analysis
2. Defining Requirements
3. Designing the Product Architecture
4. Building or Developing the Product
5. Testing the Product
6. Deployment in the Market and Maintenance

Limitations of the Waterfall Model

The waterfall model’s main disadvantage is its inflexibility. Once an application is in testing, it’s difficult to revisit and change earlier decisions. Key disadvantages include:

• Late production of working software
• High risk and uncertainty
• Unsuitability for complex and object-oriented projects
• Unsuitability for long and ongoing projects
• Difficulty measuring progress within stages
• Inability to accommodate changing requirements
• Scope adjustments can terminate the project

Q2. Advantages of Object-Oriented Design (OOD)

OOD offers several benefits:

1. Easy to understand
2. Easy to maintain, increasing its popularity
3. Promotes reusability
4. Reduces development time and cost
5. Improves system quality through program reuse
6. Increased productivity

Q3. Different Views of UML Diagrams

UML diagrams offer various perspectives:

User Model View (Use Case View)

Defines the solution from the client’s or stakeholder’s perspective. Key diagram: Use Case Diagram.

Structural View (Static/Logical View)

Provides the static structural dimensions of the system. Key diagrams: Class Diagrams, Object Diagrams.

Behavioral Model View (Dynamic View)

Describes the system’s behavioral and dynamic aspects. Key diagrams: Sequence Diagram, Collaboration Diagrams, State Diagrams, Activity Diagrams.

Implementation View (Component View)

Combines structural and behavioral dimensions of the solution’s implementation. Key diagram: Component Diagram.

Environment Model View (Deployment View)

Describes the structural and behavioral dimensions of the solution’s environment. Key diagram: Deployment Diagram.

Q4. What is a Data Flow Diagram (DFD)?

A DFD graphically represents data flow within an information system, showing incoming, outgoing, and stored data. It doesn’t specify how data flows but focuses on what data flows. Unlike flowcharts, which depict control flow in program modules, DFDs depict data flow at various levels without control or branch elements.

Q5. What is a Data Dictionary?

A data dictionary is a centralized repository of information about data. It stores the meaning, origin, relationships, and format of data. It provides rigorous definitions to aid users and software designers. Often called a meta-data repository, it’s created alongside DFDs and updated with any DFD changes.

Q6. Importance of Data Dictionary in Software Development

A data dictionary helps developers understand data items, their structure, possible values, and real-world meaning. It ensures consistency and clarity in data usage. Key functions include:

1. Defining data elements
2. Aiding scheduling
3. Facilitating control
4. Informing users about available data
5. Identifying data irregularities

Q7. What is the COCOMO Model?

The Constructive Cost Model (COCOMO) is an algorithmic software cost estimation model. It uses a regression formula with parameters derived from historical data and current project characteristics. COCOMO has three levels of detail: Basic, Intermediate, and Detailed.

Q8. COCOMO Project Types

COCOMO categorizes projects into three classes:

• Organic: Small teams with good experience and less rigid requirements.
• Semi-detached: Medium teams with mixed experience and a mix of rigid and flexible requirements.
• Embedded: Developed under tight constraints (hardware, software, operational).

Q9. COCOMO Example: Effort and Development Time

For a 32,000-line organic software product:

Effort = 2.4 * (32^1.05) = 91 PM (Person-Months)

Nominal Development Time = 2.5 * (91^0.38) = 14 months

Q10. Utility of PERT Charts

PERT (Program Evaluation and Review Technique) charts help project managers evaluate time and resources, track assets, incorporate cross-departmental data, improve communication, and perform what-if analysis. Benefits include drag-and-drop functionality, automatic calculations, integration capabilities, pre-built templates, and version control.

Q11. Software Validation vs. Verification

Q12. Generalization vs. Specialization

Generalization

Combines entities with similar properties into a generalized entity. For example, pigeon, sparrow, crow, and dove generalize into “Birds.”

Specialization

Divides a group of entities into subgroups based on their characteristics. For example, “Person” can specialize into employee, employer, customer, or vendor.

Q13. Components of an SRS Document

A Software Requirements Specification (SRS) document should contain:

Functional Requirements

Specify the desired output for given inputs, describing the input-output relationship.

Performance Requirements

Specify performance constraints, such as transactions per second or response time.

Design Constraints

Specify limitations imposed by the client environment, such as standards compliance or resource limits.

External Interface Requirements

Specify interactions with people, hardware, and other software, including logical characteristics and hardware interfaces.

Q14. Black-Box Testing vs. White-Box Testing

Q15. Alpha Testing vs. Beta Testing

Q16. Software Quality and Reliability

Software quality comprises functional quality (conformance to requirements) and structural quality (meeting non-functional requirements like robustness and maintainability).

Software reliability, a crucial aspect of quality, is the probability of failure-free operation. It’s objective and measurable, unlike many subjective quality criteria.

Q17. Software Reliability Metrics

Metrics improve reliability by identifying issues in requirements, coding, and testing. Categories include:

• Requirements reliability metrics (validity, thoroughness, clarity)
• Design and code reliability metrics (complexity, size, modularity)
• Testing reliability metrics (functional completeness, error detection and correction)

Four broad categories of measurement exist: product metrics, project management metrics, process metrics, and fault/failure metrics.

Q18. McCall’s Quality Model

McCall’s model addresses software quality through three perspectives:

• Product Revision: Maintainability, flexibility, testability.
• Product Transition: Portability, reusability, interoperability.
• Product Operations: Correctness, reliability, efficiency, integrity, usability.

Q19. Cyclomatic Complexity

Cyclomatic complexity measures code complexity and correlates with coding errors. It counts linearly independent paths through a module. Lower complexity means lower modification risk and easier understanding. The formula is M = E – N + 2P, where M is complexity, E is edges, N is nodes, and P is connected components.

Short Notes

Structured Chart: A detailed, hierarchical representation of system modules and their functions, derived from DFDs.

Software Reliability: Probability of failure-free operation, an objective and measurable aspect of software quality.

Decision Table: Tabular representation of conditions and corresponding actions.

Decision Tree: Graphical representation of possible decision outcomes using a branching method.

Software Quality: Encompasses functional quality (meeting requirements) and structural quality (meeting non-functional requirements).

Integration Testing: Testing combined software modules as a group.

Regression Testing: Verifying that changes haven’t introduced new bugs or regressions.

Recoverability Testing: Testing an application’s ability to recover from crashes or failures.