FAQ on Software Engineering (Set 4)
Question 1
Explain the concept of Software Engineering and its significance in doing Software Development.
- Software engineering is the systematic, disciplined, and quantifiable approach to the design, development, testing, and maintenance of software.
- It applies engineering principles to the software creation process to ensure that the final product is reliable, efficient, and meets user requirements.
- Software development is the actual creation of software, which involves tasks like coding, debugging, and testing.
- While software development is a key part of software engineering, it is not the whole picture.
- Software engineering provides the framework and methodology to guide and manage the entire software development life cycle, from initial concept to final delivery and beyond.
- Software engineering is crucial for software development, especially for large, complex projects, because it introduces structure and discipline.
- Without it, software development can be an unstructured, inefficient, and often chaotic process
Question 2
Analyse the performance of Waterfall Model and its limitations.
- The Waterfall Model is a traditional, linear, and sequential software development process.
- Like a real waterfall, it flows downward through distinct phases: requirements analysis, system design, implementation (coding), testing, deployment, and maintenance.
- Software Engineers must complete each phase before they can begin the next, with no overlap between them.
- This approach is highly structured, easy to understand, and relies on extensive upfront planning.
The Waterfall Model's performance is strongest in specific scenarios, primarily due to its rigid structure.
- Predictability and Control: With all requirements documented and a detailed plan created at the beginning, the project's timeline and budget are highly predictable. This makes it easier for project managers to track progress and for stakeholders to know what to expect and when.
- Clear Documentation and Structure: Each phase has specific deliverable and well-defined milestones. This results in thorough documentation that is easy for new team members to understand and use, which can be particularly useful for long-term maintenance.
While its rigidity is a strength in some cases, it's also the Waterfall Model's biggest weakness in most modern software development environments.
- Lack of Flexibility: This is the most significant limitation. If requirements change or a new need arises after a phase is completed, it's extremely difficult, costly, and time-consuming to go back and make changes. It essentially means starting over or causing major disruptions.
- Late Bug Detection: Testing is a late phase, occurring only after all the code has been written. This means that any design flaws or errors from earlier stages are not discovered until a large amount of work has already been completed, making them difficult and expensive to fix.
Question 3
What are myths in software development? Identify the software myths related to management and practitioners.
- Software myths are common, but often false, beliefs about the software development process.
- They arise from a lack of knowledge, an outdated understanding of the industry, or unrealistic expectations.
- These misconceptions can lead to poor decision-making, project failures, and a great deal of frustration for everyone involved.
- These myths are often held by managers, customers, and other stakeholders who are responsible for the business and strategic side of a project.
- They stem from a desire for control and predictability in a process that is often complex and unpredictable.
- This is false. Quality can and should be evaluated at every stage of the software development life cycle, from requirements analysis to design and coding.
- Formal technical reviews, for example, can catch errors and flaws early, when they're much easier and cheaper to fix.
- While outsourcing can be cost-effective, it introduces new challenges like communication barriers, time zone differences, and potential quality control issues.
- Without strong management and clear contracts, these issues can lead to unexpected costs and project delays, making the outsourced project more expensive than an in-house one.
- These myths are commonly held by software developers and engineers themselves.
- They often relate to the day-to-day work of coding and a misunderstanding of the broader software development process.
- A practitioner's work is far from over when the code is released.
- The majority of a software's life cycle is spent in the maintenance phase, which includes fixing bugs, adapting to new environments, and adding new features.
- This myth oversimplifies the developer's role.
- In reality, practitioners spend a significant amount of time on non-coding tasks, such as gathering requirements, designing architecture, writing documentation, and testing.
- Effective software development is a multi-faceted process that requires a range of skills beyond just programming.
- This is a dangerous myth. Important deliverable like design documents, test plans, and user manuals are essential for a project's long-term success.
- Without proper documentation, the software becomes very difficult to maintain and understand for future developers.
Question 4
What are the advantages of iterative development? Compare iterative development with incremental delivery approach.
- Iterative development is an approach to software development where a system is built and refined through repeated cycles, or iterations.
- Instead of a single, linear process, you start with a simple, incomplete version of the software and then iteratively add features and improve upon it until the final, complete product is ready.
- This model is highly flexible and well-suited for projects with unclear or changing requirements.
- Early Risk Identification: By developing a working prototype early on, teams can identify and address potential risks and issues (like design flaws or technical challenges) much sooner than in a linear model.
- Flexibility and Adaptability: This approach allows for changes in requirements to be incorporated easily in subsequent iterations.
This is critical in dynamic environments where customer feedback or market demands evolve. - Customer Involvement: Users and stakeholders can provide feedback on a working prototype after each iteration.
This continuous feedback loop ensures the final product meets their needs and increases customer satisfaction. - Faster Time-to-Market: Although the full product isn't released at once, a basic, working version can be delivered quickly, allowing the business to get a product to market and start getting value sooner.
- Improved Quality: With each cycle, the team learns from previous iterations, allowing them to refine the design, fix bugs, and improve the overall quality of the software.
While the terms "iterative" and "incremental" are often used together, they represent distinct concepts.
Question 5
What is Requirements Analysis? Explain various steps involved in it with illustration.
- Requirements Analysis is a crucial step in Requirements Engineering that focuses on understanding, documenting, and managing the needs and expectations for a new or modified system.
- The main goal of Requirements Analysis is to create a complete and accurate representation of all requirements before design and development begin, ensuring the final product meets the customer's needs and business goals.
- Once requirements are gathered, this step focuses on analyzing them to ensure they are clear, complete, consistent, and feasible. This involves the following:
- Functional Requirements: What the system must do. (e.g., "The system shall allow users to create a new account.")
- Non-Functional Requirements: How the system should perform. These are quality attributes. (e.g., "The website must load in under 3 seconds on a standard broadband connection.")
- Use Case Diagrams: Illustrating how different users will interact with the system.
- Data Flow Diagrams (DFDs): Showing the flow of information through the system.
- User Stories: Short, simple descriptions of a feature told from the perspective of the user. (e.g., "As a customer, I want to add an item to my cart so I can purchase it.")
- For the online store, the analyst would identify functional requirements like "The system must process credit card payments" and non-functional requirements like "The payment processing must be secure and encrypted."
- They would then create a use case diagram showing the "Customer" actor interacting with functions like "Browse Products," "Add to Cart," and "Checkout."