CS 385 T Software Engineering
Tutorial 3 SWPM
1. Specify whether the following statements are applicable to plan-driven, agile, or both:
a) All the process activities are planned in advance. ( plan-driven )
b) planning is incremental. ( agile )
c) Easier to change the process. ( agile )
d) Progress is measured against this plan. ( plan-driven )
e) Incremental development may be: ( both )
f) Waterfall model is an example of: ( plan-driven )
g) Integration and configuration my be: ( both )
2. Give an advantage and a disadvantage for each of the following process models:
ADVANTAGES DISADVANTAGES
1. The plan-driven nature of the waterfall 1. Difficulty of accommodating change after
model helps coordinate the work. the process is underway.
Waterfall 2. Detailed and complete documentation: Each 2. Users are only involved in the
model phase typically involves thorough requirements phase.
documentation, ensuring consistency
throughout the project.
1. The cost of accommodating changing 1. Skipping detailed docs for fast development
customer requirements is reduced. creates a blind spot for managers who need
2. It is easier to get customer feedback on the progress markers.
Incremental
development work that has been done. 2. System structure tends to degrade as new
model 3. More rapid delivery and deployment of increments are added.
useful software to the customer is possible.
1. Requirements compromises are inevitable
1. Reduced costs and risks as less software is
Integration and so system may not meet real needs of
developed from scratch.
configuration users.
2. Faster delivery and deployment of system
model 2. Loss of control over evolution of reused
system elements.
3. Choose the most suitable process model(s) from the following (Incremental, Waterfall, Integration and
configuration). Also, specify when it is necessary to include prototyping during the requirements phase.
a. The project team developing a new system is experienced in the domain. Although the new project is fairly
large, it is not expected to vary much from applications that have been developed by this team in the past.
Waterfall
b. This model is mostly used for large systems engineering projects where a system is developed at several sites.
Waterfall
c. In this process model, customers can comment on demonstrations of the software and see how much has been
implemented. Incremental
1
Tutorial 3
d. The developing organization is quite familiar with the problem domain and the requirements for the software
are clear. Waterfall
e. The system is novel (new); the client wants to get an actual feel of the system as soon as possible.
Incremental+ prototype
f. A small company would like to improve the services offered to existing clients and increase its client base by
replacing existing call centre and paper-based mailshots, with online web technology deployment by reusing
commercial of the shelf systems. Integration and Configuration
g. A system whose requirements can be relatively easily identified and are stable. Waterfall
h. A system is being developed where the customers are not sure of what they want, the requirements are often
poorly defined. Prototype+ Incremental
4. Give reason for your answer based on type of system being developed; suggest the most appropriate generic
software process model that might be used as basic for managing the development of the following systems:
a. A system to control espresso machine.
Waterfall model: the requirements are clear.
b. An Android Auto satellite navigation system for a new car model
Integration and Configuration. Developing a complex system like a car's navigation unit from
scratch is expensive and risky. It's much more practical to use a reusable components approach.
The system would be built by integrating existing components, such as a GPS module, and a
mapping database.
c. A university accounting system that replaces an existing system.
If the accounting system is reused system >> Integration and configuration model
If the accounting system will build from scratch >> Waterfall model (with full
functionality)
d. Website to show products.
Mix of Integration and Configuration, and Incremental models:
Incremental: To reflect specific customer requirements.
Integration and Configuration: Use web service to enhance and ensure better quality of the
services.
e. An Interactive Educational Game for Children
Incremental: delivers playable versions early for testing and feedback .
2
Tutorial 3
5. Explain why a software system that is used in the real-world environment must change or become possibly
less useful.
Systems need updates to keep up with:
1. New tools and technology: Things are changing fast, so systems need to adapt.
2. Mistakes and problems: We need to fix any glitches or issues that pop up.
3. Security dangers: Systems have to stay ahead of anyone who might try to harm or attack them
6. Defects are expected in all software process phases: Do you think that defects in requirement stage more
dangerous than any other phase? Prove your answer?
Yes, a defect in the requirements stage can cause defects in all of the subsequent stages of the software
development process.
7. Consider the Integration and configuration model. Explain why it is essential to have two separate
requirements engineering activities in the process?
In the Integration and Configuration model, we cannot just write the requirements once and leave them. Since we
are reusing existing components, we need two steps.
First, we write the initial requirements. At this stage we capture what the users want and what the system should
do in general, without worrying yet about what components are available.
Second, we refine the requirements. After we look at existing components, we may find they do not exactly match
the original needs. At this point we adjust the requirements to fit what those components can actually do, or we
look for alternatives.
In simple terms, the first stage is about what users want, and the second stage is about what is realistic with
reusable parts. Both are necessary to make sure the final system is useful while still taking advantage of reuse.
8. Give two reasons why prototypes should be discarded after development:
1. It may be impossible to tune the system to meet non-functional requirements.
2. Prototypes are normally undocumented.
3. The prototype structure is usually degraded through rapid change.
4. The prototype probably will not meet normal organisational quality standards.
9. State whether the following statements are true (T) or false (F)
a. Software design is to translate a software structure into an executable program. ( F )
b. Elicitation, specification, and validation are requirements engineering processes. ( T )
c. Requirement and implementation are closely related and may be inter-leaved. ( F )
3
Tutorial 3
d. Component testing is testing of the system as a whole. ( F )
e. Architectural design involves identify the overall structure of the system. ( T )
10. A small, private medical clinic wants to switch from a paper-based patient records system to a digital one. The
medical staff has limited experience with modern EMR (Electronic Medical Record) systems. The development
team decides to use prototyping to build an early version of the system to get direct feedback from the medical
staff.
Based on this scenario, what aspects should the development team consider for inclusion in the prototype, and
what aspects might they intentionally leave out? Explain the reasoning for each choice.
Aspects to Include in the Prototype
- The user interface (UI): The team would create a working UI for the most critical workflows. The text
emphasizes that prototypes are the "only sensible way to develop user interfaces" when textual descriptions
are insufficient.
- Key functionalities: The prototype would include the core functions of patient registration and basic
record access. This allows the staff to see how the system "supports their work" and to validate the initial
requirements.
Aspects to Leave Out
- Advanced or non-critical features: They would not include complex features like billing and insurance
processing, which are not essential for the initial validation of the core workflow.
- Robust error handling: The prototype wouldn't have a sophisticated system for handling every possible
error.
- High performance and security: The prototype doesn't need to be fast or fully secure.
4
Tutorial 3